Subject: RE: WG Last Call: 3GPP Analysis Document

From: Soliman Hesham <[email-masked]>
Date: Fri, 3 Oct 2003 03:16:01 -0400

Hi Alain, 

 > >=> I'd love to do that. However, how does this happen in 
 > >practice? Let's say 3GPP went with IPv6 only and 3GPP2
 > >did dual stack or IPv4 only for their IMS. And let's 
 > >say that some operators decide to enable IPv4 only
 > >in their 3GPP2 networks, or in their fixed broadband
 > >networks. Now a 3GPP operator has three options:
 > >
 > >1. Tell the others to upgrade to v6
 > >2. Tell its subscribers that they can't contact certain
 > >   networks.
 > >3. Provide a mechanism that allows subscribers to talk
 > >   to those v4 only people. 
 > >
 > >1) is unrealistic. If it can be done, then why hasn't
 > >it been done already? 2) doesn't seem realistic either
 > >from a commercial point of view
 > >
 > 
 > I'm a bit confused here. The voice communication using standard
 > technology would still work fine, right?

=> If you mean "using circuit switched voice" then
I agree. But any service using IP (including voice)
would not work.

 > So, this is only the value-added services, SIP-driven
 > that won't work between 3GPP & 3GPP2, right?

=> SIP services are intended for any peer to peer
application that uses IP. 

 > 
 > So, are you not trying to solve a social problem here instead
 > of a technical one?

=> :) am I? I think allowing people using difference
technologies to communicate is a good thing socially,
technically and commercially.

Hesham

---

From: <[email-masked]>
Date: Tue, 7 Oct 2003 18:21:50 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

here are some more comments on this document:

----
3.2.2 Tunneling outside the 3GPP Operator's Network 
     
    This subsection includes the case when the peer node is outside the 
    operator's network. In that case the IPv6-in-IPv4 tunnel starting 
    point can be in the operator's network - encapsulating node can be 
    e.g. the GGSN or the edge router. 
     
    The case is pretty straightforward if the upstream ISP provides 
    native IPv6 connectivity to the Internet. If there is no native 
    IPv6 connectivity available in the 3GPP network, an IPv6-in-IPv4 
    tunnel should be configured from e.g. the GGSN to the dual stack 
    border gateway in order to access the upstream ISP. 
     
    If the ISP only provides IPv4 connectivity, then the IPv6 traffic 
    initiated from the 3GPP network should be transported tunneled in 
    IPv4 to the ISP. 
     
    Usage of configured IPv6-in-IPv4 tunneling is recommended. As the 
    number of the tunnels outside of the 3GPP network is limited, no 
    more than a couple of tunnels should be needed. 
     
    ISP transition scenarios are described in [ISP-scen]. 
----     

it is somehow difficult to follow this section. there are three
important parts here: gprs access network, 3gpp ip backbone (if the 3gpp
operator has one) and upstream isp. it is hard to decide which is which
in the text.

is this what is meant or something else?

    This subsection includes the case when the peer node is outside the
    operator's network. In that case an IPv6-in-IPv4 tunnel should be
    configured in order to obtain IPv6 connectivity and reach other IPv6
nodes.

    Starting point can be in the operator's network and will depend on
how far
    the 3GPP operator has come in implementing IPv6. If the 3GPP
operator
    does not have an IP backbone or has not implemented IPv6 in the
backbone,
    the encapsulating node can be the GGSN. If the 3GPP operator does
have an
    own IP backbone, and has implemented IPv6, but upstream ISP does not
provide
    IPv6 connectivity to the Internet, the encapsulating node can be the
edge router. 
     
    The case is pretty straightforward if the upstream ISP provides 
    IPv6 connectivity to the Internet. In that case the 3GPP operator
    does not have to configure any tunnels, since the upstream ISP will
    take care of routing IPv6 packets. If the upstream ISP does not
    provide IPv6 connectivity, an IPv6-in-IPv4 tunnel should be
configured
    from e.g. the edge router to a dual stack border gateway operated by
another
    ISP which is offering IPv6 connectivity.

    Usage of configured IPv6-in-IPv4 tunneling is recommended. As the 
    number of the tunnels outside of the 3GPP network is limited, no 
    more than a couple of tunnels should be needed. 

jasminko

---

From: <[email-masked]>
Date: Wed, 8 Oct 2003 13:45:48 +0300

Hi, Jasiminko!

Thanks for your comments!

It is true that the current text may not be clear enough - and I think your suggested text is mostly fine. I made some minor modifications in it (see below):

----

This subsection includes the case in which the peer node is outside the
operator's network. In that case IPv6-in-IPv4 tunneling can be necessary
to obtain IPv6 connectivity and reach other IPv6 nodes.

Tunnel starting point can be in the operator's network depending on
how far the 3GPP operator has come in implementing IPv6. If the 
3GPP operator does not have an IP backbone, or has not 
implemented IPv6 in it, the encapsulating node can be the GGSN. 
If the 3GPP operator has an IP backbone, and has implemented 
IPv6 in it, but the upstream ISP does not provide IPv6 connectivity 
to the Internet, the encapsulating node can be the edge router.

The case is pretty straightforward if the upstream ISP provides 
IPv6 connectivity to the Internet and the operator's backbone network
supports IPv6. Then the 3GPP operator does not have to configure
any tunnels, since the upstream ISP will take care of routing IPv6
packets. If the upstream ISP does not provide IPv6 connectivity, 
an IPv6-in-IPv4 tunnel should be configured e.g. from the edge 
router to a dual stack border gateway operated by another ISP
which is offering IPv6 connectivity.

In the tunneling scenarios above, usage of configured IPv6-in-IPv4 
tunneling is recommended. As the number of the tunnels outside
of the 3GPP network is limited, no more than a couple of tunnels 
should be needed.

----

By the way, did you intentionally leave the [ISP-scen] reference out? That might be rational, because that reference is already mentioned in 3.2 just before subsection 3.2.1.

Cheers,
	 -Juha-

-----Original Message-----
From: ext [mailto:[email-masked]]
Sent: 07 October, 2003 19:22

----

     

     

jasminko