Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

From: "Philip Christian"<[email-masked]>
Date: Wed, 13 Feb 2002 12:53:21 -0000

So I have been thinking a little about the wording of a 
document to describe the situation/history with ISHs and to 
mandate that an implementation must be able to cope with ISHs 
or lack of ISHs.

I have hit a problem.

I assume that there are implementations out there that simply 
totally ignore incoming ISHs, and actually do nothing until 
they receive an IIH.  Would this be considerred legal or 
illegal behaviour in the doc that I am thinking of drafting?

According to 10589 the action on receipt of an ISH is that a 
new adjacency is created with adjacencyState "Initialising" 
and an IIH PDU is sent. As the IIH would be sent anyway 
whenever ISISHelloTimer expires, then there are maybe two 
consequences:-

1. The adjacency going to "Initialising", which one could 
argue is a non-event, as an adjacency that is "Initialising" 
cannot be used for anything, and the state will be ignored 
when an IIH finally comes along anyway.

2. Does it mean that the adjacency might come up faster as it 
doesn't have to wait for a ISISHelloTimer to timeout?

The only other use for ISH seems to be if a router wants to 
act as an OSI End-System for some reason.  I haven't quite 
figured out why/when/if an OSI router needs to also have 
End-System functionality, unless it is something to do with 
OSI redirects.  It would seem to me that if a router needs to 
have ES functionality is could attach it to itself rather 
than to its neighbour.  What am I missing here?  Why can't 
you have an OSI router that is only an IS, and, if so why 
does it need to worry about ISHs?

Sorry for so many questions.

Anyhow, we are going to have a choice; either we say that it 
is OK to just ignore incoming ISHs, or we say that we must 
work if they are not there but if they are then they must be 
processed.

Thoughts?

Philip

---

From: Dave Katz <[email-masked]>
Date: Wed, 13 Feb 2002 11:08:08 -0800 (PST)

Yes, and hopefully legal, or the doc is already pointless.

Angels are dancing on pins, I think.  ;-)

The creation of an adjacency on the receipt of an ISH is essentially
meaningless, since it is not reflected in any outgoing IIH (as the IS
type is not yet known) and so the "black box" test fails as there is
no way to know that it happened, except by network management.

The only function of the ISH in this case is to create the effectively
null adjacency, because the verbiage in 10589 sort of hints that you're
not supposed to create one on receipt of an IIH (though it doesn't
explicitly say to ignore it, as far as I can see.)

As for when IIHs are sent and not sent, this is effectively
non-normative as well, since (a) the protocol would be correct even if
IIHs were sent *only* on timers, though it would be slow to respond in
some cases, and (b) there is no time-based acceptance criteria on
IIHs, which means that you can send them any time you want and the
protocol will still work.  You never have to wait to send a hello
(except for the overly restrictive requirement that you not send more
than 1pps, which itself is unenforcable.)

You need ES functionality for network management (CMIP and TP4) if
you were going to be a full-blown OSI router, the Tucker Torpedo of
the networking world.  Otherwise, the ISH serves no purpose at all.

As far as I can tell, there is no practical difference between these
two choices.

What all this boils down to is that if an implementation is
excessively pedantic and will not create an adjacency on receipt of an
IIH with no preceding ISH, it will not interoperate with an
implementation that does not send ISHs.  I think that all we need to
say is that an implementation must create an adjacency in response to
a received IIH if none exists, and leave it at that.  This is backward
compatible with any behavior (or non-behavior) around the receipt of
ISHs, and so nothing needs to be said about that, except to provide
context.

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

---

From: Tony Li <[email-masked]>
Date: Wed, 13 Feb 2002 12:57:52 -0800

| What all this boils down to is that if an implementation is
 | excessively pedantic and will not create an adjacency on receipt of an
 | IIH with no preceding ISH, it will not interoperate with an
 | implementation that does not send ISHs.  I think that all we need to
 | say is that an implementation must create an adjacency in response to
 | a received IIH if none exists, and leave it at that.  This is backward
 | compatible with any behavior (or non-behavior) around the receipt of
 | ISHs, and so nothing needs to be said about that, except to provide
 | context.

Amen.

Tony

---

From: "Ken Larmer" <[email-masked]>
Date: Thu, 14 Feb 2002 10:36:48 -0500

> the networking world.  Otherwise, the ISH serves no purpose at all.

	I have hesitated to mention this in a public forum because this practice
may still be in use in some networks? But I believe if we take efforts on
this list, which do not take the following possible scenario into account,
we may unknowingly break current network implementations when they are
upgraded with code which may not fully abide by ISO-10589. Though, I must
state this is fairly unlikely given the evaluation of networks and network
security over the past years. Let me explain below:

	One could perceive of a scenario where a network is configured with its
primary management path being an in-band (Telnet, SNMP, CMIP...). Say that
path gets broken. Well, there could be a highly secure out-of-band backup
path for recovery which may also serve as a primary path for software
upgrades. The security advantages of being able to connect an ES only
implementation directly to an IS are considerable in my opinion.

Cheers,
Ken Larmer
CommSense Networks