|
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-spring-segment-routing-policy-14 Reviewer: Matthew Bocci Review Date: 28 January 2022 Intended Status: Standards Track Summary: In general, this is a well written document. Thank you. However, I have some minor concerns about this document that I think should be resolved before publication. This mostly revolve around
the clarity of the document and the use (or lack thereof) of RFC2119 language.
Comments: Major Issues: No major issues found Minor Issues: 1) This is a standards track document, but in general I found that clear specification language is missing. For example, in section 2.3: "A headend may be.." Should this be "A headend MAY be..."?
There are many other cases like this where MUST/SHOULD/MAY would be better used rather than 'is' or 'can'. 2) The references to control planes for provisioning and maintaining SR Policies are only
informational, but they are referred to in a manner in the text that I read as normative (although the language is not always clear). For example, in section 2.5: "When signaling
is via PCEP..." and then the paragraph refers to an informative reference to the PCE draft for the SR policy control plane. Given that this is a standards track architecture document, it would be much better to be clear about what the normative parts of the
architecture are. If these parts are not normative (for example even if I use BGP it is not mandatory to use it according to a particular specification) then please be explicit and use 'MAY' or 'SHOULD'. 3) Section 2.2: Candidate Path and Segment List. This section describes a hierarchical relationship between composite candidate paths, SR Policies, candidate paths, and segment lists. It would be much clearer if you could provide a diagram illustrating this hierarchy. 3) Terminology section. Since this draft is really the overall guide to all things SR Policy, it would really help to include a
terminology section summarising new terms and acronyms. Nits: 1) The definite/indefinite article ('the', 'a', etc) is missing from the text in many places.
I would suggest going through the text carefully and correcting these issues. 2) Section 2.13: In the information model: SR policy POL1 <headend = H1, color = 1, endpoint = E1> Candidate-path CP1 <protocol-origin = 20, originator = 100:1.1.1.1, discriminator = 1> Preference 200 Priority 10 Weight W1, SID-List1 <SID11...SID1i> Weight W2, SID-List2 <SID21...SID2j> ^^^^^^^^^ These are referred to as segment lists in the main text, so maybe you should align the terminology. Section 4: Segment Types. Type A: SR-MPLS Label: "...Additionally, reserved labels..." These are now commonly
referred to in MPLS as "special purpose labels". |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
