[P4-Apps] Notes from WG meeting 12/5/2019

0 views
Skip to first unread message

Jeongkeun Lee

unread,
Dec 9, 2019, 12:27:46 AM12/9/19
to p4-...@lists.p4.org
Attendees: 
Ramesh S. (Cisco), Mukesh H. (VMware), Micheal O. (Intel), Mickey S. (Barefoot/Intel), JK L. (Barefoot/Intel).

First, Ramesh walked through the INT shim headers being defined for ipv4/GRE, ipv6 extension and we decided to keep them consistent with the new shim header revised for INT over UDP. All of them follow this structure:
- type field in 4b
- flags and reserved bits (4b)
- length (8b)
- next protocol (16b)
AI: Ramesh will create or revise PRs accordingly.
Ramesh also proposed to use a new IP protocol codepoint for INT, similar to IFA, and will create a PR for this.

Second, we concluded on the clean-up suggestions from Michael.
- Remove REP (replication bits) from common hdr. User can do the replication by encoding the same info in a new domain extension hdr.
- Repurpose C bit to indicate probe/synthetic pkts for Sink to drop.
- L2 interface ID from 32b to 16b, to be consistent with L1 interface ID. We decided not to make this change as there is an on-going HW implementations of INT that models L2 interfaces as 32b.
AI: Michael will create a PR for the first two accepted changes.
 
Third topic was about domain IDs.
We will specify well-known IDs in the spec. 
While the group agrees that the ID is not hard coded in each vendor device and must be configurable, there is a need to have a registry service for different domains/operators to declare their IDs and avoid overlap, esp. when an INT service is deployed across domains. e.g., gateway connecting different domains.
AI: Ramesh will learn about how IOAM handles a registry and share with the group, and will specify the well-known IDs into the spec.

The last topic was INT over UDP.
- The consensus was to get a new INT port number assigned by IANA just for UDP but not for TCP. Carrying the original entropy at UDP src is trivial; but maintaining lots of TCP semantics seems too much.
- The group made good points that modern ToR/fabric switches parse not only L4 port numbers (for ECMP), but also look at various TCP flags + option hdrs, or RoCEv2 queue-pair numbers for ACL and QoS. If the packet is further encapsulated by UDP-INT, hence it looks like 
ETH-IP-UDP(dst=TBD_INT)-TCP 
ETH-IP-UDP(dst=TBD_INT)-RoCEv2
then the legacy switches may not recognise the new UDP dst port number and won't be able to access the TCP or RoCEv2 fields.
- However, if there are new UDP-based transport or virtualization protocols introduced in the future, the legacy switches won't be able to recognize the future protocols (and their new UDP port numbers) anyway. Introducing a new UDP port for INT today and inserting INT before those future transport protocol headers (whey they're available) seems one of the least intrusive ways to insert INT, since the legacy devices will still be able to run ECMP using outer UDP port numbers.
AI: JK will update the existing PR with this additional context and usecase scenario.

A good number of PRs have been created and updated recently for v2.0 specs based on the discussions above.
Any comments from the community will be appreciated.

The next meeting will be on 12/19 Thursday 10am: calendar link is here.
We plan to concretize the PRs by the next meeting.

Thanks,
JK Lee
Mukesh Hira

   

Reply all
Reply to author
Forward
0 new messages