Skip to main content

Minutes IETF114: pals: Tue 10:00

Meeting Minutes Pseudowire And LDP-enabled Services (pals) WG Snapshot
Title Minutes IETF114: pals: Tue 10:00
State Active
Other versions markdown
Last updated 2022-07-28


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
    No questions or comments.


    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

    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
    No questions or comments

    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
    * 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

    Presenter: Jaganbabu (Jags) RAJAMANICKAM
    Duration: 15 minutes
    (Note: previously

    Jags presented the slides -
    No questions taken. Talk ran overtime, questions pushed to
    discussion slot at end of session.

    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
    * 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

    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
    * 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
    * 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
    • 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
    • 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 for details)

  • Jie Dong: +1 to Loa, terminology clarification and alignment is

  • 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

  • Jie Dong: The draft I just mentioned can be found at:

  • 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
● Etherpad/CODIMD
● Jabber room:
● MPLS Open Design Team Wiki (The MPLS open design team keeps a log of
its work here:
● If you have any general issues with Meetecho, the meeting audio, etc.,
send an email to (Note: a Meetecho tech will be
monitoring Jabber during the meeting)