Robert, Your concerns, while valid, are no different than any other current network deployment. We have certain tools available for operators to use to handle potential congestion (strategic and tactical). What we propose in this draft does not appreciably change them or prevent their use.
In a 100% SR network where there are both native-SR and RSVP-SR forwarding there already exist tools that can be used so-as to ensure the procedures in RFC 8426 coexistence are still applicable and relevant. If one chooses not to use those tools, then it is not applicable. As Pavan stated, we can certainly tighten up the wording in a few places to clarify things and I do like the suggested title change. Thnx, -- Colby From: Robert Raszuk <[email protected]> Date: Saturday, November 7, 2026 at 10:44 AM To: Vishnu Pavan Beeram <[email protected]> Cc: Andrew Stone (Nokia) <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; spring <[email protected]>; TEAS WG ([email protected]) <[email protected]>; spring Chairs <[email protected]>; TEAS WG Chairs <[email protected]> Subject: Re: [mpls] Re: Call for adoption: draft-beeram-mpls-rsvp-sr-01 (Ends 2026-11-17) Hi Vishnu, Ok so we are clear on the accounting part now. But this is only one side of the coin - arguably less important one if compared with the other side of the same coin. Traffic co-existence on a link in no 100% TE networks may result in BW contention on each egress interface during events of congestion. Same Adj-SID or different one is really orthogonal here. Last time I checked Adj-SIDs (just like MPLS labels) are used for forwarding not for QoS. And I have not seen anywhere in the draft a solid section discussing this deployment where there is unaccounted non TE traffic flowing via the same SR-MPLS network. Sure you can deal with this using QoS on each node, but with 3 EXP bits the network QoS design may already be using all of the available classes. Then deploying this TE scheme requires a complete network QoS treatment redesign ... Cheers, R. On Sat, Nov 7, 2026 at 4:31 PM Vishnu Pavan Beeram <[email protected]<mailto:[email protected]>> wrote: Hi Robert, My earlier response addressed the coexistence question Andrew raised: SR-native and RSVP-SR traffic using the same Adj-SID. That was a statement about scope, not a normative "MUST NOT" and not a change to the SR architecture. If SR-native traffic is steered over the same Adj-SIDs that RSVP-SR selects, the transit node can't separate the two. That's the RFC 8426 coexistence problem. The draft places no restriction on how Adj-SIDs are used in SR. It only selects Adj-SIDs for RSVP-SR tunnels. The scope statement describes the deployment model the current version targets (no SR-native traffic on those Adj-SIDs), not a constraint on SR deployments. A dedicated Adj-SID reserved for RSVP-TE bandwidth engineering will address this concern, and it is consistent with your suggestion. With different Adj-SIDs there is no coexistence issue. Traffic on the dedicated Adj-SID is only the traffic admitted by RSVP-TE, so a per-SID counter reflects RSVP-TE usage and the reservations stay accurate. Regards, -Pavan On Sat, Nov 7, 2026 at 7:03 AM Robert Raszuk <[email protected]<mailto:[email protected]>> wrote: Hi Vishnu, You said: * 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. So tell me how does this matter if per adj SID/uSID counter (not per label any more) reflects only admitted by ingress traffic ? Interface still needs QoS to differentiate TE from non TE traffic to prioritize the TE traffic over non TE traffic. And you said something quite important ... traffic which is not TE MUST NOT use adj SIDs. That seems a serious limitation and modification to the base SR architecture. I would perhaps go the other way and recommend to allocate a new adj SID solely to be used for BW accounted TE purposes. Just like you say here: "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." Thx, R. On Sat, Nov 7, 2026 at 12:30 AM Vishnu Pavan Beeram <[email protected]<mailto:[email protected]>> wrote: 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) <[email protected]<mailto:[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]<mailto:[email protected]>> Date: Tuesday, November 3, 2026 at 1:06 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; spring <[email protected]<mailto:[email protected]>>; TEAS WG ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>> Cc: spring Chairs <[email protected]<mailto:[email protected]>>; TEAS WG Chairs <[email protected]<mailto:[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<https://urldefense.com/v3/__http://nok.it/ext__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wEcmnS9O$> for additional information. Also adding TEAS WG for relevance to RSVP-TE protocol. Regards, From: Tarek Saad <[email protected]<mailto:[email protected]>> Date: Tuesday, November 3, 2026 at 10:03 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; spring <[email protected]<mailto:[email protected]>> Cc: spring Chairs <[email protected]<mailto:[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]<mailto:[email protected]>> Date: Sunday, November 1, 2026 at 8:35 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[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/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wALTyg6y$> [2] https://datatracker.ietf.org/doc/bcp79/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wHFQxtTj$> [3] https://datatracker.ietf.org/doc/rfc6701/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wMz8NU88$> The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-beeram-mpls-rsvp-sr/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-beeram-mpls-rsvp-sr/__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wM6I_BvH$> There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-beeram-mpls-rsvp-sr-01<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-beeram-mpls-rsvp-sr-01__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wI89Fm_R$> A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-beeram-mpls-rsvp-sr-01<https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-beeram-mpls-rsvp-sr-01__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wL8KYrTa$> _______________________________________________ mpls mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
