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 Slides: https://datatracker.ietf.org/meeting/118/session/mpls/ Codimd for Notes Taking: https://codimd.ietf.org/notes-ietf-118-mpls/ Meetecho: http://www.meetecho.com/ietf118/mpls/ Zulip: https://zulip.ietf.org/#narrow/stream/118-mpls 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 ID: https://datatracker.ietf.org/doc/draft-xp-mpls-spring-lsp-ping-path-sid \[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 Networks Duration: 10 mins Presenter: Rakesh Gandhi ID: https://datatracker.ietf.org/doc/draft-gandhi-mpls-stamp-pw \[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 encapsulations? \[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 ID: https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecase \[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 draft. \[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 solutions. \[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 date. \[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 ID: https://datatracker.ietf.org/doc/draft-sx-mpls-detnet-bounded-latency/ \[Greg\] Do you invisage DLNA will be applied to DETNET OAM packets as well? \[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 simpler. \[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 requirements \[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 ID: https://datatracker.ietf.org/doc/draft-busizheng-teas-yang-te-mpls-topology-06 \[Adrian\] Are you asking for casual review or is there a specific issue? \[Italo\] General review/comments are welcome. No specific issue. 1. Private Line Emulation over Packet Switched Networks (PALS) Duration: 10 min Presenter: Christian Schmutzer ID: https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-01 \[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.