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

Please see zzh> below.



Juniper Business Use Only
From: Gyan Mishra <[e-mail]>
Sent: Wednesday, January 18, 2023 11:28 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Robert Raszuk <[e-mail]>; 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


The text helps explain the interaction and compatibility with Spring WG SR Policy.

With this text I don't see any issue with the WG adoption of this draft.

I agree the compact segment list is a very good idea and a significant optimization.

I support WG adoption.

Zzh> Thanks!

So with this solution can TEA method be used for steering method independent of SR policy for both unicast and multicast?

Zzh> Yes. Both can be used but for different scenarios. SR-policy referenced in a tunnel is a better fit when a pre-installed policy (with all bells and whistles like candidate paths) can be used for many service routes, while the label stack in a tunnel is quick and simple/direct.

SR policy can be complicated and this method seems to be a simplified means of steering.

In the additional text  I think we should make clear that it can be used in conjunction with SR policy or independently.

Zzh> Yes.

In the draft you mention use with a controller, however could TEA be used independently of a controller?

Zzh> Yes it can be independent of a controller, but as Robert pointed out, if it is used in routes advertised from egress routers to many ingress routers, then the explicit  path needs to be more towards the egress part so that it is applicable for traffic from those different ingress routers.

Also in the draft you don't mention if this would be a PCEP or SDN or BGP controller or could it be any?

Zzh> Any controller that uses BGP signaling.
Zzh> Thanks.
Zzh> Jeffrey

Kind Regards

Gyan

On Wed, Jan 18, 2023 at 8:56 AM Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

Sorry for the late response.
I will add it to the document.

Thanks.
Jeffrey



Juniper Business Use Only
From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, January 12, 2023 2:15 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]

Jeffrey,

Is this the text you are going to add to your document ?

Thx,
R.

On Thu, Jan 12, 2023 at 7:56 PM Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

This does not exclude the SAFI 73 way. Either of the following can be used:


  *   Use SAFI 73 to pre-install an sr-policy, and then reference the installed sr-policy when advertising the service route.
  *   Spell out the sr-path directly when advertising the service routes, w/o pre-installing an sr-policy first.

Thanks.

Jeffrey



Juniper Business Use Only
From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, January 11, 2023 2:08 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]

Jeffrey,

I am saying that existing IDR document (draft-ietf-idr-segment-routing-te-policy) covers already what is defined in this subject draft and I do not see why extensions defined in SAFI 73 could not be used as is to address requirements of steering to tunnel egress.

Zzh4> The above cannot use the existing "sr-policy tunnel" because the sr-policy tunnel is used to setup the tunnel (on the ingress) using SAFI 73, while in the above use cases we're telling that certain service routes or multicast state (with different SAFIs) use a particular sr-mpls path.

If we go by this then any use of SAFI 73 would be unnecessary as you would instead carry service routes with their own policies.

That sounds like a highly unscalable approach to use embedded into service routes underlay paths.

Instead the current SR architecture recommends to carry just the color in service routes which in turn can be use to match colors in SR policy paths.

So you are proposing to skip SAFI 73 and carry it directly in service paths. Isn't this layer violation ?

In any case, Gyan and I presented our concern. Time for other WG members to provide their opinion as well as get feedback from SPRING WG as this model directly "extends" the SR architecture.

Kind regards,
Robert





_______________________________________________
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!GqBs_kMPzzpS5K8wI16ndN5MJGASArrpj3MU5flKLjPf6JerYqE_dc5fzQ_Ijp-cYQxSkTEL_dZM30U9Mx0vsQ$>
--

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

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347