Subject: [Isis-wg] draft-ietf-isis-auto-encap-03

From: Philip Christian <[email-masked]>
Date: Wed, 9 Apr 2003 15:08:11 +0100 (BST)

I was having some list trouble when
draft-ietf-isis-auto-encap-03 was announced to the
list.

Basically there were two changes.

1. The history section was updated given that the
ITU-T version of the document has passed last call.

2. A new section 5.2 has been added.  This suggests
that ISs SHOULD ignore the LAN ID from ISs that they
don't consider to be DIS.  I believe that ISO 10589
specifies what to do with the LAN ID from the DIS, but
it it makes no mention of what to do with the LAN ID
from a none-DIS.  Given that an auto-encap IS may
misreport the LAN ID of the DIS in certain
circumstances this needed clarifying.

If anyone has any comments on the new section 5.2 then
I would appreciate them.

There are quite a lot of typos which have been pointed
out to me, and the LAN ID thing needs to be fed to the
ITU-T, so I will need to do some more work anyway.

The draft can be downloaded from
http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-03.txt

Regards, Philip Christian

__________________________________________________
Yahoo! Plus
For a better Internet experience
http://www.yahoo.co.uk/btoffer
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 09 Apr 2003 15:21:08 -0700

Philip -

I am not clear on why Section 5.2 is required. ISO 10589 says in Section 8.4.5:

The LAN ID field in the LAN IIH PDUs transmitted by this system shall be 
set to the value of the LAN ID field reported in the LAN IIH PDU (for the 
appropriate level) received from the system which this system considers to 
be the Designated Intermediate System. This value shall also be passed to 
the Update Process, as the pseudonode ID, to enable Link State PDUs to be 
issued for this system claiming connectivity to the pseudonode

As you point out, 10589 makes no mention of doing anything with the LANID 
from systems which the local system does not consider DIS. Why would/should 
it? If I pick Router A as the DIS and copy the LANID from Router A's IIH 
into my IIH and Router B's IIH does not agree, what can I do?? This 
certainly occurs as a transient situation if DIS is changing. What is most 
important (and I believe unstated by 10589) is that the DIS that we choose 
should also think that it is DIS and therefore advertise a LANID in its 
IIHs where the first 6 octets match its own systemID. If it does not, then 
there will be problems.

What was it that motivated you to add 5.2 to your document?

    Les

---

From: mike shand <[email-masked]>
Date: Thu, 10 Apr 2003 09:57:18 +0100

Philip,

I rather think that this is going down the slippery slope of specifying 
that you should not do something which is not required by the standard. 
There are two problems with this. Firstly it is unnecessary bloat in the 
spec. Secondly, and more importantly, it encourages the thinking that you 
are allowed to do anything, however stupid, provided that you haven't been 
explicitly told not to do it.

Rather in the same way that painting "no parking" lines around streets 
encourages people to park where ever there are no lines, however stupid a 
place that might be.

         Mike

At 15:21 09/04/2003 -0700, Les Ginsberg wrote:
>from systems which the local system does not consider DIS. Why 
>would/should it? If I pick Router A as the DIS and copy the LANID from 
>Router A's IIH into my IIH and Router B's IIH does not agree, what can I 
>do?? This certainly occurs as a transient situation if DIS is changing. 
>What is most important (and I believe unstated by 10589) is that the DIS 
>that we choose should also think that it is DIS and therefore advertise a 
>LANID in its IIHs where the first 6 octets match its own systemID. If it 
>does not, then there will be problems.
>

---

From: Philip Christian <[email-masked]>
Date: Thu, 10 Apr 2003 10:06:41 +0100 (BST)

> What was it that motivated you to add 5.2 to your
Two reasons.

1. If a dual autoencap IS is on a LAN with both
IPv4-only and IPv6-only ISs where it looses both
pseudonode elections, then it is not clear which LAN
ID it should put in its own Hellos.  It can only put
one.  Does it put the IPv4 DIS LAN ID? or the IPv6 DIS
LAN ID? or some other LAN ID (like its own or a
special one).

Section 5.2 is worth having at least to clarify this
point.  I would appreciate any thoughts on what the
right answer is in this scenario (if it really matters
at all).

2. I was imagining some implementation that might
check the LAN IDs from all of the ISs on the LAN to
make sure that they agree who is DIS, or something
non-10589 like that.  We have seen situations like
this before, where implementation A will interwork
with 10589 and implementation B will interwork with
10589 but A won't work with B.  Remember the ISH
discussions (A doesn't sent ISH and B won't do
anything till it gets an ISH).

A dual autoencap is forced to put the "wrong" LAN ID
in Hellos in certain circumstances.  This shouldn't
matter provided that everyone ignores the LAN ID from
non-DIS.  As 10589 doesn't actually state that though,
then it is an assumption not a fact.  Assumptions
should be stated, I would have thought.

It is not clear in my mind why non-DISs echo the DIS
LAN ID back onto the LAN if everyone is ignoring it
anyway.  It is almost as if 10589 was architected for
some sort of checking, but then it got forgotten or
something.  As no-one checks the LAN ID from non-DISs,
then why does a non-DIS even bother copying the LAN ID
of the DIS into its own Hellos?  okay it might be
useful if you network is broken and you have a LAN
analyser, but I don't think that that is what the
original authors had in mind...

Probably it could be worded better.  Or maybe I think
too much and it isn't really necessary.

Philip

---

From: mike shand <[email-masked]>
Date: Thu, 10 Apr 2003 10:22:22 +0100

>original authors had in mind...

Exactly so. I seem to recall that it was thought it might be a useful 
diagnostic tool. You could tell without having to use "management" what 
everyone's view of the DIS was. There was a particular concern about broken 
receivers, which of course cause you to elect yourself DIS, since you can't 
hear anyone else.

         Mike