Hi Nat,
Sorry for the late reply. I have submitted version-7: https://www.ietf.org/archive/id/draft-cheng-spring-sr-policy-group-07.txt，added explanations for weight load sharing in Chapter 6. Please check if it addresses your comments. Thank you! Thanks, Wenying ----邮件原文----发件人：Nat Kao <pyxi...@gmail.com>收件人：Wenying Jiang <jiangweny...@chinamobile.com>抄 送: SPRING WG List <spring@ietf.org>,draft-cheng-spring-s <draft-cheng-spring-sr-policy-gr...@ietf.org>发送时间：2024-12-08 14:01:45主题：[spring] Re: New Version Notification for draft-cheng-spring-sr-policy-group-05.txtHi, Wenying.Thanks for the update.I believe the issues I39ve raised before are clarified.Please also find my responses enclosed by <NK2></NK2>Many thanks,Nat On Thu, Dec 5, 2024 at 11:01AM Wenying Jiang <jiangweny...@chinamobile.com> wrote: Hi Nat, Thank you for your comment. We have updated the draft according to your valuable comments recently. Please check if your comments have been addressed? https://datatracker.ietf.org/doc/draft-cheng-spring-sr-policy-group/06/ For a detailed response, please see inline with [Wenying-2].Thanks,Wenying ----邮件原文----发件人：Nat Kao <pyxi...@gmail.com>收件人：Wenying Jiang <jiangweny...@chinamobile.com>抄 送: SPRING WG List <spring@ietf.org>,draft-cheng-spring-s <draft-cheng-spring-sr-policy-gr...@ietf.org>发送时间：2024-09-20 20:09:20主题：[spring] Re: New Version Notification for draft-cheng-spring-sr-policy-group-05.txtHi, Wenying.Thanks for the reply.Please find my reply enclosed by <NK></NK>. On Thu, Sep 19, 2024 at 11:22AM Wenying Jiang <jiangweny...@chinamobile.com> wrote: 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. <NK> I think this is a practical way to do per-flow steering.Since this draft is based on the concept of composite CPs, I suggest updating the statements in paragraph 5, sec. 2.11 of RFC9256 to relax the WECMP behavior:"When a composite candidate path is active, the fraction of flows steered into each constituent SR Policy is equal to the relative weight of each constituent SR Policy. Further load-balancing of flows steered into a constituent SR Policy is performed based on the weights of the segment list of the active candidate path of that constituent SR Policy." Right now, it is unclear how to deal with the weight of each c-SRP in the same p-SRP. I suspect that the weight is ignored in favor of the QoS/flow characteristics mapping, which differs from the behavior defined in the paragraph above.(Again, please correct me if I39m wrong.) </NK> [Wenying-2] Yes, your understanding is correct. When c-SRP is selected based on traffic, the SR policy is already determined for forwarding according to flow characteristics,so there will be no weight distribution among different c-SRPs. <NK2> Thanks for your explanation. It clarified my concern. I suggest adding it somewhere in the draft(maybe in Ch.3 or 6?) to avoid confusion since it39s not WECMP between each c-SRP. (Although we can still do WECMP with weighted SID-Lists in the same c-SRP) </NK2> -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. <NK> I see. Thanks for clarifying that. </NK -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. <NK> Great! Thanks. </NK> -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. <NK> I see. </NK> -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. <NK> Thanks! That would be easier to get into the situation. </NK> Thanks! Nat Kind regards, 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
