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

[Ketan Talaulikar <[e-mail]>]

Thanks Matthew


On Wed, Feb 2, 2022 at 5:37 PM Bocci, Matthew (Nokia - GB) <
[e-mail]> wrote:

> Hi Ketan
>
>
>
> Thanks for your quick response.
>
>
>
> Matthew
>
>
>
> *From: *Ketan Talaulikar <[e-mail]>
> *Date: *Saturday, 29 January 2022 at 05:33
> *To: *Bocci, Matthew (Nokia - GB) <[e-mail]>
> *Cc: *<[e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *Subject: *Re: RtgDir Last Call review:
> draft-ietf-spring-segment-routing-policy-14
>
> 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
>
>
>
>
>
> MB> Thanks. This looks good to me. See below for some additional responses.
>
>
>
> 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.
>
>
>
>  MB> I agree you have followed the precedent of the SR architecture
> (RFC8402), so I am OK with that.
>
>
>
> 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.
>
>
>
> MB> Thanks. That helps.
>
>
>
> 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.
>
>  MB> Accepted
>
>
>
>
>
> 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
>
>
>