Re: [Idr] flowspec srv6 policy

["Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>]

In--line

From: ½ªÎÄÓ± <[e-mail]>
Date: Friday, 1 April 2022 at 12:45
To: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>, ketant.ietf <[e-mail]>, zhuangshunwan <[e-mail]>, rainsword.wang <[e-mail]>
Cc: draft-jiang-idr-ts-f <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re:Re: [Idr] flowspec srv6 policy

Hi Wim,
Thank you for your comments.

As we mentioned in mails, we believe the both drafts are useful and they solved the different problems for different application scenarios.
Here are some my detail ideas£º
1. Regarding ¡°ID of an SRv6 Policy¡±
Per https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22/
#section-6.2
¡°
   The association of an SR Policy with a BSID thus MAY change over the
   life of the SR Policy (e.g., upon active path change).  Hence, the
   BSID SHOULD NOT be used as an identification of an SR Policy.
¡±
So£¬using the BSID as the redirect ID for an SRv6 Policy is not very appropriate.

For SRv6 Policy, maybe ID-type 0 or 5 can be used. But there are no such IDs for SRv6 Policy.

If we assign a new ID for SRv6 Policy, an additional mapping table needs to be maintained on both the controller and the devices ¨C 1 to1 Mapping redirect ID to (C, N) of SRv6 Policy.
This is a big modification to the current implementation. And redirect ID to (C, N) and (C, N) to redirect ID need to be mapped frequently, the operation is not so easy and it is prone to mis-operation.

Even, SRv6 Policy is not strictly a Tunnel, and assigning a tunnel ID to it may not be accepted by IETF community.

The draft-jiang-idr-ts-flowspec-srv6-policy introduces a combination: redirect-ip EC + Color EC, and then use it as (C, N) to associate SRv6 Policy, which can reuse most of the existing implementations , easy to operate, and will not mis-operation.

WH> what I am saying there is extension done for SRv6 (https://datatracker.ietf.org/doc/draft-ietf0-idr-srv6-flowspec-path-redirect/) and you can use the indirection ID as a color EC + redirect-ip and you have what you propose. Why would this not work?

2.  Regarding ¡°multiple color communities¡±£º
In the draft https://datatracker.ietf.org/doc/draft-jiang-idr-ts-flowspec-srv6-policy/ #section3
¡°
   In this document, the usage of at most one Color Extended Community
   in combination at most one BGP Prefix SID Attribute is discussed.
¡±
So there are no ambiguities in the Draft-jiang.

For the case that a flowspec route carries multiple Color Extend Communities, we can look at the description in Section 8.4.1 of https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
¡°
   When a BGP route has multiple Color Extended communities each with a
   valid SR Policy, the BGP process installs the route on the SR Policy
   giving preference to the Color Extended community with the highest
   numerical value.
¡±
We can add the above description in the Draft-jiang later to address your comments.

WH> what I am saying is that if you have multiple colors, with the redirect id I am proposing we can have multiple colors

BR
Wenying


----ÓʼþÔ­ÎÄ----
·¢¼þÈË£º"Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>
ÊÕ¼þÈË£º"½ªÎÄÓ±" <[e-mail]>,"ketant.ietf" <[e-mail]>,zhuangshunwan  <[e-mail]>
³­¡¡ËÍ: draft-jiang-idr-ts-f  <[e-mail]>,"[e-mail]" <[e-mail]>
·¢ËÍʱ¼ä£º2022-03-31 12:50:47
Ö÷Ì⣺Re: [Idr] flowspec srv6 policy


Hi,

Doing a bit more digging into this I believe the difference between what you propose versus the flowspec-path-redirect is the fact that  you propose to use the color/endpoint  in the BGP pkt instead of using the redirect ID in the flowspec NLRI

Now in any case we have to upgrade the SW to support the mapping of the flowspec to the SR-Policy. So the difference really is using color/endpoint versus the redirect  id (which actually also represent the same thing to map to the SR-Policy). Now as you pointed out the ambiguity if you have multiple color communities is resolved when you use the redirect id as you have only 1 option and as such is more safe as a mechanism.  It resolves the ambiguity.

Also given that this is a mechanism used for multiple scenario¡¯s not only SR-policy we should continue down this path in my view rather than doing special cases. My  2 cents

From: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>
Date: Wednesday, 30 March 2022 at 21:59
To: ½ªÎÄÓ± <[e-mail]>,  ketant.ietf <[e-mail]>, zhuangshunwan <[e-mail]>
Cc: draft-jiang-idr-ts-f <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Idr] flowspec srv6 policy
Thx for the info. It seems some people already added the SRV6 elements to the flow spec indirection-id

https://datatracker.ietf.org/doc/draft-ietf0-idr-srv6-flowspec-path-redirect/


From: Idr <[e-mail]> on behalf of ½ªÎÄÓ± <[e-mail]>
Date: Tuesday, 29 March 2022 at 10:49
To: ketant.ietf <[e-mail]>, zhuangshunwan <[e-mail]>
Cc: draft-jiang-idr-ts-f <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Idr] flowspec srv6 policy

Hi£¬Thanks for your comments.

I'm the co-author of the draft, which is rather than improving on the existing draft-ietf-idr-flowspec-path-redirect, here are some our consideration.

1.  The ¡¾draft-ietf-idr-flowspec-path-redirect¡¿ defines a new transitive BGP extended community. The existing network must be upgraded to support  the new sub-TLV.
The draft-jiang is based on the ¡¾draft-ietf-idr-segment-routing-te-policy¡¿ definition and is an application instance under Flowspec. That is, FlowSpec routes are steer to SRv6-Policy based on (Redirect-IP, Color EC) as (N, C).  No new TLV introduction, consistent with the existing network device implementation mechanism



2.  The ¡¾draft-ietf-idr-flowspec-path-redirect¡¿define ID-type 0 or 5£¬But there is  no these IDs for SRv6-Policy£¬and the length of Generalized indirection_id field is only 32-bit and cannot hold a SRv6-Policy BSID£¬Therefore£¬user  must assign a new 32-bit indirection_id to SRv6-Policy. In addition, this indirection_id is a global ID of multiple objects on one device, such as SR-Policy and SRv6-Policy, etc. ,  which complicates planning and deployment.
Also, since the current SRv6-Policy does not have such an ID£¬the SRv6-Policy needs to be extended to support such an ID configuration, which increases the complexity of the implementation and does not  take advantage of the deployed SRv6 Policy on the existing network.
Draft-jiang fully complies with the SRv6 Policy standard, identifying an SRv6 Policy by the <color£¬endpoint> tuple, which makes good use of the existing deployed SRv6 Policy and requiring essentially  no additional extensions, making it very simple to implement.



BR
Wenying Jiang


----ÓʼþÔ­ÎÄ----
·¢¼þÈË£ºKetan Talaulikar  <[e-mail]>
ÊÕ¼þÈË£ºZhuangshunwan  <zhuangshunwan=[e-mail]>
³­¡¡ËÍ: "[e-mail]" <[e-mail]>,"[e-mail]" <[e-mail]>
·¢ËÍʱ¼ä£º2022-03-25  18:44:42
Ö÷Ì⣺Re: [Idr] flowspec srv6 policy
Hi Shunwan,

It would be good to reference prior work and clarify the challenges with it that require the introduction of a new mechanism. Just a suggestion.

Thanks,
Ketan


On Fri, Mar 25, 2022 at 3:35 PM Zhuangshunwan <zhuangshunwan=[e-mail]<mailto:[e-mail]>> wrote:

Hi Wim,

Some forks from Nokia Shanghai Bell had also joined the discussion organized by China Mobile. Yes, they had mentioned draft-ietf-idr-flowspec-path-redirect.

In those joint discussions, we all agreed that these were 2 non-conflicting drafts.

Thanks,
Shunwan


From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Friday, March 25, 2022 5:59 PM
To: Wanghaibo (Rainsword) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: flowspec srv6 policy

Thx for the response. My point is it is better to extend an existing implementation rather than trying to define something new. As such my comment  is mainly to look  at the proposal I mentioned and augment it with the capabilities you wanted to add.

From: Wanghaibo (Rainsword) <[e-mail]<mailto:[e-mail]>>
Date: Friday, 25 March 2022 at 10:52
To: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: flowspec srv6 policy
Hi Henderickx,

The two drafts are used to resolve similar scenario, but with different solution.
Document draft-ietf-idr-flowspec-path-redirect defined a path redirect method.
But for SRv6 Policy , only ID-type 0 or 5 may be suitable. But there is no these IDs for SRv6-Policy.
So the operator must assign a new ID for SRv6-Policy and set to exist SRv6-Policy. This is not  intuitive.

Document draft-jiang-idr-ts-flowspec-srv6-policy introduce a combination: redirect-ip EC+ Color  EC,
Then use it as (N,C) to recursive SRv6-Policy, it can reuse most exists implementations and is  easy for operate.

Regards,
Haibo

From: Idr [mailto:[e-mail]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Friday, March 25, 2022 5:26 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [Idr] flowspec srv6 policy

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

Have people looked at the following draft which does something similar

https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr