Subject: Re: [Idr] flowspec srv6 policy

From: 姜文颖 <[email-masked]>
Date: Tue, 29 Mar 2022 16:48:48 +0800 (CST)

Hi，Thanks for your comments.

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

BRWenying Jiang

----邮件原文----发件人：Ketan Talaulikar  <[email-masked]>收件人：Zhuangshunwan  <zhuangshunwan=[email-masked]>抄　送: "[email-masked]" <[email-masked]>,"[email-masked]" <[email-masked]>发送时间：2022-03-25 18:44:42主题：Re: [Idr] flowspec srv6 policyHi 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=[email-masked]> 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:[email-masked]] Sent: Friday, March 25, 2022 5:59 PM To: Wanghaibo (Rainsword) <[email-masked]> [email-masked] [email-masked] 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) <[email-masked]> Date: Friday, 25 March 2022 at 10:52 To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]> 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:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp) Sent: Friday, March 25, 2022 5:26 PM To: [email-masked] [email-masked] Subject: [Idr] flowspec srv6 policy

Regarding [email-masked]

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 [email-masked] https://www.ietf.org/mailman/listinfo/idr

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 30 Mar 2022 19:59:21 +0000

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 <[email-masked]> on behalf of 姜文颖 <[email-masked]>
Date: Tuesday, 29 March 2022 at 10:49
To: ketant.ietf <[email-masked]>, zhuangshunwan <[email-masked]>
Cc: draft-jiang-idr-ts-f <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Idr] flowspec srv6 policy

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  <[email-masked]>
收件人：Zhuangshunwan  <zhuangshunwan=[email-masked]>
抄　送: "[email-masked]" <[email-masked]>,"[email-masked]" <[email-masked]>
发送时间：2022-03-25 18:44:42
主题：Re: [Idr] flowspec srv6 policy
Hi Shunwan,

Thanks,
Ketan

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

Hi Wim,

Thanks,
Shunwan

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

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

Regards,
Haibo

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

Regarding [email-masked]<mailto:[email-masked]>

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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 31 Mar 2022 04:50:47 +0000

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) <[email-masked]>
Date: Wednesday, 30 March 2022 at 21:59
To: 姜文颖 <[email-masked]>, ketant.ietf <[email-masked]>, zhuangshunwan <[email-masked]>
Cc: draft-jiang-idr-ts-f <[email-masked]>, [email-masked] <[email-masked]>
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

BR
Wenying Jiang

----邮件原文----

Thanks,
Ketan

Hi Wim,

Thanks,
Shunwan

Regards,
Haibo

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Mar 2022 11:21:16 +0200

All,

Just for the record ... Yes, the redirect function is very important
functionality and has been in flowspec 5575 since day one.

The only important design decision is that both Pedro and myself were of
the opinion that flow redirection or "tee" function needs to be built with
hierarchy in mind for flexibility and scaling aspects.

That is why original 5575 only allows redirection to a VRF. From there you
can handle the traffic in zoo of different ways, but you keep flowspec
protocol agnostic to those redirect destinations. Such local VRF redirect
implementation wise also can be built very efficiently and packets do not
recirculate.

I see now a lot of complexity introduced to flatten this and carry in
flowspec destinations next hops, colors, IDs ... That to me is an
indication that we are walking in the opposite direction
for questionable convenience.

I realize that this note may not change current proposals, but at min I do
recommend that when you are defining redirect a match option "ALL FROM VRF
FOO" is provided so at least those operators who will be willing to deploy
this have operational choice to use it flat or in a hierarchical manner.

Best,
Robert

On Thu, Mar 31, 2022 at 6:51 AM Henderickx, Wim (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> 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) <[email-masked]>
> *Date: *Wednesday, 30 March 2022 at 21:59
> *To: *姜文颖 <[email-masked]>, ketant.ietf <
> [email-masked]>, zhuangshunwan <[email-masked]>
> *Cc: *draft-jiang-idr-ts-f <
> [email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *Re: [Idr] flowspec srv6 policy
>
> *From: *Idr <[email-masked]> on behalf of 姜文颖 <
> [email-masked]>
> *Date: *Tuesday, 29 March 2022 at 10:49
> *To: *ketant.ietf <[email-masked]>, zhuangshunwan <
> [email-masked]>
> *Cc: *draft-jiang-idr-ts-f <
> [email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *Re: [Idr] flowspec srv6 policy
>
> 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  <[email-masked]>
> *收件人：*Zhuangshunwan  <zhuangshunwan=[email-masked]>
> *抄 送**: *"[email-masked]" <
> [email-masked]>,"[email-masked]" <
> [email-masked]>
> *发**送**时间**：*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
>
>
>
>
>
> 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.
>
>
>
> *From:* Henderickx, Wim (Nokia - BE/Antwerp) [mailto:
> [email-masked]]
> *Sent:* Friday, March 25, 2022 5:59 PM
> *To:* Wanghaibo (Rainsword) <[email-masked]>;
> [email-masked]; [email-masked]
> *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) <[email-masked]>
> *Date: *Friday, 25 March 2022 at 10:52
> *To: *Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>,
> [email-masked] <
> [email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *RE: flowspec srv6 policy
>
> Hi Henderickx,
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Henderickx, Wim (Nokia - BE/Antwerp)
> *Sent:* Friday, March 25, 2022 5:26 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* [Idr] flowspec srv6 policy
>
>
>
> [email-masked]
> [email-masked]