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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Robert,

Please see zzh4> below.



Juniper Business Use Only
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

[External Email. Be cautious of content]

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 ?

Zzh4> In theory, it could be that the egress PE has a few P routers near it (yet far away from those 100 ingress PEs) and the egress only care about which of the close P routers to use. That is indeed not the use case I had in mind, but mainly for the sake of argument/completeness 😊

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 ?

Zzh4> “Controller” is indeed a more suitable use case, but it is not the consumer but rather the producer (of the service routes and TEAs in those routes) as the draft mentions:

2.  Traffic Steering to the Tunnel Endpoint

   Notice that in the above example, it may be desired that PE2 or the
   controller wants PE1 to send service traffic to PE2 via a specific
   path through the underlay network.  The path may be an Segment
   Routing path identified as a label stack encoded in the Tunnel
   Encapsulation Attribute of the service routes that PE1 receives.


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.

Zzh4> That is indeed very topology dependent, that’s why as I mentioned it (PE2 signaling “common part” in the TEA) is a “theoretical” use case, but the controller use case is real – in fact what triggered this is that a controller calculates a multicast tree and signals via BGP to the tree nodes, and in some cases the controller wants a particular steered path between an upstream and downstream tree node. I can add a reference to that multicast draft.

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

Zzh4> Looks like we’re talking about two different directions – I am talking about controller to PEs yet you’re talking about PEs to controllers. Can you elaborate your use case?
Zzh4> Thanks.
Zzh4> Jeffrey

Many thx,
Robert