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
