Subject: 3way draft questions

From: Rajesh Saluja <[email-masked]>
Date: Thu, 10 Jun 1999 14:28:18 -0400

I have the following questions. I will appreciate any feedback.

1. In the new TLV, the Extended System Id can be from 0 to 8 octets. Any
system
receiving  this TLV does not know how many octets should it expect for
Extended
System Id because there is nothing like ID length field in this TLV. I
assume that in
this case, the length of the System Id will be derived from
( length of TLV - 9 octets for other fields ). Am I correct?

2. If the above assumption is correct, then is it true that there can
not be Neighbor
System ID field if there is no Neighbor Extended Local Circuit ID?  It
is possible that
an IS  has information about System ID of the neighbor but it does not
have information
about Neighbor Extended Local Circuit ID.

3. Suppose there are two ISs A and B and A implements 3way, B does not.
Now A sends first hello with new TLV and B sends without new TLV.  After

listening from B, Should A stop sending new TLVs to B for that session?

4. The draft says "Add a section 8.2.4.1.1, Three-Way Handshake,
immediately prior
to section 8.2.4.2. A received Point-to-Point IIH PDU may or may not
contain the
Point-to-Point Adjacency State Option. If it does not, the link is
assumed to be
functional in both directions, and the procedures described in section
8.2.4.2 are followed".

I think that draft is misleading here.  We must first  do the validation
for area, L1/L2 etc as
given in 8.2.4.2 a) and b), only after this we should start looking at
TLV.   The sequencing
should be corrected in the draft.

5. What is the implementation status of this draft?

Regards,
Rajesh

---

From: Dave Katz <[email-masked]>
Date: Thu, 10 Jun 1999 13:02:28 -0700 (PDT)

The System ID length will be known from the IIH header (and the neighbor's
length must be the same according to IIH acceptance rules).  In real life,
nobody uses any length other than 6.

Either both fields will be present or neither will (seen the rules
for transmission).  For backward compatibility, the receiver must
be able to cope with all three fields (those two plus the local
extended circuit ID) being missing.

There's no reason to stop, since the neighbor will have already crashed
by this point if it doesn't implement the base spec properly.  ;-)  No
reason to add the additional complexity.

It is not particularly clear, but the state machine is at least in theory
supposed to be independent from the existing mechanism.  You will note that
if the new state machine returns "up" that the adjacency is not actually
touched, but the packets are leaked through to the additional tests.
The only thing that the state machine touches outside of its own state
is in the case of a Down event, in which case it generates an adjacency
down event and deletes the adjacency.  Thus the ordering is correct.
I will try to clarify the language.

In practice you can do anything you want so long as the behavior as seen
outside the box is what it is supposed to be.

cisco has had one version or another of this deployed since around 1995
(if my memory serves) and Juniper since around 1997.  The current deployed
Juniper code matches this draft;  I can no longer speak for the cisco
version.  Perhaps Henk can jump in if he cares to.

--Dave

---

From: Henk Smit <[email-masked]>
Date: Thu, 10 Jun 1999 14:03:14 -0700 (PDT)

> version.  Perhaps Henk can jump in if he cares to.

  We have only implemented the first version of this idea. Actually
 Dave implemented it when he was still at cisco. The TLV we send has
 just one byte, indicating Up/Init/Down. That should/could interoperate
 with implementations that do more then just one byte. We have not
 implemented the full draft yet. I believe that
 the problem that is solved with the newer version of the draft is
 mainly seen when using APS. We have another mechanism (outside of
 ISIS) to solve that problem for the moment. We probably will at
 some point in the future, but we have had no customer requests yet.

     Henk.

---

From: Rajesh Saluja <[email-masked]>
Date: Thu, 10 Jun 1999 19:33:42 -0400

Dave,

> extended circuit ID) being missing.

I am concerned about the case when one endpoint supports this
and other does not.
The draft says :"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's Extended Circuit
Id field".
Suppose A supports 3way  ( point-to-point Adjacency State
option) and B does not. When A receives first Hello from B, it
will know  about the System ID of B and not about the Extended
Circuit ID.  What should A do out of following 3 options:
1. Do not send  this TLV any more since B does not support this.
2. Send this TLV with adjacency state, Extended Local Circuit ID
and Neighbor System Id.
3. Send this TLV with adjacency state and Extended Local Circuit
ID.

> I will try to clarify the language.

Is the following ordering correct:
1. Do PDU acceptance tests.
2. If the option is present, implement state table as described in 3way
draft.
3. If option not present or if the state as result of 2 is "UP" do the
following:
-  Check for Area Address Mismatch  and implement state tables  as
      described in the spec ( table 5,6 or 7 ) ( 8.2.4.2.a  and b)
- If the action is "UP" or "Accept", calculate circuitID status. ( 8.2.4.2 c)
- If the action is "Accept" and circuit ID status is different, delete
    adjacency ( 8.2.4.2.d)
- If action is "UP" or "Accept", update other fields.

My questions on this  ordering are:
1. If the result of item 2 is "INITIALIZING", you hear Hello from a neighbor
for the first time, isn't it necessary to check for 8.2.4.2 a and b? The 3way
draft suggests to do nothing but I think that 8.2.4.2 should be processed.

2. Even if result of item 2 is "UP", it is possible that adjacency can fail
because
of 8.2.4.2 a or b. Then why should you first look into TLV and then verify the

header?  ( I mean Area Address mismatch, Circuit Type )

3. Since  option processing will take care of circuit ID changes, why should
you
again process 8.2.4.2 c and d?

I have one more question on 3way draft state table:
If Adj State is Down and Received State is "Initializing", why should the new
state be "Initializing" and not "Up" because  receiving state  "Initializing"
implies that the receiver has heard Hello from this system.

Best regards,
Rajesh

---

From: Dave Katz <[email-masked]>
Date: Thu, 10 Jun 1999 16:57:10 -0700 (PDT)

Yep, you identified a small hole.  The short answer is that it doesn't
matter in the least what it sends since the other guy is ignoring
the fields anyhow.  The spec should be more explicit, however.

I see what you're getting at, I think.  If there is a level or area address
mismatch, it will take a couple of packets to detect this, and an adjacency
will be created and then destroyed.  Yeah, I guess I need to revisit this
verbiage (which of course bears no resemblance to any code in two different
implementations, which is why it's slightly broken...)

This is indeed redundant but I was trying not to take apart the existing
verbiage too much.  Obviously I need to rework this.

It is this way because I copped it straight from NLSP four years ago and
didn't think about it too much.  I think you're right, it's a bit more
conservative than it needs to be (and turns it into a four way handshake).
I'll convince myself that it won't break anything, and then change it.

--Dave

---

From: [email-masked] (Randall Atkinson)
Date: Thu, 10 Jun 1999 20:09:49 -0700

Henk,

	You now have a customer request to implement the
full draft. :-)

Ran
[email-masked]

---

From: Tony Li <[email-masked]>
Date: Thu, 10 Jun 1999 22:35:36 -0700

>         You now have a customer request to implement the

From a customer that has a constitutional aversion to running IS-IS, no
less.

Tony

---

From: Rajesh Saluja <[email-masked]>
Date: Mon, 14 Jun 1999 11:49:02 -0400

Dave,
I can think of the following sequence while processing the received
Point-to-Point Hello  packets:
- If  Adjacency exists and the option is present, examine
Neighbor System ID and Neighbor Extended Local Circuit ID.
If they are present and there is a mismatch,
PDU should be discarded.  ( as explained in 3way draft )
- 8.2.4.2 a
- 8.2.4.2 b
- if action is UP or ACCEPT as a result of 8.2.4.2 a and b then
    if option is not present
                  8.2.4.2c
                  8.2.4.2d
   otherwise if option is present
                  implement state table as given in 3way draft
- 8.2.4.2e

Also, in the state table,  Other than the previous suggestion ( If Adj State
is Down and Received State is Initializing, final  state should be UP ),
I am not convinced with one more transition: If Adj State is "Down"
and  Received State is "UP", why should the final state be "Down"
and not "Initializing".

One more thing. I assume that CSNP should be sent whenever the state
transitions to "UP" state and CSNP should be processed even if the state
is "Initializing" ( otherwise CSNP can get lost ).  It will be nice if this can
be  elaborated in the spec.

Best regards,
Rajesh