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

[Vishnu Pavan Beeram <[e-mail]>]

{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. The MPTE draft proposes to combine both in a specific
way (via DAGs with per-junction weighted load-balancing).

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.

A document that openly acknowledges and contrasts with prior multipath TE
work is not claiming to have invented the term. It is proposing a specific
architecture (DAG-based, per-junction) that it believes improves upon
existing approaches.

*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.

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. 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.

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.

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.


*On Binding SIDs and Junction nodes:*
A Binding SID can steer traffic into an SR Policy at a midpoint, and it can
be used as a building block for realizing MPTE — which is precisely what
draft-stone-spring-mpte-sr proposes. However, a BSID alone does not provide
per-junction weighted load-balancing, per-hop bandwidth accounting,
previous-hop tracking, or signaled DAG state. These are the capabilities
that MPTE junction nodes provide.

The existence of draft-stone-spring-mpte-sr validates that MPTE is a
distinct concept: if SR Policy W-ECMP and Binding SIDs already did what
MPTE junctions do, there would be no need for that draft. The
classification of draft-stone-spring-mpte-sr as Informational reflects its
role as a realization/applicability document — it describes how MPTE can be
realized using SR constructs. It does not mean the problem is already
solved by RFC 9256. On the contrary, draft-stone-spring-mpte-sr defines
per-junction SR Policies, controller-driven DAG computation, and
coordinated per-junction load-share distribution — none of which are
specified or envisioned in RFC 9256. If RFC 9256 already provided
per-junction weighted multipath TE, draft-stone-spring-mpte-sr would have
nothing to specify.


*On the characterization of the document:*
For the record — describing a document as "academically dishonest" is a
serious allegation and, in this case, is not warranted. An editorial
suggestion to add a reference is perfectly normal in the IETF process;
questioning the integrity of the authors is not. I'd ask that future
feedback be framed constructively.

Thanks,
Pavan


On Thu, Jul 23, 2026 at 4:09 AM Zafar Ali (zali) <zali=
[e-mail]> wrote:

> Hi Kireeti, WG,
>
> This is regarding my comments on
> https://datatracker.ietf.org/doc/draft-kompella-teas-mpte/
>
> >From a read of the document, it seems to claim to invent the multi-path
> TE: “One can either have TE or multipathing, but not both.”
>
> However, it is missing a key reference: “Segment Routing Policy
> Architecture [https://datatracker.ietf.org/doc/rfc9256/]”. RFC9256
> specifies the 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 also defines the notion of “Binding SID,” which supports
> multi-path TE just like the “Junction nodes” specified in
> draft-kompella-teas-mpte. This fact is illustrated by an “informational”
> draft on MPTE using Segment Routing [
> https://datatracker.ietf.org/doc/draft-stone-spring-mpte-sr/] I am a
> co-author of draft-stone-spring-mpte-sr.
>
> I would not have commented had draft-kompella-teas-mpte referenced Segment
> Routing Policy Architecture [RFC9256] rather than RFC8754.
>
> I apologize if my comments came across as disrespectful. My comments were
> directed at the draft, not at any individual.
>
> I hope the authors can address the comments above.
>
> Thanks
>
> Regards … Zafar
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>