IETF 111 PALS/MPLS/DetNet Joint Meeting Joint session with PALS, MPLS, DetNet Tuesday, 27 July 2021 - 16:00-18:00 PDT Room: 6 120/120 min allocated ********************************************************************** Chairs: Stewart Bryant and Andy Malis Secretary: David Sinicrope 1. 5 min - Chairs’ intro - Andy MALIS Andy opened the session at 16:00 and presented the Intro slides. Roughly 50 participants attended the session. 2. 20 min - MPLS Open DT summary and status - Stewart BRYANT Stewart presented the slides providing the summary and status. Tarek: are the meta-data/extended headers going to all be processed in the fast path, slow path or both? Stewart: both e.g., fast reroute needs fast path. Will depend on whether action needs to be done in realtime with packet or if action can wait. Latency sensitive processing/forwarding needs to happen in fast path. Kireeti: in 6man there was discussion of making the hop by hop option work again. The questions they had echo questions here. e.g., how much do you process in fast path? Helpful even to align terminology, approach and issues, to combine with folks there e.g., Bob [Hinden] Loa: Additional piece of information, not the TEAS WG but the SPRING WG that were initially involved in the DT. The list of DT agreements reflect the results of a DT meeting, but will be sent for a consensus call to the MPLS and other WGs. Toerless: need to also say that ignoring all the new things is also considered and valid. 3. In-stack Indicators 3.1 10 min - draft-kompella-mpls-mspl4fa FAI MSPL I-D: Kireeti KOMPELLA Kireeti presented the slides. Toerless: In 6man there was one draft that was a generic next generation router alert, perhaps there is something to bring up in LSR for consistency in the control plane. 3.2 10 min - draft-bryant-mpls-aux-data-pointer-00: Stewart BRYANT Stewart presented the slides. Kireeti: There may be a way to combine the TC TTL bits with the pointer concept. In the 01 draft [draft-kompella-mpls-mspl4fa] it addresses when to put data right there or when to refer to data beyond end of stack. It will depend on the use as two when you need things in the label stack or outside the label stack, similar to a cache to a disk. Label stacks are getting fairly big and we need to discuss with those doing silicon about the practical limits and boundaries. Also a reason to work with 6man on how to do the processing. Tarek: normally extend headers are process sequentially. But it sounds like what is being proposed is that a header is processed not sequentially. Stewart: there are some cases where you want to skip over or share specific data, but only on some hops. Need to look at the applications and then decide what the stack processing must do. 3.3 5 mins- draft-song-mpls-eh-indicator: Haoyo SONG Haoyo presented the slides. Jaganbabu: the concept seems like it would make complex hardware and would create compatibility issues with existing routers. Haoyo: no more difficult than existing headers. With any enhancement we will need additional processing so we need to limit the headers in a single packet. Jeffery: at the begining of the DT there were criticisms of the head of extension header. Haoyo: Perhaps not sure of discussion, but the EH would be used to summarize the headers. Still open for discussion. Andrew: reminder any decisions taken in the DT need to be ratified by the MPLS WG Greg Mirsky: do the proposed headers immediately follow the label stack? Haoyo: yes in most cases Greg: how will this be used with a GAL label? Haoyo: covered in the draft Tarek: a packet may arrive with an EH on a router and the router wants to insert EH. How is the insertion done and how are the EHs popped at intermediate nodes? Haoyo: you insert and modify the next header fields of the previous headers Stewart: Haoyo mentioned could put a header after the ACH, but current ACH has not length so you could not put headers after them. 4. Meta-data Encoding Options: 4.1 20 min - MPLS Extension Header: Enabling Extensible In-Network Services - Haoyu SONG Objective: Recap the solution proposal with some updates based on the DT meeting discussion. draft-song-mpls-eh-indicator draft-song-mpls-extension-header draft-andersson-mpls-eh-architecture Draft-andersson-mpls-eh-label-stack-operations See Notes for item 3.3 above. 4.2 10 min - draft-zzhang-intarea-generic-delivery-functions GFD Encodings - Jeffery ZHANG Jeffery presented the slides. Andy: this is the last formal presentation. Floor is open for comments on any presentation. Kireeti: common formats between MPLS, BIER and IPv6 is intriguing because perhaps microcode can be optimized. Does this idea actually play out in real life? Have you actually spoken with anyone from a silicon vendor to confirm? Jeffery: would be surprised if it is not done that way 5. 35 min - Discussion - All Tarek: we've seen 3 encodings of metadata after the label stack. We eventually want one standard encoding. Should we evaluate the pros and cons of each encoding and choose the best? Stewart: a proposal made to the DT was to understand the applications before focusing the design. Then it will likely be more obvious what we shoudl pick. Greg M: Should we have a list of requirements, and would backward compatibility with ACH be one of the requirements for any encapsulation scheme. Jeffery: (audio issues) - the co-existence of the ACH and the EH the DT confirmed they wanted to support that. It was noted that it should be possible if there are indications that both are present. Greg: ACH is only known if it is supported. There is no length. Stewart: confirmed Greg: then Stewarts proposal can coexist with ACH. No need for extensive discussion, just need to understand what ACH is and how it is to be supported. Stewart: one of the things that made MPLS successful was its simplicity. This characteristic seems to be lost in the current proposals. We should be asking for simple proposals going forward. Kireeti: Noted in the chat that perhaps it is time to put ACH to bed (deprecate it). It may be better to come up with a comprehensive way to encode data after end of stack and work ACH into it. Jeffery: three poitns 1. coexistence of ACH and EH if we are not going to allow coexistence or (bad audio) then how you discuss coexistence might be provided by an offset to determine where the EH starts. 2. complexity- if we have requriement, then we need to support it, but what is the definition of complexity and when would we cross it. 3.... Jeff: In backward compatible regards the GAL GACH is relatively expensive and perhaps it should be deprecated. Greg: In one geographic area ACH is widely deployed and supported. Whether it is needed for us to support compatibility is another question. May not be easy to get reliable info on what has been deployed. Stewart: ACH has been widely deployed as an OAM technique for Pseudowires. Jeffery: my point 3... backward compatibility if you have a router that only understands ACH and there is an EH present then this would not create a compatibility issue, it would process the ACH and not the EHs. Kireeti: when we redesign the stuff below BoS rather than cope with current definition of ACH, we incorporate the ACH info to make it extensible. This approach would be preferred to just throwing it out or trying to coexist as it exists today. If there is a way to coexist without adding complexity then OK, otherwise we should take the information and work it into the redesign. 6man is doing similar with router alert, where a proposal was to just do away with router alert. Stewart: We can't break ACH implementations deployed today. If we need to put EHs and ACH in the same packet, it does create a compatibility problem. If the router processes the ACH and doesn't know about the EH it will likely pass the EH as payload which will cause problems up the stack. In cases where we want to use an OAM mechanism like the one ACH provides AND do something new, then we should likely migrate the OAM to a new design and system Jeffery: clarify the compatibility issue is not specific to the coexistence and is present with the EH itself. 6. 5 min - Chairs’ summary - Stewart BRYANT Stewart briefly summarized the take aways from the session: a. need to include the TEAS WG in this work - (Lou via chat: need to discuss with the co-chair) b. need to establish a relationship with the 6man WG. The HxH options discussions they are having may have some overlap with our own problem space. Perhaps a joint call? c. Some of the approaches can be merged, (e.g., Kireeti and Bryant have overlap and synergy) Need to see how these can be used together and/or merged. There is a need for both ready-data and pointed/referenced-data. d. protocol needs to support multiple independent auxiliary data (Aux Data) elements and multiple actions e. there are still some matters outstanding (e.g., ACH coexistence (or not) with other meta/aux data) that must be resolved. The DT needs to continue working. Andy pointed to the DT wiki link in the resources slide (and below) Loa: all is on the wiki but may be hard to find due to structure - if you have questions or can't find something - ask the chairs Tarek: there is a use case page with a pointer on the wiki - please provide use cases that need to be addressed so we come up with complete solutions and evaluation of solutions. Andy closed the meeting at 17:57 ************************ Chat Room comments: (Note: timestamps are in EDT. Subtract 3 for PDT) Jeff Tantsura: +1 to on-demand programmable bindings (as opposed to SRv6 fixed actions) 19:39:07 Tarek Saad: +1 19:39:21 if programmable-then the limited number of flags becomes less of an issue 19:40:15 Kireeti Kompella: maybe it's time to put GAL/ACH to bed? 20:21:34 Andy Malis: @meetecho we're having intermittent breakup on the audio 20:22:33 Kireeti Kompella:it's mainly with jeffrey 20:22:53 Andy Malis: We had it with at least one other person as well 20:23:42 Meetecho: If everyone gets the same bad audio, it's likely an issue on the speaker side, as audio is then mixed before it's sent to everyone 20:24:05 Stewart Bryant:@Kireeti - agree - we did not design GAL/ACH for the applications we are considering with this work 20:24:41 Mach Chen:For now, GAL/ACH is only for OAM packets, maybe we could extend the new EH to support the functions of GAL/ACH,20:39:42 Adrian Farrel: It is interesting to wonder why the very flexible and extensible GAL/ACH mechanism did not take off for any uses except for OAM 20:42:59 Could it be that there is a shortage of problems to be solved? 20:43:18 This comes to Stewart's point that it would really help if knew the use cases for this proposed work 20:43:40 Jeff Tantsura: +1 @adrian Cheng Li: no screen sharing or my issue? 20:49:58 Lou Berger: none for me too 20:50:13 Joel Halpern: We are done with presentations, so no screen sharing to be done. 20:50:21 Jeff Tantsura:at some point we stopped supporting IPX? 20:50:25 Cheng Li:ok, thanks Joel:20:50:34 Jeff Tantsura:natively over the wire, encapsulation into a generic header (IPv4) was the way forward 20:52:36 Lou Berger:need to discuss with co-chair20:53:09 -- thank you either way 20:53:19 ********************************************************************** AGENDA INFORMATION FOR THE SESSION ********************************************************************** Note: This meeting is focused on Meta/Ancillary data in MPLS packets - how we know it is there and how we carry it. This is both formal reporting of the progress on the MPLS Open Design Team and a working session to progress the work. ●Agenda https://datatracker.ietf.org/meeting/111/materials/agenda-111-pals ●Etherpad/CODIMD https://codimd.ietf.org/notes-ietf-111-pals ●Jabber room: xmpp:pals@jabber.ietf.org?join ●MPLS Open Design Team Wiki (The MPLS open design team keeps a log of its work here: https://trac.ietf.org/trac/mpls/wiki/MPLSOpenDT ●If you have any general issues with Meetecho, the meeting audio, etc., send an email to support@ietf.org (Note: a Meetecho tech will be monitoring Jabber during the meeting)