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:01 AM 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
