RE: 3gpp-analysis document and automatic tunneling

["Karim El-Malki (EAB)" <Karim.El-Malki@era.ericsson.se>]

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

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

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

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

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

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

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

 >  
 > > Putting the technical aspect aside, you brought up the patent
 > > issue with one of the routing protocol mechanisms. Although
 > > we should favour non-patented solutions, are we cutting out
 > > all routing protocol based solutions because of this patent?
 > 
 > Not explicitly.

I hope not implicitly either ;-)

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

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

/Karim