RE: 3gpp-analysis document and automatic tunneling

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 27 May 2003, Karim El-Malki (EAB) wrote:
>  > >  > Examples of
>  > >  >     dynamic tunneling mechanisms are "6to4" [RFC3056], 
>  > >  > [ISATAP], [DSTM]
>  > >  >     and [TEREDO].
>  > >  > 
>  > >  > ==> replace with:
>  > >  > 
>  > >  >  An example of dynamic tunneling mechanism is "6to4" [RFC3056].
>  > > 
>  > > That removes some useful info for 3gpp people.
>  > > What did you not like about pointing out the main mechanisms
>  > > which 3gpp should be aware of? IMO we should keep all the above.
>  > 
>  > I fail to see how those techniques would be useful for 3GPP people.  
>  > Well, maybe DSTM could be leveraged, a bit, but it's not 
>  > really even an
>  > automatic tunneling mechanism.  It's all just irrelevant 
>  > information in 
>  > this context.
> 
> I have used ISATAP in 2.5 & 3G mobile networks and think it
> is a very relevant mechanism. What is your experience of
> these mechanisms in mobile networks that makes you say this?

ISATAP doesn't allow you you to connect more than a single host.  It
doesn't allow routers or networks (e.g. a /64 as recommended to the 3GPP).  
Thus, I see it being of little use at least in the 3GPP-specific part.

> ..cut some text
>  > >  >     However, manually configured tunnels can be an
>  > >  >     administrative burden when the number of islands 
>  > and therefore
>  > >  >     tunnels rises.  In that case, upgrading parts of 
>  > the backbone
>  > >  >     to dual stack may be the simplest choice.
>  > > 
>  > > I don't think this is a viable or simple choice in many cases. The
>  > > operator should be free to upgrade the backbone 
>  > independently of the
>  > > number of sites. Some may want to delay that upgrade.
>  > 
>  > The operator can, of course, do however he/she wants to.  
>  > IETF cannot 
>  > and should not mandate it.  But we can document some ways which seem 
>  > preferable.
> 
> What reasons would it be preferable for? Cost? Ease of deployment?
> I have talked to some who don't think it is cheaper or easier
> so I don't think we should make this preference. We could say that
> if the operator finds that the risk/cost allows the backbone
> to be upgraded then this could avoid tunnelling. But I guess this
> is quite obvious.

Well, we (as the working group) should document cases how to deploy IPv6
in the common case, using widely applicable mechanisms.  Obviously, some
approaches are more preferable (without defining the metric, as it isn't a
single one) than others.  One point to look at might be RFC3439, "Some
Internet Architectural Guidelines and Philosophy".

I'm not quite convinced that based on 3GPP analysis this yet fulfils the 
criteria for this.
 
>  > I've been been there when IPv6 coexistance has been planned and 
>  > implemented for at least 3 ISP networks (each with 
>  > gigabit-level traffic 
>  > levels).  In all of those cases, dual stack has been *by 
>  > far* the simplest 
>  > choice, augmented by a tunnel here and there.  There may be 
>  > other cases, 
>  > of course, too -- to be identified in the ISP scenarios if necessary.
> 
> In my experience (mobile operators) it is not favoured by many.

That may be due to real or wrong reasons.  That's something to be found
out by better analysis of it in the ISP context.
 
>  > > Also there is no discussion about reliability of connections.
>  > > Doing this with static tunnels (manually configuring a mesh of
>  > > static tunnels) and relying on v4 routing protocols does not
>  > > seem like something we can recommend above everything else.
>  > > It's an option but using a routing protocol you would achieve
>  > > the same thing without the mesh of static routes.
>  > 
>  > There isn't because that discussion is not specific to 3GPP. 
> 
> But there is a requirement of high reliability in general
> in mobile networks which isn't always there in other scenarios.

.. but in most cases, is.
 
>  >  We could 
>  > tail down the section more if that'd be closer what you expect?
> 
> No! I want it to say more. This document is supposed to help
> 3gpp deploy these networks.

It's supposed to help in 3GPP environment, not (IMO) in how 3GPP operators 
could act as ISP's, and how to build their ISP-grade backbone networks.  
These are two separate issues.

>  > > Most importantly there are some routing scenarios in which you
>  > > will not detect a route failure if you are using static routes.
>  > > I have been involved in several mobile network designs and
>  > > these cases are quite common, just like in any other network.
>  > > So I would not recommend static tunnels as the first choice.
>  > 
>  > Static tunnels include routing protocols, as above.
> 
> Above I talked about running v4 routing protocols while tunnelling
> v6-in-v4. That doesn't solve all the v6 route failure cases.

Routing protocols can be run in both v4 and v6.  Whichever combination 
seems useful for the operator. Together, they address all concerns.

>  > Or maybe it should be spelled out that in case of configured 
>  > tunnels, it
>  > may be desirable to have redundancy and run a routing protocol.
> 
> Run a routing protocol where? Inside the tunnel (v6 routing protocol)
> and a v4 routing protocol as well? In that case I would simplify things
> by running a single routing protocol that can exchange both v6 and
> v4 routes.

Yes -- if you want a simple network, you can do this quite easily by
running, for example, IS-IS on a dual-stack backbone.

For example, we run OSPF for IPv4 and IS-IS for IPv6 only.  That's not a 
problem for us.  It's better that way, for now -- we could introduce a new 
IPv6 routing protocol without disturbing the existing one at all, as 
they're completely separate.

So there are tradeoffs both ways.

>  > I think there is a need to identify the
>  > real scenarios
>  > and which approaches seem to make the most sense.  I'm 
>  > unconvinced there's
>  > anything 3GPP-specific here.  This doesn't exclude some 
>  > (future) findings
>  > in the ISP scenarios.
> 
> We don't need to cover what is in the ISP scenarios.
> However we need to give a guideline doc for 3gpp networks.
> I don't see why we should go and put 3gpp reliability or
> tunnelling transition mechanism requirements on the ISP doc.
> Also I've had a look at the ISP work and I thought the 3gpp doc
> and the ISP doc were pretty much in line when it came to the
> overlap regions.

I think we have different concepts of the scope of the 3GPP case.  I think
it's focus is, and should be, on how the 3GPP-specified part operates
(like SIP interactions, providing v4/v6 connectivity to the 3GPP devices,
etc.), and how we most fluently merge it with IPv6.

*NOT* how to implement backbone networks.  (Which is certainly an 
interesting topic, but really something which is best fit under ISP 
context because that's where backbone networks of such grade are 
deployed.)

>  > >   The administrative
>  > >  >     burden could also be mitigated by using automated management
>  > >  >     tools which are typically necessary to manage large networks
>  > >  >     anyway.  Even a dynamic tunneling mechanism could be used
>  > >  >     if other methods are not suitable.
>  > > 
>  > > Do you mean automated management tools for configuring 
>  > static tunnels?
>  > 
>  > Yes.
>  > 
>  > > Seems like you want us to clearly say we prefer static instead
>  > > of dynamic tunnelling but I don't think we have an agreement here.
>  > 
>  > Yes.
>  > 
>  > > Maybe we should pose this issue to routing folks?
>  > 
>  > This seems more like an operational issue, not a protocol 
>  > issue.  And this 
>  > happens to be an ops working group :-).
> 
> If we have routing experts in this wg I think their input would
> be helpful.

Agree.

I meddle with routing every day, but you already know my opinion *).  I'd
like to hear others' as well.

*)  How do you think big operators handle issues like:
 - updating a piece of configuration (e.g. access-lists, route-maps, 
policies) on dozens or hundreds of routers
 - configuring iBGP meshes between routers
 - update their eBGP filters on their border routers

.. other than by (advanced) management tools, or by a lot of manual work?
The former would help with tunnels too, but in the latter case the NOC 
folks are so used to it it doesn't matter anyway.  Pick your poison :-).

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