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

Please see comments "RR2>"


> Hi Jeffrey,
>
>
>
> My reading of RFC9012 leads me to believe that it is very correct and your
> subject draft is not needed.
>
>
>
> Indeed section 3.6 states there that label stack as defined in type 10
> sub-TLV must be pushed BEFORE any other labels carried in the NLRI. And I
> can't see why this would be "a bit confusing".
>
>
>
> Of course what is meant by "BEFORE" is meant before any other application
> or transport labels are imposed to the packet.
>
>
>
> Zzh2> The instructions on what to do **IS** clear and I don’t dispute
> that or its correctness. It’s the use case (steering traffic **after** it
> reaches tunnel endpoint) that is not clear and it took quite a few email to
> get the answer. It’s good to clarify that use case. Also this is just *
> *one** of the purposes for the draft.
>


RR2> So if we agree that RFC9012 already covers the "Traffic Steering after
Tunnel Endpoint" use case described in section 1 do we agree that there is
no need to keep this section in this draft at all ?


Let's take two examples:
>
>
>
> SAFI 1/4  ... Label in NLRI will be the transport label (for example (in)
> famous Seamless MPLS) and I do not see why Tunnel sub-TLV should be applied
> after it. Remember we always look towards the front of the packet ... not
> towards the payload.
>
>
>
> SAFI 1/128 ... Labels in NLRI are critical to decide which VRF (VPN
> context) packet belongs and sub-TLV has no authority to override it. It
> could hint though EPE within a given set of interfaces within a given VPN
> the traffic should go.
>
>
>
> Zzh2> As you say, for SAFI 1/128 labels in NLRI are “service” labels
> (identifying VRF or PE-CE interfaces). They don’t hint on how the egress PE
> should be reached - Tunnel Encapsulation Attribute (TEA) is for that. The
> new label stack in TEA defined in this draft does not interfere with the
> service label either – it is to steer traffic **to** the endpoint
> (independent of service label).
>


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 ?

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.

Likewise enjoy the holidays and the winter break ...

Best,
Robert.


Hope this helps to clarify my perspective.
>
>
>
> Zzh2> I hope this helps clarify my perspective as well 😊
>
> Zzh2> Happy Holidays!
>
> Zzh2> Jeffrey
>
>
>
> Thx,
> R.
>
>
>
>
>
> On Tue, Dec 27, 2022 at 10:22 PM Jeffrey (Zhaohui) Zhang <
> [e-mail]> wrote:
>
> Hi Robert,
>
>
>
> Please see zzh> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Friday, December 23, 2022 4:14 PM
> *To:* Susan Hares <[e-mail]>; Jeffrey (Zhaohui) Zhang <
> [e-mail]>
> *Cc:* [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]*
>
>
>
> Dear Sue and Jeffrey,
>
>
>
> Could you clarify what is missing for networks running standard based
> SR-MPLS which this spec would enable ?
>
> Or is this proposal an attempt to provide apparatus to achieve
> SR-MPLS-LIGHT by simply using Tunnel Encapsulation Attribute ?
>
>
>
> Zzh> As the abstract says:
>
>
>
>    RFC 9012 defines an MPLS Label Stack sub-TLV for Tunnel Encapsulation
>
>    Attribute, and specifies that it is to be pushed BEFORE other labels.
>
>    This document clarifies the use case for that, defines a new Tunnel
>
>    Label Stack sub-TLV for a label stack to be pushed AFTER other labels
>
>    (e.g., the label embedded in the NLRI for a labeled address family,
>
>    and/or the stack in an MPLS Label Stack sub-TLV), and defines two new
>
>    Segment sub-TLVs to encode a segment list in a compact format.
>
>
>
> Zzh> It does three things:
>
> Zzh> a). Section 1 clarifies the use case for pushing the label stack
> BEFORE other labels (RFC9012 does not explain why it is BEFORE; it is a bit
> confusing because it is counter intuitive unless the use case is explained)
> – for traffic steering AFTER the tunnel end point.
>
> Zzh> b). Section 2 defines another TLV to specify a label stack to be
> pushed AFTER labels, for traffic steering TO the tunnel end point.
>
> Zzh> c). Section 3 defines two new segment sub-TLVs for compact encoding
> of segment lists
>
> Zzh> a) is clarification, c) is optimization, and b) is for a missing
> functionality.
>
> Zzh> Thanks.
>
> Zzh> Jeffrey
>
>
>
> Many thx,
>
> Robert
>
>
>
>
>
> On Fri, Dec 23, 2022 at 7:36 PM Susan Hares <[e-mail]> wrote:
>
> This begins a 3 week WG adoption and IPR call for
> draft-zzhang-idr-tunnel-encapsulation-label-stack-01.txt
>
>
> https://datatracker.ietf.org/doc/draft-zzhang-idr-tunnel-encapsulation-label-stack/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-idr-tunnel-encapsulation-label-stack/__;!!NEt6yMaO-gk!DPaxTk6WPrSXFhTPgxr9Z-xwL104sML2LJOJaFhSUlumFLm0YtHdkW0hisVw0zyCLe5MTxhMpmvfA60Z$>
>
>
>
> The Authors should send an IPR statement regarding this draft.
>
>
>
>
>
>    RFC 9012 defines an MPLS Label Stack sub-TLV for Tunnel Encapsulation
>
>    Attribute, and specifies that it is to be pushed BEFORE other labels.
>
>    This document clarifies the use case for that, defines a new Tunnel
>
>    Label Stack sub-TLV for a label stack to be pushed AFTER other labels
>
>    (e.g., the label embedded in the NLRI for a labeled address family,
>
>    and/or the stack in an MPLS Label Stack sub-TLV), and defines two new
>
>    Segment sub-TLVs to encode a segment list in a compact format.
>
>
>
> The IDR shepherd for this draft is Jie Dong.
>
>
>
> Cheerily, Sue
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!DPaxTk6WPrSXFhTPgxr9Z-xwL104sML2LJOJaFhSUlumFLm0YtHdkW0hisVw0zyCLe5MTxhMpqsBTSTZ$>
>
>