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

From: "Ramalingam, Swaminathan" <[email-masked]>
Date: Mon, 11 Feb 2002 00:05:10 -0500

ISO 10589:2001 says still that on receipt of ISH PDU, a IS can create
adjacency with adj State "Init" and nbr Sys Type "unknown"

> -----Original Message-----
> From: Jeff Learman [mailto:[email-masked]]
> Sent: Monday, February 11, 2002 10:07 AM
> To: Shankar Vemulapalli
> Cc: Chan, Chung Ming; [email-masked]
> Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH
> 
> 
> At 08:57 PM 2/10/2002, Shankar Vemulapalli wrote:
> >*I believe* ISO10589 mentions that we need to send both IIH 
> and ISH packets
> >eventhough IIH packets are used to form the IS-IS 
> adjacencies.  I am not sure
> >on the implementation details of any vendor.
> >
> >At a high level I would assume that there wont' be any 
> implication if an IS
> >doesn't send any ISH as there is no any ES on a p2p 
> interface... But for sure
> >ISO 10589 may have a reason for IS to send ISH packets.
> 
> The reason ISO 10589 requires a router to send ISH packets is that it
> was written for OSI networking (CLNP/ESIS), and the ISH packet is how
> the end systems discover the router.  This reason does not apply to
> IS-IS when used for IP only.
> 
> Furthermore, receipt of an ISH should not be required to bring an
> IS-IS adjacency to the initializing or up states.  I don't have 10589
> handy, but I don't think it requires receipt of an ISH.  If it does,
> I bet it was corrected in a TC.
> 
> Regards,
> Jeff
> 
> Disclaimer: I have not worked on IS-IS at Cisco, and my opinions may
> not reflect those of my employer.
> 
> 
> >Thanks,
> >
> >/Shankar
> >
> >At 1:11pm 02/09/02 -1000, Chan, Chung Ming wrote:
> >> Hi,
> >>
> >>       I would like to find out that "On the p2p circuit, 
> should an IS go
> >> to Up State if a valid P2P IIH is received before 
> receiving any ISH?"
> >>       Apparently, one vendor's router in our lab, 
> ignore/does not rely on
> >> ISH for their p2p operation.
> >>       Would that be any implication of not using ISH for 
> bringing p2p link
> >> adj to up state?
> >>
> >>
> >> Thanks,
> >>
> >>
> >>
> >> Ming Chan
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> 
> _______________________________________________
> 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: Neal Castagnoli <[email-masked]>
Date: Mon, 11 Feb 2002 10:40:43 -0800

> I bet it was corrected in a TC.

Both 10589 and the second edition contain the text:

	c)	The first Point-to-point IIH PDU (i.e. that transmitted as a
result 
	      of receiving an ISH PDU, rather than as a result of timer 
	      expiration) 
                  . . .

but the second removes first edition text which compelled initial IIH
transmission at other times (for instance when the circuit first comes up).
Therefore, strict second edition implementations require receipt of an ISH
before transmitting an IIH.  (I think someone pointed out they changed this
in some ISO technical corrigendum or other.)

Incidentally, I'm not advocating this behavior, just reporting what the spec
sez.

  --Neal

---

From: "Philip Christian"<[email-masked]>
Date: Tue, 12 Feb 2002 10:19:48 -0000

> 
>  | Bottom line, by my interpretation: an IS is required to 
> send an ISH,
>  | but it must not expect other routers to send one.
> 
> 
> Minimalist viewpoint: the number of end systems out there is 
> vanishingly
> small and growing smaller by the day.  The thought of an end 
> system at the
> end of a point-to-point link then decreases the numbers by 
> another three
> orders of magnitude.
> 
> This seems like work that could be avoided without dire 
> consequences.  IS's
> that wanted to support this certainly could, but the rest of us don't
> really gain by it...
> 
> An RFC that said so would be a fine thing...
> 
> Tony
>

From draft-ietf-isis-3way-04.txt:-

"For example according to ISO 10589 [1] receipt of an
ISH will cause an adjacency to go to Initializing state; however
receipt of an ISH will have no effect on the three-way state of an
adjacency, which remains firmly Down until it receives an IIH from a
neighbor that contains the three-way handshaking option."

This so nearly makes the statement that you are looking for.  I feel that
there could/should? be an additional statement in there saying something
like

"Although ISO 10589 and RFC 1195 mandate the use of ISH PDUs, it has
generally been accepted within the industry that ISH PDUs are only needed
for connection to OSI End Systems, and therefore need to be supported
only by ISs that support CLNP forwarding.  Implementors should be aware
that ISs are already deployed that do not support CLNP forwarding and both
which do send ISH PDUs and which do not sent ISH PDUs.  Additionally ISO
10589 states that an adjacency MAY be created on receipt of an ISH or an IIH
and so an ISO 10589 compliant implementation SHOULD handle both scenarios.".

I would propose that as the three-way-handshake is a discussing adjacency
creation anyway, it is a good place to put something like this.

I think that I suggested this before, but I don't remember who agreed and
who disagreed :)

Philip.

---

From: "Philip Christian"<[email-masked]>
Date: Tue, 12 Feb 2002 14:44:04 -0000

As a relative newcomer, it took me a long time to realise that there are
implementations out there that do not send ISH, and others that do. It just
isn't stated anywhere except in the e-mails.

There is no point in arguing whether this is right or wrong, it can just be
stated as a fact (which it is).

A one page RFC stating that some implementations do this, and others do
that, and how one should deal with it would be very useful to other
newcomers
and would improve interop, I would have thought.

Maybe someone should write one.
Maybe I should write one.

The mandatory behaviour is not whether you send ISH or not, but is that you
have
to deal with either behaviour coming at you. This is what needs to be stated
(IMHO).

Philip

> From: Tony Przygienda [mailto:[email-masked]]
> Sent: 11 February 2002 18:03
> To: Ken Larmer
> Cc: Jeff Learman; Shankar Vemulapalli; Chan, Chung Ming;
> [email-masked]
> Ken Larmer wrote:
> >         I believe that we must be very careful when 
> providing advice from this
> > working group about implementing Int IS-IS in ways which do 
> not abide by
> > ISO-10589 and/or RFC-1195. An ISH is used by ISO-10589 for 
> many purposes
> > other than letting an ES know that it is connected to an 
> IS. An ISH is an
> > integral part of the PtP initialization process and it also 
> tells the IS
> > initializing if it is connected to another IS or an ES.
> >
> >         If an implementer does not properly take into 
> account the affects of not
> > receiving an ISH or transmitting an ISH, they could surely 
> end up with
> > scenarios where their implementation will not properly 
> initialize with
> > another vendor's product under all conceivable conditions. 
> May I suggest
> > that if there is a consensus that we do not need an ISH, we 
> modify the
> > specifications accordingly so that everyone implementing 
> Int IS-IS in
> > accordance with the appropriate specifications will possess 
> a better chance
> > of achieving full interoperability with other vendors 
> implementing Int IS-IS
> > in accordance with the same specifications.
> 
> as Tony stated and was said couple times before already, an 
> according RFC is being
> encouraged (but not as part of 3-way-hello preferrably since 
> it's a different
> problem/solution).
> 
> >         BTW, are we sure that we do not need to send ISH 
> PDUs? What about those
> > very few customer's who are using Integrated IS-IS as a 
> routing protocol to
> > forward both IP and CLNP packets. When I was at DEC in 
> another lifetime,
> > there were several customers (both core service providers 
> and enterprise
> > networks) which were using Int IS-IS for these purposes.
> >
> >         Just my thoughts?
> 
> It will be hard to reverse the course of history here. At 
> least 3 deployed implementations
> are skipping ISHs or working fine without (for IP only of 
> course). It is a more promising
> course of action to document that (and possible gotchas with 
> it), rather than tyring to
> enforce ISH processing ...
> 
>     thanks
> 
>     -- tony
>

---

From: "Martin, Christian" <[email-masked]>
Date: Tue, 12 Feb 2002 13:21:01 -0500

But, this
> is not conformant to the only written specification - so I 
> applaud Tony's
> call for an RFC which documents this protocol change. Perhaps 
> those who
> chose to ignore the spec would volunteer to write such an RFC??

If that is the direction that the group wishes to take, then there are a few
other "implementation" hacks that should be documented as well.  Externals
in L1 LSPs comes immediately to mind.  The protocol has been
enhanced/changed enough in recent years to warrant a compilation that
describes what is deployed in the field, IMHO.  1195 is becoming very
outdated - I mean it was published before 1209 - SMDS over IP!  Jeez...

chris

>    Les

---

From: mike shand <[email-masked]>
Date: Wed, 13 Feb 2002 13:09:52 +0000

At 12:53 13/02/2002 +0000, Philip Christian wrote:

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?

Its not that the router is acting as an ES (if it DID want to do
something strange like that it should be sending ESHs, but PLEASE not
both ISHs and ESHs).

The issue is that the router has an adjacent ES (over the pt-pt link).
The ES wants to see an ISH to know that it has a router adjacent to it).
It's no good just sending IIHs, since the ES just plain doesn't
understand them.

However, as has been pointed out before, this a fairly rare scenario, and
getting rarer by the minute.

Mike

---

From: "Philip Christian"<[email-masked]>
Date: Wed, 13 Feb 2002 13:15:23 -0000

So that explains why an OSI router needs to send ISH, as there might be an
ES that needs it.
It doesn't explain why an OSI router needs to process incoming ISH though.
Why is that in the standard?
 
Philip

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: 13 February 2002 13:10
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

The only other use for ISH seems to be if a router wants to 

Its not that the router is acting as an ES (if it DID want to do something
strange like that it should be sending ESHs, but PLEASE not both ISHs and
ESHs).

The issue is that the router has an adjacent ES (over the pt-pt link). The
ES wants to see an ISH to know that it has a router adjacent to it). It's no
good just sending IIHs, since the ES just plain doesn't understand them.

Mike

---

From: mike shand <[email-masked]>
Date: Wed, 13 Feb 2002 13:22:20 +0000

At 13:15 13/02/2002 +0000, Philip Christian wrote:

So
that explains why an OSI router needs to send ISH, as there might be an
ES that needs it.

It doesn't explain why an OSI router needs to process incoming ISH
though. Why is that in the standard?

Well the ORIGINAL idea was that an ES might get upset if it started
getting IIHs sent to it. So we only sent IIHs after we had established
that the neighbor was indeed a router (by receiving an ISH).

But that really doesn't apply any more, even if it ever did.

Mike

---

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

From ISO/IEC 10589:1992 8.2.3
"8.2.3 Sending point-to-point IIH PDUs
An IS shall send PointtoPoint IIH PDUs on those PointtoPoint circuits whose
externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the circuit is first enabled; or
b) whenever iSISHelloTimer expires"
 
In ISO/IEC 10589:2001 8.2.4 this becomes
"8.2.4 Sending point-to-point IIH PDUs
An IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits
whose externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the IS receives an ISH PDU
b) whenever iSISHelloTimer expires"
 
So, in neither case do the standards behave as per the original idea,
because you do send an IIH whenever the timer expires, whether you have
received an ISH or not, and so you will send IIHs to an OSI End System.
 
One interesting difference between the two is that under 1992 rules you sent
an IIH when the circuit is enabled, which would result in an adjacency
coming up immediately with or without ISHs, whereas, with the 2001 rules, if
you don't listen to ISHs then you might have to wait an entire
iSISHelloTimer interval before you see the other end.
 
At least that is my enterpretation of it.
 
I'd love to know the reasoning behind the change.
 
Philip

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: 13 February 2002 13:22
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

Well the ORIGINAL idea was that an ES might get upset if it started getting
IIHs sent to it. So we only sent IIHs after we had established that the
neighbor was indeed a router (by receiving an ISH).

        Mike

---

From: mike shand <[email-masked]>
Date: Wed, 13 Feb 2002 15:24:41 +0000

At 15:05 13/02/2002 +0000, Philip Christian wrote:

I'd
love to know the reasoning behind the change.

My guess is that there wasn't any reasoning at all, but that it happened
as an accident, when the full description of the use of ISHs was removed
and replaced by the second para in 8.2 which says

The IS shall operate the ISO  9542 protocol, shall be able to
receive ISO 9542 ISH PDUs from other ISs and shall store the information
so obtained in the adjacency database.

Probably the intention was that this included the sending of the initial
ISH, but the words at the beginning of 8.2.3 were fumbled so that it got
contradicted.

Note that there is a vestige of the original behaviour in bulllet (c) of
that para which says

The first pt-pt ISH PDU (i.e. that transmitted as a result of receiving
an ISH PDU,....)

However, I guess it says what it says, and we have to cut our cloth
accordingly.

Mike

historical note:- the words at the start of 8.2 were inserted when the
original DECnet spec was ISO'ised. It used to say

When a pt-pt router to router hello is required to be transmitted as
described in previous sections, it is constructed as follows...

and then proceeds with

a) the circuit type field shall be set... etc.

and of course the "previous sections" described sending an IIH
only after receiving an ISH.

But this is all history now.

:-)

---

From: Jeff Learman <[email-masked]>
Date: Wed, 13 Feb 2002 10:47:46 -0500

At 07:43 AM 2/13/2002, Philip Christian wrote:

>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?

First of all, I think it would be best to create an informational
RFC, alerting implementors to common practice.  That way, we avoid
legal vs. illegal, and simply describe behavior that an implementation
is recommended to be able to interoperate with.  In this way, we can
point out different interpretations of the spec, which is helpful
to implementors without creating a new spec and new contradictions.

Whether an informational RFC should contain a number of items or
whether there should be one per issue I leave to the others to hash
out -- evidently it's been hashed out a bit already.  I can see
pros and cons on both sides of that issue.

>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.

I agree, and therefore don't think it's necessary to specify anything.
We should focus on observable behavior, not internal models.  It's hard
to write a good spec without an internal model, so I'm not criticizing
10589 here.  But in this case, we don't need to exacerbate the problems
caused by specifying an internal model, we can just talk about behavior.
The hard work has already been done.

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

I assume that implementations that don't send ISH PDUs also don't wait
for a timer to expire, they just send the IIH when the circuit comes up,
so the adjacency would come up right away in either case.  Note that
10589:1992 says to send the IIH when the circuit is first enabled;
only 10589:1992+TC1:1993 says to wait to receive an ISH.  Some
implementations don't follow TC1, which clearly says when to send the
ISH.  Prior to that, there's only the implication that you wait to send
an IIH (in 8.2.3-c, renumbered to 8.2.4-c by TC1).

>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?

The only real purpose of the ISH is in case the system at the other end
supports CLNP but is not running IS-IS, such as when it's an ES.  Assuming
the OSI router's NSAP matches its NET (except for NSEL), then its network
service users are reachable without doing anything special.  Admittedly,
according to rule changes in TC1:1993, the ISH also serves the purpose of
starting the process to bring up the adjacency.  But this is unnecessary.
The only information in the ISH that is pertinent is "I'm a router!"

By the way, the ISH is neither necessary nor sufficient for handling
network service users on the OSI router, which is very important but
was ignored in a lot of the early OSI standards.  There are two cases:
(a) all NSAPs for the network service user matches the NET (except for
NSEL), and (b) there are NSAPs that don't match the NET.  Case (a) is
naturally handled by IS-IS, and the ISH isn't needed.  Case (b) isn't
covered in IS-IS, and you can't use ISH PDUs to solve it -- because
the ISH can only contain one NET, and it has to match the adjacency
so you can't just send a bunch of them.  This was resolved for SONET
NEs by the SIF; the router should advertise these as ES neighbors with
path costs of 1.  (I argued for zero, but that didn't go over because it
might have caused trouble with implementations that couldn't handle
zero metrics anywhere outside pseudonode LSPs.)  Hopefully we don't need
to go into that in an RFC!

>Sorry for so many questions. 

Sorry for such long answers ;-)

>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.

I think the thing to do is to state that prevalent implementations
do not send ISHs on PTP links, and that an implementation is advised to
bring up the adjacency anyway.  To do this, we must relax the rule in 10589:1992+TC1:1993 that does not permit sending an IIH until an ISH
has been received, and allow sending of the IIH when an IIH has been
received, or for systems where connections to OSI end systems over
PTP links are not supported, the IIH can be sent as soon as the link
is up.

I also think it may be appropriate to include a little history here,
showing how 19589:1992 could reasonably be interpreted to allow
sending IIHs before receiving ISHs, yet the rule in TC1 would not
interoperate with this interpretation.  (I think that TC1, while
well-intentioned, was unfortunately misworded.  It should have
allowed sending an IIH after receiving one.)

Regards,
Jeff

>Thoughts?

---

From: "Philip Christian"<[email-masked]>
Date: Wed, 13 Feb 2002 15:55:52 -0000

Yes of course. The conclusion is then:-
 
1. If you don't send ISHs, then it makes sense to send IIH instead as soon
as a circuit is enabled, as per 10589:1992.
 
2. If you don't process incoming ISHs, and, if the other end sends only ISH
upon circuit enable, then you might have to wait one iSISHelloTimer interval
before you see him.
 
3. If you follow 10589:1992+TC1 or 10589:2001 and only send ISH upon circuit
enable, then the you might have to wait for one iSISHelloTimer before he
sees you, but, if you follow 10589:1992 and send IIH upon circuit enable
then the other end is guaranteed to see you straight away.
 
These are simple facts that can be stated, along with the fact that there
are implementations out there which do not send ISHs.
 
I guess that I can start typing the draft now.
 
Philip

-----Original Message-----
From: Jeff Learman [mailto:[email-masked]]
Sent: 13 February 2002 15:14
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: Tony Przygienda; Micah Bartell; Les Ginsberg; 'Tony Li'; Ken Larmer;
Shankar Vemulapalli; Chan, Chung Ming; [email-masked]; 'Alex
Zinin'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

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?

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.

I think the thing to do is to state that prevalent implementations
do not send ISHs on PTP links, and that an implementation is advised to
bring up the adjacency anyway.  To do this, we must relax the rule in
10589:1992+TC1:1993 that does not permit sending an IIH until an ISH
has been received, and allow sending of the IIH when an IIH has been
received, or for systems where connections to OSI end systems over
PTP links are not supported, the IIH can be sent as soon as the link
is up.

Regards,
Jeff

Thoughts? 

Philip

---

From: "Philip Christian"<[email-masked]>
Date: Wed, 13 Feb 2002 18:25:30 -0000

Appologies for the re-send, it was too long for the list server.
Here is my first attempt:-

              Use of IS-IS ISH PDUs in IP Only Environments
                      <draft-ietf-isis-ish-00.txt>

1. Status of this Document

    This document is an Internet-Draft and is in full conformance with all
    provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering Task
    Force (IETF), its areas, and its working groups. Note that other groups
    may also distribute working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsolete by other documents at any
    time. It is inappropriate to use Internet-Drafts as reference material
    or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

2. Abstract

    This document describes how ISH PDUs are commonly used within the IS-IS
    protocol in IP Only environments for adjacency establishment over Point
    to Point circuits.
   
    The IS-IS protocol is specified in [2], with extensions for supporting
    IPv4 specified in [1].

3. The History of ISH

    The IS-IS protocol as defined in [2] and in [3] is intended for use
    with the Connectionless Network Service (CLNS).  Due to the extensible
    nature of IS-IS it was possible to extend IS-IS to provide an integrated
    routing protocol which is Integrated IS-IS as defined in [1].
Integrated
    IS-IS may now be used to route CLNP, IPv4 and IPv6 packets.

    As the original intent of RFC 1195[1] was to provide a routing protocol
    capable of routing both CLNP and IPv4 packets, all of the requirements
of [2]
    had to be retained.  This included the use of ISH PDUs, which are needed
to
    connect an OSI End System (ES) to an IS-IS router.  An ES is the OSI 
    equivalent to an IP host.

    For this reason RFC 1195 [1] states in section 5.1:-

      "On point-to-point links, the exchange of ISO 9542 ISHs (intermediate
      system Hellos) is used to initialize the link, and to allow each
      router to know if there is a router on the other end of the link,
      before IS-IS Hellos are exchanged. All routers implementing IS-IS
      (whether IP-only, OSI-only, or dual), if they have any interfaces on
      point-to-point links, must therefore be able to transmit ISO 9542
      ISHs on their point-to-point links."

    With time IP become the protocol of the Internet, and routers that could
    forward CLNP packets became increasingly rare.  The majority of
Integrated
    IS-IS routers were IP-only and thus incapable of forwarding traffic to
OSI
    ESs.

    Many router vendors decided that ISHs were no longer required, as
connection
    to an OSI ES was no longer a possibility, and did not implement
transmission
    ISHs on point-to-point links.  This did not create interoperability
    problems, as until 1993 ISO 10589 [2] stated that when a circuit is
first
    enabled, an IIH PDU would be sent.  The immediate transfer of IIHs 
    effectively made redundant the ISH that had just been sent.

    However in 1993 an update to ISO 10589 was made to ISO 10589 which
removed
    the immediate sending of IIH on enabling of a point-to-point circuit.
This
    behaviour somewhat re-instated the ISH, giving it a new purpose as
announcing
    the arrival of a router on the link in the absense of the immediate IIH.

    This new behaviour remains in the current Second Edition of ISO 10589
[3].

4. Deployed IS-IS and ISH

    There are commonly three behaviours that are already deployed.  These
are:-

    1. Routers that send ISH and IIH when a point-to-point circuit is
enabled.

    2. Routers that send only IIH when a point-to-point circuit is enabled.

    3. Routers that send ISH when a point-to-point circuit is enabled, and
then
       IIH some time later (when the iSISHelloTimer expires).

    This document does not specify which of these behaviours should be used,
    although an IS-IS router that can forward CLNP packets must clearly
follow
    1 or 3 corresponding to [1] or [2] respectively.

    This document advises that all three of these behaviours have been
deployed
    and so MUST be accomodated by any new implementation attempting to form
an
    adjacency with a deployed router.

    Another design decision is whether to receive and process ISH, or
whether to
    ignore them.  The consequence of ignoring ISH is that when connecting to
a
    deployed router with behaviour 3, the router may not be recognised until
    the iSISHelloTimer has expired.  This will only happen if the new router
    enables its point-to-point circuit before the existing router, resulting
in
    it missing the IIH from the new one.

    This is a seperate design decision to sending ISHs.  It is entirely
possible
    to have an implementation that receives and processes ISHs as per [2]
and [3],
    but which does not transmit them.

    Clearly an implementation that does not transmit ISHs MUST send an IIH
upon
    enabling of a point-to-point circuit, as per [2].

5. Security Considerations

    This document raises no new security issues for IS-IS.

6. References

    [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual
    Environments" RFC 1195, December 1990

    [2] ISO, "Intermediate System to Intermediate System Intra-
    Domain Routeing Exchange Protocol for use in Conjunction with the
    Protocol for Providing the Connectionless-mode Network Service (ISO
    8473)", ISO/IEC 10589:1992

    [3] ISO, "Intermediate System to Intermediate System Intra-
    Domain Routeing Exchange Protocol for use in Conjunction with the
    Protocol for Providing the Connectionless-mode Network Service (ISO
    8473)", ISO/IEC 10589:2001

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 13 Feb 2002 12:42:18 -0800

The original text in 10589:1992 8.2.3 caused confusion because it said to
send IIHs when "the circuit is first enabled". This suggested that there was
no need to wait for receipt of an ISH. This was not the intended behavior. A
Defect Report was filed in April of 1993 (JTC1/SC6/WG2/N523 - for those of
you lucky enough to have a vintage copy) in which this confusion was
discussed. My transcribed quote (no electronic copy I am afraid) reads:

"There seems to be a problem with the 10589 description of the
initialization of pt-pt circuits in clause 8.2. In ISO 9542 the IS starts
off by sending an ISH PDU and only when the IS has detected that the other
end is an IS (by receipt of its ISH PDU) should the IS start sending IIH
PDUs. In 10589 there seems to be an anomaly. 8.2.2 says what you do when you
receive an ISH, but nothing tells you to send them. 8.2.3 tells you to send
IIH PDUs all the time. It looks as if some attempt has been made to remove
the initial ISH exchange step, but it hasn't been completed. The standard
needs to specify that upon circuit initialization the IS sends an ISH PDU,
and sends IIH PDUs in response to receipt of ISH PDUs."

With that in mind, two changes were introduced (refer to 10589:2001 draft
for full text):
 
1)New section 8.2.3 was added to explicitly state that an ISH needed to be
sent when a point-point circuit was first enabled. Additional wording was
added to this section to clarify issues that arose in SIF a few years ago
regarding whether ISHs should continue to be periodically sent after an
adjacency was up.
 
2)8.2.4a (renumbered from 8.2.3.a in 1992 spec) was changed to indicate that
an IIH should be sent upon receipt of an ISH rather than when the circuit is
first enabled.
 
The issue that still seems to confuse some folks is 8.2.4b which says to
send IIHs when the "iSISHelloTimer expires". What is not explicity stated
(but sort of naturally falls out when you implement it (he said foolishly))
is that you don't start running the "iSISHelloTimer" until you send your
first IIH - which would come AFTER receiving an ISH. It might have been
clearer if some statement were explicutly made to say that the timer is not
started when the circuit is enabled - but I believe that was what is meant
both by the current and the original text.
 
I hope this at least clarifies the points raised below.

   Les

-----Original Message-----
From: Philip Christian [mailto:[email-masked]]
Sent: Wednesday, February 13, 2002 7:05 AM
To: 'mike shand'
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

 

 

 
Philip

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: 13 February 2002 13:22
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

        Mike

---

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

Les,
 
I also just read this in 10589:2001
 
"9.7 Point-to-point IS to IS hello PDU
This PDU is transmitted by Intermediate systems on
nonbroadcast circuits, after receiving an ISH PDU from the
neighbour system."
 
This would appear to back you up, but it really is a shame that it wasn't
more clearly stated.
 
I might not be very popular for saying this, but there does then appear to
be a fundamental incompatibility.
 
You have one router that conforms to 10589:2001 that will not send IIH until
it gets an ISH, and sits there sending out ISHs.
Then you have another that doesn't send ISHs and sits there waiting for an
IIH that never comes.
 
One thing that I still don't understand is this: if a 10589:2001
implementation receives an IIH but no ISH, does it still sit there
determined not to reply?
It would appear that it still has to perform the IIH acceptance tests,
doesn't it?
Will it actually bring up an adjacency and still not send an IIH back?
There seems to be a contradiction here.
 
We seem to have a choice here, either
 
1. Go against 10589:2001 and explicitly state that if you get an IIH then
you MUST send an IIH back and perform the IIH acceptance tests (plus three
way handshake if you both support). If we go against ISO and RFC 1195
(clarify ;-) ) then it needs to be very clearly stated that this is what is
happening.
 
or
 
2. Say that routers MUST send and receive/process ISHs, whether or not they
forward CLNP or not.
 
I think that only one of these actually guarantees interop.
 
There is the third option of course, make "1" AND "2" mandatory, which
upsets almost everyone but doubly guarantees interop. Now there's a thought.
 
Philip

-----Original Message-----
From: Les Ginsberg [mailto:[email-masked]]
Sent: 13 February 2002 20:42
To: Christian, Philip [HAL02:GI50:EXCH]; 'mike shand'
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

 

 

   Les

-----Original Message-----
From: Philip Christian [mailto:[email-masked]]
Sent: Wednesday, February 13, 2002 7:05 AM
To: 'mike shand'
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

 

 

 
Philip

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: 13 February 2002 13:22
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

        Mike

---

From: Neal Castagnoli <[email-masked]>
Date: Wed, 13 Feb 2002 14:00:04 -0800

Phil,

> 2. Say that routers MUST send and receive/process ISHs, whether or not
they 

I think the implementation that transmits the ISH until the adjacency is in
the "UP" state but that doesn't process received ISHs (transmitting IIHs
from the get-go) will interoperate even with strict 10589 version 2
implementations.

Not processing received ISHs removes most of the trouble of processing
another protocol, which would open up all the parsing issues and potential
bugs, etc.

  --Neal

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 13 Feb 2002 14:32:47 -0800

Philip -
 
The revisions in ISO 10589:2001 relevant to this topic were never intended
to "change" the way adjacency formation worked. Rather, they were intended
to clarify the original intent. In that context, it does not help to create
two sets of conformance criteria, one for 1992 compatibility and one for
2001 compatibility. Certainly, it is understandable that interpretations of
the text might differ. That is precisely why the language was altered - in
the hopes that the originally intended behavior would be better understood.
 
Now if you have two implementations and the understanding of the spec on the
part of the implementors differs in such a way that you end up with a
behavioral incompatibility, that is a real world problem that has to be
addressed. But please don't put us in the position of trying to maintain
compatibility to two different spec interpretations as if the protocol was
intentionally altered between 1992/2001 in an incompatible way. It wasn't.
 
More comments below.
 
  Les

-----Original Message-----
From: Philip Christian [mailto:[email-masked]]
Sent: Wednesday, February 13, 2002 1:44 PM
To: 'Les Ginsberg'; 'mike shand'; 'Dave Katz'; 'Jeff Learman'
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

Les,

 

You have one router that conforms to 10589:2001 that will not send IIH until
it gets an ISH, and sits there sending out ISHs.
Then you have another that doesn't send ISHs and sits there waiting for an
IIH that never comes.
[Les Ginsberg] 
Yes - this is the essence of the incompatibility - but it is NOT a
10589:2001 issue. In the IP world, some implementations simply don't send
ISHs - and therefore you can get into this deadlock unless the other end is
willing to start sending IIHs on receipt of an IIH even without an ISH. That
is precisely the issue which we are trying to clarify with a new RFC.

One thing that I still don't understand is this: if a 10589:2001
implementation receives an IIH but no ISH, does it still sit there
determined not to reply?
[Les Ginsberg]  Yes, a strictly conformant implementation would do that.
That is true of a strictly conformant 10589 implementation regardless of
spec vintage. Please do not wordsmith me here. Yes, the 1992 spec wasn't
worded as well as it might be - but I think there is clear historical
evidence for what was intended. 

 
 
or

I think that only one of these actually guarantees interop.
[Les Ginsberg] 
No. That is NOT necessary. All that is necessary is that an implementation
relax its requirements so that it will create an adjacency (in initialising
state) and start sending IIHs on receipt of an IIH even in the absence of an
ISH.

There is the third option of course, make "1" AND "2" mandatory, which
upsets almost everyone but doubly guarantees interop. Now there's a thought.
[Les Ginsberg] YOu are right - such a suggestion is likely to make you very
unpopular. 
 
Philip

-----Original Message-----
From: Les Ginsberg [mailto:[email-masked]]
Sent: 13 February 2002 20:42
To: Christian, Philip [HAL02:GI50:EXCH]; 'mike shand'
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

 

 

   Les

-----Original Message-----
From: Philip Christian [mailto:[email-masked]]
Sent: Wednesday, February 13, 2002 7:05 AM
To: 'mike shand'
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

 

 

 
Philip

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: 13 February 2002 13:22
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: [email-masked]'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

        Mike

---

From: mike shand <[email-masked]>
Date: Wed, 13 Feb 2002 22:53:33 +0000

There seems to be something funny happening with the list. I sent this 
reply nearly 6 hours ago, and I still haven't seen it on the list. I'm 
sending again in case that helps, but I apologize in advance if this 
results in a double posting when the original eventually arrives.

In any case Les appears to have said all I wanted to say anyway (and rather 
better:-).

         Mike

>I'd love to know the reasoning behind the change.

My guess is that there wasn't any reasoning at all, but that it happened as 
an accident, when the full description of the use of ISHs was removed and 
replaced by the second para in 8.2 which says

The IS shall operate the ISO  9542 protocol, shall be able to receive ISO 
9542 ISH PDUs from other ISs and shall store the information so obtained in 
the adjacency database.

The first pt-pt ISH PDU (i.e. that transmitted as a result of receiving an 
ISH PDU,....)

         Mike

and then proceeds with

and of course the "previous sections" described sending an IIH only after 
receiving an ISH.

:-)

---

From: Jeff Learman <[email-masked]>
Date: Wed, 13 Feb 2002 18:41:58 -0500

Well, once again I get to eat some humble pie.

Recently someone convinced me that an IS was not supposed to send
an IIH on receipt of an IIH, based on the text in 10589:1992
8.2.3 (2001 section 8.2.4), which says

  An IS shall send PTP IIH PDUs on those PTP circuits whose externalDomain
  attribute is set "False".  The IIH PDU shall be sent when:

  a) the circuit is first enabled [TC1 & 2001: the is receives an ISH]

  b) whenever iSISHelloTimer expires

It would have been helpful if this had also said:

  c) on receipt of an IIH pdu, in accordance with 8.2.4.2 [8.2.5.2]

Anyway, I've been on a wild tangent.  There should NOT be
an interoperability problem between systems that don't send
ISHs and those that follow 10598 explicitly (any version),
because on receipt of the IIH, the receiving system is required to
respond with an IIH.

Thanks to Micah who cleared this up for me.

Regards,
Jeff

>Date: Wed, 13 Feb 2002 16:14:23 -0500
>To: Micah Bartell <[email-masked]>
>From: Jeff Learman <[email-masked]>
>Cc: [email-masked]
>
>At 03:34 PM 2/13/2002, Micah Bartell wrote:
>>Alright....I went back and did a rehash of your doco and mine.  Integrated parts and made sure I got Dave's last comments addressed.
>>
>>At this point 10589:2001 is not a formal IS, so I would rather just reference 10589:1992 and RFC 1195.
>>
>>I would rather see a quick synopsis of what is required to be compliant than an explanation of the various implementations.  If you follow the BP for IIH and ISH handling, you will be compliant with all of the implementations.
>>
>>I think the point here is to identify where the issue is, RFC 1195 section 5.1 and 10589 Section 8.2.4.  Why it says what it does, when we do not need to strictly adhere, and in what manner we do not need to adhere.
>>
>>/mpb
>>
>>
>>
>>              IS-IS Adjacency Establishment in IP Only Environments
>>                     <draft-ietf-isis-ipadj-00.txt>
>>
>>
>>   This document describes a modification to the IS-IS protocol in IP Only
>>   environments for adjacency establishment over Point to Point circuits.
>>   This draft describes a modification to the IS-IS protocol, which will
>>   allow an IS-IS adjacency to be established over Point to Point circuits
>>   without the use of an Intermediate System Hello PDU (ISH).
>>
>>3. Introduction
>>
>>   The IS-IS protocol as defined in [2] was intended for use with the
>>   Connectionless Network Service (CLNS).  The extensible nature of IS-IS
>>   enabled IS-IS to be extended to provide multiprotocol support in an
>>   integrated routing protocol, Integrated IS-IS, as defined in [1].
>>   Integrated IS-IS now supports reachability information for CLNS, IPv4,
>>   and IPv6.
>>
>>   The original intent of [1] was to provide a routing protocol capable
>>   of handling both CLNS and IPv4 reachability information.
>
>
>
>>                                                             The need to
>>   support CLNS reachability information required that an ISH be issued
>>   to detect End Systems (ES) and initiate the formation of an ES-IS
>>   adjacency.
>
>Not quite.  You don't send an ISH to detect an ES.  You send an ISH so
>that the ES knows you're a router (if it is an ES) and the *ES* forms
>an ES-IS adjacency.  I would revise this to say,
>
>     To support the possibility of a CLNS ES attached on a PTP link,
>     ISs are required to send ISH PDUs, and are not to send IIH PDUs
>     before receiving an ISH from the peer.
>
>>   For this reason section 5.1 of [1] states:
>>
>>   Section 5.1 of [1] re-enforces the need to comply with section 8.2.4
>>   of [2].
>
>See note below about TC1.
>
>>This requirement was defined when the industry mindset was
>>   that of dual environments being the general case.  The general case
>>   has instead shifted to IP Only environments.
>
>I don't think we need to talk about mindset, and there are members of
>this list who consider dual environments very important.  All you need
>is to begin the next sentence with "However,".
>
>>   In an IP Only environment, there is no need to issue an ISH PDU over a
>>   Point to Point circuit because there are no End Systems with which to
>>   form an ES-IS adjacency.
>
>
>>[2] requires that an ISH be received in order
>>   to issue an IIH PDU.
>
>This is inaccurate unless you specify [2] as including TC1.
>10589:1992 says, in 8.2.3 (renumbered by TC1 as 8.2.4)
>
>  The IIH PDU shall be sent when:  a) the circuit is first enabled.
>
>It would be more accurate to say that [2] allows sending the IIH first, but
>this was a mistake that was corrected in [3], and is now being allowed
>again in certain circumstances.
>
>   8473) Technical Corrigendum 1", ISO/IEC 10589:1992 TC1, May 1993.
>
>Plus, you would need to change [2] in text below to [3].
>
>>4. Best Common Practice
>>
>>   An IP Only implementation has no need to issue an ISH PDU as described in
>>   section 8.2.4 of [2].  An IP Only implementation MAY issue an IIH PDU
>>   when a Point to Point circuit transitions into an "Up" state to
>>   initiate the formation of an IS-IS adjacency.  An IP Only implementation
>>   SHOULD accept an IIH to initialize an adjacency regardless of an ISH
>>   having been issued.  The IIH PDU SHOULD still be issued in conformance
>>   with section 8.2.4 of [2] with the exception of the requirement for
>>   reception of an ISH PDU.
>>
>>   An implementation that supports the forwarding of CLNS PDU's MUST act in
>>   full accordance with section 8.2.4 of [2] when CLNS functionality is
>>   enabled, including the initial issuance of an ISH PDU.
>
>An implementation that supports CLNP should be allowed to send an IIH
>after receiving one, but this is not permitted by [3].  After receiving
>the IIH, we know that the neighbor is clearly an IS, so there is no
>need to wait for an ESH or ISH.
>
>I would say:
>
>    An implementation that does not support attachments to CLNP End
>    Systems via PTP links MAY send an IIH without waiting for an ISH,
>    and MAY omit sending an ISH.
>
>    An implementation that does support attachments to CLNP End
>    Systems via PTP links MUST send an ISH when a PTP circuit is
>    established, and MAY send an IIH after receiving an IIH on the
>    link.
>

---

From: Jeff Parker <[email-masked]>
Date: Wed, 13 Feb 2002 18:55:53 -0500

Good start.  Some suggestions below.  

>     The original intent of [1] was to provide a routing 
> protocol capable of handling both CLNS and IPv4 reachability 
> information.  

"Original Intent" suggests that the reference will be 10589
or some earlier DECNet document.  Perhaps

	"The changes to 10589 [3] that were proposed in RFC 1195 [1] 
	 were designed to provide....."

> To support
>     the possibility of a CLNS ES attached on a point to point 
> link, ISs
>     are required to send ISH PDUs, and are not to send IIH PDUs before
>     receiving an ISH from the peer.

Perhaps this would flow more naturally if you started with the
ISO host/client protocol.  Second, I don't think this was special to
p2p - I think ISO had the same behavior on LANs.

>     section 8.2.4 of [3].  An IP Only implementation MAY 
> issue an IIH PDU
>     when a Point to Point circuit transitions into an "Up" 
> state to initiate
>     the formation of an IS-IS adjacency.  

Do you need to qualify this?  Why not just say that an IP Only
implementation MAY send an IIH whenever it is enabled on a link.
I think trying to overspecify may have created the problem we see.

I'd suggest these items be bullets as well.

> The IIH PDU SHOULD still be issued
>     in conformance with section 8.2.4 [3] with the exception of the
>     requirement for reception of an ISH PDU.  

Should we spell out what 8.2.4 says?  

> An IIH PDU MAY 
> be issued in
>     response to the receipt of an IIH PDU in accordance with section 
> 8.2.5.2 [3].

>     A multiprotocol IS that supports the attachment of CLNS 
> ESs over Point
>     to Point circuits MUST act in accordance with section 
> 8.2.2 [3] when
>     CLNS functionality is enabled.

Perhaps you just want to say that it

	"A multiprotocol IS that supports the attachment of CLNS 
	ESs  MUST generaate ISH hellos in accordance with section 	
	8.2.2 [3] ..."

- jeff parker

---

From: Jeff Learman <[email-masked]>
Date: Wed, 13 Feb 2002 19:23:51 -0500

>p2p - I think ISO had the same behavior on LANs.

Not exactly, LANs are different.  You send an ISH in order to support ESs,
but you don't wait to get an ISH before sending an IIH because it's
sent to the ISIS multicast address.

Jeff

---

From: Jeff Parker <[email-masked]>
Date: Wed, 13 Feb 2002 19:29:05 -0500

> sent to the ISIS multicast address.

Jeff -
	I'm just suggesting that Micah's text reads more clearly
without the qualification to P2P.  For example:

	"IS-IS Routers send ISH Hellos to allow Endstations to locate
routers."

That is why they do it.  Then he can go on to suggest that they
need not wait to send out an IIH on P2P.

We may want to reference the Finite State Machines and the prose,
but right now he is trying to describe why these things exist.  

- jeff parker

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 13 Feb 2002 16:54:47 -0800

> 
> 
> Folks,
> 
> Alright, I think we are almost in agreement now....any 
> further thoughts?  I 
> took advantage of this draft to point out that 10589 does 
> allow an IIH to 
> be sent in response to an IIH even without an ISH, as it is a 
> bit hidden in 
> section 8.2.5.2 in the state tables.  I also made the point 
> that if CLNS ES 
> attachment is supported by the IS over p-t-p circuits, they 
> must continue 
> to conform to 8.2.3 ( 10589/TC1 ).
> 
> /mpb
> 

Well, that's an interesting find - and yet another point of confusion since
there is no place in 10589 that specifies CREATING an adjacency as a result
of receiving an IIH, which would seem to be necessary to determine what the
"neighbourSystemType" is. And clearly, if we are supposed to send IIHs in
response to receiving one(in some situations), then some such verbiage
should have been added to 8.2.4.

My preference is to not try to use 8.2.5.2 as a reference here since there
is ambiguity. (In any case it is actually the state tables that specify
sending the IIH, not the text body). Let's just admit that the problem comes
about because some implementations require an ISH to be received before
creating an adjacency and since some IP only implementations don't send ISHs
we need to specify that an adjacency can be created as a result of receiving
an IIH and we can then initiate sending IIHs if we have not already.

I will try to wordsmith this when I have more time - unless somebody beats
me to it.

   Les

---

From: "Philip Christian"<[email-masked]>
Date: Thu, 14 Feb 2002 11:23:23 -0000

My text has come out a little differently to Micah's.

The main difference is that it acknowledges the existance of implementations
that will not form an adjacency unless they receive an ISH.  One can argue
whether such behaviour is right or wrong, but that would be missing the
point.  From e-mails that I have had, it would appear that such
implementations are "out there", and this text deals with it.

However, I have not had any hard evidence that such an implementation has
been deployed, only e-mails saying that it is valid to do it that way (which
would suggest that folks have deployed it).  If in fact no one has deployed
an IP-capable router that behaves that way, then there is no point in
specifying how to interwork with it, and my text would them become very
similar to Micah's. An e-mail from someone saying "yes, I have seen that in
the field" would be nice.

It would certainly appear that implementations are "out there" that do not
sent ISHs.

I believe that it does not matter how OSI-only implementations might act
(read SONET/SDH ADMs), as anything that can forward CLNP (dual or OSI-only)
will naturally send ISHs anyway.  However if one is going to upgrade a
SONET/SDH ADM to make it dual, then one had better make sure that IIHs with
no ISHs will bring up the adjacency.

The aim of this doc to provide information to those who want to interop with
everything that exists, not to say who is wrong or right.

I hope that this helps.

Philip

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

2. Abstract

    This document suggests best practise to guarantee interoperability
    with all deployed implementations.

3. The History of the ISH PDU

    The IS-IS protocol as defined in [2] is intended for use with the
    Connectionless Network Service (CLNS).  Due to the extensible nature of
IS-IS
    it was possible to extend IS-IS to provide an integrated routing
protocol
    which is Integrated IS-IS as defined in [1].  Integrated IS-IS may now
be used
    to route CLNP, IPv4 and IPv6 packets.

    Thus RFC 1195 [1] states in section 5.1:-

    For many years there have been different opinions on what the exact
purpose of
    ISH PDUs.

    One opinion is that ISH PDUs are there purely for connection to OSI ESs.
    Taken to its logical conclusion, this results an implementations that do
not
    support forwarding of CLNP packets not sending ISH PDUs either.

    An alternative opinion is that ISH PDUs are an integral part of the
IS-IS
    router to router adjacency formation process.  This approach is
reflected in
    later versions of ISO/IEC 10589.  Taken to its logical conclusion this
results
    in implementations that will not form an adjacency unless an ISH is
received.

    The unfortunate outcome is the possibility of one implementation that
does not
    send ISH PDUs over a point-to-point link becoming connected to an
alternative
    implementation that will not form an adjacency unless it receives an
ISH.

4. Deployed IS-IS and best practice

    Given that later versions of ISO/IEC 10589 have been enterpreted as
stating
    that no adjacency will be formed until an ISH is received, the only way
to
    initiate an adjacency with a resultant implementation is to actually
send
    an ISH.

    Therefore if interoperability is wanted with such implementations, then
an
    IS-IS router SHOULD send an ISH PDUs over a point-to-point circuit
whenever
    the circuit is first enabled, and periodically whenever a circuit is
Down,
    whether or not the router can forward CLNP packets.

    Given that earlier versions of ISO/IEC 10589 have been enterpreted as
stating
    that ISH PDUs are not required if CLNP forwarding is not supported, then
the
    only way to initiate an adjacency with a resultant implementation is to
accept
    IIH PDUs in lieu of ISH PDUs.

    Therefore if interoperability is wanted with such implementations, then
an
    IS-IS router SHOULD create an adjacency with adjacencyState
"Initialising" and
    send a point-to-point IIH PDU if it receives an IIH PDU and no adjacency
    already exists.

6. References

---

From: "Philip Christian"<[email-masked]>
Date: Thu, 14 Feb 2002 22:08:03 -0000

Sorry, but that was not what I said.
 
I said that in the SONET/SDH world people might still want to connect OSI
End Systems over a point-to-point link to an OSI router (and ADM).
That's all it is.
My point was that OSI End Systems are not useless, and you might actually
want to use one in a SONET/SDH DCC channel.
 
This is useful because you can use an ES to terminate CLNP packets that
happen to contain IP inside them using RFC 3147, which are then forwarded to
a seperate IP stack in the ADM.
 
This is not connecting an OSI End System to an IP-only router.
IP-only routers cannot forward CLNP packets, and so are useless to an OSI
End System. ES-IS might come up, but any CLNP packets just won't get
through.
 
Philip

as Philip pointed out, this is not simply a concern for a Dual-IS or an
OSI-Only IS, it will also impact an IP-Only IS's capability to communicate
properly with an OSI ES which uses IP as its data transport mechanism.

---

From: "Philip Christian"<[email-masked]>
Date: Fri, 15 Feb 2002 15:50:22 -0000

Ahh! I think that I know what Ken means.

I think that the suggestion is that if you have dual routers (IP and CLNP),
then, why not manage them using OSI based management tools, instead of IP
ones.

The advantage would be that it would be hard to hack them as CLNP doesn't
get routed by the Internet, and know-one out there has the tools.

Security by obscurity!

I too have been thinking that SONET/SDH network operators might be opening a
whole security can of worms by asking for a shift from CLNS management to IP
management, but they do want IP comms, hence the current ITU-T activity in
the area.

If you want to manage the routers with CLNS tools, then, all of the routers
in the area have to be dual, and therefore all of them will be sending ISH
anyway, so this whole discussion is irrelevant to this particular scenario.

Unless.... unless you want to cheat and break the topological rules of RFC
1195.  You might do this if you think that CLNP will never get routed to a
particular bit of your IS-IS area, then, you might cheat and actually put an
IP-only router there.  It might not send ISHs, and so the neighbouring dual
router had better accept IIH in lieu of the ISHs.

Philip

> From: Ken Larmer [mailto:[email-masked]]
> Sent: 15 February 2002 15:29
> To: Dave Katz
> Cc: Christian, Philip [HAL02:GI50:EXCH]; [email-masked]
> > 	   Dave, how does an IP-only IS form an adjacency with an
> > OSI-ES over a PtP
> >    link if it does not use the ESIS protocol (other than 
> the use of static
> >    routes which are always present)? Remember, these are very
> > specific cases we
> >    are talking about here with use of an OSI-ES in this 
> scenario. I am not
> >    saying that there are not other methods of accomplishing 
> this same
> >    capability through use of different mechanisms.
> >
> > It doesn't.  Why would it?  It's an IP host with default route
> > pointing at the point-to-point link, or if you're really lucky it is
> > smart enough to listen to the router discovery protocol.  The fact
> > that it speaks OSI takes up memory in the system but is otherwise
> > interesting.  The router by definition won't forward its 
> CLNP packets
> > anyhow.  There are well-known IP mechanisms for accomplishing this
> > stuff.
> 
> OK! Just one final point and then I'll stop my crusade.
> 
> I realize that given today's technological advances in the IP 
> arena, this
> makes no sense. But, given the time and need, this sort of 
> configuration did
> make sense. A DECnet Phase V ES possesses the capabilities to 
> transport its
> data via CLNP and/or IP. Given that scenario and the fact 
> that one of the
> first Integrated IS-IS routers released was OSI based and not 
> IP based,
> would it not make sense to possess the above capabilities for remote
> management purposes. Especially if you had a mix of OSI and 
> IP based IS
> routers in your network domain.
> 
> Dave, I am not trying to create a stink here! I am simply 
> trying to point
> out some network configurations (tier 1, large enterprise and 
> significantly
> complex and large banking networks) I am very familiar with 
> that have used
> this mechanism for remote management in the past.
> 
> I believe fixing something which (IMHO) is not broken can lead to
> limitations in the protocol which may impact a particular 
> customer's ability
> to upgrade with out reconfiguring their entire network management
> infrastructure. Of course, there is the other side to this 
> coin, how long do
> we provide backward compatibility for networks which MAY be out dated?
> 
> OK, time to fade away... :^)
> 
> Cheers,
> Ken Larmer
> CommSense Networks
> 
>

---

From: Jeff Learman <[email-masked]>
Date: Wed, 13 Feb 2002 10:13:35 -0500

Regards,
Jeff