RE: 3gpp-analysis document and automatic tunneling

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 27 May 2003, Karim El-Malki (EAB) wrote:
>  > > 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.

See the other thread.

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

Disagree.

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

I can imagine but it's not the only thing that's difficult :-)

> We can consider mobile network sites connected to a generic
> backbone, which is what we've done in the analysis doc. 

I don't know this scenario in enough detail to say much of anything, but 
it seems to me that you consider these mobile network sites similar to 
PoPs (Point of Presence) or even PE (Provider Edge) routers.  In which 
case, there doesn't seem to be anything 3GPP-specific in them.

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

Could you tell me why EGP's are used in such a context?  Aren't those 
mobile network sites under a single administration.

Naturally, you run BGP in addition to IGP's, but that's beside the point; 
the IGP's is basically what you use to ensure redundancy.

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

The point is, to avoid contradictions *later* and to make it faster to 
progress the drafts in other fronts (seem to be last-call or almost IESG 
material already), it would seem to be preferable to try to keep away 
from non-3GPP discussion in 3GPP documents.

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

See above.

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

Yes, that's of a value, but IMHO it seems to me, that it isn't of *that
much* value.. as mechanism where these are really needed have to be in
place anyway..

> Also, just to clarify, iBGP meshes and eBGP
> filters would typically be within the backbone ISP scope.

Exactly, why something like this is better analyzed in the ISP context.

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