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

From: "Philip Christian" <[email-masked]>
Date: Tue, 4 Dec 2001 20:03:23 -0000

The draft is definitely talking about embedded DCC channels when it says

"In addition, SONET links bring a third issue, which is that when SONET
protection is used, a system may receive packets that are actually destined
for a different system (or a different link on the same system).  The
receiving system may end up thinking that it has an adjacency with the
remote system when in fact the remote system is adjacent with a third
system."

This has to be referring to when the embedded DCC channel in a SONET signal
switches with the K bytes from one fibre to another. The problem mentioned
above occurs when the active signal goes through a different regenerator to
the protection fibre. Interestingly SDH acts differently with two
adjacencies maintained and one of them just disappearing.

A protection switch should be invisible to the SONET payload, i.e. a POS
circuit between two routers, and so this is not what it is talking about.

Philip Christian

-----Original Message-----
From: Tony Li [mailto:[email-masked]]
Sent: 04 December 2001 18:41
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: [email-masked]'; [email-masked]';
[email-masked]'
Subject: [Isis-wg] Concerns with 3-way-handshake

 | This draft specifically declares itself to be useful in SONET networks
 | (presumably in the embedded DCC channels, although this is not stated).

Actually, most of the IP routers running IS-IS do so over POS links, and
thus, IS-IS is running in-band.

I agree with your comments.  Other opinions?

Tony

---

From: Jeff Learman <[email-masked]>
Date: Tue, 04 Dec 2001 15:31:42 -0500

At 03:03 PM 12/4/2001, Philip Christian wrote:

>"In addition, SONET links bring a third issue, which is that when SONET protection is used, a system may receive packets that are actually destined for a different system (or a different link on the same system).  The receiving system may end up thinking that it has an adjacency with the remote system when in fact the remote system is adjacent with a third system."
>
>This has to be referring to when the embedded DCC channel in a SONET signal switches with the K bytes from one fibre to another. The problem mentioned above occurs when the active signal goes through a different regenerator to the protection fibre. Interestingly SDH acts differently with two adjacencies maintained and one of them just disappearing.

This would cause the LAPD link to fail with high probability, so I
doubt it's what is being referred to in the draft.

>A protection switch should be invisible to the SONET payload, i.e. a POS circuit between two routers, and so this is not what it is talking about.

For channelized SONET, reprovisioning could cause the VT to be terminated
at a different remote system.  Since the link layer protocol is unreliable
and does not detect the fact that it is now connected to a different system,
the 3-way handshake is required.

Jeff

>From: Tony Li [<mailto:[email-masked]>mailto:[email-masked]]

---

From: Jeff Learman <[email-masked]>
Date: Tue, 04 Dec 2001 15:36:47 -0500

Implementations are required to send ISHs by RFC 1195 and ISO 10589.
Therefore, wouldn't it be wise for the draft to accommodate this
requirement?  (Regardless of the fact that many (most?) implementations
don't do it.)

Jeff

At 02:53 PM 12/4/2001, Philip Christian wrote:

>I absolutely do not agree. 
>I said that it is acceptable for a pure IP implementation to ignore ISH, and so these "current vendors implementations" need not have a problem with it.
>
>We can even say this in the RFC, so for the first time ever, it will say in an RFC "you can ignore ISH". I would have thought that this would be good news for the implementations that you mention.
>
>However the draft is useless for routers that do need to terminate CLNS packets, and is therefore useless for sorting out the SONET protection switching events that it claims to help.
>
>Do we want RFCs that do not acheive what they claim to? 
>We can sort out one without affecting the other, and therefore should do so. 
>
>By the way, the draft has expired, but people can still read it at 
><http://www.watersprings.org/pub/id/draft-ietf-isis-3way-03.txt>http://www.watersprings.org/pub/id/draft-ietf-isis-3way-03.txt 
>
>Philip Christian 
>
>From: Naiming Shen [<mailto:[email-masked]>mailto:[email-masked]] 
>Sent: 04 December 2001 19:42 
>To: Tony Li 
>Cc: Christian, Philip [HAL02:GI50:EXCH]; [email-masked]'; 
>[email-masked]'; Saluja, Rajesh [BL60:432:EXCH] 
>Subject: Re: [Isis-wg] Concerns with 3-way-handshake 
>
>
>this draft reflects many vendors current implementation for the ip 
>routers, we should let this to go through to become an rfc(informational). 
>any need for ish probably should submit a seperate one, maybe a big 
>one to handle all other clns cases where the ip portion has already 
>advanced. 
>
> ] 
> ] | This draft specifically declares itself to be useful in SONET networks 
> ] | (presumably in the embedded DCC channels, although this is not stated). 
> ] 
> ] 
> ]Actually, most of the IP routers running IS-IS do so over POS links, and 
> ]thus, IS-IS is running in-band. 
> ] 
> ]I agree with your comments.  Other opinions? 
> ] 
> ]Tony 
> ] 
> ]_______________________________________________ 
> ]Isis-wg mailing list  -  [email-masked] 
> ]<http://external.juniper.net/mailman/listinfo/isis-wg>http://external.juniper.net/mailman/listinfo/isis-wg 
>
>- Naiming

---

From: Les Ginsberg <[email-masked]>
Date: Tue, 4 Dec 2001 13:00:47 -0800

The problem has nothing to do with ISHs, but rather with the clarity of the
presentation of the draft and some legacy issues from older versions of the
3 way handshake.
 
Philip states:
>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". 
>A receives this and according to the table in the draft, brings the
adjacency "up". 
>However B may never have received an IIH from A and so the three way
handshake has been short circuited, or have >I misunderstood something?
 
The draft states:
    "If the option is present, the Neighbor System ID and Neighbor
     Extended Local Circuit ID fields, if present, shall be examined.
     If they are present, and the system ID contained therein does not
     match the local system's ID, or the extended circuit ID does not
     match the local system's extended circuit ID, the PDU shall be
     discarded and no further action is taken.

     If the Neighbor System ID and Neighbor Extended Local Circuit ID
     fields match those of the local system, or are not present, the
     procedures described in section 8.2.4.2 are followed ..."

A router which supports the latest version of the draft could either omit
sending the neighbor's system ID/extended local circuit ID  in the 3 way TLV
when it doesn't know  what they are or send them as all 0's (hopefully no
one allows a system ID to be set to all 0's ???) . If the sending system
sends all 0's the above rule works. But if the sending system is allowed to
omit the neighbor system ID/circuit ID, then for proper operation the rules
above have to be modified to indicate that if either the neighbor system ID
or neighbor circuit id fields are not present then no adjacency state change
should take place.

This modification is not quite enough, however, because an older version of
the 3 way handshake specified a TLV which only included the local adjacency
state. Therefore, a robust implementation has to recognize that the presence
of the 3way TLV with only the local adjacency state in a received IIH
indicates a system which will never echo the neighbor system-id/circuit id
and so it cannot look for a match in these non-existent fields and must
resort to the revised state table solely based on the local/remote adjacency
state. This legacy usage of the option can encounter the problem outlined by
Philip, which results in behavior no different than that which occurs in the
absence of the 3 way TLV.

Reception of an ISH indicates that the neighbor is NOT an OSI End System and
therefore that it is useful to send IIHs on this link. In an IP world, this
requirement is less useful and some implementations, whether intentionally
or not, have omitted sending ISHs. In the strictest sense this is a
violation of ISO 10589, but is workable and in the spirit of "being generous
in what you receive" some implementations allow this, which requires that
the receiver start sending IIH PDUs on receipt of an IIH PDU ( as well as on
a receipt of an ISH).

It probably would be better if the draft was updated to discuss the proper
behavior when dealing with legacy 3 way implementations and what is the
expected behavior when neighbor system ID/extended circuit ID are omitted.

In any event, don't blame ISHs.

  Les

 -----Original Message-----
From: Philip Christian [mailto:[email-masked]]
Sent: Tuesday, December 04, 2001 9:34 AM
To: [email-masked]'; [email-masked]';

I have a number of concerns and comments about the 3-way-handshake draft,
draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is
about to become an RFC, although I can find no evidence of this on the RFC
editor's web page.

Here are my concerns. 

This draft specifically declares itself to be useful in SONET networks
(presumably in the embedded DCC channels, although this is not stated).
However I believe that there is an area of ambiguity in it which reduces its
usefulness somewhat. The draft mentions only IIH packets, where as SONET and
SDH networks (oh yes, SDH is not mentioned either) are currently based on
CLNS and therefore the NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not support three-way
handshaking anyway, and so a new neighbour would engage legacy mode anyway,
BUT....

With the advent of G.7712 vendors will be looking at implementing dual IP
and CLNS routers that are able to still interface to the old CLNS nodes, and
which also support three way handshaking. Such a new dual node may well need
to declare itself a CLNS End System, and so will be transmitting ISHs. This
will be necessary to terminate RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH packets "short circuits"
the three way handshake, and results in the adjacency coming up whether the
neighbour has received  IIHs, or not. This is my understanding of the
problem:

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". 
A receives this and according to the table in the draft, brings the
adjacency "up". 
However B may never have received an IIH from A and so the three way
handshake has been short circuited, or have I misunderstood something?

The draft really needs to state how a router with three way handshaking
should handle receipt of an ISH from a neighbouring IS that also supports
the option.

I guess that this is not a problem for pure IP routers if they ignore ISHs,
and this could be stated. 

Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4
"For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the
first step in establishing the link between routers. All IS-IS routers are
therefore required to transmit and receive ISO 9542 ISH packets on
point-to-point links.". There is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH packets anymore, as
they cannot terminate CLNP and thus are not an CLNS End System anymore.

This seems perfectly logical to me, but, if this is the case then I think
that this draft should state it. It is the after-all going to be (hopefully)
the first RFC to actually alter the adjacency creation process from ISO
10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs
then let's say so.

I think that this issues could be addressed just in a few sentences, once we
have agreed how to handle ISHs on nodes that need to. I am ready to help
with some drafting in order to help get this right.

Regards, Philip Christian.

---

From: "Philip Christian" <[email-masked]>
Date: Tue, 4 Dec 2001 21:15:47 -0000

okay, I can see that. But why does it talk about "SONET protection" rather
than reprovisioning ?
 
Philip Christian

Jeff

---

From: Les Ginsberg <[email-masked]>
Date: Tue, 4 Dec 2001 22:03:05 -0800

Sorry folks - but IMHO you are focusing on the wrong issue. The problem is
not ISHs, but some ambiguity in the current definition of the 3way draft and
the fact that a number of vendors still utilize the old version of the 3 way
handshake which only sends local adjacency state. (Please see my earlier
mail on this subject)

Suggesting that ISHs be ignored just creates more potential backwards
compatibility problems and ignores the real cause of the problem. That
doesn't make sense to me.

(The fact that some implementations already do not send ISHs has created
compatibility problems in that implementations in strict conformance to ISO
10589 will not interoperate with these implementations i.e. an
implementation which expects to receive an ISH before sending an IIH (as per
ISO 10589) will never form an adjacency with an implementation that never
sends an ISH.)

   Les

> From: Tony Przygienda [mailto:[email-masked]]
> Sent: Tuesday, December 04, 2001 4:35 PM
> To: Rajesh Saluja
> Cc: Philip Christian; [email-masked]'; 
> [email-masked]'
> Rajesh Saluja wrote:
> > > >From my vintage, yes, it should be fixed, maybe as 
> simply as saying that
> > > three-way-hello capable routers drop ISHs and do not send 
> them ?  The
> > > very details of 1195 slip my mind right now but that 
> should not cause
> > > any backwards capability problems?
> > >
> > >     something is definitely worth an addition to the 
> 3-way-hello draft
> > >
> > >     -- tony
> >
> > I agree with Philip's concerns. Will the following modifications be
> > acceptable to the group:
> > 1. As Tony suggested, say that  three-way-hello capable 
> routers drop ISHs
> > and do not send them.
> 
> you better be very carefull with the MUST and MAYs when 
> writing this. As well,
> someone thinks carefully whether it won't break more than it 
> fixes (although
> deployment with dropped ISHs seems to prove that it works and 
> since we will
>  be able to chhose whether we send/receive them, we can force 
> pretty much
> this situation with the draft).
> 
>     thanks
> 
>     -- tonyt
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
> 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Wed, 05 Dec 2001 09:50:27 +0000

At 17:34 04/12/2001 +0000, Philip Christian wrote:

Such a new dual node may well
need to declare itself a CLNS End System, and so will be transmitting
ISHs. This will be necessary to terminate RFC 3147 encapsulated packets,
for example.

I don't understand what you mean here. Sending ISHs has nothing to do
with being an ES, and it is CERTAINLY not necessary to declare itself an
ES in order to terminate CLNP packets. An IS can do that just as well.
The only reason an IS sends ISHs over a pt-pt link is in case the system
at thew other end happens to be an ES (only). Becuasre it has to do this,
the ISH sending is integrated into the IIH initialization sequence.

Mike

---

From: "Philip Christian" <[email-masked]>
Date: Wed, 5 Dec 2001 10:00:25 -0000

Yes, I got this wrong. I believe that the ISHs are there so that an IS can
say hello to an ES. Thus an CLNP capable router needs to send ISHs to talk
to an CLNS End System, but a pure IP router maybe does not.
 
However the ISHs still have to be there if one wants to build a dual router,
and I still believe that they short circuit the 3-way-handshake (as if it
isn't there) as it is in its current form.
 
thanks, Philip

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: 05 December 2001 09:50
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: [email-masked]'; [email-masked]'; Saluja, Rajesh
[BL60:432:EXCH]

Such a new dual node may well need to declare itself a CLNS End System, and
so will be transmitting ISHs. This will be necessary to terminate RFC 3147
encapsulated packets, for example.

I don't understand what you mean here. Sending ISHs has nothing to do with
being an ES, and it is CERTAINLY not necessary to declare itself an ES in
order to terminate CLNP packets. An IS can do that just as well. The only
reason an IS sends ISHs over a pt-pt link is in case the system at thew
other end happens to be an ES (only). Becuasre it has to do this, the ISH
sending is integrated into the IIH initialization sequence.

        Mike

---

From: "Philip Christian" <[email-masked]>
Date: Wed, 5 Dec 2001 10:51:23 -0000

I (and a colleague, credit where it's due) can think of a couple of ways to
solve this problem.
First we could add an explicit statement such as

"Sending and receiving ISHs is required by Intermediate Systems that can
route CLNP packets. Intermediate Systems that cannot route CLNP may or may
not send and receive ISHs."

Now here are the two ideas

1.
On Intermediate Systems where receipt of an ISH causes an adjacency to start
in the "initialise" state, and which support the "Point-to-Point Adjacency
State" option, such an adjacency will be reported in the option as being
Adjacency State "Down". Once an IIH has been received then the state of the
adjacency shall be reported in the option as normal.

or

2.
On Intermediate Systems where receipt of an ISH caused an adjacency to start
in the "initialise" state, and which support the "Point-to-Point Adjacency
State" option, such an adjacency will be reported in the option as being
Adjacency State 3 = "ISH_init" (for example). Intermediate Systems that do
not send and receive ISHs are not required to implement reporting of this
state, as they will neither send it, nor cause a neighbour to send it back
to them. We then have to mess with the table a little, basically saying that
if you support ISHs and receive an "ISH_init" then you go to "Initialise"
(rather than "up", which was the problem).

I think that both of these ideas allow routers that support CLNP forwarding
to also use the 3-way-handshake, without upsetting anyone who has already
stopped using ISHs on their pure IP implementations.

I prefer idea "2", as "1" feels like the IS is misreporting the state, and
just doesn't appeal to my sense of correctness so well.

The problem with "2" is that if you send an ISH to an IS, then you can
expect it to send back this new Adjacency State = 3 ="ISH_init" message
back. Now it seems to me that if someone just dumps incoming ISHs then they
shouldn't be trasmitting them either, but if someone HAS implemented that,
then they are going to get "3=ISH_init"s coming back at them and won't know
what to do with them (maybe that doesn't matter anyway, as long as they
don't bring the adjacency up).

Comments? other ideas?

Philip Christian

-----Original Message-----
From: Les Ginsberg [mailto:[email-masked]]
Sent: 05 December 2001 06:03
To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH]
Cc: Christian, Philip [HAL02:GI50:EXCH]; [email-masked]';
[email-masked]'
Subject: RE: [Isis-wg] Concerns with 3-way-handshake

   Les

---

From: Jeff Learman <[email-masked]>
Date: Wed, 05 Dec 2001 11:17:10 -0500

At 05:51 AM 12/5/2001, Philip Christian wrote:

>I (and a colleague, credit where it's due) can think of a couple of ways to solve this problem. 
>"Sending and receiving ISHs is required by Intermediate Systems that can route CLNP packets. Intermediate Systems that cannot route CLNP may or may not send and receive ISHs."

Is this intended as a statement of fact or as a proposed normative
statement?  If it's supposed to be normative, use SHOULD, MAY, and MUST.
If it's descriptive of standards, it's inaccurate, because 10589
and 1195 both require sending ISH PDUs.  If it's a statement of
practical fact, then it should be carefully written to state that --
e.g.,

  "Practically speaking, ISs that support CLNP need to send ISH
  packets on point-to-point links that might be connected to ESs in
  order for CLNP ESs to be able to communicate properly.  Many existing
  IP-only implementations fail to send ISH PDUs, even though it's required
  by 10589 and RFC-1195, and most (many?) IS-IS implementations interoperate
  with these implementations.

We need to be clear and accurate!  If I've made any inaccurate statements
here, please point them out.

Statements below are also not written using MUST, MAY, or SHOULD, and
need to be rewritten to say what the author means, because as written,
they can be misinterpreted as descriptive statements rather than
normative statements, which I assume they're intended to be.

Regards,
Jeff

>On Intermediate Systems where receipt of an ISH causes an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State "Down". Once an IIH has been received then the state of the adjacency shall be reported in the option as normal.
>
>or 
>
>2. 
>On Intermediate Systems where receipt of an ISH caused an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State 3 = "ISH_init" (for example). Intermediate Systems that do not send and receive ISHs are not required to implement reporting of this state, as they will neither send it, nor cause a neighbour to send it back to them. We then have to mess with the table a little, basically saying that if you support ISHs and receive an "ISH_init" then you go to "Initialise" (rather than "up", which was the problem).
>
>I think that both of these ideas allow routers that support CLNP forwarding to also use the 3-way-handshake, without upsetting anyone who has already stopped using ISHs on their pure IP implementations.
>
>I prefer idea "2", as "1" feels like the IS is misreporting the state, and just doesn't appeal to my sense of correctness so well.
>
>The problem with "2" is that if you send an ISH to an IS, then you can expect it to send back this new Adjacency State = 3 ="ISH_init" message back. Now it seems to me that if someone just dumps incoming ISHs then they shouldn't be trasmitting them either, but if someone HAS implemented that, then they are going to get "3=ISH_init"s coming back at them and won't know what to do with them (maybe that doesn't matter anyway, as long as they don't bring the adjacency up).
>
>Comments? other ideas? 
>
>Philip Christian 
>
>From: Les Ginsberg [<mailto:[email-masked]>mailto:[email-masked]] 
>> From: Tony Przygienda [<mailto:[email-masked]>mailto:[email-masked]] 
>> <http://external.juniper.net/mailman/listinfo/isis-wg>http://external.juniper.net/mailman/listinfo/isis-wg 
>> 
><http://external.juniper.net/mailman/listinfo/isis-wg>http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 5 Dec 2001 13:12:39 -0800

All of this is very unnecessary. Let's go back to the beginning. The
 
adjacency "up". 
>However B may never have received an IIH from A and so the three way
handshake has been short circuited
 
Pretend the 3 way handshake was never invented - so we run according to the
original rules in ISO 10589. For clarity I will refer to the 2001 draft
because it includes wording that was corrected based on Technical
Corrigendum 1. No fundamental change in procedure from the 1992 version was
made - just a clearer presentation. What happens?
 
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 sends an IIH to A
A receives the IIH and according to Table 5,6,7, or 8 (whichever applies)
brings the adjacency up
Note that at this time B has yet to receive an IIH from A (A presumably will
soon send one soon)
 
This demonstrates that this behavior involves no interaction between ISHs
and 3-way handshake.
 
Now enter the 3-way handshake era. The 3-way draft makes changes in the
adjacency state table logic so as to be able to detect neighbor state
changes even when run over unreliable link layers. It says nothing about the
use/non-use of ISHs because it is not concerned with that - quite correctly.
So, using the same scenario, what happens? 
 
There are a number of cases here depending on what form the 3-way TLV takes:
 
      Type = 0xF0 (decimal 240)
          Length = 5 to 17 octets
          Value:
            Adjacency State (one octet):
              0 = Up
              1 = Initializing
              2 = Down
            Extended Local Circuit ID (four octets)
            Neighbor System ID if known (zero to eight octets)
            Neighbor Extended Local Circuit ID (four octets, if Neighbor
              System ID is present)

As has been noted, there is a legacy version of the 3-way TLV - still in
widespread use - which sends only adjacency state (Length = 1). This is not
discussed in the current draft and should be. Anyway, we have three cases to
consider depending on what has been sent in the 3 way TLV when B sends its
first IIH:
 
Case 1)Adjacency state only (length = 1)
 
In this legacy 3-way case, B will never send neighbor system ID/circuit ID
so A cannot know whether B has received an IIH from A yet or not - and can
never know. So it must bring the adjacency up. Note that this behavior is no
different from that which happens in the total absence of the 3-way TLV.
Basically, this form of the 3-way handshake hasn't helped in this scenario.
(Part of the reason the later form was defined I assume.)
 
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. 
 
The draft is incorrect in this case because it says if the neighbor system
ID/circuit ID are "not present" the implementation should go ahead and
follow the state change table anyway. This wording needs to be corrected to
read something like:

     If they are NOT present, but the Extended Local Circuit ID is present
     then the PDU shall be discarded and no further action taken.
 
     If the Neighbor System ID and Neighbor Extended Local Circuit ID
     fields match those of the local system, or are not present and the 
     Extended Local Circuit ID is not present, the
     procedures described in section 8.2.4.2 are followed with following
     changes:"

Case 3)Adjacency state + Extended Local Circuit ID + neighbor system +
Neighbor extended local circuit ID (length = 17)
 
Presumably, if B chose to include neighbor system ID and neighbor circuit ID
before it had received an IIH from A, it would use values which are
guaranteed to not match A's local values. In my previous mail I suggested
using a system ID of all 0's, which is probably fairly safe, but a better
choice would be for B to place it's own system ID there. Since there can be
no duplicate system IDs this should never match A's local ID and therefore
the check would fail and therefore no adjacency state change would occur.
 
I believe changing the draft to include wording described in Case 2 above
solves the problem. There should also be some discussion of what the legacy
version (adjacency state only) does - that text has fallen into the black
hole of expired drafts.
 
Now, the issue of whether sending ISHs should be optional is something that
needs to be addressed - thus far this "violation" of the spec has been
supported by liberal implementations on the receiver side - but should be
agreed upon and defined in a draft. But that issue is distinct and unrelated
to the operation of the 3-way handshake. There is no reason to confuse the
two.
 
   Les

 Message-----
From: Philip Christian [mailto:[email-masked]]
Sent: Wednesday, December 05, 2001 2:51 AM
To: 'Les Ginsberg'; 'Tony Przygienda'; Rajesh Saluja
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Isis-wg] Concerns with 3-way-handshake

1. 

or 

2. 

Comments? other ideas? 

Philip Christian

---

From: Neal Castagnoli <[email-masked]>
Date: Wed, 5 Dec 2001 15:46:55 -0800

Should an ISH effect adjacency state?

The purpose of sending an ISH to an end system is to indicate the
availability of the router, and to a router to cause it to start the
router-to-router hello protocol (WANs only).  ISHs convey neighbor type,
address, and availability.

Routers send IIHs to convey router to router adjacency information.

Having ISH's set adjacency state mixes functions and gets in the way of the
IIH protocol managing the adjacency state.

To prevent ISHs from setting adjacency state, add a sentence to section 3.2
of the 3-way draft that reads something like:

	In section 8.2.2 replace each instance of "Initialising" with
"Down".

  --Neal

-----Original Message-----
From: Les Ginsberg [mailto:[email-masked]]
Sent: Wednesday, December 05, 2001 1:13 PM
To: 'Philip Christian'; Les Ginsberg; 'Tony Przygienda'; Rajesh Saluja
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Isis-wg] Concerns with 3-way-handshake

adjacency "up". 

   Les

 Message-----

---

From: Les Ginsberg <[email-masked]>
Date: Thu, 6 Dec 2001 18:07:04 -0800

Tony -

Thanks for your comments. I agree with your view that the text should be
revised before publication.

In addition to the correction mentioned below, there was also discussion of
revising it to indicate there is a legacy version of the 3 way TLV which
only sends adjacency state. This should require no changes to the state
table, which handles it (as indicated in the draft), but it should be noted
that the length can be 1-17 (rather than 5-17 as it indicates now) and
perhaps some brief description of what form this legacy version takes.

   Les

> Sent: Thursday, December 06, 2001 3:36 PM
> To: Les Ginsberg
> Cc: 'Rajesh Saluja'; Philip Christian; [email-masked]';
> [email-masked]'
> 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:
> >
> >    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:
> >
> > >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.
> 
> 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)
> 
> 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
> 
> 
>

---

From: Neal Castagnoli <[email-masked]>
Date: Thu, 6 Dec 2001 18:23:01 -0800

> for 3-way which makes for ISHs impossible to short-cut the 

Does this follow?  The first transmitted hello could be dropped, the ISH
would then come in and update the adjacency state to "Initialising" though
you've never received a hello from the other side.

>    Adjacency State option to down."

Section 8.2.3 in the original 10589 describes constructing hellos in
general.  This text would result in *all* hellos being transmitted with
"Down."

If this is meant to be added to section 8.2.2, the ISH section, then it
seems you would need to change some of the three-way text to create a new
3-way adjacency state in addition to the regular adjacency state, but is
this really necessary?

Also, if there were an implementation that forgot to turn off transmission
of ISHs, then the adjacency would potentially not come up or perhaps cycle
up and down.  Perhaps it would be better to take advantage of the built in
conditionals in section 8.2.2.

  --Neal

---

From: Les Ginsberg <[email-masked]>
Date: Thu, 6 Dec 2001 18:50:55 -0800

Neal -

Sorry. My error. I indeed was referring to Section 8.2.2 "Receiving ISHs by
an Intermediate System". Good catch. So we have:

   Add a clause e) to the end of Section 8.2.2:

   "Set the state to be reported in the Adjacency State field of the
    Point-to-Point Adjacency State option to down."

I believe after making this correction your concern about the state moving
from down to initialised as a result of receiving an ISH goes away.

ISHs received after the adjacency has been created are not a problem as
8.2.2b tells you to discard them. ISHs received after an adjacency is UP
should be ignored. This was never made explicit in the 1992 version. Much
clearer text can be found in 10589:2001 8.2.3

The issue you raise regarding adjacency state vs. 3way adjacency state can
be viewed as an implementation issue. There is nothing in the 3way draft
that requires that the state advertised in the TLV be identical to the value
of "adjacencyState" as defined in 10589. The latter is never directly
visible to the neighbor.

It can be argued that it would clearer/more intuitive if these states were
perfectly aligned. This would require some revisions to the 10589 text to
substitute "Down" for "Initialised" in some places. This should not break
anything because the 10589 state tables really depend on the notion of the
adjacency being "up or not up". But if not done carefully, there would
confusion introduced regarding the new use of state "Down" and
AdjacencyStateChange(Down) events. I do not object to this clarification in
principle - but I am not inclined to go to this trouble.

   Les

> From: Neal Castagnoli [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 6:23 PM
> To: 'Tony Przygienda'; Les Ginsberg

---

From: "Philip Christian" <[email-masked]>
Date: Fri, 7 Dec 2001 10:13:50 -0000

To be fair to Les, it was me that started the scare. I did misunderstand
what was going on, however it will hopefully result in a better RFC.

This text of Les'

Presumably this is to be added to what is already there in the draft, making
the complete text:-

"Add a clause e) to the end of section 8.2.3:

     The IS shall include the Point-to-Point Adjacency State option in
     the transmitted Point-to-Point IIH PDU.  The current state of the
     adjacency with its neighbor on the link (as defined in section
     8.2.4.1.1) shall be reported in the Adjacency State field.  If no
     adjacency exists, the state shall be reported as Down.

     The Extended Local Circuit ID field shall contain a value assigned
     by this IS when the circuit is created.  This value shall be unique
     among all the circuits of this Intermediate System.  The value is
     not necessarily related to that carried in the Local Circuit ID
     field of the IIH PDU.

     If the system ID and Extended Local Circuit ID of the neighboring
     system are known (in state Initializing or Up), the neighbor's
     system ID 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.

     Set the state to be reported in the Adjacency State field of the
     Point-to-Point Adjacency State option to Down."

Is that right?

Philip Christian.

    --- tony

---

From: Les Ginsberg <[email-masked]>
Date: Fri, 7 Dec 2001 13:24:22 -0800

As pointed out by Neal Castagnoli yesterday, the text I presented below
belongs in Section 8.2.2 Receiving ISH PDUs by an Intermediate System. This
was a section reference error on my part which I corrected based on Neal's
input.

The existing text in the 3 way draft which adds a new item (coincidentally
also "e)") still belongs in 8.2.3 Sending point-to-point IIH PDUs as is
currently indicated in the draft. 

   Les

-----Original Message-----
From: Philip Christian
To: 'Tony Przygienda'; Les Ginsberg
Cc: Rajesh Saluja; [email-masked]'; [email-masked]'
Sent: 12/7/01 2:13 AM
Subject: RE: [Isis-wg] Concerns with 3-way-handshake

This text of Les' 

Presumably this is to be added to what is already there in the draft,
making the complete text:- 

Is that right? 

Philip Christian. 

    --- tony