Hi Andrew, all, Thank you for the review and the questions. They help clarify the scope and the value of the draft. Responses below.
*1. Bandwidth management / RFC 8426* Your analysis of the shared Adj-SID is correct for a deployment where SR-native traffic is also steered over the same Adj-SIDs: the transit node cannot separate the two, so measurement-based options such as RFC 8426 Section 3.3 and Section 3.5 do not apply. This deserves explicit treatment in the document, and we will add it. When we wrote RFC 8426, SR traffic was assumed to be unreserved, and distributed bandwidth engineering was not envisioned as an SR function. The RFC therefore treats SR load as something to be measured around RSVP-TE. This document addresses the different case where distributed bandwidth engineering is provided by RSVP-TE over an SR-MPLS data plane. The deployment model this version targets is the one RFC 8577 is positioned for: SR-MPLS is the forwarding plane for RSVP-TE-signaled tunnels, which provide distributed bandwidth engineering, and no SR-native traffic is steered over the Adj-SIDs selected by this specification. In that model: - the traffic on those Adj-SIDs is the traffic admitted by RSVP-TE, so a per-label counter reflects RSVP-TE usage, as with RFC 8577 TE link labels; - other traffic on the link is not reflected in RSVP-TE reservations. Prefix/node-SID shortest-path traffic uses different labels, and transient traffic such as TI-LFA repair paths is short-lived. This is accounted for as unengineered background traffic through reservable-bandwidth headroom, exactly as IGP and LDP traffic is today. In the next version we will state this scope explicitly in Section 1 and Section 7, and say that where SR-native traffic is steered over the same Adj-SIDs, the coexistence problem described in RFC 8426 arises and is not addressed by this document. For deployments that want to run SR-native engineered traffic alongside, a natural extension is an IGP-advertised Adj-SID carrying a marker that it is reserved for RSVP-TE bandwidth engineering. That restores per-label separation and would be defined in a separate IGP extension document, as we already anticipate for the protection extension in Section 6.2. *2. Section 1 benefits* The motivation is operators who run SR-MPLS as their forwarding plane and need distributed, bandwidth-aware TE. This lets them do so using the Adj-SIDs that the IGP already advertises for each adjacency, without introducing a separate label allocation scheme for RSVP-TE. We will sharpen the benefits in a subsequent version: - Operational simplicity (single label allocation): The value is no separate TE-label allocator for these tunnels, optional persistence via the Adj-SID P-flag, and a label stack identical to what an SR Policy headend would impose. We will drop the wording about label exhaustion and fragmentation, which are not the main driver on current platforms. - IGP-native discovery: You are right that signaling still has to complete and that the RRO remains authoritative (Section 4.1). We will reword the benefit accordingly. Because the Adj-SIDs are in the IGP-learned TED, the ingress's own path computation can determine the label stack, check MSD/ETLD feasibility, identify any delegation hops and, where needed, constrain Adj-SID selection with ERO Label sub-objects before signaling, and can cross-check the RRO against the result. The same applies if an external path computation engine computes the path. - Interoperability: We will reframe this benefit as reuse of existing SR-MPLS capabilities and drop the data-plane-conflict wording. The tunnels use Adj-SIDs that nodes already allocate and advertise, and can leverage SR OAM. These are clarifications to the text and scope of the document; none of them changes the signaling procedures or protocol extensions in the draft. We will handle them in the next version. Thanks again for the thorough review; it will make the document better. Regards, -Pavan On Fri, Nov 6, 2026 at 12:24 PM Andrew Stone (Nokia) <andrew.stone= [email protected]> wrote: > Hi all, authors, > > I have some concerns with some aspects of this draft, with comments and > questions split into two categories. Any clarification appreciated. > > > 1. Bandwidth management - coexistence problem > > Section 7: I don't follow how bandwidth admission control will function. > Unless I'm missing something, the same Adj-SIDs will carry SR-native > traffic pushed from any ingress, and that load never appears in RSVP-TE > reservations, which only account for the signalled LSPs. RSVP-TE would > therefore be reserving bandwidth on links whose actual load it cannot see > or control. > > This looks to be the RSVP-TE and SR coexistence problem described in RFC > 8426 but the shared label makes it harder. > > For example, the options in RFC 8426 Sections 3.3 and 3.5 depend on > measuring SR utilization on each interface, but a transit node can no > longer separate SR traffic from RSVP-TE traffic when both use the same > Adj-SID. The SR traffic measured will contain none, some, or all of the > RSVP-TE signalled traffic on that Adj-SID. Any RSVP-TE traffic counted as > SR utilization reduces RSVP-TE's available bandwidth, creating a feedback > loop. The RSVP-TE related bandwidth may be counted twice. > > The other RFC 8426 options don't help either: static partitioning (RFC > 8426 Section 3.1) gives up shared bandwidth, and centralized management > (RFC 8426 Section 3.2), removes a goal for this draft. > > Section 7 of this document does not seem to address RFC 8426 within > context, which feels light given that Section 1 presents bandwidth > admission control as what RSVP-TE continues to provide. In the context of > bandwidth admission control, I don't see the gains this brings over RFC8577 > or classic RSVP-TE. > > > > 2. Benefits listed in Section 1 > > These benefits don't seem significant to me: > > - Single label allocation: I don't think local label exhaustion is a risk, > since this saves one label per TE link compared to RFC8577. What is the > concern with allocation fragmentation? It also doesn't help general RSVP-TE > scaling, since the per-LSP RSVP-TE state on each node is still there. > > - IGP-native discovery: Agreed, IGP flooding is useful, but Section 1 says > the ingress doesn't need to wait for Resv processing, while Section 4.1 > says it must still use the labels from the RRO, so it waits anyway. Is the > faster pre-computation really that significant? > > - Interoperability: I agree the same labels serve all data-plane traffic > in this proposal, but given the bandwidth concern in point 1, I'm not sure > this is actually a benefit. For the comment about data-plane conflict: what > data-plane conflict does this avoid, when it is all MPLS forwarding anyway? > > Thanks > Andrew > > > > > *From: *Tarek Saad <[email protected]> > *Date: *Tuesday, November 3, 2026 at 1:06 PM > *To: *[email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] < > [email protected]>; spring <[email protected]>; TEAS WG ( > [email protected]) <[email protected]> > *Cc: *spring Chairs <[email protected]>; TEAS WG Chairs < > [email protected]> > *Subject: *[spring] Re: Call for adoption: draft-beeram-mpls-rsvp-sr-01 > (Ends 2026-11-17) > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > Also adding TEAS WG for relevance to RSVP-TE protocol. > > Regards, > > *From: *Tarek Saad <[email protected]> > *Date: *Tuesday, November 3, 2026 at 10:03 AM > *To: *[email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] < > [email protected]>; spring <[email protected]> > *Cc: *spring Chairs <[email protected]> > *Subject: *Re: Call for adoption: draft-beeram-mpls-rsvp-sr-01 (Ends > 2026-11-17) > > Adding the SPRING WG to this thread due to the document's relevance to > Segment Routing. > > Regards, > Tarek (as MPLS WG chair) > > *From: *Tarek Saad via Datatracker <[email protected]> > *Date: *Sunday, November 1, 2026 at 8:35 PM > *To: *[email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] < > [email protected]> > *Subject: *Call for adoption: draft-beeram-mpls-rsvp-sr-01 (Ends > 2026-11-17) > > This message starts a mpls WG Call for Adoption of: > draft-beeram-mpls-rsvp-sr-01 > > This Working Group Call for Adoption ends on 2026-11-17 > > Abstract: > RFC 8577 introduced the concept of signaling RSVP-TE tunnels on a > shared MPLS forwarding plane using preinstalled "TE link labels". > Those labels are functionally equivalent to Segment Routing (SR) > Adjacency Segment Identifiers (Adj-SIDs) but are allocated and > distributed solely via RSVP-TE signaling. > > This document extends RFC 8577 so that RSVP-TE tunnels can use > Segment Routing over MPLS (SR-MPLS) Adj-SIDs, as specified in RFC > 8402 and RFC 8660, in place of TE link labels. It restricts scope to > Adj-SIDs attached to a single unidirectional adjacency and defines > the signaling procedures and protocol extensions required to couple > the RSVP-TE control plane with the SR-MPLS data plane. > > Please reply to this message and indicate whether or not you support > adoption > of this Internet-Draft by the mpls WG. Comments to explain your preference > are greatly appreciated. Please reply to all recipients of this message and > include this message in your response. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > Appropriate IPR disclosures required for full conformance with the > provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-beeram-mpls-rsvp-sr/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-beeram-mpls-rsvp-sr-01 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-beeram-mpls-rsvp-sr-01 >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
