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

[Robert Raszuk <[e-mail]>]

Jeffrey,

> Since you can signal a label stack in an MPLS tunnel in a TEA attached to
some routes
> to steer traffic after reaching that tunnel endpoint, you can do the same
to signal a label
> stack (sure, it is an SR label stack) in that same MPLS tunnel for the
purpose of steering
> traffic to that tunnel endpoint.

Here we clearly have different opinions.

TEA has been standardized to signal parameters of the tunnel egress point
to all ingress nodes. No more no less. Egress does not have the ability to
signal in p2mp fashion an explicit path towards himself which would be
proper for all ingress PEs.  So your answer is that it will not be an
egress, but a controller to advertise those TEAs. RFC9012 does not even
mention third party TEA's injection so if this is objective of your draft
dedicated section for controller originated TEAs would be proper.

Also in your draft stating that current TEA sub-TLV is to be used "within
site2" is IMO wrong. At best it could be used on PE2 but only "towards
site2". Site2 is unlikely to signal label stack to other domains counting
on other's domain's ingress to apply it. I hardly see a benefit of it.
Maybe CSC could be only one but even if so it would not go beyond directly
attached first node in site2.

Your draaft also states that current encoding for label stack
in draft-ietf-idr-segment-routing-te-policy is quote: "not efficient
on-the-wire encoding format". If so I do recommend to update said draft
rather then trying to push "more efficient" encoding formats in separate
documents. If for nothing else then for consistency in encodings.

To summarize this discussion I do not see that IDR WG should adopt this
document in the current shape.

Cheers,
Robert




On Mon, Jan 2, 2023 at 7:41 PM Jeffrey (Zhaohui) Zhang <[e-mail]>
wrote:

> Robert,
>
>
>
> Since you can signal a label stack in an MPLS tunnel in a TEA attached to
> some routes to steer traffic after reaching that tunnel endpoint, you can
> do the same to signal a label stack (sure, it is an SR label stack) in that
> same MPLS tunnel for the purpose of steering traffic to that tunnel
> endpoint.
>
>
>
> This does **not** exclude SR policy based options for other scenarios.
> When I said “forgot about …” I meant, for the discussion, don’t tangle in
> those things, just consider the above simple context.
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr <[e-mail]> *On Behalf Of * Robert Raszuk
> *Sent:* Monday, January 2, 2023 10:02 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>
> *Cc:* [e-mail]; Susan Hares <[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,
>
>
>
> Zzh2> Forget about ODN. Forget about color. Forget about SR-Policy (and SR
> policy tunnel).
>
>
>
> While you are clearly entitled to forget about SR standards,
> implementations and deployments, what you are effectively proposing is
> SR-like behaviour using TEA as a signalling vehicle for the MPLS
> explicit path between controller and ingress nodes.
>
>
>
> That unfortunately has obvious consequences of implementations needed now
> to deal with it.
>
>
>
> In any case I think it is now clear to everyone where are you going with
> this draft. It is up to IDR and SPRING WGs to decide if such work should be
> taken on.
>
>
>
> Best,
>
> Robert
>
>
>
>
>
> On Mon, Jan 2, 2023 at 3:45 PM Jeffrey (Zhaohui) Zhang <zzhang=
> [e-mail]> wrote:
>
> Hi Gyan,
>
>
>
> You have many things tangled together unnecessarily. Please see zzh2>
> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Friday, December 30, 2022 9:22 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
>
>
>
> Thinking about this further ..
>
>
>
> You had mentioned that the core  SR source node needs the TEA endpoint to
> build the SID list label stack to push onto the packet.
>
>
>
> Zzh2> The service ingress router (PE1 in the subject draft)  needs to know
> the egress service router (PE2). Normally it’s the BGP protocol nexthop.
> TEA allows a different way to do that.
>
> Zzh2> With the existing label stack sub-TLV in a TEA, you can allow
> traffic steering AFTER the traffic reaches the egress service router PE2
> (this is optional – the TEA can simply specify a tunnel endpoint). The
> subject draft covers three things **in the context of using TEA**:
>
> Zzh2> a) explain the use case for steering AFTER the tunnel endpoint PE2;
>
> Zzh2> b) define a new label stack for steering TO the tunnel endpoint PE2;
>
> Zzh2> c) define a compact way of encoding uniformed SIDs in a list
>
>
>
> However you also have ODN On Demand Next Hop or automated steering
> 0.0.0.0/4
> <https://urldefense.com/v3/__http:/0.0.0.0/4__;!!NEt6yMaO-gk!D04hIgM3IpI6sp3zAgKMrz5Q9E9ULFXqciFTm81PcJIvB0vfH2f-jKK2TZhWVZfpdD6NiOXRwLZx8CbYYGE-Cg$>
> which both are endpoint independent and rely on the egress PE signaling
> color via TEA color extended community only that maps to the head end SR
> policy color to instantiate the steered path.
>
>
>
> Zzh2> Forget about ODN. Forget about color. Forget about SR-Policy (and SR
> policy tunnel).
>
> Zzh2> **In the context of using TEA** where a controller is simply using
> a TEA with an MPLS tunnel (w/o color  – note that it is optional) attached
> to the service routes, it can attach a label stack (per RFC9012)  for the
> purpose of steering AFTER the tunnel endpoint, and we’re proposing to allow
> a new tunnel label stack (per this subject draft) for the purpose of
> steering TO the tunnel endpoint.
>
> Zzh2> Simple as that.
>
>
>
> So in that case Source nodes could push the SR label stack onto the packet
> before the NLRI label encoding.  Not true and now I realize why.
>
>
>
> For SR policy since the TEA is used for both service label SAFI and for SR
> policy color to intent mapping even if endpoint independent you still need
> the color to intent mapping signaling NLRI encoding to happen before the
> label stack can be pushed onto the packet.
>
>
>
> Even though RFC 9012 states that  the label stack is pushed onto the
> packet before the TEA  NLRI encoding I don’t think any SR implementation
> follows that or SR would be broken.
>
>
>
> Bottom line is RFC 9012 TEA color to SR policy intent mapping is apriori
> and must and has to occur prior to pushing the SR label stack onto the
> packet for the steering to work.  It’s impossible to do the other way
> around.
>
>
>
> Zzh2> You don’t need to involve SR policy or color stuff (they can be
> useful in some cases but they are not mandatory). Please see above.
>
> Zzh2> Jeffrey
>
>
>
> Many Thanks!
>
>
>
> Gyan
>
>
>
> On Fri, Dec 30, 2022 at 3:20 PM Gyan Mishra <[e-mail]> wrote:
>
> Hi Jeffrey
>
>
>
> So in summary what you are saying is normally with MPLS RFC 3032 you push
> the label stack before the NLRI encoding since SR Policy TEA color / intent
> mapping does not come into play for vanilla mpls label stack domain.
>
>
>
> However with SR-MPLS with SR Policy the TEA endpoint 2 tuple comes into
> play {color, endpoint}.  So now the core routers need to see the RFC 9012
> TEA for the egress PE tunnel endpoint termination for the SR policy and
> since the BGP update has all the common path attributes per update packing
> we have the TEA sub TLV is in the same packet as the service label and so
> now we need NLRI encoding before the label stack is pushed onto the packet
> so the core router see the TEA tunnel endpoint info.  So this same concept
> update to RFC 9012 is applicable as well for inter-as steering to sites
> connected to the core steering past the core tunnel endpoint egress PE to
> the connected sites.  In that particular case would it be a CSC
> hierarchical VRF backbone carrier and customer carrier and in that case
> between the ASs you would have inter-as PE-PE link so the other side of
> PE-PE inter-as link would be the source PE for steering within the site 1
> or 2.  So this would be like a seamless SR use case inter-as coloring to
> intent  mapping or translation per AS hop if the coloring is different per
> AS hop.  Also the L3 VPN service label NLRI encoding SAFI 128  would be
> extended end to end per inter-as options.
>
>
>
> Below stick diagram
>
>
>
> Site 1                            Core                  Site 2
>
>
>
> PE1 - P - PE2 — PE3 - P - PE4 — PE5 - P - PE6
>
>
>
> PE2-PE3 and PE4-PE5 are inter-as L3 vpn links / inter-as TE links
>
>
>
> The SR source  node in each AS for the SR policy AS hop stitching for the
> end to end path built by the stateful PCE would be ..
>
>
>
> Left to Right
>
>
>
> PE1, PE3, PE5
>
>
>
> Right to Left
>
>
>
> PE6, PE4, PE2
>
>
>
> So in the case going left to right LSP  where Site 2 PE5 is not capable of
> pushing the label stack, would it be PE4 not PE3 that would provide a proxy
> service acting as a source node to push the label stack onto the packet.
> If this is within the same administrative domain, option C  end to end LSP
> it’s  possible to leverage a different PE in another domain to push the
> label stack.  However if it’s between administrative domains option B
> stitched LSP then you would more than likely not be able to leverage a PE
> in another domain to push the label stack.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Fri, Dec 30, 2022 at 10:12 AM Jeffrey (Zhaohui) Zhang <
> [e-mail]> wrote:
>
> Gyan,
>
>
>
> Please see zzh> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr <[e-mail]> *On Behalf Of *Gyan Mishra
> *Sent:* Thursday, December 29, 2022 10:47 PM
> *To:* Susan Hares <[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]*
>
>
>
> Hi Jeffrey
>
>
>
> I read the draft and have questions related to the reason for the two new
> Segment sub-tlv to encode a segment list in compact format.
>
>
>
> I read through the thread on the comments from Robert and I have similar
> questions which I will reiterate to help get to the goal or objective of
> the draft which is confusing to the reader.
>
>
>
> Let’s first understand and agree on the label stack encoding for MPLS and
> SR-MPLS.
>
>
>
> Let’s start with standard MPLS Label Stack RFC 3032.  So with RFC 3032 you
> have transport label TL and then the L2 or L3 VPN service labels Bottom of
> Stack labels with S bit set.
>
>
>
> RFC 6790 defines the Entropy label EL and Entropy Label Indicator ELI
> encoded {TL, ELI, EL, SL} where SL is the service label with S bit set.
>
>
>
> The way I read RFC 8660 SR-MPLS section 2.7 the label stack for steering
> is imposed on the packet where the TL would normally be placed on the SR
> source node once the SR Policy BSID is popped and the Candidate path
> defining the SID list is bound to the forwarding plane.
>
>
>
> RFC 8662 SR Entropy Label section 4 shows the ERLD and in this case you
> can see as well the SR label stack imposed on the packet once the BSID is
> popped on the source node TL is now replaced with SR label stack {SR label
> stack, ELI, EL, SL}  where SL is the service label.
>
>
>
> So now if we agree on the MPLS and SR-MPLS label stack encoding we can
> discuss the draft further below.
>
>
>
> Section 1 talks about traffic steering after the tunnel endpoint.  SR
> policy defines a 2 tuple {color, endpoint} so the endpoint is the egress PE
> loopback tunnel endpoint which is defined in the TEA for SR Policy.
> Section 8.4 of RFC 9256 defines the per destination SR policy color /
> intent mapping where egress PE endpoint signals VPN overlay TEA color to
> ingress PE SR policy color to intent mapping to instantiate the steering
> path.
>
>
>
> Section 1
>
>
>
> Specifically, the label stack in the sub-TLV is to be pushed BEFORE any
> other labels are pushed. This may sound counter-intuitive, in that if a
> label stack (e.g. for Segment Routing) is to be used to steer traffic to
> the tunnel endpoint, the stack should be pushed AFTER other labels (e.g.
> the label embedded in the NLRI).¶
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-idr-tunnel-encapsulation-label-stack-01*section-1-3__;Iw!!NEt6yMaO-gk!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0XSa3EzzQ$>
>
>
>
> Why would this be different for SR-MPLS as compare to MPLS and from the
> above review of the label stack encoding as SR-MPLS is reusing the MPLS
> data plane the label stack encoding should be the same.
>
>
>
> AFAIK I think the SR label stack should still be pushed before the NLRI
> labels are pushed. Why would that be any different??
>
>
>
> I don’t understand the statement below.  Steering is from the SR source
> node to egress PE loopbacks tunnel endpoint. What other steering is there
> past the egress PE tunnel endpoint?
>
> Zzh> If you’re talking about steering TO the (core/base) tunnel endpoint
> (which is the egress PE), you need to push the corresponding label AFTER
> you push the NLRI (service) label (so that the core routers see the tunnel
> label instead of service label). That’s why I said it is counter-intuitive
> to push the labels BEFORE pushing service label, and why we need to clarify
> it is for steering AFTER the endpoint.
>
> Zzh> For traffic steering AFTER the endpoint, it is explained as following
> in the draft:
>
>                  controller
>
>                 .          .
>
>                .            .
>
>     site1 --- PE1 -------- PE2 --- site2
>
>
>
>    Two sites are connected to two PEs respectively, and traffic steering
>
>    is desired within each site not just among the PEs.  While PE2 could
>
>    push the label stack used for steering within site2, there may be
>
>    situations where PE2 is not a device capable of pushing a large label
>
>    stack so PE1 is tasked with pushing the label stack that is used
>
>    after the tunnel end point PE2, within site2.
>
>
>
> Zzh> Notice the red text “within site2” (i.e., AFTER tunnel endpoint
> PE2). Note that the service label mentioned earlier could mean “pop and
> switch out of an interface”, which means there could be labels after that
> service label, which were pushed BEFORE the service label was pushed.
>
>
>
> Two sites are connected to two PEs respectively, and traffic steering is
> desired within each site not just among the PEs. While PE2 could push the
> label stack used for steering within site2, there may be situations where
> PE2 is not a device capable of pushing a large label stack so PE1 is tasked
> with pushing the label stack that is used after the tunnel end point PE2,
> within site2.
>
>
>
> All PEs in the SR domain are ingress/egress PE thus all PEs as they can
> all be source nodes they would have to be capable of pushing the label
> stack onto the packet.  In most SR deployments a stateful PCE is used and
> the source node is programmed to push the label stack onto the packet by
> the stateful PCE.  In this stateful PCE case the SR source node instructed
> by the PCE still has to push the label stack for steering onto the packet.
> So if an SDN controller / PCE is used the same predicament the source node
> still as instructed by the SDN controller has to push the label stack onto
> the packet for steering.
>
>
>
> So no matter what the SR source node has to be capable of pushing the
> label stack onto the packet.
>
>
>
> Zzh> Please see purple text above and notice the word “large”.
>
> Zzh> Also note that I did not come up with this use case or corresponding
> mechanism. I found it counter-intuitive and want to document what I found
> out by offline email inquries, so that it will help other people and so
> that the feature could be more widely used.
>
> Zzh> Jeffrey
>
>
>
> I have more questions but I think this is a good start and will help steer
> tbe discussion.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Fri, Dec 23, 2022 at 1:37 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!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0W1VfX5mA$>
>
>
>
> 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!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0XfNuqLTw$>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0WSFAsGuQ$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **[e-mail]* <[e-mail]>
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!D04hIgM3IpI6sp3zAgKMrz5Q9E9ULFXqciFTm81PcJIvB0vfH2f-jKK2TZhWVZfpdD6NiOXRwLZx8CbixlAAHQ$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **[e-mail]* <[e-mail]>
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!D04hIgM3IpI6sp3zAgKMrz5Q9E9ULFXqciFTm81PcJIvB0vfH2f-jKK2TZhWVZfpdD6NiOXRwLZx8CbixlAAHQ$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **[e-mail]* <[e-mail]>
>
> *M 301 502-1347*
>
>
>
> _______________________________________________
> 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!BLUOm2uEdLPhYCCY0iACTMpYOD--fWHNRRdGoXnHDtfkv5KGbcuMeFyhmFv1sp_Vjkzx90p7fDhIJVT5$>
>
>