IETF 114 PALS/MPLS/DetNet/SPRING Joint Meeting **\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\* Tuesday, 26 July 2022 - 10:00-12:00 Meeting time/Philadelphia Room: Independence A/B 120/120 min allocated \*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\*** Chair: Andy Malis Secretary: Dave Sinicrope Minute-taker: Dave Sinicrope (+attendees on CodiMD/HedgeDoc) NOTE: Attendees who want to help with notes, please enter your notes in this facility. Dave will then add his and publish the final notes after the session. Thanks for your help! Note: all questions (including persons physically present) will need to line up into the virtual queue on Meetecho 1. Chairs Intro (Agenda Bashing, etc.) Chair: Andy MALIS Duration: 5 min Andy opened the meeting at 10am EDT and went through the Chair's slides. No questions or comments. 2. https://datatracker.ietf.org/doc/draft-schmutzer-pals-ple https://datatracker.ietf.org/doc/draft-schmutzer-bess-ple-vpws-signalling Presenter: Christian SCHMUTZER Duration: 10 min (combined) Christian presented the slides. Concept was introduced to BESS at IETF 108, want to introduce to PALS since the feedback was that it should be addressed to PALS. The drafts examine the deprecation of the OTN (TDM) switching layer and what to do with the "private line" services provided by OTN when all is moved to packet switching. Looks to complement SAToP / RFC4553 for higher speed interfaces and associated signaling. There was a request by the author to get feedback on whether the signaling draft could address the SPRING Martini Pseudowires and SR issues. No questions or comments 3. Open Design Team Report Presenter: Tarek SAAD Duration: 15 min Tarek presented the slides providing a status update on the MPLS MNA Open Design Team work. It was noted that questions beyond clarification should be directed to the discussion at the end of the session. No questions or comments 4. https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-requirements Presenter: Mathew BOCCI Duration: 10 min Matthew presented the slides summarizing the main changes to the requirements and ongoing work. (The MNA framework draft was noted https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-fwk/) \* Loa Andersson: Didn't follow bit about IANA registry for user defined actions. The problem is that the standards part of the registry needs code points for the user defined actions. \* Matthew: Correct, it should be a range \* Tony Li: when can we expect the same update? \* Matthew: v02 was posted this past Monday 5. https://datatracker.ietf.org/doc/draft-jags-mpls-mna-hdr Presenter: Jaganbabu (Jags) RAJAMANICKAM Duration: 15 minutes (Note: previously https://datatracker.ietf.org/doc/draft-jags-mpls-ext-hdr) Jags presented the slides - No questions taken. Talk ran overtime, questions pushed to discussion slot at end of session. 6. https://datatracker.ietf.org/doc/draft-song-mpls-extension-header Presenter: Haoyu SONG Duration: 10 min Haoyu presented the slides which was a review of the draft. It was noted that the title of the draft changed to "MPLS Post-Stack Extension Header" to reflect the focus of the solution. It was noted that the authors are requesting the WG adopt the draft as the solution for supporting post-stack MNAs - see the slide Next Steps. \* Greg Mirsky: Confused with order of next steps - proposal is to adopt as a partial solution to MNA requirements, but as is the document doesn't address all the MNA requirements agreed by the WG. \* Haoyu: this document addresses the post stack encoding that can be adopted with other solutions \* Greg: would prefer a solution for all requirements, not partial solution 7. https://datatracker.ietf.org/doc/draft-kompella-mpls-mspl4fa https://datatracker.ietf.org/doc/draft-kompella-mpls-nffrr Presenter: Kireeti KOMPELLA Duration: 15 minutes (combined) Kireeti presented the slides. It was noted that Tony Li has been added to the author's list to reflect his major contribution. Next Steps: It was noted that the authors think they are ready for WG adoption, and would like to start doing some prototype implementations to get a sense of implementation details. To do this an early allocation of a bSPL is needed. The WG Chairs need to determine the order of the Next Steps requests \* Loa: would like a better alignment of the terminology with the framework.Likely not changing anything technical but would help reading the multiple documents. \* Kireeti: agree \* Loa: The the document is complete on iSD, but not as complete on pSD. \* Kireeti: yes, intended - this document focuses on the iSD part and points to Jeffrey's document for pSD which has a different set of authors. \* Loa: fine, but need to say it and provide pointers. \* Kireeti: yes agreed, will do \* Tarek: there is some resemblence with the one presented by Jagan earlier. The Open Design Team chairs are encouraging such similar solution to see if alignment can be reached. \* Kireeti: must discuss with co-authors, while desire is to encode multiple actions and data with the actions, the encodings are different. Desire is to implements what is in this draft and get feedback. If after that point it is possible to converge, will look at that. \* Loa: what is meant by implement? prototype or product \* Kireeti: alpha/lab implementation \* Loa: should do for all and compare \* Kireeti: cycles and resource issues. Others are welcome to do others and we can compare. Authors will focus on this draft and collect feedback just on this draft, looking at different drafts. \* Haoyu: comment - good idea to compare solution proposals from different proposals on overhead, performance, etc. On one side we can ask ASIC experts and also do a software evaluation very quickly to get some feedback on performance. \* Kireeti: good point but take in steps - step 1 is proposal implementable and what are the issues. Next step would be to do comparison with different implementations. then share the metrics \* Haoyu: different ideas to implement \* Kireeti: right, but one step at a time \* Wim Henderickx: not necessarily question to Kireeti, but to WG - on pSD we are converging. for iSD we have competing solutions where one is moving ahead. Is this aligned with the working group objectives. If each focuses on own, will we be able to converge onto most hardware. \* Kireeti: Just want to know if our particular approach works and get feedback. Convergence is important so if alternative approach did a similar preliminary implementation and then make comparisons would be good and provide input as how to converge them. \* Loa: can't answer what the WG's take is now, needs discussion, but on same page as Wim, need to look at how best to reach implementable compatible solution. Understandable that some companies want to proceed to test own solution, but will eventually need to come back to WG. \* Kireeti: yes, but implementation will provide valuable feedback and practical experience. We will come back and look at any agreeable metrics to see where we score. \* Tarek: as co-Chair understand desire to diverge, but the Open DT owes the group reasons for why can't converge. \* Kireeti: yes, but not there yet, just want to implement to get experience and then look at convergence and issues with convergence. \* Zafar Ali: What we have done in the past is to define metrics to use to give feedback to the WG. \* Kireeti: agree we would eventually need to define metrics \* Andy: you still have 3 slides... \* Kireeti: yes the NFFFRR draft - was a stand alone draft asking for a new bSPL, now just asks for a bit or action in the MNA document. This should discontinue gettin bogged down with the SPL. Other than this feedback received has been incorporated. It was noted that no alternatives proposed to the general problem. The authors ask for WG adoption. The authors also will include in the protoyping mentioned above. \* Ketan Talaulikar: there are issues with the solution that are related to BESS and SPRING work - will follow up on the mailing list. \* Kireeti: the goal here was a Data plane solution \* Wen Lin: am aware that 2 IETFs ago there was a proposal for an alternative solution. It wasn noted at that time that this solution is more scalable and that EVPN is a different types of service and that this solution is more general and flexible e.g., this applies for L3VPN and other services. \* Kireeti: we owe Ketan a response on the mailling list \* Ketan: we will discuss, suggest the BESS WG - not saying that the BESS draft is complete but should be considered \* Haoyu: interesting use case that should be considered in discussion. This action is applied at the MPLS path not at the edge. This implies some actions on the forwarding path, which makes things more flexible but not currently reflected in the other documents. \* Greg Mirsky: remind NFFRR is part of the use cases document adopted by the WG No further questions 8. Open Discussion (followup on Open DT activities) Duration: 40 min Andy opened the discussion * Tarek: question about order of actions - are we indicating that instack should be before post stack? With instack how should the order of instack be handled * Jags: We have in stack indicator and post stack indicator - how are the actions ordered? * Tarek: yes * Jags: the encoding reflects the order for instack. for post stack it is not covered. Referred to the Huawei draft * Tarek: thx looking forward to the details * Greg Mirsky: To Kireeti - is the intent to cooperate with Haoyu for the post stack data encoding? * Kireeti: yes the idea is that the implementaiton woudl focus on the instack piece, perhaps not for NFFRR but for network slice. The post stack is what is defined by Haoyu. * Greg: so you support the different encoding of in stack and post stack data * Kireeti: for instack it may need more compact way, in post stack don't have the same constraints so not tied to same format * Jie Dong: post stack data - according to prior call result pSD is a necessary component of the MNA requirements and we appear to be converging on the pSD encoding. Proposed to make the iSD an optional component to minimize its use. If want to minimize its use, then restrict its length. Need to also examine concerns about iSD label stack handling. * Loa: The discussion of order of actions: do we actually think that we can take them in the order specified and just go through the entire chain. OR do we need to give the actions semantics that determine their order. The order may be defined by different actions. What do we do about dependencies between actions? How is this handled? * Tarek: question on framework terminology - there is a term in the framework of Network Actions Substack - there is a stack for an action but need to clarify how to push and pop. The substack has an order. * Loa: This implies we can only do this for a homogenious set of actions on iSD or pSD. * Tarek: then needs to be clarified * Tony Li: a solution must define what the order of operation of the actions are. can be anything but must be deterministic and specified. * Loa: should do a list * Tony: can do that too, just needs to be specified * Loa: can it mix iSD and pSD * Tony: yes just so long as it is documented * Haoyu: the hop by hop type must come before end to end types. Other than that we shouldn't specify any order of operations. In many implementations they parse the header and then take them in the order of implementation. * John Drake: the specific order would need to be documented. * Gyan Mishra: in the case of both iSD and pSD are there any issues of processing pSD first then iSD or not doing them in parallel? Which would you do first? and what is the impact on performance. * Kireeti: the idea of iSD is more critical and is closer to the top of stack so implicitly the iSD is more urgent and should be done first. for pSD some things are hop by hop and some are end to end, which should be ordered that way. 5 min left - Andy cut queue * Rakesh Gandhi - to answer the order question - Jags draft has a good solution. e.g., an operation can be a series of opcodes or an opcode with series of flags to be executed in that order * Haoyu - don't think the urgency is criteria to put in stack or post stack - size and overhead have an impact which might force post stack but still be urgent. If you to parsing first then processing doesn't matter where in the pact the info is placed. Andy closed the meeting at noon local time. Meeting Chat comments (See https://zulip.ietf.org/#narrow/stream/15-pals/topic/jabber for details) * Jie Dong: +1 to Loa, terminology clarification and alignment is needed * Ketan Talaulikar: Why is early allocation of bSPL required for an internal prototype implementation? Perhaps I missed something there ... * Tony Li: Was Robert Raszuk invited to present? * Andy Malis: @Tony he didn't request a slot * Tony Li: :disappointed: * Tony Li: More generally, a solution needs to specify the order of operations. And it needs to be clear so that implementations are consistent. * Jie Dong: The draft I just mentioned can be found at: https://www.ietf.org/id/draft-dong-mpls-mna-encaps-00.html * Tony Li: Importance and urgency are orthogonal axes * Tony Li: If ordering is left to the implementer, we will have chaos * Ketan Talaulikar: +1 order has to be specified! * * * AGENDA INFORMATION FOR THE SESSION **\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}*\*\** ● Agenda https://datatracker.ietf.org/meeting/114/materials/agenda-114-pals ● Etherpad/CODIMD https://codimd.ietf.org/notes-ietf-114-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)