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
