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

From: "Chan, Chung Ming" <[email-masked]>
Date: Sat, 9 Feb 2002 13:11:07 -1000

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

---

From: Shankar Vemulapalli <[email-masked]>
Date: Sun, 10 Feb 2002 17:57:19 -0800 (PST)

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

Thanks,

/Shankar

---

From: Jeff Learman <[email-masked]>
Date: Sun, 10 Feb 2002 23:37:07 -0500

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

---

From: "Ken Larmer" <[email-masked]>
Date: Mon, 11 Feb 2002 09:45:38 -0500

> I bet it was corrected in a TC.

	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.

	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?

Cheers,
Ken Larmer
CommSense Networks

---

From: Jeff Learman <[email-masked]>
Date: Mon, 11 Feb 2002 10:45:58 -0500

Note that I did not say that an IS need not send an ISH.  I said that
it should be able to bring up an adjacency without receiving one.

10589:1992, as amended by Cor. 1:1993, requires sending an ISH on a
point-to-point circuit "when the circuit is first enabled" (an
unfortunate choice of phrase; it should have said "when the link is
established").  However, implementations that don't follow TC1 might
not send an ISH, so it would be unwise to assume that every other
router will send one.  Furthermore, my interpretation of 10589 is
that any router that fails to bring up the adjacency if it does not
receive the ISH is not adhering to 10589 Section 8.2.2.

As I remember it (hazily), the reason for this particular change in TC1
was to avoid sending IIH PDUs on point-to-point links to end systems.
Sending an ISH first and waiting for an ISH before sending an IIH
prevented that, provided that the end system sends an ESH.  Note that,
even with TC1, if an IS receives an IIH, this is sufficient to
move the state machine forward towards bringing the adjacency up.

Sending the initial ISH is a good idea from the general rule "Be
strict in what you require of yourself and liberal in what you expect
of others."  Other than that general maxim, I don't know of any benefit
it provides when used on a link where one side or the other doesn't
support CLNP.

Note that the initial ISH can't be used to indicate a link or router
reset on an unreliable link, because it is legal to send the ISH
periodically.  According to a SONET Interoperability Forum (SIF)
agreement, it's not necessary to send the ISH periodically.  10589 is
ambiguous on this point.  On an unreliable link, the 3-way handshake
is needed to detect a router or link reset.

Bottom line, by my interpretation: an IS is required to send an ISH,
but it must not expect other routers to send one.

Regards,
Jeff

Disclaimer: I don't speak for Cisco.

---

From: Tony Li <[email-masked]>
Date: Mon, 11 Feb 2002 09:56:23 -0800

| 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: mike shand <[email-masked]>
Date: Tue, 12 Feb 2002 08:39:14 +0000

>end of a point-to-point link then decreases the numbers by another three

Yes. I think even in "the good old days" you could count the number of ESs 
on pt-pt links on one hand :-)

         Mike

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 11 Feb 2002 10:03:17 -0800

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

> networks) which were using Int IS-IS for these purposes.

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