Christian,
We have to remember that IETF specs need to be sufficient (with
their normative references attached) for an implementer who has no
access to any existing code. It isn't for the benefit of existing
implementers, but for future ones. I think what Elwyn is suggesting
fits into that picture - maybe the answer is text, maybe the answer
is careful pointers to normative references, but the result shouldn't
depend on any assumption of esoteric knowledge.
Brian
Elwyn Davies wrote:
Christian:
The review is not suggesting that you respecify everything, merely that
it covers the things that have really changed and makes it really clear
to somebody who hasn't been immersed in IS-IS for years how to implement
the extensions interoperably. I would guess that doing this would add
perhaps 2 or 3 pages to the text but make it considerably more useful.
I'll just extract two points with regards to completeness which IMO
cannot be deduced from the current or pre-existing text:
- Tutorials on IS-IS always emphasise that you can't mix IPv4/v6
dual-stack and single stack in an area. This means, if I understand
correctly, new values for a configuration variable which are not
specified. Even if not, a sentence indicating that mixing types in an
area won't work would be useful.
- Using IPv6 in the implementation which your company produces appears
to imply turning on wide metrics for links (but I maybe wrong). Hence
it needs RFC3784 support. Is this required in all implementations?
Either way a few words about this would make it clear what the
relationship is.
As you say it is up to your AD's and the IESG as a whole whether they
consider that this is an adequate IETF document. All I can say is that
from my point of view there are some holes in the specification that
require guesses from implementers.
Regards,
Elwyn
Christian Hopps wrote:
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
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
