November 8, 2021 (UTC) 14:30-15:30 Monday Session II Slides: https://datatracker.ietf.org/meeting/112/session/mpls/ Codimd for Notes Taking: https://codimd.ietf.org/notes-ietf-112-mpls/ Meetecho: http://www.meetecho.com/ietf112/mpls/ Jabber: xmpp:mpls@jabber.ietf.org?join Chairs: Loa Andersson, Tarek Saad and Nicolai Leymann Secretary: Mach Chen 1. Administrivia Presenter: WG Chairs, (5 mins) [Tarek]: Note Well and IETF Guidelines for Conduct [Tarek]: There is a new github (http://github.com/ietf-wg-mpls) for the MPLS Working Group. Please use it and add your input/comments. 2. WG Status & MPLS Open DT Report Presenter: Tarek & Loa (15 mins) [Tarek]: If you have updates to your drafts, please let us know (also for upcoming IETF meetings). [Tarek]: One new RFC: RFC9041 [Loa]: Authors of draft-ietf-mpls-lsp-ping-ospfv3-codepoint have confirmed that they will respsond to open questions from AD. [Pavan]: Took a while to update draft-ietf-mpls-ri-rsvp-frr after it was send back by AD to WG. Draft can progress again. [Rakesh]: For draft-ietf-mpls-rfc6374-sr email was send, believe document ready for WG last call. [Tarek]: Chairs take action. [Stewart]: On SFL-control, the draft is ready can we proceed to next step? [Loa]: Chairs will take action. [Shraddha]: For draft-ietf-mpls-epe-oam, authors think it is ready for WGLC. [Tarek]: Please note that there will be in addition the the MPLS session a joint session with PALS and DetNet later today (Session 3). [Tarek]: No outstanding action for draft-ietf-mpls-inband-pm-encapsulation on authors from IETF111 and move to next step accordingly. Review was done by MPLS-RT, comments were addressed. [Kireeti]: LARP is ready for WG adoption. Can we get this done? [Loa]: Report on Design Team. DT was formed to guarantee that we have a future proof architecture. Scoped to MPLS Indicators and Ancilliary Data (or “MIAD”). Ancillary Data may take different forms: ISD (In Stack Data), PSD (Post Stack Data) or NoD (No Data). Functions that are already specified must also work in the future. Several drafts are available, MIAD Architecture and Framework not posted yet. Work will continue in DT meetings (Thursdays). 3. Encapsulation of Simple TWAMP (STAMP) for Pseudowires in MPLS Networks Draft: https://datatracker.ietf.org/doc/draft-gandhi-mpls-stamp-pw Presenter: Rakesh Gandhi (10 mins) [Rakesh]: Requirements are encapsulation fo STAMP test packets for MPLS PWs and packets need to follow smake (ECMP) path as data packets. Scope is RFC8762/RFC8972 and P2P and P2MP MPLS PWs. [Greg]: Why do we need to define encapsulation for no IP/UDP? We already have it defined for IP/UDP. [Rakesh]: This is for traffic that is non-IP. We want the probe packet to follow the same path (i.e. not to use IP/UDP). [Tarek]: Take questions/discussion to the list. [Stewart]: Wanted to ask the same questions as Greg. [Stewart]: Suggest a separate side meeting with the group interested to discuss in more detail. 4. A YANG Model for MPLS MSD Draft: https://datatracker.ietf.org/doc/draft-qu-mpls-mpls-msd-yang Presenter: Yinzhen Qu (10 mins) [Yingzhen]: Maximum SID Depth were defined in RFC8476/RFC8491. MSD YANG augmentation of RFC8960. Was decided to move MSD YANG as a split-off from RFC9020 to separate draft. [Yingzhen]: Can we go for WG adoption after this IETF? [Loa]: Are you asking for comments or WG adoption? [Yingzhen]: Comments were addressed. Invite people to review. Additional comments will be addressed after adoption. [Tarek]: Is it maximum segment, or maximum label depth? [Yingzhen]: Yes, can be changed to label [Jeff]: Is there a return value in case node does not know MSD? [Yingzhen]: Software only knows about features node supports. [Jeff]: Let’s move the discussion to the list. [Tarek]: Why do we have type/value? [Yingzhen]: Type is defined in RFC8476 also Entropy Label possible. [Loa]: Running out of time, take it to the list. 5. Deterministic QoS for MPLS data plane considerations Draft: https://datatracker.ietf.org/doc/draft-eckert-detnet-mpls-tc-tcqf Presenter: Toerless ECKERT (10 mins) [Toerless]: Would like to see more people from MPLS involved in DetNet to see how we can evolve the draft. [Toerless]: MPLS only allows per hop/per flow bounded latency. Not in line with preferred service provider MLPS designs. Several options to overcome this problem (with and without extensions/changes to MPLS packet header / processing). [Toerless]: Would like to see one well working, proven Service Provider Class bounded latency for DetNet with MPLS. Also would like to start work on longer-term QoS header effort. [Loa]: What do you want to get from the presentation in MPLS WG? [Toerless]: Want to get MPLS folks to understand the problem. If we want to have DetNet as future driver for MPLS networks, we need to have a bounded latency solution which fit SP deployments.