********************************************************************* IETF 110 PALS/MPLS/DetNet/SPRING Joint Meeting Friday, 12 March 2021 - 12:00-14:00 UTC Room:7 120/120 min allocated ********************************************************************** Chairs: Stewart Bryant and Andy Malis Secretary: David Sinicrope 1. 5 min - Chairs’ intro - Andy MALIS Andy opened the session - the Chairs are Andy Malis (PALS), Nic Leyman (MPLS), Lou Berger (DetNet) and Jim G (SPRING) Andy presented the Chair's slides. It was requested that questions during the talk be limited to clarification and keep the bulk of the discussion for the 45 min slot toward the end of the meeting. 2. 20 min - MPLS architectural considerations - Stewart BRYANT Stewart presented the MPLS architecture slides noting the recent activity that motivated this meeting, and the MPLS architecture and model. It was noted that since only the top label is processed, the forwarding is light weight and efficient, in particular for the fastpath (hardware forwarding). It was stressed that Extended Special Purpose Labels (ESPLs) are the antithesis of the original approach. There is concern about the size of the label stack and complexity. It was noted that PWs and DetNet have OAM for themselves at the end of the label stack which was kept mutually exclusive with data and never more than one ACH. We need to examine and understand when to use SPLs vs a regular label and signaling in the control plane. It was stressed that the list of proposals is not exhaustive, there are likely others. (e.g., It was noted that the "path id draft" is missing.) Is it easier for hard ware to process data after the stack or in the stack. It is normal to process data after the stack has been processed at termination. It was noted that the forwarding buffer where forwarding processing takes place is incredibly expensive. Not every function can have large number of labels. It was noted that in the original model the forwarding was not to look beyond the top of stack label and there was also processing of the TC and TTL. 3. 10 min - DetNet data plane, RFCs 8938, 8939, 8964 - Balázs VARGA Balázs presented the slides. It was noted that the DetNet function looks similar to the Pseudowire processing and control word. No questions. 4. 10 min - Generic delivery functions - Zhaohui (Jeffrey) ZHANG https://tools.ietf.org/html/draft-zzhang-intarea-generic-delivery-functions-00 Jeffery presented the slides. Must GDFH always be BoS, it must always follow a BoS label, but after the GDFH there could be additional label stacks. This is the current thinking but may change. But could GDFH be anywhere in the stack? Currently, yes, but may evolved. e.g., if it is applied to hop by hop behavior. There was some concern as to how it would work with segment routing. 5. 15 min - MPLS in-situ OAM - Rakesh GANDHI https://tools.ietf.org/html/draft-gandhi-mpls-ioam-sr-06 Rakesh presented the slides. It was noted that the IOAM is carried past the end of stack in the MPLS header. It was noted that putting the ACH at the end would be disruptive to DetNet where the processing is time sensitive and in this proposal comes after a long and variable length set of IOAM data. It was noted that currently the G-ACH does not have a "next header" concept. However the channel defines what follows. There is no intrinsic endoding of what follows, but one can define what follows depending on the G-ACH type. It was noted that there are 64K and that it would be an expensive table look up which would be expensive but still feasible. 6. 10 min - Multi-purpose Special Purpose Label for Forwarding Actions - Kireeti KOMPELLA https://tools.ietf.org/html/draft-kompella-mpls-mspl4fa-00 Kireeti presented the slides. In particular, see slide 3 on the Behavior of Forwarding Engines on the Label Stack. It was noted that processing anything beyond the top label, is not treating the label stack as a stack. It was noted that the architecture was designed at a time when the forwarding processing power was far less than today. There are questions we should be asking: What is the architecture of the label stack? What is the architecture of what comes after the label stack? What functions are needed today? How does this map into the power of NPs today? See slide 9 It was noted that we do need to be concerned about legacy, but we should also be looking at how we can be doing more. It was noted that jumping to the BoS, especially with the label stack size SPRING has introduced can be difficult. In examining whether the ELI should be at the top of stack, the label stack ends up not being a stack any longer. 7. 45 min - Discussion - all Rakesh: If in the Forwarding Actions Indicator always at bottom stack. Kireeti: it isn't it can appear anywhere in the stack and be processed. Rakesh: if not at BoS it could break existing network by introducing new forwarding semantics. Kireeti: this would happen at the introduction of a new special purpose label. If the hardware doesn't understand the label it will not parse it correctly anyway and should be ignored or the packet should be dropped which will not necessarily break anything. Rakesh: the pros and cons would need to be weighed. Kireeti: There are issues with special purpose labels anyway, however with this it can be repeated and pushed to the top so it is processed right away. Stewart: This is only one proposal, we should come up a level and consider a general approach and then dig into details Haoyu Song: it was noted that a few years ago there would be several bottom of stack functions such as IOAM, Service Chain, etc. that may require hop by hop or end to end processing. Tried to borrow IPv6 extension headers to allow them to be jumped over for processing. Several related drafts are published describing the extension headers that list the ways the headers can be used along with the pros and cons. There was little interest at the time, but now seems to be a good time to look at them again. Andy: the drafts referenced are in the non-exhaustive list provided in the overview at the start of the session Jeffery: on reason for the GDF is to make it applicable to many layers. e.g., insitu OAM can be done for MPLS, BIER, etc. A general function would be more useful if applicable to other layers and technologies. Toerless: We have done a very much ad hoc set of solutions. It would be good to have more of a strategic approach with an encoding language or scheme. This would have an adjacency to P4 so the IETF can come up with more flexibile headers. Rakesh: one important aspect of hop by hop processing is that we shouldn't have to walk the entire stack to figure out that something should be done, it should be presented up front. Zhenbin Li: Most of this general processing is done for IPv6. For Ethernet and for Bier it would be difficult and the generic delivery function causes complications. Jeffery: Don't agree. Fragmentation are defined for IP, but can be done for MPLS and BIER if we go with a generic function. It is a bigger topic but we should be resolving the issue for all layers if possible. Rakesh: we should optimize the midpoint processing of the header without diving into the metadata and/or G-ACH. Jeffery: currently we are only dealing with edge to edge, but hop by hop are other functions to be considered. Those functions can alos be abstracted to generic delivery function. More homework is needed. Tarek: the usecase for mulitple G-ACH and a G-ACH type and having multiples after the BoS. it is not clear that the way it was described is how IANA is allocating the types. Also for every combination a new type is needed. Not sure this is the road we want to be on. Weiqiang: it was noted that the third draft on the list draft-cheng was adopted by the MPLS WG Stewart: we need to build better list of drafts via the email lists Rakesh: the label + G-ACH defines the action on the node. not a cascading of the G-ACH Greg Mirsky: RFC 8169 resident time measurement uses ACH type that defines the encoding of what follows. This is a good example of the ACH type use. 8. 5 min - Chairs’ summary - Stewart BRYANT Stewart summarized the situation noting that there is sufficient interest and there is some urgency. There was some assertion that we should let the normal progression of drafts continue. It was noted from the ADs that indeed the urgency and interest is there and that waiting for the next IETF is not sufficient. There were suggestions for an interim and for a design team although there was concern about a design team being as large as the Working Group. The discussion of next steps is to be done on the MPLS email list. Stewart will update the slides and they will be posted to the meeting materials. None of the proposals were noted as being bletcherous.