Christian,
That is the correct course of action - evaluate Elwyn's review
like any other Last Call comment, and take what action your AD
advises. My comments are generalities - and if you believe the
draft already satisfies those generalities, and your AD agrees,
that's a perfectly valid response. However, I would add from my
own experience that somebody who *hasn't* lived with a spec for
6 years may see gaps that you don't.
Brian
Christian Hopps wrote:
Brian,
I'm not sure what you mean by 'access to existing code'. This draft
came about the old way. 6 years ago, at Merit working on gated I
engineered the following: let's use IS-IS to enable IPv6 routing, and
let's keep things as simple as possible. I then wrote and published the
draft after it was reviewed by multiple engineers from other vendors.
So basically 6 years ago we had running code and rough consensus.
Today at least 3 other independent interoperable implementations have
been written and deployed (see the implementation report), and actual
packets are being routed. No one queried for the published
implementation report raised any issues, and to quote: ``No one
reported any difficulty in comprehending the standard while
implementing or in needing any clarifications.''
Part of my problem I suppose is the dual role I'm playing. As co- chair
of the IS-IS WG I must have the perspective which says, "Here are
comments and questions raised by Elwyn which seem to need to be
addressed before we declare this draft as a standard of IETF". The
author side of me is utterly annoyed at all of this. This latter side
says, "There are at least 4 independent interoperable versions of this
feature; no clarification questions were every asked; the feature has
been deployed and interoperating for years, what exactly is the problem?"
Anyway as I mentioned previously I'll discuss the situation with the
ADs, and possibly the routing directorate in Dallas before deciding
what to do.
Chris.
On Feb 8, 2006, at 1:28 AM, Brian E Carpenter wrote:
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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
