Hi, Wenying. Thanks for the updates! That paragraph addressed my concerns. It looks good to me.
Many thanks, Nat On Fri, Mar 7, 2025 at 3:05 PM Wenying Jiang <jiangweny...@chinamobile.com> wrote: > 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.txt > > Hi, Wenying. > > Thanks for the update. > I believe the issues I've 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.txt >> >> Hi, 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.txt >>> >>> 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. >>> >>> *[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 I'm 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 it's > 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 SRPG's endpoint. Maybe I've 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
