Subject: draft-ietf-v6ops-isp-scenarios-analysis-00.txt "IS-IS Dual Stack Convex Requirement" question

From: "Green" <[email-masked]>
Date: Sun, 8 Feb 2004 23:23:29 +0800

Hi, all:

in draft-ietf-v6ops-isp-scenarios-analysis-00.txt 4.3.1, it was written:
    Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6 
     topologies must be "convex", unless the Multiple-topology IS-IS 
     extensions [MTISIS] have been implemented.  In simpler networks or 
     with careful planning of IS-IS link costs, it is possible to keep 
     even non-congruent IPv4/IPv6 topologies "convex".

Well, I checked the refenced id draft-ietf-isis-wg-multi-topology-06.txt, but I can't find an explanation of the problem if non-convex MT with IPv4/v6 is present.

I guess it would be quite helpful if you can explain the issue with some word, so reader like meself can figure it out. To me, without knowing other motive of the mt-isis design, I would certainly prefer to use ISIS to run both IPv4 and V6 protocol, since ISIS is so widely deployed in ISP Backbone. Running OSPFv3 in parallel or waiting for vendors to add mt-isis support into their box and testing its stability must be painful to time-to-market.

I still don't know the problem yet. Please shed some light.

Thanks and best regards.

Green
Ericsson China

---

From: Pekka Savola <[email-masked]>
Date: Mon, 9 Feb 2004 09:06:17 +0200 (EET)

[WG chair note: as you aren't subscribed, the approval of the message 
took a while.  Also, it would be nice to turn of HTML in the messages 
posted.]

On Sun, 8 Feb 2004, Green wrote:
> Well, I checked the refenced id =
> draft-ietf-isis-wg-multi-topology-06.txt, but I can't find an
> explanation of the problem if non-convex MT with IPv4/v6 is present.
> 
> I guess it would be quite helpful if you can explain the issue with some 
> word, so reader like meself can figure it out. To me, without knowing
> other motive of the mt-isis design, I would certainly prefer to use ISIS
> to run both IPv4 and V6 protocol, since ISIS is so widely deployed in
> ISP Backbone. Running OSPFv3 in parallel or waiting for vendors to add
> mt-isis support into their box and testing its stability must be painful
> to time-to-market.

Let me try to explain the convex requirement for single-topology
IS-IS.  This obviously needs some more text (or a diagram) in the memo
as it has been brought up earlier.

In short, this could be summarized as:

 1) "any IP-independent path from an IPv4 router to any other IPv4
router must only go through routers which are IPv4 capable", and

 2) "any IP-independent path from an IPv6 router to any other IPv6
router must only go through routers which are IPv6 capable".

Note in particular, as IS-IS is based upon CLNS, these are NOT 
trivially accomplished.  The single-topology IS-IS builds paths 
which are agnostic of IP versions.

Consider an example scenario:

        cost 5     R4   cost 5
        ,------- [v4/v6] -----.
       /                       \
  [v4/v6] ------ [ v4 ] -----[v4/v6]
    R1   cost 3    R3  cost 3  R2

.. here the second requirement would not hold.  IPv6 packets from R1
to R2 (or vice versa) would go through R3, which does not support
IPv6, and the packets would get discarded.  By reversing the costs
between R1-R3,R3-R2 and R1-R4,R4-R2 the traffic would work in the
normal case, but if a link fails and the routing moves to go through
R3, you're again in trouble.

Hopefully this clarifies the situation.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings