Minutes IETF114: pals: Tue 10:00
|Meeting Minutes||Pseudowire And LDP-enabled Services (pals) WG Snapshot|
|Title||Minutes IETF114: pals: Tue 10:00|
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
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
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
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
* 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
* 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
* 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
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
- 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.
- Tarek: question about order of actions - are we indicating that
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
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 INFORMATION FOR THE SESSION
● Jabber room: xmpp:firstname.lastname@example.org?join
● 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 email@example.com (Note: a Meetecho tech will be
monitoring Jabber during the meeting)