Subject: [Isis-wg] draft-ietf-isis-auto-encap-00.txt

From: "Philip Christian" <[email-masked]>
Date: Tue, 23 Jul 2002 13:52:20 +0100

Mike Shand and myself have already found one problem with this draft as it
is.

If you look at page 12 of 
http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-00.txt you
will
see

"4.The dual automatic encapsulating IS might be elected DIS both by 
   the IPv4 ISs and by the IPv6 ISs; in this case it MUST create two 
   separate pseudonodes. One of the pseudonodes MUST declare 
   adjacencies with all IPv4-capable ISs on the LAN, and the other 
   pseudonode must declare adjacencies with all-IPv6 capable ISs on 
   the LAN.  Both pseudonodes MUST declare an adjacency with the 
   dual automatic encapsulating IS, and with any other dual ISs on 
   the LAN."

In fact this is not possible.

ISs that are not DIS learn the ID of the pseudonode from the LAN ID of
Hellos
from the DIS (I had not appreciated this when I wrote the draft).

They use the LAN ID to derive the ID of the pseudonode so that they can
mention
the pseudonode in their LSPs.

The problem is that the automatic encapsulating IS can only send out one LAN
ID
in Hellos, so it can therefore support only one Pseudonode.

The clause that says this in ISO 10589 is towards the end of 8.4.5.

The consequence of this is that the automatic encapsulation IS will only
create
one pseudonode even if both "subLANs" elect it.

Either all of the other ISs on the LAN had better conform to ISO/IEC 10589
section C.2.5 item "h", or, the priority of any ISs that don't must be
higher 
than the automatic encapsulation IS.

Unless anyone can think of anything better....

I will fix this and do an -01.txt
Basically I will just use the G.7712 Annex B method which is correct as it
is.

Philip