Last Call Review of draft-ietf-spring-segment-routing-policy-14
review-ietf-spring-segment-routing-policy-14-rtgdir-lc-bocci-2022-01-28-00

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".