Draft:  draft-ietf-isis-ipv6-06.txt
Reviewer: Elwyn Davies [elwynd@dial.pipex.com]
Review Date: Tuesday 2/7/2006 6:42 AM CST
IETF LC Date: 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.