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
