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

From: Jodie Kruger <[email-masked]>
Date: Tue, 11 May 1999 17:21:01 -0400

I had some questions on the 3way draft:

1. In 3.1 the minimum Length of the option is 5 but earlier versions have a 
   length of 1.

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?

   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?

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?

Thanks,

Jodie

---

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

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.)

   2. Section 3.2 states: 

      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.)

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 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.

Thanks...

--Dave