First, while later it may sound like I'm disregarding this review,
I'm not. Obviously you did a thorough review and thanks are in order
for that.
I think perhaps you're not taking the following text into full account.
``In [1] a method is described to route both OSI and IPv4. We utilize
this same method with some minor changes to allow for IPv6. To
do so
we must define 2 new TLVs, namely "IPv6 Reachability" and "IPv6
Interface Address" and a new IPv6 protocol identifier. In our new
TLVs we utilize the extended metrics and up/down semantics of [2].''
The point is that we don't need to re-specify all the things already
explained previously, especially with regards to [1] (the OSI+IPv4
RFC). Indeed if we start re-specifying these things there is much
greater room for error.
You are right that this has been implemented by many vendors, and in
the 6 years the draft has existed no vendor has had any issue
implementing interoperable versions. I need to discuss where to go
with from here with the routing ADs. If indeed this 6 page simple
document is going to require becoming 30 pages of details seemingly
unneeded by implementers I think I'll be in favor of either removing
it from the standards track, or I'll need to find someone who has
time to do all this extra work.
Chris.
On Feb 7, 2006, at 4:41 AM, Elwyn Davies wrote:
I was selected as General Area Review Team reviewer for this
specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Document: draft-ietf-isis-ipv6-06.txt
Intended Status: Proposed Standard (Individual submission via AD)
Shepherding AD: Alex Zinin
Review Trigger: IETF Last Call (ends 15 Feb 2006)
Summary:
This draft is intended as an extension of the base Integrated IS-IS
specification RFC1195 to allow IS-IS to route IPv6- as well as
IPv4- (and OSI-) addressed packets. Having just checked back on my
memory of operating a single instance of Integrated IS-IS for
multiple addressing systems, I find that I did remember correctly
that a single area in IS-IS must not contain both OSI-only and IP
(v4)-only systems. Failure to adhere to this configuration rule is
likely to result in attempts to forward packets to nodes that do
not support the address type of the packet (because the topology
calculations don't worry too much about the address types supported
on a node).
This new draft adds a third address family but does not discuss the
interaction of IPv6 with IPv4 (or OSI). This wouldn't matter if
the multi-topology extensions (draft-ietf-isis-wg-multi-
topology-11.txt) were being used but for the basic protocol I think
something needs to be said about some new classes of routers (in
principle there are now six possibilities { {OSI}, {IPv4}, {IPv6},
{OSI, IPv4}, {OSI, IPv6}, {IPv4, IPv6}, (OSI, IPv4, IPv6}}).
RFC1195 indicates that routers need to be configured with their
domain type (essentially the common set of address families
supported by all nodes in the domain) which would need to be
extended to cover the extra family. (This issue is mentioned in
many presentations on the use of a single instance of IS-IS for
routeing IPv4 and IPv6).
Aside from this fairly fundamental issue, it was not clear to me
where the additional preference rules specified in s6 had to be
integrated into the fairly complex preference rules already
specified in s3.10 of RFC1195 or what their relationship was to the
preference rules given in s3.2 of RFC2966 (the semantics of the up/
down bit used in the IPv6 Reachability TLVs appear to be derived
through ref [2] which is now RFC3784 which in turn defers to RFC2966).
Talking of RFC3784, there is no clear statement as to whether
implementation of the RFC3784 extensions is a necessary
prerequisite for these extensions: if I understand correctly, NOT
implementing RFC3784 means that only 'narrow' metrics would be
available for IS link specifications but the IPv6 extensions only
provide for 'wide' path metrics, whereas RFC1195+RFC3784 gives a
choice of wide and narrow for both IS links and IPv4 paths. I am
not clear if the situation would be reasonable without RFC3784
support.
Another related area which is really rather buried in these
specifications is the issue of separate metrics for the various
address families. This may be obvious to afficionados of IS-IS but
the fact that the SPF is run separately for each metric gets rather
lost. Referring back to the original specification it is possible
that the SPF is run multiple times for the same address family if
multiple metrics are defined - originally to handle multiple TOS
metrics. A reminder of this would not go amiss. Presumably we
have to wait for TE extensions to get multiple metrics for IPv6.
Overall I felt that the draft lacked attention to detail and there
were areas (especially s6) which amounted to 'hand-waving' rather
than rigorous specification. This seems slightly surprising as
there are (I believe) several implementations already in service. I
would consider it NOT READY for PS.
Other Details:
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
