Re: [RTG-DIR] RtgDir Last Call review: draft-ietf-spring-segment-routing-policy-14

[Ketan Talaulikar <[e-mail]>]

Hi Matthew,

Thanks for your detailed review and please find responses inline below.

Also, we've posted an updated version to address your comments. Request you
to please check and let us know your feedback.
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-16


On Fri, Jan 28, 2022 at 5:21 PM Bocci, Matthew (Nokia - GB) <
[e-mail]> wrote:

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

KT> Ack. Fixed in some places and please let us know if we've missed any.


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

KT> Given that this is an architecture document, it describes the
architecture and not really the protocol mechanisms. This is in line with
other SPRING documents. The normative language for the BGP mechanism is in
the IDR document. The informative references, in this document, to those
protocol mechanisms are only to give a better reference/info to the reader.


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

KT> The sec 2.13 illustrates this. We will add a forward reference to it in
Sec 2.2.


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

KT> The document currently describes the constructs in the flow. A
terminology section would just end up repeating the text up front and
without proper context. I prefer to keep the current structure. If there is
any specific terminology that you believe is better dealt with in the
Terminology section, please let us know.


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

KT> Ack. Fixed in a few places. Please let us know if any others were
missed out.


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

KT> Ack. Fixed.


>
>
> Section 4: Segment Types.
>
> Type A: SR-MPLS Label: "...Additionally, reserved labels..." These are now
> commonly
>
> referred to in MPLS as "special purpose labels".
>
>
>

KT> Ack. Fixed.

Thanks,
Ketan