Re: [Idr] //FW: I-D Action: draft-ietf-idr-ts-flowspec-srv6-policy-02.txt

Hi, Nat

     Thank you very much for your comments. 

     Please check my comments inline below with [Wenying].

Many Thanks,

Wenying

From: Nat Kao [mailto:pyxislx@gmail.com] Sent: Thursday, March 9, 2023 10:46 PM To: Zhuangshunwan <zhuangshunwan@huawei.com> Cc: Susan Hares <shares@ndzh.com> idr@ietf.org Nat Kao (PyxisLX) <pyxislx@gmail.com> Subject: Re: [Idr] draft-jiang-idr-ts-flowspec-srv6-policy-07.txt - (8/17/2022 to 8/31/2022

Hi, Shunwan.

First of all, thank you so much for including the SR-MPLS use case.

After carefully reading, I have a few suggestions: 1. It would be pretty useful if we also covered "Flow-spec Redirect to IPv6" descriptions in Chapter 4.     In RFC9256, there were no limitations on the AFI/SAFI of the endpoints.     We could steer traffic into SR-Policies constructed with SR-MPLS SID Lists with either IPv4 or IPv6 endpoints.     So we could have a unified steering framework for both IPv4/IPv6 endpoints and SR-MPLS/SRv6 SID Lists.     It also added flexibility in dual-stacked SR-MPLS networks.

[Wenying] Agree with you.

 2. It would be worth mentioning the case regarding multiple Color Extended communities.     We could refer this behavior to Section 8.4.1 of RFC9256:     "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."

[Wenying] Agreed. We have added the above text to page 5 of the draft. https://datatracker.ietf.org/doc/draft-ietf-idr-ts-flowspec-srv6-policy/02/.

 3. [Optional] A pretty minor one: It would be better to unify the terms "SR List" and "SID List"     We could align the terms with RFC9256(SID List).

[Wenying] Agreed, We will use the uniform term "SID List" in the draft. 

The following might be out of the scope of this draft, but worth mentioning: 1. [Optional] Should we consider Flow-spec routes with multiple "Redirect to IPv4/IPv6" extended communities?     If yes, what kind of behavior should be defined?     For example, we might want to:         -Load balance traffic into multiple SR-Policies with different endpoints          OR         -Ignore the Color Extended community in this case(resulting the same behavior defined in "draft-ietf-idr-flowspec-redirect-ip")                                                                                                                                   2. [Optional] Should we consider the case defined in "draft-ietf-idr-flowspec-redirect-ip" with mixed "Redirect to VRF" and "Redirect to IPv4/IPv6" actions?

    If yes, I would suggest that we should ignore Color Extended communities in this case since most implementations had only one shared SR-Policy table.     It might not be reasonable to have SR-Policies in different tables/VRFs currently.

[Wenying] Agree with you that the above is beyond the scope of this draft. Perhaps we can discuss together afterwards to see if there is an opportunity to submit new drafts.

Many Thanks.

Nat

On Mon, Mar 6, 2023 at 5:07PM Zhuangshunwan <zhuangshunwan@huawei.com>  wrote:

Hi Nat and All,

As promised, we have added SR-MPLS use case in draft-ietf-idr-ts-flowspec-srv6-policy.

Special thanks to Nat Kao for suggesting adding SR-MPLS use cases to this document.

The IETF datatracker status page for this Internet-Draft is:

https://datatracker.ietf.org/doc/draft-ietf-idr-ts-flowspec-srv6-policy/

There is also an htmlized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-idr-ts-flowspec-srv6-policy-02

A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-ts-flowspec-srv6-policy-02

Any comments and suggestions are welcome!

Best Regards,

Shunwan

From: Idr  [mailto:idr-bounces@ietf.org] On Behalf Of Nat Kao Sent: Wednesday, August 31, 2022 4:30 PM To: Susan Hares <shares@ndzh.com> Cc: idr@ietf.org Subject: Re: [Idr] draft-jiang-idr-ts-flowspec-srv6-policy-07.txt - (8/17/2022 to 8/31/2022

Hi, Susan & WG.

As an operator, I support WG adoption of this draft.

This approach is very useful for on-demand traffic steering with specific/dynamic traffic patterns.

My answers are inline:

On Wed, Aug 17, 2022 at 10:59 PM Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG adoption call for draft-jiang-idr-ts-flowspec-srv6-policy-07.txt

https://datatracker.ietf.org/doc/draft-jiang-idr-ts-flowspec-srv6-policy/

During your discussion of this draft, please consider:

1) Do you agree with extending 8955 and 8956 to carry the

action bit [C] found for IPv4 and IPv6 found

draft-ietf-idr-flowspec-redirect-ip-02.txt

Figure 1 : Local Administrator

0                   1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|          Reserved           |C|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C = 0 – redirect original flow

C = 1 – redirect copy of original flow

This bit augments the Redirect to IP action in RFC8955

And RFC8956.

Yes.

2) Do you agree with this document use of this feature

in addition to  draft-ietf-idr-flowspec-path-redirect

https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/

See the following thread for a discussion of this in March:

 https://mailarchive.ietf.org/arch/msg/idr/HENTMEoiMJGmcMuVz7LTYclCSdw/

Yes, this approach provides a unified way for steering traffic into SR-policies using either SR-MPLS or SRv6 SID-lists.

Note: As discussed before, the same mechanism can also be applied to policies with SR-MPLS SID-lists. 

https://mailarchive.ietf.org/arch/msg/idr/q0If1M-UgoeeM16HR-TXCSWRTAQ/

3) Will this work help deployment of SRv6 networks?

Yes.

We’ll discuss this draft at the IDR interim on 8/29/2022.

Cheerily, Susan Hares

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

Regards,

Nat