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,


  *   TEA has been standardized to signal parameters of the tunnel egress point to all ingress nodes. No more no less.

The draft-ietf-idr-segment-routing-te-policy that you pointed to is directly against the above statement.

More zzh3> below.



Juniper Business Use Only
From: Robert Raszuk <[e-mail]>
Sent: Monday, January 2, 2023 2:25 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>; [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]

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.

Zzh3> RFC9012 is more about the TEA as building blocks. So what if it does not mention controllers? draft-ietf-idr-segment-routing-te-policy talks about controllers using TEA to signal SR policies. It's certainly ok for another draft to talk another controller related use case and procedure.

Zzh3> As for "dedicated section for controller originated TEAs would be proper", the subject draft does have the following:

   This document clarifies that it is NOT for steering traffic to but
   for steering AFTER the tunnel endpoint.  Consider the following use
   case:

                 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.


zzh3> The "controller" is right in that diagram. I will add more text to make it further explicit.
Zzh3> The purple text in the above quote is for the next response.

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.

Zzh3> Please note that "within site2" is about "traffic steering via the label stack (that is in the packet)", not that the sub-TLV is to be used "within site2". I can certainly reword it to reduce ambiguity.

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.

Zzh3> I assume draft-ietf-idr-segment-routing-te-policy is in a state where they may want to freeze the content. It's currently "Submitted to IESG for Publication"
Zzh3> Having this "addendum" draft for extensions to TEA encoding sounds reasonable to me, though I will defer this to the WG.
Zzh3> Thanks.
Zzh3> Jeffrey

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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Robert Raszuk
Sent: Monday, January 2, 2023 10:02 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, December 30, 2022 9:22 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:
Gyan,

Please see zzh> below.



Juniper Business Use Only
From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Gyan Mishra
Sent: Thursday, December 29, 2022 10:47 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0XfNuqLTw$>
--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0WSFAsGuQ$>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!D04hIgM3IpI6sp3zAgKMrz5Q9E9ULFXqciFTm81PcJIvB0vfH2f-jKK2TZhWVZfpdD6NiOXRwLZx8CbixlAAHQ$>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!D04hIgM3IpI6sp3zAgKMrz5Q9E9ULFXqciFTm81PcJIvB0vfH2f-jKK2TZhWVZfpdD6NiOXRwLZx8CbixlAAHQ$>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

_______________________________________________
Idr mailing list
[e-mail]<mailto:[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$>