Routing IPv6 with IS-IS
draft-ietf-isis-ipv6-07
Yes
(Bill Fenner)
No Objection
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Lars Eggert)
(Lisa Dusseault)
(Ted Hardie)
Abstain
Note: This ballot was opened for revision 07 and is now closed.
Bill Fenner Former IESG member
Yes
Yes
()
Unknown
Ross Callon Former IESG member
Yes
Yes
(2006-05-10)
Unknown
This is in fact the fourth or fifth protocol that is supported using IS-IS (the first two were DECnet Phase 4 and CLNP which were pretty much supported simultaneously, then came IPv4, then came NLSP for routing IPX, which is so similar to IS-IS that some implementations use a single implementation to support both NLSP and IS-IS). Thus many of the questions that implementors might otherwise have, have already been answered in previous work. I think that it would make sense for the security considerations section to include informational references to RFC3567 and to draft-ietf-opsec-current-practices-02.txt. Possible replacement text for section 8 would be: 8 Security Considerations This document raises no new security considerations. Authentication of IS-IS packets may optionally be provided using the extension specified in [RFC3567]. A threat model as well as operational security features which are commonly deployed in networks is provided in [OPSECPRACTICES]. then add to references: [RFC3567] "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", T.Li and R.Atkinson, July 2003. [OPSECPRACTICES] "Operational Security Current Practices", draft-ietf-opsec-current-practices-02.txt, work in progress, July 2005. (note that this last one has timed out but will be updated very soon as -03). Reference 2 is clearly obsolete, and needs to be replaced by something. I am pretty sure that this would be: [RFC3784] "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", H. Smit and T.Li, June 2004. Most likely we should also add a reference to: [RFC2966] "Domain-wide Prefix Distribution with Two-Level IS-IS", T. Li, T. Przygienda, H. Smit, October 2000. I am told that all deployments (except pure CLNS deployments) use wide-metrics-only. Thus the use of wide metrics seems fine. It might be worthwhile to write a different very short RFC deprecating the use of narrow (ie original) metrics.
Chris Newman Former IESG member
No Objection
No Objection
(2007-12-13)
Unknown
I'd prefer if the IANA considerations section was kept after the document was published. The fact two codepoints were registered and a new registry was created is interesting and relevant.
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was No Record, Discuss)
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
(2006-05-10)
Unknown
Please expand the first usage of the acronym "LSP" in the document.
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2006-05-09)
Unknown
Abrevation should be expanded on the first usage of each of them.
Mark Townsley Former IESG member
No Objection
No Objection
(2006-05-09)
Unknown
Might be a good idea to reference RFC2460 at the start of the document. Need a 2119 ref at the end of the doc.
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2006-05-08)
Unknown
Section 4 says: > > This TLV maps directly to [1]'s "IP Interface Address" TLV. > Suggested rewording: > > This TLV maps directly to the "IP Interface Address" TLV defined > in [1].
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
(was Discuss, Abstain)
Abstain
Abstain
(2006-05-09)
Unknown
Extra comments from Gemn-ART review by Elwyn Davies: s2/s5: The IPv6 protocol identifier is not new with this specification. If I understand correctly it is defined in ISO/IEC TR 9577 (in the 1999 update at least). There should be a reference to this document. s2: I think it would be appropriate to discuss whether the updates of ref [2] (now RFC3784) for IPv4 are a prerequisite for implementing the changes in this document. At first I didn't *think* they were but the statement that the IPv6 stuff 'uses' the semantics etc of [2] doesn't make this totally clear, and omitting RFC3784 support would result (but I may be confused) in a combination of 'narrow' (6 bit) link metrics and 'wide' (24-32 bit) path metrics for IPv6. Is this reasonable? s3: This section lacks precise definitions of several of the fields: In particular the length field is unspecified. By analogy with s5.3 of RFC1195 one could ASSUME that it is the total length of the value part of the TLV excluding the first two octets but that assumes that everything said for IP(v4) applies for IPv6 - which is not made explicit. To avoid uncertainty it would be worth being explicit. Similarly the encoding of the metric (presumably unsigned 32 bit integer), the possible values of prefix length and the number of octets of prefix are not made explicit. s3: s/external original/external origin/ s3: '...the octet following the prefix will contain the length of the sub-TLV portion of the structure': Aside from the redundancy of this octet (the sub-TLV length can (probably) be derived from the overall length and the prefix length fields unless the TLV length does not cover the sub-TLVs as well), it needs to be made clear if this length includes or excludes the length octet itself. I would suggest repeating section 4.2 of RFC3784 which would also make it clear that the draft doesn't define any sub-TLVs and notes the limitations of the size of sub-TLVs that are possible (slightly different in this case). s4: Again the length is not precisely defined. s6: I don't think it is very clear how the various preference rules in RFC1195, RFC2966 and this document are supposed to be integrated. s6: Copying over some of the reasoning for the choice of the maximum metric from RFC3784 would not go amiss. s9: Ref [2] is RFC2784. Need a reference to ISO/IEC TR 9577:1999.
Sam Hartman Former IESG member
(was Yes)
Abstain
Abstain
(2006-05-11)
Unknown
I don't think this document has enough information in order to create an interoperable implementation of the spec. I'm concerned that there may be unwritten knowledge necessary to make this work. Alternatively, it may all become clear if you have a better understanding of the normative references than I do. However I definitely do not have enough confidence in this document to support publication.