Re: [Idr] flowspec srv6 policy

[Robert Raszuk <[e-mail]>]

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) <
[e-mail]> 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) <[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]> 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]]
> *Sent:* Friday, March 25, 2022 5:59 PM
> *To:* Wanghaibo (Rainsword) <[e-mail]>;
> [e-mail]; [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]>
> *Date: *Friday, 25 March 2022 at 10:52
> *To: *Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail] <
> [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] <[e-mail]>] *On
> Behalf Of *Henderickx, Wim (Nokia - BE/Antwerp)
> *Sent:* Friday, March 25, 2022 5:26 PM
> *To:* [e-mail]; [e-mail]
> *Subject:* [Idr] flowspec srv6 policy
>
>
>
> Regarding [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]
> https://www.ietf.org/mailman/listinfo/idr
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>