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
