Subject: RE: [Isis-wg] Concerns with 3-way-handshake

From: Les Ginsberg <[email-masked]>
Date: Wed, 5 Dec 2001 21:37:38 -0800

Rajesh -
 
You have reminded me that the adjacency states defined by the 3way draft and
sent in the 3 way TLV are not equivalent to the adjacency states defined in
10589. 10589 defines the following states:
 
   INITIALISING: Created on receipt of ISH (or IIH if you allow that)
   UP
   FAILED (Only used on DA circuits - let's ignore that)
   DOWN: A transient state because the adjacency is deleted immediately
after
 
3way defines:
 
   DOWN: Can mean no adjacency exists or the state associated with the
adjacency when an IIH is received and the action in Tables 5,6,7, or 8 from
10589 is UP
  INITIALISING: Reached after receiving an IIH when you are in down state
(as per table in 3way draft)
  UP
 
Conceptually it is necessary to maintain these two sets of adjacency states
because until you receive an IIH you do not know whether your neighbor
supports 3way or not. If your neighbor does not include the 3way TLV then
you follow the original 10589 rules, which means that you transition from
Initialising to UP when receiving an IIH.
 
If your neighbor does include the 3 way TLV, then after determining via
Tables 5,6,7,8 that the action is UP you must set local 3way state to DOWN
and then apply the 3way state table.
 
If you are initiating an IIH before you have received one, then you should
set the adjacency state field in the 3way TLV to down (NOT initialising),
whether you have received an ISH or not. The 3way state can only transition
to Initialising after receiving an IIH.
 
All of this makes me think that Philip's original premise is wrong (and
unfortunately much of the discussion, including much of my comments) is off
the mark. Philip said:
 
 >A is connected to B and issues an ISH. 
>B receives the ISH, and according to ISO 10589 section 8.2.2 creates an
adjacency of type "Initialising". 
>B now reports to A in the new "Point to point adjacency state" option that
the adjacency is "Initialising". 

No - this is incorrect. B should report the 3way state as "Down" because it
has yet to receive an IIH.
 
>A receives this and according to the table in the draft, brings the
adjacency "up". 
 
Now A will, following the table in 3 way draft, change the adjacency to
Initialising.

>However B may never have received an IIH from A and so the three way
handshake has been short circuited
 
This no longer applies.
 
---------------------------
 
The textual correction that is needed in the 3 way draft is as follows:
 
   Add a clause e) to the end of Section 8.2.3:
 
   "Set the state to be reported in the Adjacency State field of the
Point-to-Point
   Adjacency State option to down."
 
(NOTE: This would be clause f) in the 10589:2001 draft)
 
The previous textual correction I suggested then is not needed. No further
change to ISH sending/processing is needed either. Whether we want to
standardize not sending ISHs is a separate issue which should be discussed
on a separate thread.
 
Sorry for heading down the wrong road previously.
 
   Les
 
 -----Original Message-----
From: Rajesh Saluja [mailto:[email-masked]]
Sent: Wednesday, December 05, 2001 3:49 PM
To: 'Les Ginsberg'; Philip Christian; 'Tony Przygienda'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Isis-wg] Concerns with 3-way-handshake

 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A -
otherwise B would have inserted the neighbor system ID/circuit id. A should
only record B's advertised info (system ID/circuit ID) for use in its own
IIH but not make any adjacency state change. 
[Rajesh Saluja] 
Les,
If a router has not heard from its neighbor, the first IIH will always
contain just the extended local circuit id and then the adjacency goes from
down to initialising. If we do not make any adjacency change, we will
actually need one extra IIH to come to UP state. Also how does this help in
solving the original problem to interoperate with ISH?
 
Thanks,
Rajesh

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 06 Dec 2001 15:36:28 -0800

Les,

> ajesh -
>
> You have reminded me that the adjacency states defined by the 3way draft and sent in the 3 way TLV are not equivalent to the adjacency states defined in 10589.
> 10589 defines the following states:
>
>    DOWN: A transient state because the adjacency is deleted immediately after
>
> 3way defines:
>
>    DOWN: Can mean no adjacency exists or the state associated with the adjacency when an IIH is received and the action in Tables 5,6,7, or 8 from 10589 is UP
>   INITIALISING: Reached after receiving an IIH when you are in down state (as per table in 3way draft)
>   UP
>
> Conceptually it is necessary to maintain these two sets of adjacency states because until you receive an IIH you do not know whether your neighbor supports
> 3way or not. If your neighbor does not include the 3way TLV then you follow the original 10589 rules, which means that you transition from Initialising to UP
> when receiving an IIH.
>
> If your neighbor does include the 3 way TLV, then after determining via Tables 5,6,7,8 that the action is UP you must set local 3way state to DOWN and then
> apply the 3way state table.
>
> If you are initiating an IIH before you have received one, then you should set the adjacency state field in the 3way TLV to down (NOT initialising), whether
> you have received an ISH or not. The 3way state can only transition to Initialising after receiving an IIH.
>
> All of this makes me think that Philip's original premise is wrong (and unfortunately much of the discussion, including much of my comments) is off the mark.
> Philip said:
>
> >B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising".
> >B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising".
>
> No - this is incorrect. B should report the 3way state as "Down" because it has yet to receive an IIH.
>
> >A receives this and according to the table in the draft, brings the adjacency "up".
>
> Now A will, following the table in 3 way draft, change the adjacency to Initialising.
>
> >However B may never have received an IIH from A and so the three way handshake has been short circuited
>
> This no longer applies.
>

fine, so if understood correctly you originate first hello always with 'Down'
for 3-way which makes for ISHs impossible to short-cut the 3-way state machine.
Any first hello you receive for ISH you sent should therefore be 'Down' for
3-way as well. That solves the problem or rather it seems really non-existent.

yes, seems to me indeed necessary AND sufficient. I suggest to halt the
RFC publication and do another last call after this fix is propagated.  Protocol
specifications
with buggy or unclear state machines shine a poor light on the group involved
;-)

> The previous textual correction I suggested then is not needed. No further change to ISH sending/processing is needed either. Whether we want to standardize
> not sending ISHs is a separate issue which should be discussed on a separate thread.
>

yes, it is a fully orthogonal issue and if somebody feels like documenting it,
fine, does not seem to me very important or even necessary (seems you can
violate the 10589 here in many inventive
ways and it is still stable enough to survive it).

> Sorry for heading down the wrong road previously.

good scare, everybody fell for it initially ;-)

    --- tony

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg