[spring] Re: New Version Notification for draft-cheng-spring-sr-policy-group-05.txt

[Nat Kao <[e-mail]>]

Hi, Wenying.

Thanks for this draft.
This draft provides a reasonable mechanism to steer traffic by different
flow characteristics or QoS classes.

-If I understand correctly, this draft modifies the load-balancing behavior
defined in paragraph 5, Sec. 2.11 of RFC9256.
 There are three levels of recursion:
    1. SR Policy Group(SRPG) level. Grouped by the color of the SRPG.
        The resolution procedure for a specific service route with (NH=E,
Color=C) starts with the color C.
        C indicates the intent for per-flow-characteristic/SLA resolution
using SRPG PG1.
    2. Parent SR-Policy(p-SRP) level. Grouped by different endpoints.
        Inside PG1, we resolve the service route with NH=E for a specific
p-SRP (E, C1).
    3. Constituent SR-Policy(c-SRP) level. Grouped by different flow
characteristics.
        Inside p-SRP (E, C1), the service route resolves into an array of
c-SRPs (E, Cx).
        As defined in PG1, we map per-flow-characteristic/SLA to color
'Cx' instead of weighted load-balancing defined in RFC9256.
        The above procedure also ignores the relative weight(assigned at
the p-SRP level) of those c-SRPs.
    Please correct me if I'm wrong.

-AFAIK, for a specific SRPG PG1, only its color C1 is relevant. Its
endpoint is irrelevant.
 However, as defined in paragraph 3, Sec.4, an SRPG is identified by
<color, endpoint>.
 Not sure how we define an SRPG's endpoint. Maybe I've missed something?

-The interactions with the Color-EC CO bits carried in the service route
are not mentioned.
 Are those bits ignored in this mechanism?

-We might need to consider some corner cases:
    1. What is the precedence between an SR policy and an SRPG if they
share the same color?
    2. How do we fall back when both the SRPG and the p-SRP are available
while the c-SRP is not?
       Is the "drop-upon-invalid" behavior of the p-SRP and the c-SRPs
relevant in this situation?

-Chapter 6 provides a concise and straightforward introduction to the whole
approach.
 I would suggest moving Chapter 6 before Chapter 3 for better readability.

Thanks!
Nat


On Fri, Aug 30, 2024 at 2:50 PM Wenying Jiang <[e-mail]>
wrote:

> Hi WG,
>
>
>
> We have submitted a new version of draft-cheng-spring-sr-policy-group
> according to the suggestions received.
>
> https://datatracker.ietf.org/doc/draft-cheng-spring-sr-policy-group/05/
>
>
>
> This draft was presented at IETF-115 and IETF-117.
>
> For detailed content, please refer to the presentation slides from
> IETF-117:
>
>
> https://datatracker.ietf.org/meeting/117/materials/slides-117-spring-sr-policy-groupslides-117-spring-sr-policy-group-00.pdf
>
>
>
> The main updates of version 05 include:
>
> 1.Adding Chapter 9, which provides details on the implementation status
> of various vendors.
>
>
>
> Further review and comments are welcome, thank you.
>
>
>
> BR.
>
> Wenying
>
>
> _______________________________________________
> spring mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>

On Fri, Aug 30, 2024 at 2:50 PM Wenying Jiang <[e-mail]>
wrote:

> Hi WG,
>
>
>
> We have submitted a new version of draft-cheng-spring-sr-policy-group
> according to the suggestions received.
>
> https://datatracker.ietf.org/doc/draft-cheng-spring-sr-policy-group/05/
>
>
>
> This draft was presented at IETF-115 and IETF-117.
>
> For detailed content, please refer to the presentation slides from
> IETF-117:
>
>
> https://datatracker.ietf.org/meeting/117/materials/slides-117-spring-sr-policy-groupslides-117-spring-sr-policy-group-00.pdf
>
>
>
> The main updates of version 05 include:
>
> 1.Adding Chapter 9, which provides details on the implementation status
> of various vendors.
>
>
>
> Further review and comments are welcome, thank you.
>
>
>
> BR.
>
> Wenying
>
>
> _______________________________________________
> spring mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>