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

"Bocci, Matthew (Nokia - GB)" <matthew.bocci@xxxxxxxxx> · Wed, 2 Feb 2022 12:07:00 +0000

Hi Ketan

Thanks for your quick response.

Matthew

From:
Ketan Talaulikar <ketant.ietf@xxxxxxxxx>

Date: Saturday, 29 January 2022 at 05:33

To: Bocci, Matthew (Nokia - GB) <matthew.bocci@xxxxxxxxx>

Cc: <rtg-ads@xxxxxxxx>, rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>, spring@xxxxxxxx <spring@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, draft-ietf-spring-segment-routing-policy.all@xxxxxxxx <draft-ietf-spring-segment-routing-policy.all@xxxxxxxx>

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) <matthew.bocci@xxxxxxxxx> 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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call