IS-IS Extensions for Segment Routing
draft-ietf-isis-segment-routing-extensions-25
Yes
(Alvaro Retana)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
(Martin Vigoureux)
(Suresh Krishnan)
Note: This ballot was opened for revision 24 and is now closed.
Roman Danyliw
(was Discuss)
No Objection
Comment
(2019-06-05)
Sent for earlier
Thanks for explaining the issues I noted in the DISCUSS.
Warren Kumari
No Objection
Comment
(2019-05-15 for -24)
Not sent
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)
Sent
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.
Alvaro Retana Former IESG member
Yes
Yes
(for -24)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2019-05-14 for -24)
Sent
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 IESG member
No Objection
No Objection
(for -24)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(for -24)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(2019-05-15 for -24)
Sent
— 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 IESG member
No Objection
No Objection
(for -24)
Not sent
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -24)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -24)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -24)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2019-05-14 for -24)
Sent
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 IESG member
No Objection
No Objection
(for -24)
Not sent