Subject: RE: FW: 3gpp scenario 2

From: <[email-masked]>
Date: Thu, 19 Dec 2002 10:05:34 +0200

Pekka,

thanks for your constructive comments! Comments (marked JW) below:

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 18 December, 2002 23:50

Let's consider the possible cases here (perhaps it should be clarified 
which is the case in the particular scenario):

1) inside the GPRS network: if the 3GPP operator has a large backbone, it
may not have native IPv6 everywhere.  Tunneling may have to be used there.

Personally I think this is a non-issue, because as 3GPP is so heavily 
IPv6, I don't see why anyone would bother deploying it without all the 
network infrastructure (or most of it so it doesn't really matter) being 
IPv6-enabled.

But if this is important, here something like [BGP][IGP] could be usable.  
Not required, really, or maybe not even optimal, but they could be used.

 JW: I agree with Karim's later comments that many GPRS operators already 
have IPv4 backbone networks (gradually migrating them while introducing 
IPv6 islands). And native v6 backbones are quite rare in the first phases 
of the transition. We can write clearer 'applicability statement' for the use
of [BGP] / [IGP]. Another thing we should do is to more clearly separate
'inside the operator's network' and 'outside the operator's network' cases in
the next revision!

2) outside the GPRS network, between the operator's network and the 
Internet IPv6 (islands): there is no doubt some tunneling over IPv4 will 
be needed _somewhere_.  But where?

 JW: Yep, tunneling is needed in the network and 'where to tunnel' can 
be considered case by case; only general recommendations can be 
given in our draft.

 a) if the 3GPP operator is connected natively to an v6-enabled ISP, the
3GPP operator himself does not necessarily have to do anything: he can
more or less assume someone else (e.g. his ISP) is doing the bridging
between these IPv6 islands.

 JW: Well, yes...this looks like an easy case and starts to be close to 
the scope of the ISP design team..  :-)

 b) if the 3GPP operator is connected to some IPv4 and IPv6 networks, it 
may want to perform tunneling to some IPv6 islands over IPv4 itself.  This 
is just a matter of routing and policy.

However, considering these two specific tools:

[IGP] is used in IGP only and IGP is not run across administrative 
borders; so it's clearly useless.

[BGP] could theoretically be used, but its main area of applicability is
to enable automatic tunneling over IPv4-enabled core using IPv4/6 edge
routers (the typical case being an ISP's MPLS core network).  If this was
applied to the general Internet, it would basically mean that
participating islands would have to be have BGP sessions between them
using some tunneling techinique like 6to4, IPv4 eBGP multihop, etc.

So it seems to me neither of these is applicable in the context 2).

 JW: Thanks for your opinion, I can quite clearly see that your basic
recommendation for this case 2b) is to use a couple of configured 
tunnels?

Perhaps this clarifies my point?

 JW: Yep, it does!

BR,
	-Juha-

> -----Original Message-----
> From: ext Pekka Savola [mailto:[email-masked]]
> Sent: 17 December, 2002 21:10
> 
> On Tue, 17 Dec 2002 [email-masked] wrote:
> > Our proposed solution concluding that "In most 3GPP scenarios it is
> > preferred to use manually configured tunnels or EGP/IGP based tunneling
> > mechanisms." is written in "3GPP analysis" chapter 3.2.
> > 
> > In my comment below I just refer to using "IPv6 in IPv4" tunnels from
> > the operator's network to other IPv6 islands - configured tunneling
> > makes sense, if there is a limited number of other IPV6 islands you need
> > to connect to. Note that we also state
> > 
> >    "However, manually 
> >     configured tunnels can be an administrative burden when the number 
> >     of islands and therefore tunnels rises. Therefore it is also 
> >     possible to use dynamic tunneling mechanisms such as "6to4" 
> >     [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms 
> >     [BGP][IGP]."
> > 
> > in our analysis doc.
> 
> I think one should keep in mind that it's not necessary to reach every 
> IPv6 island directly (a usual justification for e.g. IGP/EGP tunneling).
> 
> I think we can pretty much discard [BGP][IGP] from scenario 2 too -- 
> they're applicable for smaller-than-Internet scopes, which scenario 2 does 
> not seem to be at all.
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Dec 2002 10:28:13 +0200 (EET)

On Thu, 19 Dec 2002 [email-masked] wrote:
> of [BGP] / [IGP]. 

Sure, but my thought is that dual-stack v4/v6 backbones already exist, and
are definitely on the rise.  It's not like 3GPP networks are deploying
today or tomorrow.  Often setting up the infrastructure required to
install something like BGP/IGP tunneling is greater than the pain of 
configured tunneling or dual-stack backbone.

In any case, I'm not sure how specific this discussion is to 3GPP.  
Depending on how you view the operator, seems pretty close to ISP (or 
enterprise) network.

> Another thing we should do is to more clearly separate

Definitely agree :-)

> the scope of the ISP design team..  :-)

Definitely...

If the 3GPP operator does tunneling over IPv4 Internet, IMO it should be 
considered 3GPP operator/ISP, and then ISP parts would apply.  Nothing 
really 3GPP-specific as I see it.
 
> recommendation for this case 2b) is to use a couple of configured 

Yes -- but it depends quite a bit on how many ISP functions the 3GPP
operator wants to perform (indeed, I believe most of them are ISP's of
some sort themselves) -- and then the issue about external connectivity
seems a bit moot.

My point is that I don't see anything 3GPP -specific in the Internet case.  
Either it gets connectivity to other IPv6 sites through its ISP's or
transits, or connects to some of them directly ("acting as ISP doing 
peering").  The latter is unscalable.