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

We are indeed going in circles.

One more try from my side to clarify some points below.



Juniper Business Use Only
From: Robert Raszuk <[e-mail]>
Sent: Tuesday, January 3, 2023 10:28 AM
To: Jeffrey (Zhaohui) Zhang <[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]

> it is clear that the service routes are *not* using any SR policy.

This is going in circle ...

We have already established that SR Policy is an explicit path which you are proposing to attach to TEA attribute without use of SAFI 73 from controllers.

Zzh> SR Policy is one way to create a named "tunnel" with explicit path. It then can be used to carry traffic.
Zzh> The subject draft specifies one option to allow explicit path for an MPLS tunnel in a TEA used for service routes, without involving SR *policy*.

Now you are also presumably reusing IGP extentions to ISIS and OSFP to signal domain wide labels .. no ?

Zzh> Where did you get that idea? The controller calculates the explicit path, represent it with a label stack, and put it in the MPLS tunnel in the TEA. Where is the hint of using IGP?

Yet you are keep claiming this is not SR ...

Zzh> Where did I claim that? I am just saying that I am not using SR *policy*, and the TEA can still use an MPLS tunnel with an SR label stack.

Zzh> Jeffrey

I rest my case here.

Cheers,
R.

On Tue, Jan 3, 2023 at 4:18 PM Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>> wrote:
SAFI 73 is for setting up a policy (like a tunnel) on the ingress. That policy may be used for *many* purposes; all kinds of traffic can be steered into that SR policy - even for traffic beyond the tunnel endpoint.

With *existing mechanism*, traffic for some service routes can be steered into an MPLS tunnel by using a TEA attached to the service routes. That does NOT involve SR policy at all.

Now we're just adding one enhancement to the above, by encoding a label stack for steering the traffic along the tunnel.

There is *no* collision, whether SR policy is used in the same network or not. If you want some service routes to use a particular SR policy, you'll somehow have to specify which SR policy to use. When you use TEA with an MPLS tunnel in it (with or without the tunnel label stack proposed in this draft) for some service routes, it is clear that the service routes are *not* using any SR policy.

Jeffrey



Juniper Business Use Only
From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, January 3, 2023 9:48 AM
To: Jeffrey (Zhaohui) Zhang <[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]


> Why do we need/want to exclude traffic steering to tunnel endpoint from the "MPLS tunnel in a TEA" use case?

Because that use case is already covered in SAFI 73.

You want to introduce parallel signalling and deal with cases of collisions without clear definition if TEA in service routes itself should be less or more important then SR Policy of SAFI 73 with TEA .

Thx,
R.

On Tue, Jan 3, 2023 at 3:39 PM Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

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

I pointed out "draft-ietf-idr-segment-routing-te-policy is directly against that" - meaning, TEA does NOT have to be restricted to what is specified in RFC9012. Any protocol mechanisms can be enhanced and extended.

Why does it matter that draft-ietf-idr-segment-routing-te-policy is about a new SAFI?

Why do we need/want to exclude traffic steering to tunnel endpoint from the "MPLS tunnel in a TEA" use case?

Jeffrey



Juniper Business Use Only
From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, January 3, 2023 9:28 AM
To: Jeffrey (Zhaohui) Zhang <[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]



On Tue, Jan 3, 2023 at 3:19 PM Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]<mailto:[e-mail]>> wrote:
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.

But this is only within context of new SAFI 73 ... note:

"The use of SR Policy Tunnel-type is applicable only for the AFI/SAFI pairs of (1/73, 2/73)."

You are proposing to use it in any SAFI that is a significant difference.