Hi Nat,
Thank you for your comment. For a detailed response, please see inline with
[Wenying].
Thanks,
Wenying
----邮件原文----发件人：Nat Kao <pyxi...@gmail.com>收件人：Wenying Jiang
<jiangweny...@chinamobile.com>抄 送: SPRING WG List
<spring@ietf.org>发送时间：2024-09-05 12:32:22主题：[spring] Re: New Version
Notification for draft-cheng-spring-sr-policy-group-05.txtHi, 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 39Cx39 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 I39m wrong.
[Wenying] You understood correctly traffic steering based on flow
characteristics is achieved through three levels.
1. The Policy Group level uses colors to identify different service qualities.
2. The Parent SR Policy is identified by a combination of color and endpoint to
signify a set of point-to-point SR Policies with different service qualities.
3. Finally, after traffic enters the Parent SR Policy, it is forwarded through
different SR Policies based on specific flow characteristics.
In fact, section 2.2 of RFC9256 defines Parent SR Policies, and section 8.6
(Per-flow Steering) describes this forwarding scenario.
This document refines the hierarchical traffic steering framework of SR Policy
Groups in its entirety.
-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 SRPG39s endpoint. Maybe I39ve
missed something?[Wenying] This description in paragraph 3, Sec. 4 is
incorrect. The SR Policy Group defines point-to-multipoint paths without
endpoints. We will fix this in the next version.
-The interactions with the Color-EC CO bits carried in the service route are
not mentioned. Are those bits ignored in this mechanism?[Wenying] This document
does not change the existing traffic steering mechanism but needs to supplement
how it works in coordination with the original steering. For detailed
descriptions, please refer to section 6.
We will add some descriptions in the next version, and we appreciate your
feedback on this issue.
-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?[Wenying] The SR Policy
Group merely facilitates directing traffic into a set of SR Policies. The
working mechanism of the original parent SR Policy and SR Policies remains
unchanged.The SR Policy Group and the SR Policy must have different colors. For
specific details, please refer to section 6. We will add more descriptions in
the next version.
-Chapter 6 provides a concise and straightforward introduction to the whole
approach. I would suggest moving Chapter 6 before Chapter 3 for better
readability.
[Wenying] Thank you for the suggestion. I will discuss it with my co-authors
and make the modifications in the next version.
Thanks!
Nat
On Fri, Aug 30, 2024 at 2:50PM 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:50PM 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
