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

From: "Philip Christian"<[email-masked]>
Date: Thu, 14 Feb 2002 19:34:41 -0000

I think that if you can forward CLNP packets, then it is pretty clear that
you MUST conform with ISO 10589, and therefore MUST send ISHs, and MUST be
able to connect to ESs.

Hence the whole issue of whether you send ISH or not, and what you do if you
don't receive one, is simply irrelevant to routers that support CLNP
forwarding.

It really is only a problem for IP-only routers, and maybe a dual router
that might get connected to an IP-only router and thus not receive an ISH.
A dual router connected to a dual router will always receive an ISH as the
other end will have to send one in order to connect to ESs anyway.

Also in the SONET/SDH world it is quite possible that someone might make
their SONET/SDH ADM (Add Drop Multiplexer) an ES.
For example if you have an IP managed ADM then you might think that ES only
functionality is all that is needed to terminate RFC 3147 encapsulated IP
packets for example.

In this case your ADM (an ES) would be connected to some other ADM (an IS)
across an embedded DCC link, which is a point-to-point link, and the
point-to-point ISH is clearly needed.

Philip.

> -----Original Message-----
> From: Ken Larmer [mailto:[email-masked]]
> Sent: 14 February 2002 15:37
> To: Dave Katz; 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
> >    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?
> >
> > 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.
> 
> 	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
> 
>

---

From: "Ken Larmer" <[email-masked]>
Date: Thu, 14 Feb 2002 15:51:49 -0500

RE: [Isis-wg] Question on the usage of ISH and P2PIIH
  I think that if you can forward CLNP packets, then it is pretty clear that
you MUST conform with ISO 10589, and therefore MUST send ISHs, and MUST be
able to connect to ESs.
  Hence the whole issue of whether you send ISH or not, and what you do if
you don't receive one, is simply irrelevant to routers that support CLNP
forwarding.

  For example if you have an IP managed ADM then you might think that ES
only functionality is all that is needed to terminate RFC 3147 encapsulated
IP packets for example.

   Philip.

    Yes, that was my original point. It is possible to have an OSI ES
connected to a Dual-IS, which uses CLNP and/or IP as its data transport
mechanism.  In addition, it is also possible to have an OSI ES connected to
an IP-Only IS, which uses IP as its data transport mechanism and NOT CLNP.
Consequently, 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.

    This leads to a larger point. While I believe, as others do on this
list, that ISO-10589 in combination with RFC-1195 are very well thought out
specifications for a Link State IGP, they both (IMHO) fall short in their
explanation of why they do certain things the way they do. As a consequence,
it may appear harmless on the surface to remove and/or ignore certain
sections from either specification, but in practicality it may not be the
smartest thing to do unless you fully understand the ramifications of your
actions.

Cheers,
Ken Larmer
CommSense Networks

---

From: Dave Katz <[email-masked]>
Date: Thu, 14 Feb 2002 12:59:56 -0800 (PST)

This makes no sense at all.  If the IS is IP-only, the fact that the
ES is OSI-capable makes no difference to anyone, and the ES will be
acting as an IP host and using IP mechanisms, and the ISH would serve
no purpose.

I'm kind of at a loss as to why this issue is so hard to codify.  It
seems simple to me: IP-only ISs may not send ISHs, so all ISs should
be prepared to create an ISIS adjacency based only on the receipt of
an IIH, which most of them probably already would do anyhow.
The use of ISHs is of no functional use in non-OSI routers, and
only adds code and complexity.

This is universally true of routing protocol specs.  I think OSPF is
even worse in this respect, as it is inherently more complex, and
breaks easily if you don't follow the rules exactly.  (But as a
knowledgable implementor, it gives me a competitive edge.)  FWIW, I
was not a signficant contributor to either spec, so it's not my fault.  ;-)

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

---

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

> From: Dave Katz [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 4:00 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH
>
>

	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.

Ken

---

From: Dave Katz <[email-masked]>
Date: Thu, 14 Feb 2002 13:17:07 -0800 (PST)

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.
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Fri, 15 Feb 2002 09:02:21 -0500

>anyhow.  There are well-known IP mechanisms for accomplishing this

Having some experience in this area (not at Cisco), I agree with Dave.
The pertinent ISH would have to come from the other endpoint of the
CLNP/IP tunnel, not from the adjacent IP-only router.  In fact, the
ADM must be careful to realize that any ISH it might receive from an
IP-only neighbor is NOT to be fed to the local ESIS RIB database for
use with CLNP.  If the ADM is running ISIS this isn't a problem,
because ISIS will figure out what's going on.

This has interesting consequences in the discussion (not pertinent
to this list) about multiprotocol encapsulation on SONET DCC and
deployment rules.  I think it means that an IP-only router should
NOT send an ISH, to avoid creating the impression that it supports
CLNP if a multiprotocol ES happens to be at the other end.  (If
an OSI-only ES is at the other end, it's misconnected, and it won't
work regardless of whether it sends an ISH.)

Regards,
Jeff

---

From: "Ken Larmer" <[email-masked]>
Date: Fri, 15 Feb 2002 10:28:35 -0500

> anyhow.  There are well-known IP mechanisms for accomplishing this

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: Sun, 17 Feb 2002 09:27:56 -0500

Ken,

We're not disagreeing with the scenario or motivation.

But if you have an IP-only IS-IS router connected to an IP end system
that supports CLNP/IP tunneling (that's the scenario, right?) then the
ISH sent by the IS-IS router does NOT help CLNP on the ES in any way at
all.

In fact, it could easily confuse the CLNP ES into thinking that the IS-IS
router was a CLNP router, which it is not.  From that point of view, it
would be far better for an IP-only router NOT to send an ISH.

Kapish?

By the way, don't back off until we understand one another.  Then,
if we still disagree, that's another thing.  But your reply and your
earlier email say that the ISH emitted by an IP-only router helps
a CLNP ES, and it most definitely does not; it is more likely to
cause confusion.  This is not a case of breaking something that
works.  If there are CLNP/IP ESs that interoperate with IP-only
IS-IS routers, they should continue to work even if the IS-IS router
doesn't send an ISH.  If it did break such an implementation, that
implementation is misinterpreting the ISH.

If you want, we can take this discussion off-line.  I've done a bit
of work in this very area.

Jeff