Hi Roman, Could you please check the latest revision below and my responses to your discussion points and comments in the email thread below?
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-20 Please let us know your feedback on whether the responses and draft updates address your concerns. Thanks, Ketan On Thu, Feb 17, 2022 at 11:53 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > Hi Roman, > > We've just posted an update for the document to address the comments > raised by you and other ADs: > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18 > > Thanks, > Ketan > > > 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. >> >> >>> >>> ** 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. >> >> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I support John Scudder and Alvaro Retana's DISCUSS positions. >>> >>> ** Section 2.1. >>> The color is an unsigned non-zero 32-bit numerical value that >>> associates the SR Policy with an intent or objective (e.g. low- >>> latency). >>> >>> Should “numeric value” be “integer”? >>> >> >> KT> Ack. Will clarify. >> >> >>> >>> ** Section 2.1 >>> The SR Policy name >>> MAY also be signaled along with a candidate path of the SR Policy >>> (refer to Section 2.2). >>> >>> -- It would be helpful to explicitly state either here or in Section 2.2 >>> that >>> Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section >>> 5.2.1 of >>> [I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how >>> this >>> naming is signaled. Section 2.2 doesn’t discuss signaling the name. >>> >>> -- Both of these document need to be normative reference since there is >>> dependency on them for interoperable behavior. >>> >> >> KT> Please see one of my previous responses on the architecture and >> protocol specifications split across documents. >> >> >>> >>> ** Section 2.2. Typo. s/heirarchical/hierarchical/ >>> >> >> KT> Ack. >> >> >>> >>> ** Section 2.3. It would be helpful if the precise mechanism to signal >>> the >>> Protocol-Origin was cited. >>> >> >> KT> It is not something that is signaled - refer to "The head-end assigns >> different Protocol-Origin values to each source of SR Policy information.". >> It is like an "administrative distance" that is used to attach preference >> to routes learned via different protocols like OSPF, IS-IS, and BGP. This >> is local on the headend. >> >> >>> >>> -- I believe it is Section 5.2.2 of >>> [I-D.ietf-pce-segment-routing-policy-cp] >>> >> >> KT> Ack but likely we'll need to remove section number references or >> revalidate them at publication given how these documents have been moving >> along and their interdependencies. >> >> >>> >>> -- I didn’t find any reference to a “Protocol Origin” or this section in >>> [I-D.ietf-idr-segment-routing-te-policy]. >>> >> >> KT> Please check my previous comment. >> >> >>> >>> ** Section 2.4. >>> When signaling is via BGP SR Policy, the ASN and Node Address are >>> provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy]) >>> on the headend. >>> >>> [I-D.ietf-idr-segment-routing-te-policy] needs to be a normative >>> reference (as >>> stated before due to the text in Section 2.1) >>> >>> ** Section 2.5. Per “When provisioning is via configuration, this is >>> an >>> implementation's configuration model-specific unique identifier for a >>> candidate >>> path”, what is a “configuration model-model-specific unique identifier? >>> What >>> scope of the uniqueness? >>> >> >> KT> Please refer to draft-ietf-spring-sr-policy-yang - we could not be >> more specific or provide exact pointer here since that document is still >> under development. >> >>> >>> ** Section 2.13. This section says “the information model is the >>> following”, >>> but I don’t follow where that information model (IM) is per the >>> definition in >>> RFC3444. The text here appears be an example with hard-coded parameter >>> values. >>> >> >> KT> This is an overview and the actual model is being specified >> in draft-ietf-spring-sr-policy-yang >> >> >>> >>> ** Section 4. >>> Based on the desired dataplane, either the MPLS label stack or the >>> SRv6 Segment Routing Header [RFC8754] is built from the Segment- >>> List. >>> >>> Do SRv6 SRH and MPLS label stacks support all the segment types >>> enumerated >>> here? For example, does Type E and F, IPv4 segments, work with a SRv6 >>> SRH? >>> >> >> KT> What goes into the packet, at the end of the day, are MPLS labels or >> SRv6 SIDs. The segment types introduce the different context types that are >> used to specify a segment especially in the signaling protocols. >> >> >>> >>> ** Section 4. >>> When the algorithm is not specified for the SID types above which >>> optionally allow for it, the headend SHOULD use the Strict Shortest >>> Path algorithm if available; otherwise, it SHOULD use the default >>> Shortest Path algorithm. The specification of the algorithm enables >>> the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific >>> SIDs in SR Policy. >>> >>> Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative >>> reference? >>> >> >> KT> We enable the specification of an algorithm that was introduced by >> RFC8402. A later enhancement carved out a range of algos from there for IGP >> Flexible Algorithm. The reference is informative to indicate that one could >> use IGP Flex Algo as well. >> >> >>> >>> ** Section 10. Given that this document has a dependency on >>> [I-D.ietf-idr-segment-routing-te-policy] and >>> [I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR >>> Policy, their >>> security considerations should apply. >>> >> >> KT> I refer again to the dependency between this SPRING and the other >> protocol specs. >> >> Thanks, >> Ketan >> >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
