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
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.
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
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
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
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.
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