Subject: RE: draft-ietf-isis-3way-01.txt questions

From: Jodie Kruger <[email-masked]>
Date: Wed, 12 May 1999 09:50:47 -0400

> -----Original Message-----
> From: Dave Katz [mailto:[email-masked]]
> Sent: Wednesday, May 12, 1999 3:00 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-ietf-isis-3way-01.txt questions
> 
> 
>    1. In 3.1 the minimum Length of the option is 5 but 
> earlier versions have a 
>       length of 1.
> 
> Yes, but it is backward compatible:
> 
>      If the Neighbor System ID and Neighbor Extended Local Circuit ID
>      fields match those of the local system, or are not present, the
>      state table below is used to determine the next state, 
> based on the
>      current adjacency state and the received state value from the
>      option.  (Note that the procedure works properly if neither field
>      is ever included.  This provides backward compatibility to an
>      earlier version of this option.)
> 
It is backward compatible but it would be nice to note that earlier versions
only contain the Adjacency State field and not the Extended Local Circuit
ID. It would also be nice to state that when interoperating with an earlier
version either just the Neighbor System ID is returned or neither or both
with a zero Neighbor Extended Local Circuit ID.  Previous implementation do
not seem to care what we do but for consistency and clarity I think it is
worth stating.

>    2. Section 3.2 states: 
> 	If the system ID of the neighboring system is known (in state
> 	Initializing or Up), it shall be reported in the 
> Neighbor System ID
> 	field, and the neighbor's Extended Local Circuit ID shall be
> 	reported in the Neighbor Extended Local Circuit ID field.
> 
>       The Neighbor System ID is known in state Initializing via 
>       the ISH but the neighbor's Extended Local Circuit ID is 
> not.  Are these 
>       fields only supposed to be reported after having 
> received an IIH with the
> 
>       "Point-to-Point Adjacency State" option present and in 
> state Initializing
> 
>       or Up?
> 
> Essentially I am assuming that the ES-IS transaction is irrelevant
> (which it is).  The only thing that requires the ISH is the triggering
> of the padding gorp on point-to-point links, and the padding is not
> correctly implemented in the dominant implementations (it is always
> there) and it's more or less useless anyhow.
> 
> Going back to the spec, I see that it in fact does say to go to
> Initialising state when an ISH is received, so I'll change the
> verbiage to say to wait for the IIH with the option present.
> (Note that the adjacency cannot be in Up state when the first IIH
> with this information is seen.)
> 
>       Earlier version of this option do not contain the 
> Extended Local Circuit
>    ID,
>       should the Neighbor Extended Local Circuit ID not be 
> reported in this
>    case?
> 
> Not sure what you're asking.  Older implementations do not contain it,
> but at least the dominant fielded implementations are tolerant of it
> not being there, and thus will work fine (there is no need for a
> version handshake or anything).
> 
>    3. Section 3.2 states: 
> 	If the new state is "Initializing", the adjacency state shall be
> 	set to "Initializing" and no further action is taken.
> 
>       When going from state Down to Initializing shouldn't an 
> adjacency be
>    created
>       if one does not already exist and a padded point to 
> point IIH PDU sent?
> 
> If you take the spec literally, you will note that you will 
> never transition
> from Down to Initializing on a received IIH (since this is 
> the purview of
> the ISH).  It is also worth noting that an adjacency can 
> never exist and
> be in "down" state.  In any case, the verbiage here is a 
> little muddled,
> so I should see if I can't clean it up a tad.
> 

Just so I am clear, isn't this draft proposing that now you can transition
from down to initializing on a received IIH?

> Thanks...
> --Dave

Thanks,

Jodie

---

From: Dave Katz <[email-masked]>
Date: Wed, 12 May 1999 17:40:04 -0700 (PDT)

Fair enough.  I can augment the verbiage a little bit.

That's the reality of all of the fielded implementations that I know
of.  Keep in mind that the ISH hack is there from the days when people
actually thought that someone was going to use CLNP (and thus ES-IS
was serving a useful purpose).  Not too many folks are doing this
any longer.

It wasn't my intention to codify this practice in this draft, though
I could probably do so.  This kind of behavior (and the state stuff
in general) is only marginally standardizable in any case (since it
is only visible if you implement the GDMO management gorp).  What
really counts is that you tear down the adjacency in all the right
places.  Ah, well...