Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023

[Susan Hares <[e-mail]>]

Robert:

I’m catching up with email sent over the break.  This email may be out of context with the stream.

I ran into this text being unclear when looking at SR-p2mp work for multicast.  ( See draft-ietf-idr-sr-p2mp-policy-00 and alignment with BESS Multicast VPNs).

The controller deployments arise out of the SR work.  If you want to remove “controller” from the face of BGP, please argue with the SPRING Group on SR.  The fact is we have SR-p2mp work approved for IDR.   Given the WG and IETF as agreed to “controllers” and SR work, let’s try to make documents unclear for those cases.

Sue

From: Robert Raszuk <[e-mail]>
Sent: Wednesday, December 28, 2022 2:51 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Susan Hares <[e-mail]>; [e-mail]
Subject: Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023

Hi Jeffrey,  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzE5YmNmNDVhY2E0NTlkZDBlZDVjY2QwMWM1MDg5OGExLzE2NzIyNTcwNzEuMzQ=#key=746e5eb39c1ff6ed186082557e43d5ce>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Hi Jeffrey,

RR2>  So let's zoom into your use case #2 - "Traffic Steering to the Tunnel Endpoint" You want egress to signal the path from Ingress to itself ? But how is this possible if the nature of BGP is p2mp routing information distribution and you do not have any idea which node will be the ingress of the traffic ?

Zzh3> What if the label stack only specifies the common part from those ingress PEs?

What is "the common part" of the transport tunnel in a label stack when such an encap starts on 100 different ingress PEs ?

At best you could signal constraints and let ingress compute paths meeting those constraints, but not MPLS label stack. In fact outside of SR-MPLS and domain wide labels which is already covered in a bunch of other documents egress can not even create such label stack as it has no information about labels signalled to each ingress.

Zzh3> Why can’t this be used for SR-MPLS where a controller to signal state to individual ingress PEs?


Now you are introducing "controller" to this picture as a consumer of encoded label stacks in the proposed sub-TLVs.

So such controller(s) will get Tunnel Encapsulation Attribute along with service routes and based on contained Tunnel Encapsulation Attributes sub-TLVs take the label stacks, process this and signal to ingress PEs "optimal" SR-MPLS paths for each ingress PE ?

Honestly a real example illustrating this "common part" known to egress and encoded label stack would be very helpful. IMHO if such use case is real it is very much topology dependent.

But I must admit one point here ... if you are trying to use such a mechanism instead of using BGP-LS from egress PEs to controllers you have my full support :)  But if so I would recommend to take a broader view and instead of stuffing such partial information into Tunnel Encapsulation Attribute define a completely new attribute and carry with service routes to controller(s).

Many thx,
Robert