Subject: [Idr] Roman Danyliw's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 11 Jun 2019 18:31:11 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-idr-bgp-ls-segment-routing-ext-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Section 2.0.  Does the sentence, “This document adds additional BGP-LS
Attribute TLVs in order to encode SR information” imply that this document
should explicitly update RFC7752?

(2) Add more detailed citations
-- Section 2.x.  Section 2.1.x.  When citing a reference to explain a given
TLV/sub-TLV, consider adding the relevant section number to improve
readability.  For example:

OLD: Section 2.1.1, IS-IS, as defined by the SID/Label sub-TLV in
[I-D.ietf-isis-segment-routing-extensions].

NEW: Section 2.1.1, IS-IS, as defined by the SID/Label sub-TLV in Section 3.2
of [I-D.ietf-isis-segment-routing-extensions].

-- Section 2.1.2  Per the octet of flags, please specify the specific section
number of [I-D.ietf-isis-segment-routing-extensions].

-- Section 2.2.*.  Consider adding the appropriate section number in the
references when described the flags field.

(3) Section 2.1.4.  Per “SID/Label sub-TLV (as defined in Section 2.1.1) which
encodes the first label in the range”, why is this just the first label?  Isn’t
there the potential of a series of labels each in a distinct SID/Label sub-TLV?

(4) Section 2.2.2.  Is there a reference to explain the semantics of the weight
field?

(5) Section 2.3.1.  Is there a reference to explain the semantics of the
algorithm field?

(6) Editorial Nits:
-- Section 2.1.1.  Missing word:
s/The TLV and has the following format:/
/The TLV and sub-TLV has the following format:/

-- Section 2.1.5.  Typo.  s/a unsigned/an unsigned/

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 12 Jun 2019 07:06:11 -0400

On June 11, 2019 at 9:31:12 PM, Roman Danyliw via Datatracker (
[email-masked]) wrote:

Roman:

Hi!

Just answering this first question:

No.

rfc7752 is the base BGP-LS specification…some TLVs are defined there.  This
document extends BGP-LS with more TLVs to support Segment Routing…but this
is an independent extension: not all rfc7752-compliant implementations have
to support SR.

Thanks!

Alvaro.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 27 Jun 2019 17:37:51 +0000

Hi Roman,

Thanks for your review. I've updated the draft for all your comments and please check inline below for response.

The version 16 of the draft has been posted to address your and other comments from the IESG review:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16 

Thanks,
Ketan

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: 12 June 2019 07:01
To: The IESG <[email-masked]>
Cc: [email-masked]; Susan Hares <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Roman Danyliw's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

(1) Section 2.0.  Does the sentence, “This document adds additional BGP-LS Attribute TLVs in order to encode SR information” imply that this document should explicitly update RFC7752?

[KT] As clarified by Alvaro, this document only add new TLVs to BGP-LS for SR functionality. As such, it does not update RFC7752.

(2) Add more detailed citations
-- Section 2.x.  Section 2.1.x.  When citing a reference to explain a given TLV/sub-TLV, consider adding the relevant section number to improve readability.  For example:

OLD: Section 2.1.1, IS-IS, as defined by the SID/Label sub-TLV in [I-D.ietf-isis-segment-routing-extensions].

NEW: Section 2.1.1, IS-IS, as defined by the SID/Label sub-TLV in Section 3.2 of [I-D.ietf-isis-segment-routing-extensions].

-- Section 2.1.2  Per the octet of flags, please specify the specific section number of [I-D.ietf-isis-segment-routing-extensions].

-- Section 2.2.*.  Consider adding the appropriate section number in the references when described the flags field.

[KT] The section references were previously there in the tables in sections 2.4 and 2.5 but were later removed as part of the AD review. Now adding back the same sections inline.

(3) Section 2.1.4.  Per “SID/Label sub-TLV (as defined in Section 2.1.1) which encodes the first label in the range”, why is this just the first label?  Isn’t there the potential of a series of labels each in a distinct SID/Label sub-TLV?

[KT] The Range TLV can carry multiple sub-ranges and it should be read as "first label in the sub-range". I've clarified this text in the update.

(4) Section 2.2.2.  Is there a reference to explain the semantics of the weight field?

[KT] It is described in section 3.4 of RFC8402 and I've added the same reference.

(5) Section 2.3.1.  Is there a reference to explain the semantics of the algorithm field?

[KT] It is described in section 3.1.1 of RFC8402 and I've added the same reference.

(6) Editorial Nits:
-- Section 2.1.1.  Missing word:
s/The TLV and has the following format:/ /The TLV and sub-TLV has the following format:/

[KT] Fixed

[KT] Fixed.