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]> 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]> 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) <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 >>> >> _______________________________________________ >> mpls mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
