IS-IS Extensions for Segment Routing
draft-ietf-isis-segment-routing-extensions-25

Note: This ballot was opened for revision 24 and is now closed.

Alvaro Retana Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2019-06-05)
Thanks for explaining the issues I noted in the DISCUSS.

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2019-05-15 for -24)
Due to lack of time this week I was only able to review the first half of the document, and so am balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem / I have no cycles" sense.

Mirja Kühlewind No Objection

Comment (2019-05-14 for -24)
A few comments/questions:

1) For both the Prefix Segment Identifier and the Adjacency Segment Identifier sub-TLV it is not fully clear to me what the value field is used for when the V-Flag is set. Can you further elaborate this in the draft or provide a respective pointer?

2) The F-Flag in Adjacency Segment Identifier sub-TLV and SID/Label Binding TLV is only one bit. I'm not expecting a new version of IP any time soon, however, maybe completely different address families could be useful as well. Not sure if only 1 bit is future-proof...?

3) Would it make sense to also discuss any risk of leaking information (e.g. about the network topology) in the security consideration section?

Barry Leiba No Objection

Comment (2019-05-15 for -24)
— Section 4.4 —
As you’re defining a new Expert Review registry, it would help to include some brief guidance for the designated expert (see RFC 8126).

Alexey Melnikov No Objection

Adam Roach No Objection

Comment (2019-05-14 for -24)
Thanks for the work everyone has put into this document. I have only a small
number of minor comments.

---------------------------------------------------------------------------

§2.4:

>  o  1 octet of RESERVED

For the sake of making this byte potentially usable in the future, consider
adding text specifying something like "MUST be set to 0 on transmission,
and MUST be ignored on reception."

---------------------------------------------------------------------------

§2.4.6:

>  10.1.1/24, Prefix-SID: Index 51
>  10.1.2/24, Prefix-SID: Index 52
>  10.1.3/24, Prefix-SID: Index 53
>  10.1.4/24, Prefix-SID: Index 54
>  10.1.5/24, Prefix-SID: Index 55
>  10.1.6/24, Prefix-SID: Index 56
>  10.1.7/24, Prefix-SID: Index 57

Please change these addresses to ranges reserved by IANA for
documentation purposes rather than those reserved for private use.

---------------------------------------------------------------------------
§2.4.6:

>  2001:DB8:1/48, Prefix-SID: Index 151
>  2001:DB8:2/48, Prefix-SID: Index 152
>  2001:DB8:3/48, Prefix-SID: Index 153
>  2001:DB8:4/48, Prefix-SID: Index 154

Please change these IPv6 addresses to use lowercase hex digits.
See https://tools.ietf.org/html/rfc5952#section-4.3

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-05-16 for -24)
Thanks for the work everyone has put into this document. Even if I do care about segment routing, and after a quick read of the document, I am in the same boat as Warren Kumari for available time: I am balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem / I have no cycles" sense.


== COMMENT ==

-- Section 2.4.4.1.  --

Out of curiosity, this section seems to imply that a host always has a /128 prefix in IPv6. There are other use case, notably RFC 8273, where a host has a /64. Does it change anything in this document?

== NITS ==

-- introduction --

Suggest to expand IGP & ECMP.

-- section 2.4.6 ---

Please follow RFC 5952 and use lower case for IPv6 addresses.

Magnus Westerlund No Objection