IETF 118 MPLS WG Meeting (version 01)

Date/Time: Thursday Session II, November 9, 2023 13:00 - 14:30 (local)
Room: Congress Hall 1

Chairs: Tarek Saad/Nicolai Leymann/Adrian Farrel
Secretary: Mach Chen

Codimd for Notes Taking:

Note-takers: Tarek and Adrian

  1. Working Group Status
    Duration: 10 mins
    Presenter: WG Chairs

[Nic] Welcome to Adrian as a new co-chair
[Tarek/Sasha/all] Thank you Loa for being an exemplary WG chair for
more than 20 years and for the many contributions.

  1. Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment
    Identifiers (SIDs) with MPLS Data Planes
    Duration: 10mins
    Presenter: Xiao Min

[Adrian] What is the status of the SPRING path segment draft?
[Xiaomin] In IESG evaluation. Multiple implementations.
[Weiqiang Cheng, CMCC] I'm a co-author of the SPRING draft. It is
passed IESG evaluation.
[Adrian] Request noted. Chairs will evaluate and get back.
[Andrew/Jim/Bruno] The SPRING path segment document is in the IESG
queue, but has not passed already. Placed on next IESG telechat at end
of November.

  1. Encapsulation of Simple TWAMP (STAMP) for Pseudowires in MPLS
    Duration: 10 mins
    Presenter: Rakesh Gandhi

[Greg] For type 3 VCCV, how would it work in multi-segment PW?
[Rakesh] Good comment, not covered in draft right now. We can discuss.

[Greg] There is a consideration for non-IP encpasulation. But that is
long past history, and I'm not sure anyone is interested.
[Adrian] Should we reach out to IPPM? Is it just using IPPM
[Greg] IPPM does not define any encapsulation. Thee is no clear
indication how the reflected packet is encpasulated. There is assumption
that PW is bidirectional and same encap is used for the reflected
packet. For BFD we use just one ACH channel.
[Rakesh] Draft has been around for couple of years. I always mention
this draft (and SPRING draft) in IPPM.
[Adrian] Good so they are aware and we don't need to chase. We'll just
let them know when we do an adoption poll.

  1. Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data

    Duration: 10mins
    Presenter: Greg Mirsky

[Sasha] Have you considered merging this document with the MNA
framework document?
[Adrian] It is a possibility.
[Greg] We are asking on feedback on the current content of the
document. Maybe some use cases are relevant any more.
[Sasha] I am suggesting a further option for your list of potential
ways to progress the document.
[Greg] We will follow the guidance of the WG and chairs
[Tony] Personally, think the document is stable and can be progressed.
Framework and Requirements are based on this one.
[Greg] Based on recent feedback we got, at least one of the usecases
is not needed any more.
[Tony] So fix it and ship it.
[Stewart] I'm aware of research lab interested in adding time in the
packet. I support shipping it.
[Quang Xiong] About the DETNET usecase, no consensus as mentioned.
Suggest updating section 2.5 to reference DETNET scaling requirements
[Greg] Need to check with DETNET WG. My understanding is that there
are multiple proposals for how to do scaling in DETNET, but nothing
agreed. Carrying explicit data in the data packet is one of the possible
[Quang] Maybe the time information can be generic.
[Greg] I think it more practical if MNA supports mechanisms that are
agreed upon by other WGs.
[Rakesh Gandhi] Agree with Tony on document progressing to be
published. These are (example) usecases, not a complete set. I can work
on other use cases that are not in this document.
[Greg] If we consider the option to keep it alive, then new usecases
can be added as they are agreed on.
[Rakesh] I am an author of an I-D in SPRING that is another MNA use
case not in this document.
[Adrian] The document is a list of possible use cases. It is not
exclusive. It is possible to have new use cases in the future that are
not in the document.

[Tony] How is MNA being progressed?
[Adrian] Carefully. Chairs have been approaching individuals to
understand some of the concerns are and what compromises are willing to
make. Soon, is what we're projecting to getting the MNA requirement
draft progressed, and to open the way for next documents.
[Tony] Any specific date?
[Adrian] Too soon to put a date. The chairs will try to put out a

[Lou] As DETNET co-chair, no consensus for the need for that usecase.
If you say there is a requirement that traces back to DETNET, we would
not support that as a WG, although there would be individuals that
support that. As a usecase, if you phrase it as a possible thing that
somebody might want, then it is fine. Concern on taking use case and
deriving MNA requirement from it and driving solution work.
[Greg] Thanks for clarifying. The purpose was for the usecase draft to
drive requirements. If a usecase is not required by a group (not
individuals) then too early to reflect in requirements.
[Lou] It's premature. I'm not saying we won't get there, but we have
other topics to deal with first.
[Adrian] Tony said in chat "MNA is extensible". Usecases draft could
distinguish between 'motivational' (we have this need now and MNA is
going to solve it for us) and 'aspirational' (if we had MNA, this is
what we might do with it) use cases
[Greg] Usecases that remain [in the I-D] will be what MNA solutions
will need to support. Other things that we as individual contributors
consider using MNA for can be presented as individual drafts.

[János Farkas from chat] Sorry if I confused the terms "use case" and
"solution". Having timing information in packet header is a solution
from DetNet's perspective. DetNet WG has not reached consensus on what
solution to go for to meet scaling requirements.

  1. MPLS Encapsulation for Deterministic Latency Network Action
    Duration: 10mins
    Presenter: Xueyan Song

[Greg] Do you invisage DLNA will be applied to DETNET OAM packets as
[Xueyan] Not considered yet.
[Greg] DETNET ACH is larger than DETNET CW, so it complicate
processing of DLNA depending on data or control. It seems ISD option is
[Xueyan] We will discuss this further.

[János via chat] I'd repeat what we said: DetNet WG has a WG document
on scaling requirements, but no other WG document yet no solution
developed we have meetings to work on solution to address scaling

[Rakesh] I'm co-author, but DETNET may or may not be ready for full
interest. Can bounded latency be an MPLS WG use case instead? Then if
DETNET is interested they can pick it up.
[Lou] DETNET may likely suggest things to support bounded latency
conditions. This is a topic we will get to in DETNET WG. [Flip back to
slide 6] Discussion about accumulated timing info. You may want this,
but we have to be careful on what to carry (still under consideration) -
For example, 'accumulated timing' may be very expensive in HW. The
reason DETNET is not there yet is because we don't have agreement on
what we want to do for queuing. Then can choose right info to go in
dataplane and end up in HW.

  1. A YANG Data Model for MPLS-TE Topology
    Duration: 5mins
    Presenter: Italo Busi

[Adrian] Are you asking for casual review or is there a specific
[Italo] General review/comments are welcome. No specific issue.

  1. Private Line Emulation over Packet Switched Networks (PALS)
    Duration: 10 min
    Presenter: Christian Schmutzer

[Adrian] This is being presented in MPLS WG since PALS is not meeting
this time and this is a little related to MPLS.

[Adrian] Anything you're looking for from MPLS WG since MPLS is hardly
mentioned in this draft?
[Christian] At this stage, not.

[Adrian] Do the PALS chairs want to say anything?
[Andy as PALS co-chair] I have been working with Christian on this.
Still interest in PALS on this.

[Sasha] Don't understand the need for endpoint ID in signaling. Why
not use FEC129 instead of FEC128 to verify endpoint? There is existing
support in RFC 8077 including local/remote AC groups and unique
identfiers. IMO, no need for new dedicated interface parameter.
[Christian] Good suggestion. Will evaluate this. Motivation for new
TLV was looking at OTN where customers encode specific things in the
identifiers - trying to match this operational model.
[Sasha] Monitoriing and path trace mismatch existed in SDH/SONET long
before OTN. Usually considered as critical alarm. I think you have all
necessary tools
[Christian] Will try to connect with you offline.