Subject: [Idr] Some questions and comments on draft-ketant-idr-rfc7752bis

From: Nandan Saha <[email-masked]>
Date: Tue, 20 Aug 2019 19:16:36 +0530

Hi authors,

Had some questions and comments on draft-ketant-idr-rfc7752bis. Some
of the stuff isn't specific to the new/revised content in
draft-ketant-idr-rfc7752bis versus rfc7752 and likely applies to
rfc7752 as well.

1. https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.3.1.1
<QUOTE>
The value is a variable-length bit array of flags, where each bit
represents a node capability
</QUOTE>
1.1) The value does not appear to be variable length as the size is
fixed to 1 byte.
1.2) Nit: In the context of IS-IS, overload and attached aren’t
“capabilities”, to me at least they represent operational/network
state.

2. What is the length to be used for IGP Metric TLV
(https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.3.2.4)
for IS-IS narrow metrics.
<QUOTE>
IS-IS small metrics have a length of 1 octet (the two most significant
bits are ignored).
</QUOTE>
What is the intent of the text in brackets since the length will be
set to 1 when narrow metrics is used, so only one octet will be
present.
(Or) should narrow metrics be sent with length=3 and most significant
2 bytes set to 0?

3. 'O', 'A' bit missing from MT-ID TLV when used as a node attribute
Table 6 in https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.3.1
points to section-4.2.2.1 where the MT-ID TLV is defined as per
https://tools.ietf.org/html/rfc5120#section-7.2 where the flags are
all reserved. This is fine from the point of view of link, prefix
information. However in IS-IS in LSP fragment 0, when the MT-IDs are
carried in TLV 229 (https://tools.ietf.org/html/rfc5120#section-7.1),
the overload and attached bits have meaning. So shouldn’t the bgp-ls
definition also carry them when carried as a Node attribute to
indicate overload or attached for that MT.

4. Is there any padding in the Node, Link, Prefix NLRIs ?
It's not clear to me from figures 7,8, 9 in
https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.2,
whether there's 3 bytes of padding / reserved between "Protocol-ID"
and "Identifier". If there is, it'll be good to mention that it needs
to be set 0. If not, then it'll be good to maybe add some text to
indicate that Identifier immediately follows the Protocol-ID because
IMO someone reading this can interpret it either way.

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+
     |  Protocol-ID  |  <Is this portion 3 bytes of padding?>
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Identifier                          |
     |                            (64 bits)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,
Nandan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 20 Aug 2019 14:41:16 +0000

Hi Nandan,

Thanks for your review and comments. All of these are for the existing RFC7752 content and we'll try to address them in the bis draft.

Please check inline below.

-----Original Message-----
From: Nandan Saha <[email-masked]> 
Sent: 20 August 2019 19:17
To: [email-masked]
Cc: [email-masked]; Prakash Badrinarayanan <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Subject: Some questions and comments on draft-ketant-idr-rfc7752bis

Hi authors,

Had some questions and comments on draft-ketant-idr-rfc7752bis. Some of the stuff isn't specific to the new/revised content in draft-ketant-idr-rfc7752bis versus rfc7752 and likely applies to
rfc7752 as well.

1. https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.3.1.1
<QUOTE>
The value is a variable-length bit array of flags, where each bit represents a node capability </QUOTE>
1.1) The value does not appear to be variable length as the size is fixed to 1 byte. 
[KT] Agree that the size is 1 byte and will fix this.
1.2) Nit: In the context of IS-IS, overload and attached aren’t “capabilities”, to me at least they represent operational/network state.
[KT] Ack

2. What is the length to be used for IGP Metric TLV
(https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.3.2.4)
for IS-IS narrow metrics.
<QUOTE>
IS-IS small metrics have a length of 1 octet (the two most significant bits are ignored).
</QUOTE>
What is the intent of the text in brackets since the length will be set to 1 when narrow metrics is used, so only one octet will be present.
[KT] The length is 1 octet and the two MSB bits are to be ignored because the range is 1-63 for narrow metrics in ISIS. Perhaps for clarity, we MUST set the two significant bits to 0.
(Or) should narrow metrics be sent with length=3 and most significant
2 bytes set to 0?
[KT] Size is 1 octet.

3. 'O', 'A' bit missing from MT-ID TLV when used as a node attribute Table 6 in https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.3.1
points to section-4.2.2.1 where the MT-ID TLV is defined as per
https://tools.ietf.org/html/rfc5120#section-7.2 where the flags are all reserved. This is fine from the point of view of link, prefix information. However in IS-IS in LSP fragment 0, when the MT-IDs are carried in TLV 229 (https://tools.ietf.org/html/rfc5120#section-7.1),
the overload and attached bits have meaning. So shouldn’t the bgp-ls definition also carry them when carried as a Node attribute to indicate overload or attached for that MT.
[KT] Agreed. When used as a descriptor TLV, the flags MUST be set to 0 while when used as Node attribute these flags are used to indicate overload or attached. Will clarify this in the text.

4. Is there any padding in the Node, Link, Prefix NLRIs ?
It's not clear to me from figures 7,8, 9 in https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.2,
whether there's 3 bytes of padding / reserved between "Protocol-ID"
and "Identifier". If there is, it'll be good to mention that it needs to be set 0. If not, then it'll be good to maybe add some text to indicate that Identifier immediately follows the Protocol-ID because IMO someone reading this can interpret it either way.
[KT] There is no padding anywhere in the picture here. When there is padding, it is specifically indicated as such using reserved field or explicitly in the text. IMHO the diagram and text is clear on this.

Thanks,
Ketan

Thanks,
Nandan

---

From: Nandan Saha <[email-masked]>
Date: Tue, 20 Aug 2019 20:19:25 +0530

> Thanks for your review and comments. All of these are for the existing RFC7752 content and we'll try to address them in the bis draft.
Thanks for the prompt response Ketan.
About my narrow metric comment, I misread the text as "2 bytes" rather
than "2 bits". So it's fine to leave the text as is also.
Ack on the rest.

Thanks,
Nandan