Re: [Idr] //Re: Status changes as of 6/21/2022

Hi Robert,

Thanks for your clarification and comments!
Yes, what your explanation is perfect and can help all of us to understand the current solution.
“next hop using existing redirect-to-ip” will be a natural and convenient way, and we are pleased to see that section 11 of draft-kaliraj-idr-bgp-classful-transport-planes-16 also proposes the same solution.
We'll rewrite some of the texts per your suggestions to make the solution clearer.
Best Regards,
Shunwan
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Friday, June 24, 2022 4:05 AM
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: idr@ietf.org; Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] //Re: Status changes as of 6/21/2022

Hi Jeff,

The way I read this proposal they do not require any new code point allocation to either flowspec v1 or v2.

They instead took a clever idea to glue new functionality by next hop using existing redirect-to-ip functionality.

So the draft is Informational and presents new functionality with no protocol extension required.

Also that is confirmed in  the draft by either statement:

   For the case that a flowspec route carries multiple Color Extend
   Communities and/or a BGP Prefix SID Attribute, a protocol extension
   to Flowspec is required, and is thus out of the scope of this
   document.

&

6.  IANA Considerations
    No IANA actions are required for this document.

So I am not sure what potential squating you are referring to here.

Many thx,
Robert

PS .

I do think some rewrite is needed to make the text more clear. For example statements like this:

   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.

need to be reworded as they indeed make an illusion that new code points may be used.
While if I understand what authors meant to propose was to say instead "in the same UPDATE
message" not within the NLRI itself.

On Thu, Jun 23, 2022 at 9:30 PM Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>> wrote:
Wenying,

Glad to hear you're having good experiences with work on your draft.

However, please remember two things as you take your work forward:
- New features implemented in Flowspec v1 will cause session resets in
  implementations that don't understand the new feature.
- Please don't ship code that squats on an unallocated code point.  Not only
  does this raise issues of session resets, but may cause issues as we start
  having Flowspec v2 work make progress.  The code points for Flowspec v1 and
  v2 are likely to be the same.

The IDR Chairs would encourage you to support moving Flowspec v2 work
forward to help you safely and interoperably deploy the new feature.

-- Jeff

On Thu, Jun 23, 2022 at 09:51:57AM +0800, 姜文颖 wrote:
>
>
> Hi Sue and WG,
>
>
>
> draft-jiang-idr-ts-flowspec-srv6-policy has been presented at IETF#108/109/113 and got good feedback from WG. It has also been implemented by multiple vendors and successfully passed the joint interoperability test hosted  by China Mobile. We co-authors think that it is ready for WG adoption call. Would you please consider adding this document to the awaiting list of the adoption calls？
>
>
>
> Thanks,
>
> Wenying and co-authors

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr