[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis document and automatic tunneling
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