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

Martin Vigoureux No Objection

Roman Danyliw (was Discuss) No Objection

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

Warren Kumari No Objection

Comment (2019-05-15 for -24)
No email
send info
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.

É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.

(Adam Roach; former steering group member) No Objection

No Objection (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

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -24)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -24)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (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).

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -24)
No email
send info

(Ignas Bagdonas; former steering group member) No Objection

No Objection ( for -24)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -24)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection (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?

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -24)
No email
send info