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)