Subject: [Idr] flowspec srv6 policy

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 25 Mar 2022 09:26:16 +0000

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

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Fri, 25 Mar 2022 09:52:37 +0000

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]<mailto:[email-masked]>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 25 Mar 2022 09:58:44 +0000

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,

Regards,
Haibo

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 25 Mar 2022 10:05:05 +0000

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

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

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 25 Mar 2022 16:14:42 +0530

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=
[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.
>
>
>
> *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
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 25 Mar 2022 10:47:08 +0000

Indeed let’s see if we really need a new mechanism and at the end this is a WG decision.

From: Ketan Talaulikar <[email-masked]>
Date: Friday, 25 March 2022 at 11:44
To: Zhuangshunwan <zhuangshunwan=[email-masked]>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>, Wanghaibo (Rainsword) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: 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=[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

Regards,
Haibo

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: Fri, 25 Mar 2022 10:49:16 +0000

As Ketan suggest please motivate why you decided to go down a new track.

From: Idr <[email-masked]> on behalf of Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Date: Friday, 25 March 2022 at 11:47
To: Ketan Talaulikar <[email-masked]>, Zhuangshunwan <zhuangshunwan=[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Idr] flowspec srv6 policy
Indeed let’s see if we really need a new mechanism and at the end this is a WG decision.

Thanks,
Ketan

Hi Wim,

Thanks,
Shunwan

Regards,
Haibo

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Mar 2022 12:20:56 +0100

Zhuangshunwan,

Your document says:

   This document proposes to carry the Color Extended Community and BGP
   Prefix-SID Attribute in the context of a Flowspec NLRI [RFC8955]
   [RFC8956] to an SRv6 Headend to steer traffic into one SRv6 policy,
   as well as to indicate specific Tailend functions.

Please observe that we already have a way to do exactly that with BGP as
described in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-16

See section 3 about color .

So why to define the same thing twice ? How to resolve conflicts when both
extensions will provide contradicting steering ?

I am not seeing much rationale for this draft. And I do not buy "Oh this is
just another way"  type of answer.

Best,
R.

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Sat, 26 Mar 2022 02:58:08 +0000

Hi  Robert,

I don't think it's a conflict.
[draft-ietf-idr-segment-routing-te-policy-16] just defined the mechanism for route resolution.
But how to use it in Non-unicast-route’s address family? Especially for the Flowspec SAFI, there is no nexthop.
This document is an informational draft. It just defined the usage of combine these elements and how to use it in Flowspec address family.

Regards,
Haibo

From: Robert Raszuk [mailto:[email-masked]]
Sent: Friday, March 25, 2022 7:21 PM
To: Zhuangshunwan <zhuangshunwan=[email-masked]>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Wanghaibo (Rainsword) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] flowspec srv6 policy

Zhuangshunwan,

Your document says:

Please observe that we already have a way to do exactly that with BGP as described in https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-16

So why to define the same thing twice ? How to resolve conflicts when both extensions will provide contradicting steering ?

I am not seeing much rationale for this draft. And I do not buy "Oh this is just another way"  type of answer.

Best,
R.

On Fri, Mar 25, 2022 at 11:05 AM Zhuangshunwan <zhuangshunwan=[email-masked]<mailto:[email-masked]>> wrote:

Hi Wim,

Thanks,
Shunwan

Regards,
Haibo

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 26 Mar 2022 10:46:22 -0400

Hi Shuwan

I agree the two drafts are very similar and as Kethan and others have
mentioned that in your draft you should make informational reference to the
redirect  draft and state what challenges are faced by that draft and the
gap that your draft solves in SRv6 steering using BGP Flowspec.  That would
be a good read out comparison and contrast that should be included in the
draft ideally to help progress.

In your presentation slide 3, is option 1 the redirect draft I am guessing.

Also in slide 3 the FS SAFI 133 is matching global table prefixes and I am
assuming this solution works for SAFI 134 for VPN as it’s using existing
mechanisms. Also was the implementation and interoperability test done on
both Global and VPN FS   133 and 134.

In the presentation you mentioned changing draft status from standards
track to informational however you mention that this was implemented and
tested by the vendor platforms listed.  As this draft is using existing
mechanisms what was needed to be implemented by the vendors for the test.

In your interoperability test both inter domain and intra domain and load
balancing to the tail end using multiple paths in one SRv6 policy using FS
route to indicate SRv6 policy?

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 30 Mar 2022 07:01:23 +0000

Hi Wim,

Thanks for your comment.  I think that Wen Ying has made a good explanation, please refer to Wen Ying's reply.
https://mailarchive.ietf.org/arch/msg/idr/XMQCzwFTRpi4iY6z1HHZ6c960IE/

Regards,
Shunwan

From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:[email-masked]]
Sent: Friday, March 25, 2022 6:49 PM
To: Ketan Talaulikar <[email-masked]>; Zhuangshunwan <zhuangshunwan=[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] flowspec srv6 policy

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>
Date: Friday, 25 March 2022 at 11:47
To: Ketan Talaulikar <[email-masked]<mailto:[email-masked]>>, Zhuangshunwan <zhuangshunwan=[email-masked]<mailto:zhuangshunwan=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] flowspec srv6 policy
Indeed let's see if we really need a new mechanism and at the end this is a WG decision.

From: Ketan Talaulikar <[email-masked]<mailto:[email-masked]>>
Date: Friday, 25 March 2022 at 11:44
To: Zhuangshunwan <zhuangshunwan=[email-masked]<mailto:zhuangshunwan=[email-masked]>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>, Wanghaibo (Rainsword) <[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: [Idr] flowspec srv6 policy
Hi Shunwan,

Thanks,
Ketan

Hi Wim,

Thanks,
Shunwan

Regards,
Haibo

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 30 Mar 2022 09:01:03 +0000

Hi Gyan,

Thanks for your helpful comments and suggestions.
Please check inline below with [SW].

Kind Regards,
Shunwan

From: Gyan Mishra [mailto:[email-masked]]
Sent: Saturday, March 26, 2022 10:46 PM
To: Zhuangshunwan <zhuangshunwan=[email-masked]>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Wanghaibo (Rainsword) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] flowspec srv6 policy

Hi Shuwan

I agree the two drafts are very similar and as Kethan and others have mentioned that in your draft you should make informational reference to the redirect  draft and state what challenges are faced by that draft and the gap that your draft solves in SRv6 steering using BGP Flowspec.  That would be a good read out comparison and contrast that should be included in the draft ideally to help progress.
[SW] Regarding the comparison between the two drafts, I think the co-author Wenying has made a good explanation, and we can refer to Wenying's reply.
https://mailarchive.ietf.org/arch/msg/idr/XMQCzwFTRpi4iY6z1HHZ6c960IE/
In next revision, we will add more detailed descriptions.

Also in slide 3 the FS SAFI 133 is matching global table prefixes and I am assuming this solution works for SAFI 134 for VPN as it’s using existing mechanisms. Also was the implementation and interoperability test done on both Global and VPN FS   133 and 134.
[SW] The current requirement is to match global table prefixes. For VPN scenarios, we can use the Flowspec redirect VRF solution defined in RFC8955 & RFC8956, due to this reason, the solution described in this document has not been considered yet. We will consider whether this solution is necessary in the VPN scenarios.

In the presentation you mentioned changing draft status from standards track to informational however you mention that this was implemented and tested by the vendor platforms listed.  As this draft is using existing mechanisms what was needed to be implemented by the vendors for the test.
[SW] Due to the solution described in this draft uses various existing components, but there are no new IANA applications, after the IETF109 presentation, per the comments of Jeff and John, the intended status of this draft had been changed to informational.

The basic idea provided by this draft is: Flowspec NLRI + Redirect IP Action + Policy Color + PrefixSID (Optional)

Using Nexthop from Redirect IP Action and Policy Color to associate with the SRv6 Policy (C, N), it is a new protocol specification that is not documented in the other drafts.

And “PrefixSID carried in Flowspec route” is also another new protocol specification.

The purpose of interoperability testing is to ensure that multiple vendors have identical implementations of the above two new protocol specifications.

In your interoperability test both inter domain and intra domain and load balancing to the tail end using multiple paths in one SRv6 policy using FS route to indicate SRv6 policy?
[SW] Yes.

Thanks again,
Shunwan

Kind Regards

Gyan

On Fri, Mar 25, 2022 at 6:05 AM Zhuangshunwan <zhuangshunwan=[email-masked]<mailto:[email-masked]>> wrote:

Hi Wim,

Thanks,
Shunwan

Regards,
Haibo

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 30 Mar 2022 10:01:37 -0400

Hi Shuwan

I read Wenying’s comments and they really helped explain the gap with the
redirect draft and the benefits for operators in simplicity using the SRv6
FS policy.

I would recommend adding Wenying’s comparison verbiage clearly identifying
the gaps to your draft.

I support progressing the draft as it would be great benefit to operator
deployments of SRv6.

Kind Regards

Gyan
On Wed, Mar 30, 2022 at 5:01 AM Zhuangshunwan <[email-masked]>
wrote:

> *From:* Gyan Mishra [mailto:[email-masked]]
> *Sent:* Saturday, March 26, 2022 10:46 PM
> *To:* Zhuangshunwan <zhuangshunwan=[email-masked]>
> *Cc:* Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>;
> Wanghaibo (Rainsword) <[email-masked]>;
> *Subject:* Re: [Idr] flowspec srv6 policy
>
>
>
>
>
> Hi Shuwan
>
>
>
> [SW] Regarding the comparison between the two drafts, I think the
> co-author Wenying has made a good explanation, and we can refer to
> Wenying's reply.
>
> [SW] The current requirement is to match global table prefixes. For VPN
> scenarios, we can use the Flowspec redirect VRF solution defined in RFC8955
> & RFC8956, due to this reason, the solution described in this document has
> not been considered yet. We will consider whether this solution is
> necessary in the VPN scenarios.
>
>
>
>
>
> [SW] Due to the solution described in this draft uses various existing
> components, but there are no new IANA applications, after the IETF109
> presentation, per the comments of Jeff and John, the intended status of
> this draft had been changed to informational.
>
>
>
> The basic idea provided by this draft is: Flowspec NLRI + Redirect IP
> Action + Policy Color + PrefixSID (Optional)
>
>
>
> Using Nexthop from Redirect IP Action and Policy Color to associate with
> the SRv6 Policy (C, N), it is a new protocol specification that is not
> documented in the other drafts.
>
>
>
> The purpose of interoperability testing is to ensure that multiple vendors
> have identical implementations of the above two new protocol specifications.
>
>
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 31 Mar 2022 02:03:47 +0000

Hi Gyan,

Thanks for your interest, comments, suggestions and support for this work!

Kind Regards,
Shunwan

From: Gyan Mishra [mailto:[email-masked]]
Sent: Wednesday, March 30, 2022 10:02 PM
To: Zhuangshunwan <[email-masked]>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Wanghaibo (Rainsword) <[email-masked]>; Zhuangshunwan <zhuangshunwan=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] flowspec srv6 policy

Hi Shuwan

I read Wenying’s comments and they really helped explain the gap with the redirect draft and the benefits for operators in simplicity using the SRv6 FS policy.

I would recommend adding Wenying’s comparison verbiage clearly identifying the gaps to your draft.

I support progressing the draft as it would be great benefit to operator deployments of SRv6.

Kind Regards

Gyan
On Wed, Mar 30, 2022 at 5:01 AM Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Kind Regards,
Shunwan

From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, March 26, 2022 10:46 PM
To: Zhuangshunwan <zhuangshunwan=[email-masked]<mailto:[email-masked]>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] flowspec srv6 policy

Hi Shuwan

Thanks again,
Shunwan

Kind Regards

Gyan

Hi Wim,

Thanks,
Shunwan

Regards,
Haibo

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347