RE: 3gpp-analysis document and automatic tunneling

[Pekka Savola <pekkas@netcore.fi>]

Hope I'm able to clarify..

On Mon, 19 May 2003, Hesham Soliman wrote:
>  > If an operator wishes redundancy, he will run routing
>  > protocol(s) on top
>  > of his network infrastructure. This would be the case e.g. 
>  > if the IPv6
>  > network was run on top of static ATM PVC's.
>  > 
>  > In the case of IPv6-over-IPv4, this is often not (as) 
>  > necessary 
> 
> => Why is it not necesary in this case? I feel like
> I'm missing something.

Because the operator must ensure the redundancy of his IPv4 infrastructure 
*anyway*, thus must run an IPv4 routing protocol.  So, if a link becomes 
unreachable to tunnel end-point X, the IPv4 routing protocol will route 
around the problem, and X will still be reachable.  This is invisible to 
IPv6.

>  > (but there
>  > are some other failure modes in some scenarios), if the IPv4
>  > infrastructure is redundant and there is an IPv4 routing protocol to
>  > ensure the reachability.  
> 
> => If you're tunnel end point is a certain IPv4 address 
> and that address is statically configured I don't 
> understand the relevance of the IPv4 routing infrastructure
> and potential redudancy. If you always tunnel to B and 
> B crashes (B was manually configured) what can IPv4
> routing do here ?

Nothing.  But then IPv4 infrastructure will be dead too.

When/if you're worried about this (and most are), they create two or three 
tunnels/connections: backup connectivity.  This covers crashing of one 
single device by routing around it.  For more extensive discussion, see 
below.

>  > On the other hand, if you cannot 
>  > rely on the
>  > IPv4 infrastructure, you have to run the routing protocol anyway.
> 
> => Don't see the relevance to the point. Am I missing
> a few things :( ?

I'm not sure.. see above?

The point I tried to make here is that in the real world, connections are 
like:
             /-------- [network] -------\
            /                            \
R1 .--''''-.              |               \   RA
  ( network )             |               - [network]
R2 '--____-'\                            /    RB
             \-------- [network] -------/

.. they do not rely on just one device, and if that fails, you're in 
problems.  (Actually, many networks do have single points of failure, but 
that's their operational/security decision.

Now, in a rather quick picture above, if you want to tunnel between 
network on the left and network on the right, you typically have:

 o an IPv4 routing protocol running which includes everything here

 o if redundancy is important, both networks have two routers and proper 
internal infrastructure to handle the redundancy (R1 + R2, RA + RB).

 o if you want to build a direct tunnel between the two, you can either:
    1) build it between virtual loopback interfaces, one from each
        - that is, create a specific address which is configured at 
          both {R1,R2} and {RA,RB} and put that in the routing protocol 
          and configure the tunnel between R_12 and R_AB on all of them. 
    2) build it between one of each, e.g. R1-RA (or R2-RB, or whatever)
    3) build it between two of each, e.g. R1-RA, R2-RB (or whatever), or
    4) build a full mesh between all of them: R1-RA, R1-RB, R2-RA, R2-RB

The IPv4 routing protocol ensures that the redundancy in the last bullet 
is only needed when one of the tunnel endpoints goes down.  If there is no 
IPv4 routing protocol, IPv6 routing protocol must be used to ensure 
rerouting.

Now, between the alternatives of the last bullet.  These have different
tradeoffs.  The first is the easiest thing in a way if you require
end-point redundancy as it requires only one tunnel.  The second is the 
most used scenario: there you take a risk that the endpoint goes down; in 
some cases, it may be acceptable.  If you don't want to do it, you can 
pick the third option: the chance that both devices would be down at the 
same time is very rare: this is not a single point of failure anymore.  
That last option is typically too heavy to consider here.

Speaking of personal operational ISP experience with IPv6-in-IPv4, we've 
done 2) and 3).  Especially 3) should give you everything you'd wish.

So, I think you have to consider how much edge network redundancy you want
(and what you're willing to pay for it, as there is no free lunch).

Sorry for rambling, just trying to explain better why this is not such a 
problem (IMHO) as one may think.

>  > It seems to me that IGP/EGP mechanisms provide little added 
>  > value here --
>  > except if you have a very large number of IPv6-enabled 
>  > routers you wish to
>  > connect in a full-mesh manner, and manual configuration
>  > would be a chore.  
>  > Such operators have a lot of other chores too, as managing the other
>  > aspects of the routers is not simple either.
> 
> => What other choices do they have?

Which part are you referring to?  (The above explanation should also cover 
this.)

>  > I've having difficulty picturing that particular deployment (a lot of
>  > routers, dense mesh instead of some hierarchy, etc.) to be a 
>  > requirement.
> 
> => This is the case in many planned networks today.

Unfortunately I think I know (a bit) what you refer to, but please 
elaborate.

I really hope that those who have designed the networks know what they're
doing, and what kind of tradeoffs it entails.

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