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

From: Thomas M Holland <[email-masked]>
Date: Thu, 18 May 2000 17:19:22 -0400

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

Here is the configuration:

     Dual-1 ---   OSI-1   ---   OSI-2  ---   Dual-2
       |                                        |
     Dual-3  ---  Dual-4   ---  Dual-5 ---   Dual-6

(note: there are supposed to be vertical connections
from Dual-1 to Dual-3 and from Dual-2 to Dual-6, in
case my artwork gets mangled)

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.  

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.  

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?

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

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. Is there any kind of mechanism for easing the transition
from OSI to IP (or vice-versa)? 

Do you know if anyone is using RFC1195 to route both CLNP and 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?

Thanks,

Tom Holland
Alcatel

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

---

From: Henk Smit <[email-masked]>
Date: Fri, 19 May 2000 00:02:40 +0200 (MEST)

> case my artwork gets mangled)

  The picture is crisp clear.

> By definition, this must be an OSI-only area since two of the NEs are

  Don't know where you found that definition.
 This is what rfc1195 has to say.
 See paragraph 1.4: Support of Mixed Routing Domains.

     In a dual routing domain, IP-only, OSI-only, and dual routers may be
     mixed on a per-area basis. Specifically, each area may itself be
     defined to be pure IP, pure OSI, or dual.

     In a dual area within a dual routing domain only dual routers may be
     used. Both IP and OSI traffic can be routed within a dual area.

  When I read this, I understand that it states that you may not mix
 Dual routers and OSI-only routers *inside* one area. In the design
 you presented in your example, you do mix them. That is forbidden.
 Your network design will not work.

> 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

  Which field ?
 The description of a link inside an LSP only tells you between which
 routers the link is, and what the cost is. It does not tell you
 which protocols are supported over that link.
  This is TLV #2. If you use the newer TLV #22, then you might want
 to add a new sub-TLV to describe the protocols supported. Then each
 router can run an SPF per protocol.
  IMHO this is not worth the trouble.

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

  You'll need a separate SPF for IP and one for OSI.

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

> be routed.

  Correct.
 That is probably why the requirement is there to make all routers
 inside an area in the same mode.

> Is there any kind of mechanism for easing the transition

  I am not sure what you mean by that question.

> Do you know if anyone is using RFC1195 to route both CLNP and IP?

  Of course.

> the transition); do you know of any work along these lines?

  Nothing that I know of.
 Tunnels are a pain.
 Hope this helps,

            Henk.