Hi Ketan! I’m clipping the text a bit to make it readable …
On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> wrote: Hi Roman, Thanks for your review and comments/inputs. Please check inline below for responses. On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There appear to be a few places where additional pointers or specification is needed to ensure interoperability. ** Section 2.5 When signaling is via PCEP, the method to uniquely signal an individual candidate path along with its discriminator is described in [I-D.ietf-pce-segment-routing-policy-cp]. Where is the explanation of discriminator in this reference? “Discriminator” appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2. In the first three section it is simply named but not explained. In the last section, it isn’t explained beyond being defined as 32-bits. KT> I have not yet reviewed that document and will do so to pass the comments to the authors of that document. As a reminder, this is an architecture document in SPRING that is then realized using protocol extensions/mechanisms that are specified in their respective WG documents. [Roman] Understood that the WG considers this an architecture document, however, it is being published as proposed standard. For that reason, I’m making these particular comments about explicitly referencing the expected normative behavior. ** Section 2.6. Candidate paths MAY also be assigned or signaled with a symbolic name comprising printable ASCII [RFC0020] [RFC5234] characters How these candidate paths names are signaled isn’t defined. I believe it is per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section 2.4.7 of draft-ietf-idr-segment-routing-te-policy. ** Section 2.7. How is the candidate path preference signaled? Is that draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1? KT> Those protocol specs normatively refer to this document. Your understanding is correct about the parts of those documents. [Roman] Specifically about Section 2.6 and 2.7, thanks for confirming that I read the other documents correctly. Is there a reason the text doesn’t explicitly reference this relevant the normative behavior? Thanks, Roman
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
