Subject: Re: [Isis-wg] IS-IS mixed domains

From: Jeff Learman <[email-masked]>
Date: Fri, 19 May 2000 15:32:09 -0400

>> I have a question about mixing Dual and OSI-only routers in an OSI-only
area.

You can mix OSI-only and dual routers in an area, but only OSI
routing will be supported in the area.  While the dual routers
support IP routing capability, you won't get meaningful IP routing
in the area.  RFC1195 says:

   In a pure-OSI area within a dual domain, OSI-only and dual routers
   may be freely mixed. Only OSI traffic can be routed by level 1
   routing within a pure OSI area.

The protocol does not enforce the requirement.  But if you
try to break the rules, it just won't work.  IP-capable routers 
may attempt to forward IP packets to OSI-only routers, which
will drop them (if it's robust, but NE implementations aren't
always as robust as one might wish ;-).

As Henk says, the protocol doesn't distinguish between CLNP links
and IP links.  It just describes links, and a link is assumed to
be capable of any protocol supported by the router that's running
SPF.  The strange upshot of this is that there are some
mixed networks (some dual, some CLNP-only) where IP actually works,
but only because all best paths between dual routers are via dual
routers.  I would strongly recommend against building a network
like this on purpose, except in very special cases.  Note that the
fault tolerance assesment is much more complicated.  For example,
in your picture:

>> 
>> Here is the configuration:
>> 
>>      Dual-1 ---   OSI-1   ---   OSI-2  ---   Dual-2
>>        |                                        |
>>      Dual-3  ---  Dual-4   ---  Dual-5 ---   Dual-6
>>

If Dual-1 is trying to send IP traffic to Dual 2, it will forward it
via OSI-1, which will just drop it.  Assuming all link costs are
equal, Dual-3 will be able to exchange IP traffic with Dual-6, but
only if none of the links between them are down.

>> Each of these NEs support Integrated ISIS and are all in the same area.
>> By definition, this must be an OSI-only area since two of the NEs are
>> OSI-only.  

Correct.

>> Assume Dual-1 wants to send an IP packet to IP3 which is attached to
Dual-2.
>> Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP
>> reachability entries list.  Dual-1 should now have 2 paths to IP3,
>> one through OSI-1 and one through Dual-3.  The one through OSI-1
>> looks like the shorter path, but won't work, because it includes OSI
>> only routers.
>
>  Correct.
>
>> The standard states that you cannot route IP packets in an OSI-only
>> area.  But it doesn't indicate any checks that you must do to
>> prevent doing this.  Are you required to check the 'protocol
>> supported' field in each LSP and keep track of what type of area you
>> are in?
>
>  I would assume it is the responsability of the network adminstrator
> who install and configures the routers.
> Note: the protocol supported TLV is inside hello packets. So routers could
> check that to accept or reject adjacencies with other routers that
> are differently configured. Note also that this would make migration
> between modes more difficult.
>
>> It seems if the node was required to look at the 'protocol
>> supported' field of each link to determine if the area was OSI-only,
>> that would fix the problem.  Either the node would drop the packet
>> itself with an appropriate ICMP error, or perhaps the SPF algorithm
>> would take into account which nodes support IP and which do
>> not.

As Henk says, there is no information for each link.  There is, however,
a Protocols Supported TLV in each LSP, identifying the protocols supported
by the router, according to RFC 1195:

   The "Protocols Supported" field identifies the protocols which are
   supported by each router. This field must be included in all IS-IS
   Hello packets and all LSPs with LSP number 0 transmitted by IP-
   capable routers.

But this information is not consulted when running SPF (or at any other
time, so some implementations might even omit them from LSPs, and
there would be no side effects except when trying to debug routing
problems by looking in a router's LSDB).

>> However, the way the standard reads to me (especially sec 1.4
>> and 3.10), it implies that you just send it out and the packet will
>> get dropped. Is my reading correct?
>
>  My reading is that your setup is illegal. Behaviour of routers in
> illegal configurations in not (always) defined.

I disagree that the setup is illegal (using dual routers in an OSI-only
area).  I do agree that trying to route IP traffic in this area is
illegal.  This is only a semantic nit I am picking ;-) and I agree
with Henk's assessment that the behavior is a "don't care case" in
the spec.

>> It seems that if you have even one OSI only router in an area, there's not
>> much use in having Dual routers in that area, since IP packets can't
>> be routed.

The only reason would be for transition purposes.

>> Is there any kind of mechanism for easing the transition
>> from OSI to IP (or vice-versa)? 

Introduce dual routers, but use only CLNP, until all routers are dual-
capable.  Then it is a dual area, and you can start using IP.

>> Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms
>> for forwarding packets through incompatible routers (which might help ease
>> the transition); do you know of any work along these lines?

Unfortunately, RFC 1195 makes this difficult if not impossible to do,
because of ignoring the Protocols Supported TLV when running SPF.
This makes tunneling impossible without creating some new special
kind of link that would need to be understood by all dual routers
in the area as being an IP-only link.  This need to upgrade all
dual routers in the area makes such an enhancement impractical.

Regards,
Jeff

____________________________________________________________________

  Jeff Learman                           Internet:     [email-masked]
  Engineering Manager                    Voice:     (734)-975-7323
  ONE (Open Networks Engineering, Inc)   Fax:       (734)-975-6940
  2725 South Industrial Pkwy, Suite 100
  Ann Arbor, MI  48104  USA
____________________________________________________________________

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