Hi Robert, Thank you for chiming in with responses on the thread. I went back through it and am responding to your points that haven't been explicitly addressed in other responses.
*Name and framing: *We're open to renaming. "Bandwidth validation" alone seems a bit limiting. Something like "Distributed Bandwidth Management using RSVP-TE over an SR-MPLS Forwarding Plane" might be apt. You're also right that we need a term like "RSVP-SR", and it isn't defined in the draft today. Someone offline suggested "RS-MPLS". We'll pick an appropriate term and use it consistently. *CSPF:* The authors felt it was obvious that the ingress runs CSPF over an IGP-learned TED, as in any RSVP-TE deployment. We can state it explicitly for clarity. *Operational considerations:* We'll add a section on non-TE traffic: planned and unplanned, and its interaction with QoS class design. *RFC 9256:* The draft extends RFC 8577 signaling. It doesn't define or modify SR Policy behavior, so we don't see it as updating RFC 9256. As noted in my reply to Andrew, an implementation could add a signaling knob to an SR Policy construct. If the WG sees value in specifying that, a separate document, for example in SPRING, could do so, and any update to RFC 9256 would belong there. *Controller-based bandwidth accounting:* Agreed. Controller-allocated and RSVP-SR bandwidth can share a link if they are accounted against separate partitions, and we'll make that explicit in the draft. Regards, -Pavan On Mon, Nov 9, 2026 at 11:32 AM Robert Raszuk <[email protected]> wrote: > Hi Andrew, > > Good comments ... Let me again provide my POV > > IMO what they are proposing does not touch data plane. So it will be SR >> Policy (with some level of BW accountability). I am saying it vaguely as >> that level depends on what is in the network. >> >> <Andrew> If so, wouldn't this be an extension to RFC 9256? As written, >> though, the draft abstract says "This document extends RFC 8577 so that >> RSVP-TE tunnels can use Segment Routing”. To me this is not an SR Policy >> with RSVP-TE signalling. >> > > > Yes .. that is why I stated the other day that this is an extension of SR > architecture. But I think in a positive direction overall meaning that SR > Policies today have segment BW awareness only when they are centrally > allocated. > > Computing those policies in a distributed way seems an advantage and > positive extension of RFC 9256. > > Now if the question states - Should this draft if progressed to RFC update > RFC9256 I would say Yes. > > I am just not so keen on undusting RSVP-TE for the stated purpose. (More > on that soon :). > > > >> The fundamental point is that coexistence of TE and non TE traffic even >> if vanilla MPLS RSVP-TE has the very same issue. Dealing with congestion is >> required by QoS. >> >> <Andrew> Agreed, but I don't think we're discussing data-plane congestion >> handling here, rather control-plane admission. The coexistence concern is >> primarily between RSVP-TE and engineered SR traffic on the same Adj-SIDs. >> Coexistence of TE and non-TE traffic is (ex: whether it be LDP, or >> SR-ISIS/OSPF or Flex Algo using Node SIDs etc..), I agree, unchanged >> challenges by this draft. The same ADJ-SID use brings in new challenges, >> one of which I believe creates a potential control-plane oscillating >> feedback loop. >> > > > Admission to TE LSPs happens on ingress. > > Of course if someone is using SR-MPLS instead of LDP that would fall under > non-TE traffic. > > If however someone is using controller BW accounting to create SR Policies > and this distributed technique those would be completely incompatible. > Draft should be clear about that. > > > <Andrew> this relates to the next question. Is this allowing RSVP-TE to >> use SR, or is this to bring RSVP-TE into SR? I do think there’s subtle >> differences to either of these views and right now the doc leans on >> “RSVP-TE to use SR”. >> > > > I think neither :) > > See the crux of the matter here that authors decided to use only subset of > what otherwise RSVP-TE does when constructing MPLS RSVP-TE. > > The confusion seems to be caused by the fact that we do not have a good > name for this subset. > > Colby once mentioned the "RSVP-SR" term .. but this term is not formally > defined anywhere (even in the body of the subject draft). > > > That is why I do believe those would be still SR Policies on ingress. This >> document is not proposing a new data plane construct. >> >> <Andrew> If so, then yes, we'll need clarity on this. I do see a >> difference between an "RSVP-TE tunnel using Adj-SIDs” vs an "SR Policy >> using RSVP-TE for admission control". The data-plane forwarding is the >> same, but the ecosystem, config, understanding, integration etc.. around it >> changes. >> > > Yup. > > It would know per link state TE advertisements. >> >> <Andrew> So I assume an LSR extension document is still needed / to be >> created (?). >> > > > Not sure about that. I think the assumption is still single TED and > vanilla CSPF on ingress nodes. > > > >> I think the hope is that there is no more real MPLS RSVP-TE running there >> :) >> >> <Andrew> As written, though, the draft still requires RSVP-TE message and >> state processing at every transit node, so what I would view as “real" >> RSVP-TE is very much still running on every hop. >> > > Yes to some extent ... This is where "RSVP-SR" term would come up helpful > .. if authors insist to use RSVP for this. > > Thx, > R. > > > > > > > > >> >> >> Thx, >> R. >> >> >> >> >> >> >> >> Thanks >> Andrew >> >> >> >> *From: *Robert Raszuk <[email protected]> >> *Date: *Saturday, November 7, 2026 at 12:20 PM >> *To: *Barth, Colby <[email protected]> >> *Cc: *Robert Raszuk <[email protected]>; Vishnu Pavan Beeram < >> [email protected]>; 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: [spring] Re: [mpls] 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. >> >> >> Hi Colby, >> >> Glad you agree ! But pls trust me I am still meeting people who do try >> to convince me that RSVP-TE reservations are done in the data plane and >> packets (after admission control) into their TE-LSPs will magically never >> compete for BW on any link with non TE traffic. We know this is not how it >> works. >> >> Here with this draft you are entering a new TE model territory ... >> partially same (control plane wise) and vastly different data plane wise >> running on shared SR-MPLS or SRv6 underlay. >> >> I have no objections to adopting this document - perhaps as experimental >> for the time being, but irrespective of how it will progress in IETF I >> would encourage authors to add an Operational section discussing how to >> deal with potential congestion caused by non-TE traffic. Irrespective if >> that non-TE traffic is planned, unplanned (example transient loops), if it >> is unicast or multicast etc ... >> >> Kind regards, >> Robert >> >> >> On Sat, Nov 7, 2026 at 6:03 PM Barth, Colby <jonathan.barth= >> [email protected]> wrote: >> >> 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]> 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]> 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 >> <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]> >> *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/ >> <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] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> spring 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]
