Hi, Wenying. Thanks for the reply. Please find my reply enclosed by <NK></NK>.
On Thu, Sep 19, 2024 at 11:22 AM 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> > -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
