Subject: RE: 3gpp-analysis document and automatic tunneling

From: Hesham Soliman <[email-masked]>
Date: Tue, 20 May 2003 10:27:05 -0400

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 May 2003 10:30:21 +0300 (EEST)

> => Hmmm, that's not relevant I think, my point is:

The point is not have X crash.  If this is considered a problem, a backup
connection is built&configured so that the routing protocol can switch
over to it in case it does.

> => No it won't be dead, unless you consider every router

I assume you mean SPoF.

Right, it depends on your network infrastructure.  Networks are typically
hierarchical, with some added routers for redundancy depending on the
level you want.  If you tunnel from an edge router to some router and your
edge router dies, your connectivity in the edge dies too unless you've
backed them up.

If the edge networks where the tunnels originate are not backed up, 
backing up in the core may not be justified.

> manually, therefore solving it dynamically is not needed.

Yes.  And it adds complexity which is unnecessary, and has some other 
problems as well (e.g. automated, open-to-the-world tunneling is always 
dangerous).  Also, did you know that BGP tunneling has IPR claims?

Another point is that it seems to be much easier to just deploy/upgrade to
a dual-stack backbone than start with an overlay network, and just add a
few tunnels here and there when appropriate or where necessary, the number
to be reduced at will.

But some ISPs are so fond of overlay network model they may want to build
such networks anyway.  AFAICS, this is nothing specific to 3GPP.  
Therefore, an extensive analysis of this case -- whether it's really
neeeded, how to address it, etc. -- belongs to the ISP documents, not
3GPP.

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