p4-apps@lists.p4.org

P4 Applications Working Group

View all threads

Re: [P4-Apps] 10/9 meeting notes

LJ
Lee, Jeongkeun
Thu, Nov 5, 2020 12:17 AM

For some reason, Jonathan's message below was not posted to the mailing.

For the next meeting (11/12), I suggest we collect the use cases for public domain IDs, and derive concrete ideas to carve out and manage those IDs.

Thanks!
JK


From: Stone, Jonathan jonathan.stone@intel.com
Sent: Wednesday, October 21, 2020 6:13 PM
To: Lee, Jeongkeun jk.lee@intel.com; p4-apps@lists.p4.org p4-apps@lists.p4.org
Subject: Re: [P4-Apps] 10/9 meeting notes

Here is one suggestion for carving up the DsId space:

  • reserve the upper half for future use
  • Reserve the first 4096 DsId values for "public p4" use.  These effectively give the WG another 64k "instruction bits", which the community can use as for the "standard" instruction bits. Senders are not required to implement these DsIds, but may choose to do so. Receivers which implement the full INT spec, are expected to implement these DsIds, as any interoperable sender may choose to use them.
  • Leave a large gap ( 4k values?)
  • Reserve the next 4k DsId values for "public private": privately-defined DsIDs. IDs in this range have a public spec, but it's up to each collector implementor whether to implement them, or not.  (I think of these as "experimental")
  • Leave another large gap (4k values?)
  • Reserve the next 4k for "truly private".  These IDs have no public definition, and are usable only within an INT domain where all devices and collector(s) agree out-of-band on the meaning of these bits.

The "gaps" are so that we can grow any of the three classes, while keeping the range of each class contiguous.  That leaves another 4K at the end, plus the upper half of the range.


From: P4-apps p4-apps-bounces@lists.p4.org on behalf of Lee, Jeongkeun jk.lee@intel.com
Sent: Wednesday, October 21, 2020 5:44 PM
To: p4-apps@lists.p4.org p4-apps@lists.p4.org
Subject: [P4-Apps] 10/9 meeting notes

<> Application library

Questions from the prev meeting:

Q1. what if the app requires a modification of Barefoot switch.p4, which is not open? A patch to switch.p4 can be shared?

A: having public version of switch.p4 and APIs is under discussion. Till then, we start from apps that don’t require switch.p4 integration.

Q2. What about non-p4 apps, such as INT implementation in DPDK or eBPF under a license different from Apache2 that P4.org uses?

A: we start from apps under Apache2.

Candidate apps to host in the library:

Princeton Cabernet projects: https://github.com/Princeton-Cabernet/

SwitchML: in-network ML training acceleration. https://arxiv.org/abs/1903.06701

INT implementation in ONF repo: add pointers to them

AIs:

bring the license issue to P4 TST.

  • JK creates a PR of template to submit a p4 app: documents and code directory structure.

<> SwitchML talk
Amedeo Sapio gave a talk on SwitchML, which will be open-sourced in Apps library soon.

<> BUM (Broadcast, Unknown unicast and Multicast) traffic handling in INT

Key questions: duplicate INT per egress bcast/mcast copy? Distinguish each branch/copy as a new flow or not? More issue with MD, less with MX.

Consensus: every copy carries metadata, but policy-specific. E.g., only for mcast not for bcast or unknown unicast.

Issue: tree ID is vendor specific.

We agreed that BUM handling varies and is implementation specific, not easy to define one way everyone has to follow. In the future, INT spec might capture per-switch branch ID metadata.

<> INT UDP port number

IANA declined the request to assign a UDP dest port number for INT. The main reason from IANA is that INT is deployed in confined/controlled environments rather than Internet. A port from the dynamic range can be selected and used by each INT domain (similar to VLAN assignment). IANA would assign a port number if INT is to be deployed in the Internet, but then INT must handle e2e security, congestion control as required for any new UDP transport services. Although INT-UDP is an infra tunnel service, the INT encap/decap points are considered as end-hosts generating and consuming the new UDP traffic from IANA's point of view.

Members agreed that this is not a blocker in using UDP-based INT encap.

AI: update the spec re: the UDP port number assignment.

<> INT UDP encap with IPSEC

When we want INT outside of IPSEC:

OuterIP-UDP-INT-InnerIP-AH/ESP

example: https://github.com/p4lang/p4-applications/pull/90/files

If INT is purely edge to edge (only btw end-hosts or vswitches, excluding fabric switches),

INT can come inner of IPSEC AH or ESP.

e.g., IP-AH/ESP-UDP-INT-...

<> new PR: Telemetry Report: Support packet fragments longer than 1020 bytes

https://github.com/p4lang/p4-applications/pull/89

AI: review PR

<> INT domain ID concept and management
Domain ID goal: maps a set of domain-specific instructions to their format and semantics

Who participates in a domain is a business decision between vendors and operators. Some Domain Specific (DS) instructions may be published, others may stay private or shared between participants in a private channel.

3 unique roles around domain ID are discussed.

Who are the producers of domain IDs (and DS instructions)? Implementors of INT devices. Vendors (SW/HW), or network/system owners with DevOps capabilities on programmable dataplanes.

Who do consume domain IDs? parsers of the DS instructions and metadata. Either public, or private the parser is part of the domain. Examples: collector that analyzes the telemetry reports and generate high-level information. Pkt dissector such as wireshark parser can be implemented based on public or private DS definitions. INT transit/sink devices that execute the instructions populated by INT source.

Network admin: configures collector/transit/sink devices to understand the ID->instruction mapping.

A large network owner w/ devops may play all three 3 roles.

Discussion to be continued in the next meeting, topics including

  • IANA registry for INT domain IDs.
  • A set of public, P4-official domain IDs may need to be reserved. A concrete use case needs more discussion.

The next meeting is tentatively planned for 10/29 Thursday.

Thanks,
JK

For some reason, Jonathan's message below was not posted to the mailing. For the next meeting (11/12), I suggest we collect the use cases for public domain IDs, and derive concrete ideas to carve out and manage those IDs. Thanks! JK ________________________________ From: Stone, Jonathan <jonathan.stone@intel.com> Sent: Wednesday, October 21, 2020 6:13 PM To: Lee, Jeongkeun <jk.lee@intel.com>; p4-apps@lists.p4.org <p4-apps@lists.p4.org> Subject: Re: [P4-Apps] 10/9 meeting notes Here is one suggestion for carving up the DsId space: * reserve the upper half for future use * Reserve the first 4096 DsId values for "public p4" use. These effectively give the WG another 64k "instruction bits", which the community can use as for the "standard" instruction bits. Senders are not required to implement these DsIds, but may choose to do so. Receivers which implement the full INT spec, are expected to implement these DsIds, as any interoperable sender may choose to use them. * Leave a large gap ( 4k values?) * Reserve the next 4k DsId values for "public private": privately-defined DsIDs. IDs in this range have a public spec, but it's up to each collector implementor whether to implement them, or not. (I think of these as "experimental") * Leave another large gap (4k values?) * Reserve the next 4k for "truly private". These IDs have no public definition, and are usable only within an INT domain where all devices and collector(s) agree out-of-band on the meaning of these bits. The "gaps" are so that we can grow any of the three classes, while keeping the range of each class contiguous. That leaves another 4K at the end, plus the upper half of the range. ________________________________ From: P4-apps <p4-apps-bounces@lists.p4.org> on behalf of Lee, Jeongkeun <jk.lee@intel.com> Sent: Wednesday, October 21, 2020 5:44 PM To: p4-apps@lists.p4.org <p4-apps@lists.p4.org> Subject: [P4-Apps] 10/9 meeting notes <> Application library Questions from the prev meeting: Q1. what if the app requires a modification of Barefoot switch.p4, which is not open? A patch to switch.p4 can be shared? A: having public version of switch.p4 and APIs is under discussion. Till then, we start from apps that don’t require switch.p4 integration. Q2. What about non-p4 apps, such as INT implementation in DPDK or eBPF under a license different from Apache2 that P4.org uses? A: we start from apps under Apache2. Candidate apps to host in the library: * Princeton Cabernet projects: https://github.com/Princeton-Cabernet/ * SwitchML: in-network ML training acceleration. https://arxiv.org/abs/1903.06701 * INT implementation in ONF repo: add pointers to them AIs: * bring the license issue to P4 TST. * JK creates a PR of template to submit a p4 app: documents and code directory structure. <> SwitchML talk Amedeo Sapio gave a talk on SwitchML, which will be open-sourced in Apps library soon. <> BUM (Broadcast, Unknown unicast and Multicast) traffic handling in INT Key questions: duplicate INT per egress bcast/mcast copy? Distinguish each branch/copy as a new flow or not? More issue with MD, less with MX. Consensus: every copy carries metadata, but policy-specific. E.g., only for mcast not for bcast or unknown unicast. Issue: tree ID is vendor specific. We agreed that BUM handling varies and is implementation specific, not easy to define one way everyone has to follow. In the future, INT spec might capture per-switch branch ID metadata. <> INT UDP port number IANA declined the request to assign a UDP dest port number for INT. The main reason from IANA is that INT is deployed in confined/controlled environments rather than Internet. A port from the dynamic range can be selected and used by each INT domain (similar to VLAN assignment). IANA would assign a port number if INT is to be deployed in the Internet, but then INT must handle e2e security, congestion control as required for any new UDP transport services. Although INT-UDP is an infra tunnel service, the INT encap/decap points are considered as end-hosts generating and consuming the new UDP traffic from IANA's point of view. Members agreed that this is not a blocker in using UDP-based INT encap. AI: update the spec re: the UDP port number assignment. <> INT UDP encap with IPSEC When we want INT outside of IPSEC: OuterIP-UDP-INT-InnerIP-AH/ESP example: https://github.com/p4lang/p4-applications/pull/90/files If INT is purely edge to edge (only btw end-hosts or vswitches, excluding fabric switches), INT can come inner of IPSEC AH or ESP. e.g., IP-AH/ESP-UDP-INT-... <> new PR: Telemetry Report: Support packet fragments longer than 1020 bytes https://github.com/p4lang/p4-applications/pull/89 AI: review PR <> INT domain ID concept and management Domain ID goal: maps a set of domain-specific instructions to their format and semantics Who participates in a domain is a business decision between vendors and operators. Some Domain Specific (DS) instructions may be published, others may stay private or shared between participants in a private channel. 3 unique roles around domain ID are discussed. * Who are the producers of domain IDs (and DS instructions)? Implementors of INT devices. Vendors (SW/HW), or network/system owners with DevOps capabilities on programmable dataplanes. * Who do consume domain IDs? parsers of the DS instructions and metadata. Either public, or private the parser is part of the domain. Examples: collector that analyzes the telemetry reports and generate high-level information. Pkt dissector such as wireshark parser can be implemented based on public or private DS definitions. INT transit/sink devices that execute the instructions populated by INT source. * Network admin: configures collector/transit/sink devices to understand the ID->instruction mapping. A large network owner w/ devops may play all three 3 roles. Discussion to be continued in the next meeting, topics including * IANA registry for INT domain IDs. * A set of public, P4-official domain IDs may need to be reserved. A concrete use case needs more discussion. The next meeting is tentatively planned for 10/29 Thursday. Thanks, JK
OM
Orr, Michael
Sun, Nov 8, 2020 4:26 AM

I support Jonathan's proposal.

From: P4-apps p4-apps-bounces@lists.p4.org On Behalf Of Lee, Jeongkeun
Sent: Wednesday, November 4, 2020 4:18 PM
To: Stone, Jonathan jonathan.stone@intel.com; p4-apps@lists.p4.org
Subject: Re: [P4-Apps] 10/9 meeting notes

For some reason, Jonathan's message below was not posted to the mailing.

For the next meeting (11/12), I suggest we collect the use cases for public domain IDs, and derive concrete ideas to carve out and manage those IDs.

Thanks!
JK


From: Stone, Jonathan jonathan.stone@intel.com
Sent: Wednesday, October 21, 2020 6:13 PM
To: Lee, Jeongkeun jk.lee@intel.com; p4-apps@lists.p4.org p4-apps@lists.p4.org
Subject: Re: [P4-Apps] 10/9 meeting notes

Here is one suggestion for carving up the DsId space:

  • reserve the upper half for future use

  • Reserve the first 4096 DsId values for "public p4" use.  These effectively give the WG another 64k "instruction bits", which the community can use as for the "standard" instruction bits. Senders are not required to implement these DsIds, but may choose to do so. Receivers which implement the full INT spec, are expected to implement these DsIds, as any interoperable sender may choose to use them.

  • Leave a large gap ( 4k values?)

  • Reserve the next 4k DsId values for "public private": privately-defined DsIDs. IDs in this range have a public spec, but it's up to each collector implementor whether to implement them, or not.  (I think of these as "experimental")

  • Leave another large gap (4k values?)

  • Reserve the next 4k for "truly private".  These IDs have no public definition, and are usable only within an INT domain where all devices and collector(s) agree out-of-band on the meaning of these bits.
    The "gaps" are so that we can grow any of the three classes, while keeping the range of each class contiguous.  That leaves another 4K at the end, plus the upper half of the range.


From: P4-apps p4-apps-bounces@lists.p4.org on behalf of Lee, Jeongkeun jk.lee@intel.com
Sent: Wednesday, October 21, 2020 5:44 PM
To: p4-apps@lists.p4.org p4-apps@lists.p4.org
Subject: [P4-Apps] 10/9 meeting notes

<> Application library

Questions from the prev meeting:

Q1. what if the app requires a modification of Barefoot switch.p4, which is not open? A patch to switch.p4 can be shared?

A: having public version of switch.p4 and APIs is under discussion. Till then, we start from apps that

don't require switch.p4 integration.

Q2. What about non-p4 apps, such as INT implementation in DPDK or eBPF under a license different from

Apache2 that P4.org uses?

A: we start from apps under Apache2.

Candidate

apps to host in the library:

AIs:

  • bring

  • the license issue to P4 TST.

  • JK

  • creates a PR of template to submit a p4 app: documents and code directory structure.

<> SwitchML talk
Amedeo Sapio gave a talk on SwitchML, which will be open-sourced in Apps library soon.

<> BUM (Broadcast, Unknown unicast and Multicast) traffic handling in INT

Key questions: duplicate INT per egress bcast/mcast copy? Distinguish each branch/copy as a new flow

or not?

More issue with MD, less with MX.

Consensus: every copy carries metadata, but policy-specific. E.g., only for mcast not for bcast or

unknown unicast.

Issue: tree ID is vendor specific.

We

agreed that BUM handling varies and is implementation specific, not easy to define one way everyone has to follow. In the future,

INT spec might capture per-switch branch ID metadata.

<> INT UDP port number

IANA declined the request to assign a UDP dest port number for INT. The main reason from IANA is that

INT is deployed in confined/controlled environments rather than Internet. A port from the dynamic range can be selected and used by each INT domain (similar to VLAN assignment). IANA would assign a port number if INT is to be deployed in the Internet, but

then INT must handle e2e security, congestion control as required for any new UDP transport services. Although INT-UDP is an infra tunnel service, the INT encap/decap points are considered as end-hosts generating and consuming the new UDP traffic from IANA's

point of view.

Members agreed that this is not a blocker in using UDP-based INT encap.

AI: update the spec re: the UDP port number assignment.

<> INT UDP encap with IPSEC

When we want INT outside of IPSEC:

OuterIP-UDP-INT-InnerIP-AH/ESP

example:

https://github.com/p4lang/p4-applications/pull/90/files

If INT is purely edge to edge (only btw end-hosts or vswitches, excluding fabric switches),

INT can come inner of IPSEC AH or ESP.

e.g.,

IP-AH/ESP-UDP-INT-...

<> new PR: Telemetry Report: Support packet fragments longer than 1020 bytes

https://github.com/p4lang/p4-applications/pull/89

AI: review PR

<> INT domain ID concept and management
Domain ID goal: maps a set of domain-specific instructions to their format and semantics

Who

participates in a domain is a business decision between vendors and operators. Some Domain Specific (DS) instructions may be published, others may stay private or shared between participants in a private channel.

3 unique roles around domain ID are discussed.

  • Who are the producers of domain IDs (and DS instructions)? Implementors of INT devices. Vendors (SW/HW), or network/system owners with DevOps capabilities on programmable dataplanes.
  • Who do consume domain IDs? parsers of the DS instructions and metadata. Either public, or private the
  • parser is part of the domain. Examples: collector that analyzes the telemetry reports and generate high-level information. Pkt dissector such as wireshark parser can be implemented based on public or private DS definitions. INT transit/sink devices that execute the instructions populated by INT source.
  • Network admin: configures collector/transit/sink devices to understand the ID->instruction mapping.

A large network owner w/ devops may play all three 3 roles.
Discussion to be continued in the next meeting, topics including

  • IANA registry for INT domain IDs.
  • A set of public, P4-official domain IDs may need to be reserved. A concrete use case needs more discussion.
    The next meeting is tentatively planned for 10/29 Thursday.

Thanks,
JK

I support Jonathan's proposal. From: P4-apps <p4-apps-bounces@lists.p4.org> On Behalf Of Lee, Jeongkeun Sent: Wednesday, November 4, 2020 4:18 PM To: Stone, Jonathan <jonathan.stone@intel.com>; p4-apps@lists.p4.org Subject: Re: [P4-Apps] 10/9 meeting notes For some reason, Jonathan's message below was not posted to the mailing. For the next meeting (11/12), I suggest we collect the use cases for public domain IDs, and derive concrete ideas to carve out and manage those IDs. Thanks! JK ________________________________ From: Stone, Jonathan <jonathan.stone@intel.com> Sent: Wednesday, October 21, 2020 6:13 PM To: Lee, Jeongkeun <jk.lee@intel.com>; p4-apps@lists.p4.org <p4-apps@lists.p4.org> Subject: Re: [P4-Apps] 10/9 meeting notes Here is one suggestion for carving up the DsId space: * reserve the upper half for future use * Reserve the first 4096 DsId values for "public p4" use. These effectively give the WG another 64k "instruction bits", which the community can use as for the "standard" instruction bits. Senders are not required to implement these DsIds, but may choose to do so. Receivers which implement the full INT spec, are expected to implement these DsIds, as any interoperable sender may choose to use them. * Leave a large gap ( 4k values?) * Reserve the next 4k DsId values for "public private": privately-defined DsIDs. IDs in this range have a public spec, but it's up to each collector implementor whether to implement them, or not. (I think of these as "experimental") * Leave another large gap (4k values?) * Reserve the next 4k for "truly private". These IDs have no public definition, and are usable only within an INT domain where all devices and collector(s) agree out-of-band on the meaning of these bits. The "gaps" are so that we can grow any of the three classes, while keeping the range of each class contiguous. That leaves another 4K at the end, plus the upper half of the range. ________________________________ From: P4-apps <p4-apps-bounces@lists.p4.org> on behalf of Lee, Jeongkeun <jk.lee@intel.com> Sent: Wednesday, October 21, 2020 5:44 PM To: p4-apps@lists.p4.org <p4-apps@lists.p4.org> Subject: [P4-Apps] 10/9 meeting notes <> Application library Questions from the prev meeting: Q1. what if the app requires a modification of Barefoot switch.p4, which is not open? A patch to switch.p4 can be shared? A: having public version of switch.p4 and APIs is under discussion. Till then, we start from apps that don't require switch.p4 integration. Q2. What about non-p4 apps, such as INT implementation in DPDK or eBPF under a license different from Apache2 that P4.org uses? A: we start from apps under Apache2. Candidate apps to host in the library: * Princeton Cabernet projects: https://github.com/Princeton-Cabernet/ * SwitchML: in-network ML training acceleration. https://arxiv.org/abs/1903.06701 * INT implementation in ONF repo: add pointers to them AIs: * bring * the license issue to P4 TST. * * JK * creates a PR of template to submit a p4 app: documents and code directory structure. * <> SwitchML talk Amedeo Sapio gave a talk on SwitchML, which will be open-sourced in Apps library soon. <> BUM (Broadcast, Unknown unicast and Multicast) traffic handling in INT Key questions: duplicate INT per egress bcast/mcast copy? Distinguish each branch/copy as a new flow or not? More issue with MD, less with MX. Consensus: every copy carries metadata, but policy-specific. E.g., only for mcast not for bcast or unknown unicast. Issue: tree ID is vendor specific. We agreed that BUM handling varies and is implementation specific, not easy to define one way everyone has to follow. In the future, INT spec might capture per-switch branch ID metadata. <> INT UDP port number IANA declined the request to assign a UDP dest port number for INT. The main reason from IANA is that INT is deployed in confined/controlled environments rather than Internet. A port from the dynamic range can be selected and used by each INT domain (similar to VLAN assignment). IANA would assign a port number if INT is to be deployed in the Internet, but then INT must handle e2e security, congestion control as required for any new UDP transport services. Although INT-UDP is an infra tunnel service, the INT encap/decap points are considered as end-hosts generating and consuming the new UDP traffic from IANA's point of view. Members agreed that this is not a blocker in using UDP-based INT encap. AI: update the spec re: the UDP port number assignment. <> INT UDP encap with IPSEC When we want INT outside of IPSEC: OuterIP-UDP-INT-InnerIP-AH/ESP example: https://github.com/p4lang/p4-applications/pull/90/files If INT is purely edge to edge (only btw end-hosts or vswitches, excluding fabric switches), INT can come inner of IPSEC AH or ESP. e.g., IP-AH/ESP-UDP-INT-... <> new PR: Telemetry Report: Support packet fragments longer than 1020 bytes https://github.com/p4lang/p4-applications/pull/89 AI: review PR <> INT domain ID concept and management Domain ID goal: maps a set of domain-specific instructions to their format and semantics Who participates in a domain is a business decision between vendors and operators. Some Domain Specific (DS) instructions may be published, others may stay private or shared between participants in a private channel. 3 unique roles around domain ID are discussed. * Who are the producers of domain IDs (and DS instructions)? Implementors of INT devices. Vendors (SW/HW), or network/system owners with DevOps capabilities on programmable dataplanes. * Who do consume domain IDs? parsers of the DS instructions and metadata. Either public, or private the * parser is part of the domain. Examples: collector that analyzes the telemetry reports and generate high-level information. Pkt dissector such as wireshark parser can be implemented based on public or private DS definitions. INT transit/sink devices that execute the instructions populated by INT source. * Network admin: configures collector/transit/sink devices to understand the ID->instruction mapping. A large network owner w/ devops may play all three 3 roles. Discussion to be continued in the next meeting, topics including * IANA registry for INT domain IDs. * A set of public, P4-official domain IDs may need to be reserved. A concrete use case needs more discussion. The next meeting is tentatively planned for 10/29 Thursday. Thanks, JK
LJ
Lee, Jeongkeun
Wed, Nov 11, 2020 11:44 PM

Thanks for the inputs. Let's discuss them tomorrow.

Feedback on this PR is also appreciated.
https://github.com/p4lang/p4-applications/pull/87

We will close on this tomorrow as well.

Thanks,
JK


From: Orr, Michael michael.orr@intel.com
Sent: Saturday, November 7, 2020 8:26 PM
To: Lee, Jeongkeun jk.lee@intel.com; Stone, Jonathan jonathan.stone@intel.com; p4-apps@lists.p4.org p4-apps@lists.p4.org
Subject: RE: [P4-Apps] 10/9 meeting notes

I support Jonathan’s proposal.

From: P4-apps p4-apps-bounces@lists.p4.org On Behalf Of Lee, Jeongkeun
Sent: Wednesday, November 4, 2020 4:18 PM
To: Stone, Jonathan jonathan.stone@intel.com; p4-apps@lists.p4.org
Subject: Re: [P4-Apps] 10/9 meeting notes

For some reason, Jonathan's message below was not posted to the mailing.

For the next meeting (11/12), I suggest we collect the use cases for public domain IDs, and derive concrete ideas to carve out and manage those IDs.

Thanks!

JK


From: Stone, Jonathan jonathan.stone@intel.com
Sent: Wednesday, October 21, 2020 6:13 PM
To: Lee, Jeongkeun jk.lee@intel.com; p4-apps@lists.p4.org p4-apps@lists.p4.org
Subject: Re: [P4-Apps] 10/9 meeting notes

Here is one suggestion for carving up the DsId space:

  • reserve the upper half for future use

  • Reserve the first 4096 DsId values for "public p4" use.  These effectively give the WG another 64k "instruction bits", which the community can use as for the "standard" instruction bits. Senders are not required to implement these DsIds, but may choose to do so. Receivers which implement the full INT spec, are expected to implement these DsIds, as any interoperable sender may choose to use them.

  • Leave a large gap ( 4k values?)

  • Reserve the next 4k DsId values for "public private": privately-defined DsIDs. IDs in this range have a public spec, but it's up to each collector implementor whether to implement them, or not.  (I think of these as "experimental")

  • Leave another large gap (4k values?)

  • Reserve the next 4k for "truly private".  These IDs have no public definition, and are usable only within an INT domain where all devices and collector(s) agree out-of-band on the meaning of these bits.

The "gaps" are so that we can grow any of the three classes, while keeping the range of each class contiguous.  That leaves another 4K at the end, plus the upper half of the range.


From: P4-apps p4-apps-bounces@lists.p4.org on behalf of Lee, Jeongkeun jk.lee@intel.com
Sent: Wednesday, October 21, 2020 5:44 PM
To: p4-apps@lists.p4.org p4-apps@lists.p4.org
Subject: [P4-Apps] 10/9 meeting notes

<> Application library

Questions from the prev meeting:

Q1. what if the app requires a modification of Barefoot switch.p4, which is not open? A patch to switch.p4 can be shared?

A: having public version of switch.p4 and APIs is under discussion. Till then, we start from apps that

don’t require switch.p4 integration.

Q2. What about non-p4 apps, such as INT implementation in DPDK or eBPF under a license different from

Apache2 that P4.org uses?

A: we start from apps under Apache2.

Candidate

apps to host in the library:

AIs:

  • bring

  • the license issue to P4 TST.

  • JK

  • creates a PR of template to submit a p4 app: documents and code directory structure.

<> SwitchML talk

Amedeo Sapio gave a talk on SwitchML, which will be open-sourced in Apps library soon.

<> BUM (Broadcast, Unknown unicast and Multicast) traffic handling in INT

Key questions: duplicate INT per egress bcast/mcast copy? Distinguish each branch/copy as a new flow

or not?

More issue with MD, less with MX.

Consensus: every copy carries metadata, but policy-specific. E.g., only for mcast not for bcast or

unknown unicast.

Issue: tree ID is vendor specific.

We

agreed that BUM handling varies and is implementation specific, not easy to define one way everyone has to follow. In the future,

INT spec might capture per-switch branch ID metadata.

<> INT UDP port number

IANA declined the request to assign a UDP dest port number for INT. The main reason from IANA is that

INT is deployed in confined/controlled environments rather than Internet. A port from the dynamic range can be selected and used by each INT domain (similar to VLAN assignment). IANA would assign a port number if INT is to be deployed in the Internet, but

then INT must handle e2e security, congestion control as required for any new UDP transport services. Although INT-UDP is an infra tunnel service, the INT encap/decap points are considered as end-hosts generating and consuming the new UDP traffic from IANA's

point of view.

Members agreed that this is not a blocker in using UDP-based INT encap.

AI: update the spec re: the UDP port number assignment.

<> INT UDP encap with IPSEC

When we want INT outside of IPSEC:

OuterIP-UDP-INT-InnerIP-AH/ESP

example:

https://github.com/p4lang/p4-applications/pull/90/files

If INT is purely edge to edge (only btw end-hosts or vswitches, excluding fabric switches),

INT can come inner of IPSEC AH or ESP.

e.g.,

IP-AH/ESP-UDP-INT-...

<> new PR: Telemetry Report: Support packet fragments longer than 1020 bytes

https://github.com/p4lang/p4-applications/pull/89

AI: review PR

<> INT domain ID concept and management

Domain ID goal: maps a set of domain-specific instructions to their format and semantics

Who

participates in a domain is a business decision between vendors and operators. Some Domain Specific (DS) instructions may be published, others may stay private or shared between participants in a private channel.

3 unique roles around domain ID are discussed.

  • Who are the producers of domain IDs (and DS instructions)? Implementors of INT devices. Vendors (SW/HW), or network/system owners with DevOps capabilities on programmable dataplanes.
  • Who do consume domain IDs? parsers of the DS instructions and metadata. Either public, or private the
  • parser is part of the domain. Examples: collector that analyzes the telemetry reports and generate high-level information. Pkt dissector such as wireshark parser can be implemented based on public or private DS definitions. INT transit/sink devices that execute the instructions populated by INT source.
  • Network admin: configures collector/transit/sink devices to understand the ID->instruction mapping.

A large network owner w/ devops may play all three 3 roles.

Discussion to be continued in the next meeting, topics including

  • IANA registry for INT domain IDs.
  • A set of public, P4-official domain IDs may need to be reserved. A concrete use case needs more discussion.

The next meeting is tentatively planned for 10/29 Thursday.

Thanks,

JK

Thanks for the inputs. Let's discuss them tomorrow. Feedback on this PR is also appreciated. https://github.com/p4lang/p4-applications/pull/87 We will close on this tomorrow as well. Thanks, JK ________________________________ From: Orr, Michael <michael.orr@intel.com> Sent: Saturday, November 7, 2020 8:26 PM To: Lee, Jeongkeun <jk.lee@intel.com>; Stone, Jonathan <jonathan.stone@intel.com>; p4-apps@lists.p4.org <p4-apps@lists.p4.org> Subject: RE: [P4-Apps] 10/9 meeting notes I support Jonathan’s proposal. From: P4-apps <p4-apps-bounces@lists.p4.org> On Behalf Of Lee, Jeongkeun Sent: Wednesday, November 4, 2020 4:18 PM To: Stone, Jonathan <jonathan.stone@intel.com>; p4-apps@lists.p4.org Subject: Re: [P4-Apps] 10/9 meeting notes For some reason, Jonathan's message below was not posted to the mailing. For the next meeting (11/12), I suggest we collect the use cases for public domain IDs, and derive concrete ideas to carve out and manage those IDs. Thanks! JK ________________________________ From: Stone, Jonathan <jonathan.stone@intel.com> Sent: Wednesday, October 21, 2020 6:13 PM To: Lee, Jeongkeun <jk.lee@intel.com>; p4-apps@lists.p4.org <p4-apps@lists.p4.org> Subject: Re: [P4-Apps] 10/9 meeting notes Here is one suggestion for carving up the DsId space: * reserve the upper half for future use * Reserve the first 4096 DsId values for "public p4" use. These effectively give the WG another 64k "instruction bits", which the community can use as for the "standard" instruction bits. Senders are not required to implement these DsIds, but may choose to do so. Receivers which implement the full INT spec, are expected to implement these DsIds, as any interoperable sender may choose to use them. * Leave a large gap ( 4k values?) * Reserve the next 4k DsId values for "public private": privately-defined DsIDs. IDs in this range have a public spec, but it's up to each collector implementor whether to implement them, or not. (I think of these as "experimental") * Leave another large gap (4k values?) * Reserve the next 4k for "truly private". These IDs have no public definition, and are usable only within an INT domain where all devices and collector(s) agree out-of-band on the meaning of these bits. The "gaps" are so that we can grow any of the three classes, while keeping the range of each class contiguous. That leaves another 4K at the end, plus the upper half of the range. ________________________________ From: P4-apps <p4-apps-bounces@lists.p4.org> on behalf of Lee, Jeongkeun <jk.lee@intel.com> Sent: Wednesday, October 21, 2020 5:44 PM To: p4-apps@lists.p4.org <p4-apps@lists.p4.org> Subject: [P4-Apps] 10/9 meeting notes <> Application library Questions from the prev meeting: Q1. what if the app requires a modification of Barefoot switch.p4, which is not open? A patch to switch.p4 can be shared? A: having public version of switch.p4 and APIs is under discussion. Till then, we start from apps that don’t require switch.p4 integration. Q2. What about non-p4 apps, such as INT implementation in DPDK or eBPF under a license different from Apache2 that P4.org uses? A: we start from apps under Apache2. Candidate apps to host in the library: * Princeton Cabernet projects: https://github.com/Princeton-Cabernet/ * SwitchML: in-network ML training acceleration. https://arxiv.org/abs/1903.06701 * INT implementation in ONF repo: add pointers to them AIs: * bring * the license issue to P4 TST. * * JK * creates a PR of template to submit a p4 app: documents and code directory structure. * <> SwitchML talk Amedeo Sapio gave a talk on SwitchML, which will be open-sourced in Apps library soon. <> BUM (Broadcast, Unknown unicast and Multicast) traffic handling in INT Key questions: duplicate INT per egress bcast/mcast copy? Distinguish each branch/copy as a new flow or not? More issue with MD, less with MX. Consensus: every copy carries metadata, but policy-specific. E.g., only for mcast not for bcast or unknown unicast. Issue: tree ID is vendor specific. We agreed that BUM handling varies and is implementation specific, not easy to define one way everyone has to follow. In the future, INT spec might capture per-switch branch ID metadata. <> INT UDP port number IANA declined the request to assign a UDP dest port number for INT. The main reason from IANA is that INT is deployed in confined/controlled environments rather than Internet. A port from the dynamic range can be selected and used by each INT domain (similar to VLAN assignment). IANA would assign a port number if INT is to be deployed in the Internet, but then INT must handle e2e security, congestion control as required for any new UDP transport services. Although INT-UDP is an infra tunnel service, the INT encap/decap points are considered as end-hosts generating and consuming the new UDP traffic from IANA's point of view. Members agreed that this is not a blocker in using UDP-based INT encap. AI: update the spec re: the UDP port number assignment. <> INT UDP encap with IPSEC When we want INT outside of IPSEC: OuterIP-UDP-INT-InnerIP-AH/ESP example: https://github.com/p4lang/p4-applications/pull/90/files If INT is purely edge to edge (only btw end-hosts or vswitches, excluding fabric switches), INT can come inner of IPSEC AH or ESP. e.g., IP-AH/ESP-UDP-INT-... <> new PR: Telemetry Report: Support packet fragments longer than 1020 bytes https://github.com/p4lang/p4-applications/pull/89 AI: review PR <> INT domain ID concept and management Domain ID goal: maps a set of domain-specific instructions to their format and semantics Who participates in a domain is a business decision between vendors and operators. Some Domain Specific (DS) instructions may be published, others may stay private or shared between participants in a private channel. 3 unique roles around domain ID are discussed. * Who are the producers of domain IDs (and DS instructions)? Implementors of INT devices. Vendors (SW/HW), or network/system owners with DevOps capabilities on programmable dataplanes. * Who do consume domain IDs? parsers of the DS instructions and metadata. Either public, or private the * parser is part of the domain. Examples: collector that analyzes the telemetry reports and generate high-level information. Pkt dissector such as wireshark parser can be implemented based on public or private DS definitions. INT transit/sink devices that execute the instructions populated by INT source. * Network admin: configures collector/transit/sink devices to understand the ID->instruction mapping. A large network owner w/ devops may play all three 3 roles. Discussion to be continued in the next meeting, topics including * IANA registry for INT domain IDs. * A set of public, P4-official domain IDs may need to be reserved. A concrete use case needs more discussion. The next meeting is tentatively planned for 10/29 Thursday. Thanks, JK