Re: [Idr] draft-jiang-idr-ts-flowspec-srv6-policy-07.txt - (8/17/2022 to 8/31/2022

[Nat Kao <[e-mail]>]

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.
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."
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).

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.

Many Thanks.
Nat


On Mon, Mar 6, 2023 at 5:07 PM Zhuangshunwan <[e-mail]>
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:[e-mail]] *On Behalf Of *Nat Kao
> *Sent:* Wednesday, August 31, 2022 4:30 PM
> *To:* Susan Hares <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
> Regards,
>
> Nat
>
>
>
>
>