Skip to main content

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