Subject: [Gen-art] Gen-art review of draft-ietf-isis-ipv6-06.txt

From: Elwyn Davies <[email-masked]>
Date: Tue, 07 Feb 2006 12:41:52 +0000

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 07 Feb 2006 14:13:21 +0000

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:
>
>> (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).
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> 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 
>> integer), the possible values of prefix length  and the number of 
>> octets of prefix are not made explicit.
>>
>> 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).
>>
>> 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.
>>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 7 Feb 2006 05:15:32 -0800

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.

    this same method with some minor changes to allow for IPv6.  To  
do so

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:

> 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).
>
> 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).
>
> 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).
>
> 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.
>
> metrics.  A reminder of this would not go amiss.  Presumably we  
> have to wait for TE extensions to get multiple metrics for IPv6.
>
> 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: '...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).
>
> s6: Copying over some of the reasoning for the choice of the  
> maximum metric from RFC3784 would not go amiss.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Feb 2006 10:28:26 +0100

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Feb 2006 16:40:12 +0100

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,
>>
>>> 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.
>>> 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:
>>>
>>>> I'm not. Obviously you did a thorough review and thanks  are in 
>>>> order for that.
>>>>
>>>> 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  
>>>> 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.
>>>>
>>>>> 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 
>>>>> 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 
>>>>> 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).
>>>>>
>>>>> 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.
>>>>>
>>>>> there are (I believe) several implementations  already in service. 
>>>>> I would consider it NOT READY for PS.
>>>>>
>>>>> Other Details:
>>>>> specification.  If I understand correctly it is defined in ISO/ IEC 
>>>>> semantics etc of [2]  doesn't make this totally clear, and  
>>>>> omitting RFC3784 support would result (but I may be confused) in  a 
>>>>> 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.
>>>>>
>>>>> 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).
>>>>>
>>>>> 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.
>>>>>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 8 Feb 2006 03:41:53 -0800

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.

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?"

Chris.

On Feb 8, 2006, at 1:28 AM, Brian E Carpenter wrote:

>> 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:
>> 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.
>> 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  
>>> 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.
>>>
>>> OSI+IPv4 RFC). Indeed if we start re-specifying these things  
>>> there is much greater room for error.
>>>
>>> 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.
>>>
>>>> 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).
>>>>
>>>> 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  
>>>> 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).
>>>>
>>>> derived through ref [2] which is now RFC3784 which in turn  
>>>> defers to RFC2966).
>>>>
>>>> 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.
>>>>
>>>> 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:
>>>> specification.  If I understand correctly it is defined in ISO/ 
>>>> IEC TR 9577 (in the 1999 update at least).   There should be a  
>>>> s2: I think it would be appropriate to discuss whether the  
>>>> updates of ref [2] (now RFC3784) for IPv4 are a prerequisite for  
>>>> *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?
>>>>
>>>> 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: '...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).
>>>>