Subject: RE: 3gpp-analysis document and automatic tunneling

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Mon, 26 May 2003 19:47:51 +0200

Hi Pekka
 
 > I've tried to think of ways how to edit the text a bit.  Let's see..:
 > 
 >                                                             
 > 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.
Or are you saying that the other mechanisms except 6to4 should
not be considered because they are not RFCs?

 > 
 > In 3.2.1, replace:
 > 
 >     Many GPRS operators already have IPv4 backbone networks deployed
 >     and they are gradually migrating them while introducing IPv6
 >     islands. IPv6 backbones can be considered quite rare in the first
 >     phases of the transition. If the 3GPP operator already has IPv6 
 >     widely deployed in its network, this subsection is not 
 > so relevant.
 >      
 >     In initial, smaller scale IPv6 deployment, where a small 
 > number of
 >     IPv6 in IPv4 tunnels are required to connect the IPv6 
 > islands over
 >     the 3GPP operator's IPv4 network, manually configured tunnels can
 >     be used. In a 3GPP network, one IPv6 island could 
 > contain the GGSN
 >     while another island contains the operator's IPv6 
 > application       
 >     servers. However, manually configured tunnels can be an 
 >     administrative burden when the number of islands and therefore   
 >     tunnels rises. 
 > 
 >     It is also possible to use dynamic tunneling mechanisms such as
 >     "6to4" [RFC3056] and IGP/EGP routing protocol based tunneling  
 >     mechanisms [BGP][IGP]. Routing protocol based mechanisms such as
 >     [BGP] consist of running BGP between the neighboring 
 > router tunnel
 >     endpoints and using multi-protocol BGP extensions to exchange 
 >     reachability information of IPv6 prefixes. The routers use this
 >     information to create IPv6 in IPv4 tunnel interfaces and 
 > route IPv6
 >     packets over the IPv4 network. It is possible to combine 
 > this with 
 >     different types of tunnels. 
 >      
 >     "6to4" nodes use special IPv6 addresses with a "6to4" prefix
 >     containing the IPv4 address of the corresponding "IPv6 in IPv4"
 >     tunnel endpoint ("6to4" router) which performs encapsulation / 
 >     decapsulation. When connecting two nodes with "6to4" 
 > addresses, the
 >     corresponding "6to4" routers use the IPv4 addresses 
 > specified in   
 >     the "6to4" prefixes to tunnel IPv6 packets through the IPv4 
 >     network. But if only one of them has a "6to4" address, a "6to4"
 >     relay must be present to perform the missing "6to4" router 
 >     functionality for the native-IPv6 node. In this case 
 > there are two
 >     deployment options for "IPv6 in IPv4" tunneling between 
 > the "6to4"
 >     router and the relay. The first option assumes that 
 > "6to4" routers
 >     using a given relay each have a default IPv6 route 
 > (configured    
 >     tunnel) pointing to that relay. The other one consists 
 > of using an
 >     IPv6 exterior routing protocol; this way the set of 
 > "6to4" routers
 >     using a given relay obtain native IPv6 routes from it using a 
 >     routing protocol such as BGP4+ [RFC2283]. Although this 
 > solution is
 >     more complex, it provides effective policy control, i.e. BGP4+ 
 >     policy determines which "6to4" routers are able to use 
 > which relay.
 >      
 >     The conclusion is that in most "internal" 3GPP scenarios it is
 > 	preferred to use manually configured tunnels or EGP/IGP based 
 >     tunneling mechanisms, if it is not feasible to enable IPv6 in the
 >     network infrastructure yet. 
 > 
 > with:
 > 
 >     Many GPRS operators already have IPv4 backbone networks deployed
 >     and they are gradually migrating them while introducing IPv6
 >     islands. IPv6 backbones can be considered quite rare in the first
 >     phases of the transition. If the 3GPP operator already has IPv6
 >     widely deployed in its network, this subsection is not 
 > so relevant.
 > 
 >     In initial, smaller scale IPv6 deployment, where a small 
 > number of
 >     IPv6 in IPv4 tunnels are required to connect the IPv6 
 > islands over
 >     the 3GPP operator's IPv4 network, manually configured tunnels can
 >     be used. In a 3GPP network, one IPv6 island could 
 > contain the GGSN
 >     while another island contains the operator's IPv6 application
 >     servers.
 > 
 >     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.

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.

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.

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?

  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?

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.
Maybe we should pose this issue to routing folks?

 > 
 >     As there is nothing 3GPP-specific in how the core networks
 >     are built, further analysis is done in the context of ISP
 >     scenarios and solutions [ISP].

I would replace "core" with backbone since there are some differences
in 3gpp terms.

The last time I looked at the ISP case, they recommended sticking
with BGP for exchanging info over the EGP boundary. That is
different from what you are suggesting we write above.

Rgds
/Karim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 May 2003 10:41:42 +0300 (EEST)

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

> not be considered because they are not RFCs?

6to4 is only one of those currently on our charter, widely deployed and 
used, and RFC.   If we have to pick an example of automatic tunneling, 
6to4 is the best candidate.  Alternatively, the whole automatic tunneling 
section could be deleted.

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

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.
 
> the same thing without the mesh of static routes.

There isn't because that discussion is not specific to 3GPP.  We could 
tail down the section more if that'd be closer what you expect?
 
> So I would not recommend static tunnels as the first choice.

Static tunnels include routing protocols, as above.

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.
 
> all routing protocol based solutions because of this patent?

Not explicitly.  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.
 
> Do you mean automated management tools for configuring static tunnels?

Yes.

> 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 :-).
 
> I would replace "core" with backbone since there are some differences

I'm not sure with the terminology, but backbone is probably better, yes.
 
> different from what you are suggesting we write above.

I'm not sure what you're saying.  The last time I looked, the ISP
scenarios didn't include *any* discussion to warrant any automatic routing
protocol tunneling mechanisms, yes.  But the document isn't finished yet.

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