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

[Nandan Saha <[e-mail]>]

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