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

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]>
Sent: Tuesday, January 3, 2023 9:48 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]


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