RE: 3gpp-analysis document and automatic tunneling

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

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

Yes you can connect one host on one tunnel which is useful in early
stages and in special roaming cases for example as documented in
the draft. /64 is recommended to 3GPP for IPv6-only connections
(PDP Contexts). ISATAP is used when you have IPv4-only connections.
It's described in the analysis doc.

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

It looks to me like the best way to proceed is to keep what we have in
the analysis document until we can get the output from the ISP team to
see if we are missing things and where to reference the ISP doc.

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

Fine. I assume we'll see it spelled out in the ISP documents.

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

It's hard to define a 3gpp environment as a separate entity.
We can consider mobile network sites connected to a generic
backbone, which is what we've done in the analysis doc. 

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

No problem with that. But we must consider both IPv4 and IPv6
backbones between the mobile network sites.

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

That's OK, but your scenario covers the internal backbone routing
(IGPs) which is outside the 3gpp analysis scope. However external
connectivity from mobile network sites is in scope. That's a different
scenario where you typically use EGPs (already deployed). That's why we
have the discussion in the doc which considers as one case that in
which the backbone has not yet been migrated to v6. I will be looking
at the ISP docs when they are out to make sure there are no contradictions.

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

We're covering how to connect mobile network sites (some may be
migrated to v6 before others) to the backbone. That creates some
overlap with the ISP work but so far it's not been an issue IMO. 

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

I was hoping we would not add more manual config than there is
already if possible. Also, just to clarify, iBGP meshes and eBGP
filters would typically be within the backbone ISP scope.

/Karim