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.

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

On Fri, Mar 25, 2022 at 6:05 AM Zhuangshunwan <zhuangshunwan=
40huawei.com@dmarc.ietf.org> 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:
> wim.henderickx@nokia.com]
> *Sent:* Friday, March 25, 2022 5:59 PM
> *To:* Wanghaibo (Rainsword) <rainsword.wang@huawei.com>;
> draft-jiang-idr-ts-flowspec-srv6-policy@ietf.org; idr@ietf.org
> *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) <rainsword.wang@huawei.com>
> *Date: *Friday, 25 March 2022 at 10:52
> *To: *Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>,
> draft-jiang-idr-ts-flowspec-srv6-policy@ietf.org <
> draft-jiang-idr-ts-flowspec-srv6-policy@ietf.org>, idr@ietf.org <
> idr@ietf.org>
> *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:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
> Behalf Of *Henderickx, Wim (Nokia - BE/Antwerp)
> *Sent:* Friday, March 25, 2022 5:26 PM
> *To:* draft-jiang-idr-ts-flowspec-srv6-policy@ietf.org; idr@ietf.org
> *Subject:* [Idr] flowspec srv6 policy
>
>
>
> Regarding draft-jiang-idr-ts-flowspec-srv6-policy@ietf.org
>
>
>
> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*