Re: [Idr] flowspec srv6 policy

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

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