IETF 116 MPLS WG Meeting (version 00) Date/Time: Tuesday Session III, March 28, 2023 15:30 - 16:30 (local) Room: G403 Chairs: Loa Andersson/Tarek Saad/Nicolai Leymann Secretary: Mach Chen (notes courtesy Dave Sinicrope and others via Hedgedoc) Max participants noted: 93 Slides: https://datatracker.ietf.org/meeting/116/session/mpls/ Codimd for Notes Taking: https://codimd.ietf.org/notes-ietf-116-mpls/ Meetecho: http://www.meetecho.com/ietf116/mpls/ Jabber: xmpp:mpls@jabber.ietf.org?join 1. Working Group Status Duration: 10 mins Presenter: WG Chairs Nic presented the slides and went through the working group status. There was a question about the duration of the drafts ready for approval. The AD noted that he has drafts in his queue and that movement should occur after IETF 116. Stewart: would like an update from the AD on the SFL draft that is sitting in the queue for a while now. Andrew: acknowledge the presence of the document in the queue and planning on taking action on those after this meeting. 2. State-updating mechanism in RSVP-TE for MPLS network Duration: 10mins Presenter: David Dai ID: https://datatracker.ietf.org/doc/draft-gao-mpls-teas-rsvpte-state-update-05 David Dai presented the slides - asking for comment and feedback. Also asking for implementation. Vishnu Beeram: the problem statement is already resolved RFC-8370 2018 - some text in the draft is reproduced from RFC 8370 so hard ot understand why this draft is proposed. https://www.rfc-editor.org/rfc/rfc8370.html#section-3 covers this in detail From the Meetecho chat: *"Vishnu Beeram: To the authors of draft-gao-mpls-teas-rsvpte-state-update -- There isn't anything in this draft that is not already covered by the Refresh-Interval Independent (RI-RSVP) procedures discussed in RFC8370. Since RFC8370 is listed as a normative reference for this draft, I'm assuming that you have read it. So, please elaborate on the list why draft-gao-mpls-teas-rsvpte-state-update is needed."* David: will take comment and discuss with the authors Lou: does this belong in this working group? Would belong in the TEAS WG which has the remit for general RSVP-TE, if it is to be progressed. Loa: CCAMP as well Lou: CCAMP is not technology specific so not needed - just TEAS 3. Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP Duration: 10mins Presenter: Greg Mirsky ID: https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-bootstrap-clarify-03 Greg presented the slides asking for WG adoption no questions or comments 4. Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs) Duration: 10mins Presenter: Greg Mirsky ID: https://datatracker.ietf.org/doc/draft-mirsky-mpls-stamp-04 Greg presented the slides asking for WG adoption, comments and feedback Jared Mauch: is the response from the UDP port coming from the hardware path or punted to the control path? Greg: implementation specific, some could do it with hardware assist others not. what is important is how the timestamping is done and the packet handling is not as important. Jared: in order to protect the control plane, we use filters and are running out of filter space. When we look at a new UDP port that may punt info to the control plane it gives concern. Perhaps it could use LSP Ping or another mechanism that would prevent another port from being allocated. Greg: the purpose of using UDP ports was to make it less detectable but could use others. Want to use this as a performance monitoring protocol Jared: we shouldn't factor into all hardware limitations into new protocols but we should still consider them and think about them. Perhaps using specific port numbers may help mitigate concerns. Tarek: the current approach relies on LSP ping to bootstrap the STAMP session. If STAMP has applicability beyond MPLS dataplane should there be a generic approach to bootstrap the STAMP session? Greg: currently under consideration and needs to be put into documentation 5. mLDP/RSVP-TE P2MP Tunnel with SRv6 SID Duration: 10 min Presenter: Jeffrey Zhang ID: https://datatracker.ietf.org/doc/draft-zzhang-mpls-mldp-rsvp-p2mp-srv6-01 Jeffery presented the slides Eventually separate drafts on LDP vs RSVP but want to get the document started. Tarek: the SR nodes needs to be enabled with RSVP/LDP to support this proposal. This may not be always desirable. Why not just do RSVP end-to-end then? Jeffery: there are some operators that want to migrate away from MPLS so they can use this in the core and the rest of the tunnel can be MPLS based. Situation is end to end it is RSPV-TE going through and SRv6 core. 6. MNA for Performance Measurement with Alternate Marking Method & Encapsulation For MPLS Performance Measurement with Alternate Marking Method (2 drafts) Duration: 10 min Presenter: Weiqiang Cheng ID: https://datatracker.ietf.org/doc/draft-cx-mpls-mna-inband-pm-00 ID: https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation-05 Weiqiang presented the slides The draft has been around for a while Asking for WG LC Fang Gao: interested in the applicability of this to MPLS and MPLS-TP. Why is there not a different value space for the labels? Weiqiang: we listed some examples e.g., Hierarchical LSPs you need performance LSP and PW monitoring at different levels and both may be desirable. Just an example on how to use the Flow label. Loa: backward compatibility on the TC field Weiqiang: had some discussion on this during adoption call and text is in the draft - most people think what is in the document is OK. Approach follows other RFCs. 2nd draft presented by Weiqiang - no questions or comments Total presentation time: 60 mins Shuffling time: 0 mins