Re: [Idr] flowspec srv6 policy

[linchangwang <[e-mail]>]

Hi Wim,

Thanks for your comments.

<WH> what I am saying there is extension done for SRv6 (https://datatracker.ietf.org/doc/draft-ietf0-idr-srv6-flowspec-path-redirect/) and you can use the indirection ID as a color EC + redirect-ip and you have what you propose. Why would this not work?

<Changwang lin> :  For redirecting traffic through the indirection ID or a color EC + redirect-ip, the reply is as follows:

Refer to https://datatracker.ietf.org/doc/draft-ietf0-idr-srv6-flowspec-path-redirect/, the indirection_id is mapped to SRv6 binding SID.
indirection_id,  ID-Type: 1 octet value.  This draft defines following Context Types:
  *  7 - Binding Segment ID with SID/index in SRv6 (This means the
      indirection-id is mapped to an SRv6 binding SID using the
      indirection-id as index for global offset in the SID space).
   *  8 - Binding Segment ID with SID/index in SRv6 (This means
      indirection-id is mapped to an SRv6 binding SID using the
      indirection-id as global SRv6 SID).
The Binding SID SHOULD NOT be used as an identification of an SR Policy Refer to https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22/
Section 6.2.
The association of an SR Policy with a BSID thus MAY change over the life of the SR Policy (e.g., upon active path change).
Hence, the BSID SHOULD NOT be used as an identification of an SR Policy.

Refer to https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22  section2.1:
2.1.  Identification of an SR Policy
An SR Policy MUST be identified through the tuple <headend, color,endpoint>.
In the context of a specific headend, an SR policy MUST be identified by the <color, endpoint> tuple.

Therefore, it is inappropriate to indirection ID to map binding Sid and then binding Sid to map srv6 policy. Binding sid is not the identification of srv6 policy.

This document [draft-jiang-idr-ts-flowspec-srv6-policy-07] redirects traffic to srv6 policy through a color EC + redirect-ip,
there is no ambiguity in the implementation, the method of steering traffic to srv6 policy based on the Color Extended community is widely used in various scenarios,which is more universal and easy to deploy.


Best regards,
Changwang lin



----------------------------------------------------------------------
Date: Sat, 2 Apr 2022 06:02:44 +0000
From: "Henderickx, Wim (Nokia - BE/Antwerp)"
        <[e-mail]>
To: ??? <[e-mail]>, ketant.ietf
        <[e-mail]>, zhuangshunwan <[e-mail]>,
        rainsword.wang <[e-mail]>
Cc: draft-jiang-idr-ts-f
        <[e-mail]>, "[e-mail]"
        <[e-mail]>
Subject: Re: [Idr] flowspec srv6 policy
Message-ID:
        <[e-mail]>

Content-Type: text/plain; charset="gb2312"

In--line

From: ??? <[e-mail]>
Date: Friday, 1 April 2022 at 12:45
To: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>, ketant.ietf <[e-mail]>, zhuangshunwan <[e-mail]>, rainsword.wang <[e-mail]>
Cc: draft-jiang-idr-ts-f <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re:Re: [Idr] flowspec srv6 policy

Hi Wim,
Thank you for your comments.

As we mentioned in mails, we believe the both drafts are useful and they solved the different problems for different application scenarios.
Here are some my detail ideas?
1. Regarding ?ID of an SRv6 Policy?
Per https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22/
#section-6.2
?
   The association of an SR Policy with a BSID thus MAY change over the
   life of the SR Policy (e.g., upon active path change).  Hence, the
   BSID SHOULD NOT be used as an identification of an SR Policy.
?
So?using the BSID as the redirect ID for an SRv6 Policy is not very appropriate.

For SRv6 Policy, maybe ID-type 0 or 5 can be used. But there are no such IDs for SRv6 Policy.

If we assign a new ID for SRv6 Policy, an additional mapping table needs to be maintained on both the controller and the devices ? 1 to1 Mapping redirect ID to (C, N) of SRv6 Policy.
This is a big modification to the current implementation. And redirect ID to (C, N) and (C, N) to redirect ID need to be mapped frequently, the operation is not so easy and it is prone to mis-operation.

Even, SRv6 Policy is not strictly a Tunnel, and assigning a tunnel ID to it may not be accepted by IETF community.

The draft-jiang-idr-ts-flowspec-srv6-policy introduces a combination: redirect-ip EC + Color EC, and then use it as (C, N) to associate SRv6 Policy, which can reuse most of the existing implementations , easy to operate, and will not mis-operation.

WH> what I am saying there is extension done for SRv6 (https://datatracker.ietf.org/doc/draft-ietf0-idr-srv6-flowspec-path-redirect/) and you can use the indirection ID as a color EC + redirect-ip and you have what you propose. Why would this not work?

2.  Regarding ?multiple color communities??
In the draft https://datatracker.ietf.org/doc/draft-jiang-idr-ts-flowspec-srv6-policy/ #section3
?
   In this document, the usage of at most one Color Extended Community
   in combination at most one BGP Prefix SID Attribute is discussed.
?
So there are no ambiguities in the Draft-jiang.

For the case that a flowspec route carries multiple Color Extend Communities, we can look at the description in Section 8.4.1 of https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
?
   When a BGP route has multiple Color Extended communities each with a
   valid SR Policy, the BGP process installs the route on the SR Policy
   giving preference to the Color Extended community with the highest
   numerical value.
?
We can add the above description in the Draft-jiang later to address your comments.

WH> what I am saying is that if you have multiple colors, with the redirect id I am proposing we can have multiple colors

BR
Wenying


----????----
????"Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>
????"???" <[e-mail]>,"ketant.ietf" <[e-mail]>,zhuangshunwan  <[e-mail]>
???: draft-jiang-idr-ts-f  <[e-mail]>,"[e-mail]" <[e-mail]>
?????2022-03-31 12:50:47
???Re: [Idr] flowspec srv6 policy


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]<mailto:[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]<mailto:[e-mail]>]
Sent: Friday, March 25, 2022 5:59 PM
To: Wanghaibo (Rainsword) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, 25 March 2022 at 10:52
To: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Friday, March 25, 2022 5:26 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [Idr] flowspec srv6 policy

Regarding [e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/idr/attachments/20220402/07277ea1/attachment.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr


------------------------------

End of Idr Digest, Vol 216, Issue 4
***********************************

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!