RE: 3gpp-analysis document and automatic tunneling

[Hesham Soliman <H.Soliman@flarion.com>]

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

=> Hmmm, that's not relevant I think, my point is:
what if X crashed?

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

=> No it won't be dead, unless you consider every router
to be a SPF.

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

=> see below.

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

=> Thanks for the summary. It seems to me that you are
agreeing with the redundancy argument but you don't
want to automate the whole process, why? 
Instead of configuring multiple tunnels why not allow
the routing to give you the full mesh (option 4) of tunnels
in a dynamic manner? 

Your argument boils down to (I think): we can do this
manually, therefore solving it dynamically is not needed.

We can also configure addresses manually but having dynamic
address allocation makes things easier so I don't think
that's a reason to discourage dynamic mechanisms.

Hesham