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

From: "Philip Christian" <[email-masked]>
Date: Tue, 4 Dec 2001 17:34:22 -0000

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: Tony Li <[email-masked]>
Date: Tue, 4 Dec 2001 10:40:30 -0800

| 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

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 04 Dec 2001 10:15:38 -0800

Philip Christian wrote:

>
>
> 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.
>
> (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:
>
> 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".
> 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.

funny enough, I know that multiple vendors shortcut ISHs since a while
and I stated in some conversations that I'm concerned. Since I could not
prove the specific problem that would cause (since IIHs will bring the
adjacency anyway), it was dismissed with a shrug.

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

---

From: Naiming Shen <[email-masked]>
Date: Tue, 04 Dec 2001 11:41:37 -0800

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

- Naiming

---

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

>thus, IS-IS is running in-band.

In addition, the draft addresses running IS-IS over an unreliable
point-to-point link level protocol, whereas 10598 states that a
reliable link is required.  I believe the draft states this to
be the case (at least, the author promised me it would!)

I agree with the recommendation.  While the three-way handshake
is superfluous on a reliable link, it should be permitted.  If I
remember correctly, it could be used for a related purpose -- 
a larger circuit ID or something.

Regards,
Jeff

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 04 Dec 2001 16:35:19 -0800

Rajesh Saluja wrote:

> 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

---

From: Dave Katz <[email-masked]>
Date: Tue, 4 Dec 2001 22:10:37 -0800 (PST)

Sounds reasonable.

   2. Reword SONET protection to SONET reprovisioning.

This is *not* what was intended when the draft was written.

SONET purists will choke on their Cheerios when they read this, but several
router vendors have implemented a scheme where two routers act together
as a SONET ADM for the purposes of implementing Automatic Protection
Switching (APS.)  The idea is that the trunk circuit comes into a POP,
hits an ADM, and out the other side come the APS Working and Protect
circuits, which then go into different routers.  This is primarily viewed
as a way of protecting against router/interface failure or somebody
tripping over the last 100 feet of fiber, while keeping the expensive
trunk circuit operating.  The routers coordinate via a back channel
to instigate and react to APS signalling (via the K1/K2 overhead bytes.)

In 1+1 Bidirectional mode, the ADM will send the same bit stream to both
routers, but only listen to one of them.  Without the addition of the
ID stuff, it is theoretically possible that the router on the circuit
not selected by the ADM can think that it has an adjacency to the guy
at the far end of the trunk, which would cause traffic to be poured down
a black hole.

Frankly, I think this bastardization of APS is of dubious use, but the
customers were willing to pay real cash money for it, so I wrote the
APS code.  However, it became apparent that a sane (if that's a
reasonable word to use in this context) implementation will logically
shut down the interface based on APS signalling anyhow, so this
detection mechanism is probably redundant, unless folks have come up
with something else that it is good for.

In any case, this is *not* about DCC, and it is *not* about SONET
provisioning, it's about terminating APS protection on routers running
ISIS in-band over the SONET circuit.

   3. Allowing length of option from 1 (not 5) to 17 octets so that it can work
   with old three way implementations.

Sure.

--Dave

BTW, for what it's worth, the dominant CLNP router in the world did
not couple ISHs to ISIS at all when I last saw the source code (five
years ago) and probably still doesn't today.  It is just as happy to
bring up an ISIS adjacency based on receipt of only an IIH when
operating in CLNP mode as it is in IP mode.  Doesn't make it right,
but there it is.

---

From: "Rajesh Saluja" <[email-masked]>
Date: Tue, 04 Dec 2001 19:33:21 -0500

If that's the case, I can add these and submit version 0.4.

Best regards,
Rajesh

---

From: Dave Katz <[email-masked]>
Date: Mon, 17 Dec 2001 14:40:12 -0800 (PST)

Hm, another old message.  Something got unstuck somewhere.

   From: "Rajesh Saluja" <[email-masked]>
   X-Accept-Language: en
   CC: "Philip Christian" <[email-masked]>,
      "[email-masked]'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>,
      "Rajesh Saluja" <[email-masked]>
   Content-Type: text/plain; charset=us-ascii
   X-Orig: <[email-masked]>
   Sender: [email-masked]
   X-BeenThere: [email-masked]
   X-Mailman-Version: 2.0rc1
   Precedence: bulk
   List-Help: <mailto:[email-masked]?subject=help>
   List-Post: <mailto:[email-masked]>
   List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=subscribe>
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=unsubscribe>
   List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
   Date: Tue, 04 Dec 2001 19:33:21 -0500

   Best regards,
   Rajesh