Hi Pavan,
> 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. > You are welcome :) > *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. > Actually IMO it does extend RFC9256. Reason being is that today RFC9256 does not support distributed bw management for SR Policy Paths. > *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. > I would rather recommend against mixing those two paradigms of bw management in a single network. Not adding a text which generates even more complexity. Regards, Robert > 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]
