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. ** 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? ---------------------------------------------------------------------- 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”? ** 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. ** Section 2.2. Typo. s/heirarchical/hierarchical/ ** Section 2.3. It would be helpful if the precise mechanism to signal the Protocol-Origin was cited. -- I believe it is Section 5.2.2 of [I-D.ietf-pce-segment-routing-policy-cp] -- I didn’t find any reference to a “Protocol Origin” or this section in [I-D.ietf-idr-segment-routing-te-policy]. ** 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? ** 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. ** 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? ** 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? ** 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. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
