[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis document and automatic tunneling
On Tue, 20 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.
>
> => Hmmm, that's not relevant I think, my point is:
> what if X crashed?
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.
> > > => 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.
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.
> > 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.
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