RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE]

[Pekka Savola <pekkas@netcore.fi>]

 (chair hat=on)
Btw, please try to trim the text being quoted -- to make it easier to 
read -- and remove any unnecessary text (e.g. at the end).
 (chair hat=off)

On Wed, 26 Nov 2003, Soliman Hesham wrote:
>  > Basically the options seem to be two-fold: either the home operator
>  > knows which users are potential IPv6 users in advance (and can
>  > associate "user-wants-ipv6" and the user information, and always when
>  > the customer performs the PDP context activation, update the tunnel
>  > end-point information), 
> 
> => This alternative is a non starter. This knowledge would not
> exist unless static addresses are used, and they're not used
> at all.

This cannot be true.  The home operator must know the address of the 
UE, if for no other reason, but because it's tunneled back from the 
foreign network.  

In the traditional ISP networks, the knowledge is out there, even for
dynamic prefixes (e.g. in TACACS/RADIUS logs, etc.).  I fail to see
how that would be different for 3GPP?  Please elaborate!

>  > or that all the users are potential users
>  > (implying the tunnel end-point should be updated based on the first
>  > packet sent over the tunnel).  The former requires a bit of ops &
>  > management glue to tie these two together.  The latter requires a
>  > minor modification to proto-41 decapsulation code at the 3GPP
>  > operator's tunnel router, but basically that's it.  
> 
> => I'd rather not make this assumption either. 

Well, some rather might! :-)  Can you provide some technical 
arguments?

> It seems to me that we're going around trying to avoid 
> using an existing, well understood, implemented in products,
> proposal (ISATAP), why? The people that implemented it in
> products are happy with it. 

This is not true.  I know for sure that it is not well understood (I'm
not sure how well I can argue about the others, so I don't respond to
that point now).  The previous ISATAP advocate, for example, thought
it to be a simple host-to-router tunneling mechanism without direct
connectivity between hosts in the ISATAP domain.  That feature had
been included for at least a couple of years or so..

> It's time to make a concensus call on this issue. Frankly,
> this discussion has gone for a long time and no one is
> moving so let's get a feel for what the WG thinks.

The discussion has gone for long time, that's for sure, but I believe
only until recently we've been able to tease apart the assumptions
different people have about the requirements and the scenario in
question.  People have been talking past each other, with certain
assumptions in mind (e.g. about configuration required in configured
tunneling).  I believe there is progress to be made, if especially
folks who have taken ISATAP as their "one true solution" are willing
to keep the eyes open.

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