RE: 3gpp-analysis document and automatic tunneling

[Pekka Savola <pekkas@netcore.fi>]

Hi,

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

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

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

(The first two paragraphs are basically unchanged; removed the dynamic 
tunneling chapter, longer 6to4 consideration and the conclusion.  Also, 
add an informative reference to the ISP scenarios document.)

Thoughts?

On Sat, 17 May 2003, Pekka Savola wrote:
> On Thu, 15 May 2003 juha.wiljakka@nokia.com wrote:
> > I'd like to raise one issue in the 3gpp-analysis document which bothers me 
> > a lot.
> > 
> > I'd like to either understand the reasoning for mentioning all the kinds
> > of automatic tunneling mechanism in this draft, or remove the references.
> > (the last paragraph of 2.2 quoted below, and some re-editing of the
> > paragraphs in 3.2.1).
> > 
> >   JW: What comes to the tunneling text in 2.2, I am fine with shortening
> > it. There actually isn't anything 3GPP-specific, it is more like general
> > tunneling description that is already described elsewhere (RFC 2893,
> > etc...). As you see, the references to DSTM, ISATAP and TEREDO are
> > informational references and thus not vital in this document. They are
> > just mentioned as examples of tunneling mechanisms. Would making the
> > tunneling text shorter (e.g. one paragraph) and removing the references
> > to mechanisms (that are not used in this document) be a good thing to do
> > in your opinion?
> 
> Yes, 1-2 paragraphs (one about tunneling in general, possibly one about
> static/dynamic distinction) without going too far into the specifics would
> seem to be a good approach -- enough to give the reader an impression 
> about the basic choices he has.
> 
> > In particular, I feel this is an issue about IGP/BGP tunneling.  It is
> > possible such methods could be used -- if the network is built just so --
> > but that's entirely different thing from whether they're a required or
> > even a recommended solution ("we have a hammer, now let's go find the
> > nails").
> > 
> >   JW: Well, I don't think we can give unambiguous recommendations. It is
> > much better to discuss different solution alternatives. Anyway, we can't
> > require any solutions to be used by operators. We had some discussion
> > with other authors (especially Karim) how to edit the text. One point
> > that was brough up in the discussion was redundancy. Static tunnels on
> > their own don't give a solution if a route goes down. Instead, EGP/IGP
> > mechanisms support this. Say that I have multiple tunnels to two router
> > endpoints connected to the same network. If one goes down I would like
> > to start tunnelling to the other. Do you have any comments on this?
> 
> If an operator wishes redundancy, he will run routing protocol(s) on top
> of his network infrastructure. This would be the case e.g. if the IPv6
> network was run on top of static ATM PVC's.
> 
> In the case of IPv6-over-IPv4, this is often not (as) necessary (but there
> are some other failure modes in some scenarios), if the IPv4
> infrastructure is redundant and there is an IPv4 routing protocol to
> ensure the reachability.  On the other hand, if you cannot rely on the
> IPv4 infrastructure, you have to run the routing protocol anyway.
> 
> It seems to me that IGP/EGP mechanisms provide little added value here --
> except if you have a very large number of IPv6-enabled routers you wish to
> connect in a full-mesh manner, and manual configuration would be a chore.  
> Such operators have a lot of other chores too, as managing the other
> aspects of the routers is not simple either.
> 
> I've having difficulty picturing that particular deployment (a lot of
> routers, dense mesh instead of some hierarchy, etc.) to be a requirement.
>  
> > I fail to see anything 3GPP specific in the description of the network in 
> > 3.2.1 and consequently, I'd rather not go down the rathole of describing 
> > how an ISP would run its network in the 3GPP scenarios/analysis document.  
> > Rather, I'd try to work out generic ISP scenarios in the ISP 
> > documents to avoid duplicating the work.
> > 
> >   JW: I fully agree with you that we should not do work that actually
> > belongs to the ISP design team. What kind of text would you suggest in
> > our document?
> 
> I'll try to work on something to start with within a week.
> 
> 

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