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 <jiangweny...@chinamobile.com>
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 -- spring@ietf.org
> To unsubscribe send an email to spring-le...@ietf.org
>
On Fri, Aug 30, 2024 at 2:50 PM Wenying Jiang <jiangweny...@chinamobile.com>
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 -- spring@ietf.org
> To unsubscribe send an email to spring-le...@ietf.org
>
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
