Hi WG, Authors, Support publication. The document reads well and describes key concepts clearly. Just some friendly suggestions for the authors to consider -
- IMHO introduction section should be expanded as it can provide helpful clues to new-bees, our published document is not just for the insiders. - Section 2.1, is there any guidance for the IP address for the headend and endpoint? If a node is identified by multiple addresses, from the point of view of the SR policy they would be considered as different nodes, correct? - Section 2.1, I am worried that the use of the noun "intent" to describe 'color'. It does not align with the other use of the term in industry/NMRG. I see 'SLA associated with color' in other places. There was a jabber discussion in 110, maybe I am in rough here but wanted to reconfirm! - Section 2.3, Reference to RFC 8664 for PCEP is wrong here, as <color, endpoint> is signalled via draft-ietf-pce-segment-routing-policy-cp instead. - Section 2.3, What are the 8-bit values for the Protocol-Origin, is there an existing registry that is used here? Is it - https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4 , should it be listed in this document perhaps? - Section 2.4, For ASN, maybe add "If 2-byte ASNs are in use, the low-order 16 bits MUST be used, and the high-order bits MUST be set to zero.". For IPv4 Node Address, I would suggest adding the high-order bits MUST be set to zero! - Section 2.5, in draft-ietf-pce-segment-routing-policy-cp, no further clarification is given about the Discriminator and it simply points to this I-D. This draft says it is left for the future for PCEP. Since the I-D says tuple <Protocol-Origin, originator, discriminator> uniquely identifies a candidate path; we need to specify clearly how to populate the discriminator value in PCEP in this I-D or in PCE WG I-D (it cant be left for the future IMHO)! - Section 2.7, we need to say that preference is a 32-bit value (as done for other fields). - Section 2.11, why only a SHOULD and not MUST in "Only the active candidate path SHOULD be used for forwarding traffic that is being steered onto that policy."? - Section 3, The focus is on SR headend, some text on SR-DB at the controller would be nice. Further, in "A non-attached (remote) domain topology MAY be learned via BGP-LS or NETCONF."; could we clarify that this is at the controller? The PCEP references should be changed to draft-ietf-pce-segment-routing-policy-cp. - Section 4, there should be rules regarding which combinations of segment types are allowed to form a valid segment list. Cant mix SR-MPLS and SRv6 for example! - Section 10, It might be a good idea to acknowledge security considerations from the SR policy architecture point of view: how various SR policy parameters and attributes could be exploited to make a headend to forward the traffic incorrectly. It is better to add details that clearly show that the authors/WG have given it a thought and analyzed the implications. - Section 11, What is the range of the value for Segment Types? A-Z only? It would be good to be clear about this. With A-K already allocated, worth thinking if this is too restrictive and not future-proof. Perhaps we could think of the value as a string that is currently populated with a single alphabetic character. - Since the I-D talks about policy configuration, explicit candidate paths, verification, SR-DB, etc. I don't want to add work for the authors but I do feel in this case a dedicated manageability consideration section would be useful :) Nits - Expand on first use: SRv6, SRGB, SRLB,SRLG, SRH, BSID, PW, BFD, - s/SR DB/SR-DB/g - Section 2.2, s/via protocols like/via protocol extensions like/ Hope the authors and WG find these suggestions useful. Thanks! Dhruv On Fri, Apr 16, 2021 at 12:27 AM James Guichard < [email protected]> wrote: > Dear WG: > > > > This email starts a 2 week Working Group Last Call for > draft-ietf-spring-segment-routing-policy [1]. > > > > Please read this document if you haven’t read the most recent version and > send your comments to the SPRING WG list no later than April 29th 2021. > > > > If you are raising a point which you expect will be specifically debated > on the mailing list, consider using a specific email/thread for this point. > > > > Lastly, if you are an author or contributors for this document please > response to the IPR call in the previous email thread. > > > > Thanks! > > > > Jim, Joel & Bruno > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ > > > > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
