[Teas] Re: My comments on draft-kompella-teas-mpte

["Zafar Ali (zali)" <[e-mail]>]

Hi Pavan

Thanks for your follow-up. Sorry for delay in the follow-up due to summer.

Thanks for advocating for authors to “citing (SRTE Architecture) RFC 9256 as related work to explicitly contrast the two approaches”.
My main intention was also for this document to capture the existing state of the art and technologies in the MPTE space.

Taking a step back, does the author want to position this document as an architecture/ framework document for MPTE? Or realizing MPTE with RSVP-TE?

For details, please see [ZA] in-line.


From: Vishnu Pavan Beeram <[e-mail]>
Date: Thursday, July 23, 2026 at 9:56 AM
To: Zafar Ali (zali) <zali=[e-mail]>
Cc: [e-mail] <[e-mail]>; TEAS WG <[e-mail]>; Zafar Ali (zali) <[e-mail]>
Subject: Re: [Teas] My comments on draft-kompella-teas-mpte

{as a WG participant}

Hi Zafar,

Thank you for posting your comments. I'd like to address the technical points you raised.

On the quote "One can either have TE or multipathing, but not both":

This is a problem statement describing the current state of practice with conventional mechanisms. With conventional P2P TE tunnels, you get traffic engineering but not multipathing. With ECMP, you get multipathing but not traffic engineering.

[ZA] I do not understand what you mean by “conventional P2P TE tunnels”? The draft-kompella-teas-mpte also does not define any such term or scope. However, SRTE is also “P2P TE tunnels” supporting notion of multi-path TE using weighted-ECMP (W-ECMP) segment-list and forwarding “based according to the relative weight of each segment list” [RFC9256]. A segment list may contain node SIDs or adjacency SIDs or both. Please see my earlier question on scope/ position the document.

The MPTE draft proposes to combine both in a specific way (via DAGs with per-junction weighted load-balancing).

[ZA] As I mentioned earlier, RFC9256 defines the notion of “Binding SID,” which supports multi-path TE just like the “Junction nodes” specified in draft-kompella-teas-mpte.

Moreover, the authors explicitly acknowledge the existence of prior non-DAG-based multipath TE approaches. The companion signaling document (draft-kbr-teas-mptersvp-04, Section 1.3) discusses "RSVP Multipath Traffic Engineered Container (MPTEC) Tunnels" — a pre-existing, deployed approach to combining TE and multipath — and contrasts it with the DAG-based approach. Prior presentations to this WG (IETF 123: https://datatracker.ietf.org/meeting/123/materials/slides-123-teas-07-multipath-traffic-engineering-02) also discuss existing multipath TE approaches as context.

[ZA] There are two issues with this 1) This does not address omission of multi-paths support in SRTE in draft-kompella-teas-mpte 2) The draft-kompella-teas-mpte does not directly reference the MPTEC work mentioned above.

A document that openly acknowledges and contrasts with prior multipath TE work is not claiming to have invented the term.

[ZA] The draft explicitly states: "One can either have TE or multipathing, but not both”. It is missing reference and acknowledgement of existence of multi-paths support in SRTE.

<snip>

On RFC 9256 and SR Policy W-ECMP:

RFC 9256 defines weighted segment lists within an SR Policy, where the headend (ingress) splits traffic across candidate paths based on relative weights. This is headend-only weighted multipathing — the policy is instantiated and the traffic split decision is made solely at the ingress.

[ZA] RFC9256 BSID usage is never limited solely at the ingress. RFC9256 is an architecture document. It defines BSID construct with W-ECMP forwarding “based according to the relative weight of each segment list”. However, during progression of [RFC 9256], the WG feedback was to keep use-cases into a separate draft [draft-filsfils-spring-sr-policy-considerations]. [RFC 9256] references [draft-filsfils-spring-sr-policy-considerations]. SR Policy consideration draft was not developed further because there was no interest in the working group at that point.
Nonetheless, [RFC9256] section 8.3 “Incoming Active SID is a BSID” defines specifically defines procedure for steering into a transit policy using its BSID. Furthermore, RFC9857 specifies SR policy advertisement in BGP-LS and defines a T-flag as follows:
•     “T-Flag:  Indicates that the candidate path has been marked as eligible for use as a transit policy on the headend when set and not eligible for use as a transit policy when clear. Transit policy is a policy whose BSID can be used in the segment list of another SR Policy.  Refer to Section 8.3 of [RFC9256] for steering into a transit policy using its BSID.” [RFC9857].


Importantly, RFC 9256 does not advocate the use of Binding SIDs at every hop along the policy paths to achieve per-hop weighted load-balancing.

[ZA] Does MPTE requires use of Junction nodes “at every hop along the policy paths to achieve per-hop weighted load-balancing”. If yes, it would be good if authors can specify this aspect to differentiate.

That would be an MPTE-like construct built on top of SR Policy — which is exactly what draft-stone-spring-mpte-sr proposes — not something RFC 9256 itself defines or envisions.

[ZA] Please see response above.

MPTE is architecturally distinct: it defines weighted load-balancing at every junction node in a Directed Acyclic Graph, not just at the ingress. Each junction independently distributes traffic across its next-hops based on signaled load shares. This is distributed per-hop weighted multipathing — a fundamentally different model from the headend-only W-ECMP specified in RFC 9256.

[ZA] As mentioned above, BSID forwarding with W-ECMP is not limited to the Ingress; BSID supports multi-path TE just like the “Junction nodes” of MPTE. This is further illustrated by draft-stone-spring-mpte-sr, which is an “informational" draft on MPTE using Segment Routing for that reason. I am a co-author.

That said, citing RFC 9256 as related work to explicitly contrast the two approaches is a fair editorial suggestion, and I'd recommend the authors consider adding the comparison and reference in the next revision.

[ZA] Thanks – I agree. Looking forward to reviewing the changes.

<snip>