p4-apps@lists.p4.org

P4 Applications Working Group

View all threads

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

LJ
Lee, Jeongkeun
Sat, Dec 19, 2020 1:36 AM

Thanks Anoop for sharing the links.
There seems a good overlap btw this list and the SAI list. We will discuss them comparatively in the next meeting.

JK


From: Anoop.Ghanwani@dell.com Anoop.Ghanwani@dell.com
Sent: Thursday, December 17, 2020 9:28:41 PM
To: Lee, Jeongkeun jk.lee@intel.com; p4-apps@lists.p4.org p4-apps@lists.p4.org
Subject: Re: 12/10 meeting notes

​The following spec contains the drop reasons used by sFlow.

https://sflow.org/draft_sflow_drops_6.txt

It uses values defined by ICMP and Devlink Trap

https://www.kernel.org/doc/html/latest/networking/devlink/devlink-trap.html

In the case of sFlow, this annotation is typically done by software so it may not have the limitations that are being discussed for INT.

Anoop


From: P4-apps p4-apps-bounces@lists.p4.org on behalf of Lee, Jeongkeun jk.lee@intel.com
Sent: Thursday, December 17, 2020 7:25 PM
To: p4-apps@lists.p4.org
Subject: [P4-Apps] 12/10 meeting notes

[EXTERNAL EMAIL]

Attendees: Rajshekhar B. (Arista), Mukesh H. (VMware), Jonathan S. (Intel, Deep Insight), Mickey S. (Intel, Barefoot),  JK L. (Intel, E2E App).

Three topics were discussed

  • Drop reason semantics
  • Domain ID mgmt (cont'd)
  • Report traffic load balancing
  1. Drop reason semantics
    Today drop reason code points are not listed in the spec, up to each vendor/implementation (Barefoot switch.p4, Arista, VMware NSX..).
    JS questioned if there is any fixed function HW implementation of drop reports and reason codepoints. The group is not aware of one. But even if codepoint is programmable, there may HW resource implications in creating and managing many drop reasons in the dataplane.

RB proposed to start with a few categories to classify common drop reasons.
There was a consensus on having a list of common drop reasons (name strings and semantics), the group debated on having a standard mapping between drop reasons and their codepoints, or leaving it up to each domain.

JK pointed to SAI drop reasons:
https://github.com/opencomputeproject/SAI/blob/master/inc/saidebugcounter.h
https://github.com/opencomputeproject/SAI/blob/master/doc/SAI-Proposal-Debug-Counters.md

AI for everyone: compare the SAI list with each vendor list and analyze if this is a good start to use and extend.

  1. Domain ID
    JS contacted IANA expert for creating a domain ID registry, the reply: follow the standard procedure. JS will check with ONF.

MS had a proposal to define a set of metadata semantics in the spec, while the mapping of metadata to a DS (Domain-specific) bitmap is under each domain control. Currently Yang model doesn’t assign bits but only specifies each metadata format or semantics. This concept can be applied even to standard metadata (JK). The Yang model defines a 'pool or library' of metadata (format + semantics), and no restriction on adding a new metadata or a variation of semantics. The spec determines a subset of metadata to form the "standard metadata" and their bit locations in the INT instruction.

There are 2 level mappings: DS ID => bitmap => metadata format + semantics.
Register service can maintain the DS ID => the rest mapping.
Each domain controls the bitmap allocation of metadata selected for each domain.

Even standard metadata has per-domain/vendor semantical variations in details such as timestamp unit, the meaning of virtual interface ID. The Yang model was introduced to capture the variations but is meant to be published by each device through mgmt channel. We can change it such that Domain ID in the INT header indicates the set semantics of standard metadata. We will continue the discussion in the next meeting.

AI: JS will open a PR on carving out DS IDs.
AI from the last meeting: JK to create a PR on domain ID role.

  1. Telemetry report traffic load balancing.
    Briefly discussed the impact of UDP source port number, its correlation with report SEQ numbering.

AI: JS and MS discuss first offline and propose in the next meeting.

The next WG meeting will be in early January.

Thank you and happy holidays to all!

JK
Mukesh

Thanks Anoop for sharing the links. There seems a good overlap btw this list and the SAI list. We will discuss them comparatively in the next meeting. JK ________________________________ From: Anoop.Ghanwani@dell.com <Anoop.Ghanwani@dell.com> Sent: Thursday, December 17, 2020 9:28:41 PM To: Lee, Jeongkeun <jk.lee@intel.com>; p4-apps@lists.p4.org <p4-apps@lists.p4.org> Subject: Re: 12/10 meeting notes ​The following spec contains the drop reasons used by sFlow. https://sflow.org/draft_sflow_drops_6.txt It uses values defined by ICMP and Devlink Trap https://www.kernel.org/doc/html/latest/networking/devlink/devlink-trap.html In the case of sFlow, this annotation is typically done by software so it may not have the limitations that are being discussed for INT. ​ Anoop ________________________________ From: P4-apps <p4-apps-bounces@lists.p4.org> on behalf of Lee, Jeongkeun <jk.lee@intel.com> Sent: Thursday, December 17, 2020 7:25 PM To: p4-apps@lists.p4.org Subject: [P4-Apps] 12/10 meeting notes [EXTERNAL EMAIL] Attendees: Rajshekhar B. (Arista), Mukesh H. (VMware), Jonathan S. (Intel, Deep Insight), Mickey S. (Intel, Barefoot), JK L. (Intel, E2E App). Three topics were discussed * Drop reason semantics * Domain ID mgmt (cont'd) * Report traffic load balancing 1. Drop reason semantics Today drop reason code points are not listed in the spec, up to each vendor/implementation (Barefoot switch.p4, Arista, VMware NSX..). JS questioned if there is any fixed function HW implementation of drop reports and reason codepoints. The group is not aware of one. But even if codepoint is programmable, there may HW resource implications in creating and managing many drop reasons in the dataplane. RB proposed to start with a few categories to classify common drop reasons. There was a consensus on having a list of common drop reasons (name strings and semantics), the group debated on having a standard mapping between drop reasons and their codepoints, or leaving it up to each domain. JK pointed to SAI drop reasons: https://github.com/opencomputeproject/SAI/blob/master/inc/saidebugcounter.h https://github.com/opencomputeproject/SAI/blob/master/doc/SAI-Proposal-Debug-Counters.md AI for everyone: compare the SAI list with each vendor list and analyze if this is a good start to use and extend. 2. Domain ID JS contacted IANA expert for creating a domain ID registry, the reply: follow the standard procedure. JS will check with ONF. MS had a proposal to define a set of metadata semantics in the spec, while the mapping of metadata to a DS (Domain-specific) bitmap is under each domain control. Currently Yang model doesn’t assign bits but only specifies each metadata format or semantics. This concept can be applied even to standard metadata (JK). The Yang model defines a 'pool or library' of metadata (format + semantics), and no restriction on adding a new metadata or a variation of semantics. The spec determines a subset of metadata to form the "standard metadata" and their bit locations in the INT instruction. There are 2 level mappings: DS ID => bitmap => metadata format + semantics. Register service can maintain the DS ID => the rest mapping. Each domain controls the bitmap allocation of metadata selected for each domain. Even standard metadata has per-domain/vendor semantical variations in details such as timestamp unit, the meaning of virtual interface ID. The Yang model was introduced to capture the variations but is meant to be published by each device through mgmt channel. We can change it such that Domain ID in the INT header indicates the set semantics of standard metadata. We will continue the discussion in the next meeting. AI: JS will open a PR on carving out DS IDs. AI from the last meeting: JK to create a PR on domain ID role. 3. Telemetry report traffic load balancing. Briefly discussed the impact of UDP source port number, its correlation with report SEQ numbering. AI: JS and MS discuss first offline and propose in the next meeting. The next WG meeting will be in early January. Thank you and happy holidays to all! JK Mukesh