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

[Robert Raszuk <[e-mail]>]

Hi Sue,


> 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 subject draft does not even say a single word "multicast". If it would
.. meaning if the proposed extension would be clearly applicable to
multicast only I would perhaps not even asked a single question.


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

Nope ... that was not what I was stating.

There is nothing wrong to use controllers and I never intended to remove
it :).

I am saying that existing IDR document
(draft-ietf-idr-segment-routing-te-policy) covers already what is defined
in this subject draft and I do not see why extensions defined in SAFI 73
could not be used as is to address requirements of steering to tunnel
egress.

If we clearly answer this - then perhaps rest of the points will become
solved. So far I have not seen an answer to it other then preference not to
use it. To me this is a little bit insufficient to take on the work on the
alternative protocol extension.

Cheers,
Robert.

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