Hi Roman, My understanding is that you would like us to put references to the relevant BGP and PCEP documents in sections 2.6 (CP name) and 2.7 (Preference).
Can you please confirm so we can include those changes in the next update (once submission re-opens)? Thanks, Ketan On Fri, Mar 18, 2022 at 6:33 AM Roman Danyliw <r...@cert.org> wrote: > 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> > 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> 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
