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

[Soliman Hesham <H.Soliman@flarion.com>]

 > As for the client side configuration...
 > 
 > No, this does not seem to be the case.  The user just has to find out
 > the IPv4 address of the tunnel endpoint somehow.  As the tunnel
 > endpoint is located at its local 3GPP operator, it is fairly static,
 > and can even be routed somewhere else in the IGP if it moves.  Manual
 > one-time config (need to be redone only if you switch your home
 > operator) is sufficient, as well as doing it with an SMS [as one-time
 > config], looking it up from the DNS, or something else.
 > 
 > So there clearly seems to be some disconnect here, maybe some 
 > assumptions which haven't been spelled out.
 >  
 > Now, the network side configuration is slightly trickier..
 > 
 > 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.



   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. 

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. 

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.

Hesham


(This is
 > elaborated a bit in the STEP draft already mentioned.)  There are 
 > probably other ways to tackle this problem as well.
 > 
 > The point is, the client configuration seems close to trivial.  The
 > network configuration is slightly trickier, but should be manageable.
 > 
 > > > Sounds like a circular argument without justification.
 > > 
 > > I think the justification is above.
 > 
 > Nope, there are still some assumptions out there...
 >  
 > > > We know that there is a scenario where tunneling is desirable in
 > > > certain cases, yes.  However, I'm not sure if we know 
 > the requirements
 > > > of the scenario, or the scenario itself, well enough yet (see the
 > > > points above why exactly configuring is bad, what 
 > exactly would need
 > > > to be configured, etc.).
 > > 
 > > Configuration would not work. I think this has been explained above
 > > and in other mails sent on this list. Trust me on this - 
 > configuring
 > > the tunnels can be at the most a very marginal case.
 > 
 > Based on the misunderstandings as shown above, I do not believe 
 > different people have a right mindset when they talk about 
 > "configuration".  I'm not sure if folks realize that it's really not 
 > so complicated.  See above.
 > 
 > > > I don't know what you mean by the ISATAP reference.  
 > Clearly, we could
 > > > take it, and apply it in this specific scenario, and I 
 > think it would
 > > > work, at least to some definition of "work".  That 
 > doesn't mean it's
 > > > the right thing to do, of course. Is it the *right* tool for 
 > > > the job?  
 > > 
 > > It is at least one possible tools for this job. Do you have others
 > > candidates (except for configured tunnels)?
 > 
 > Configured tunnels work just fine.
 >  
 > > > For example, a proof of concept procedure was introduced in
 > > > draft-savola-v6ops-conftun-setup-01.txt; it would 
 > probably solve the
 > > > problem in a much simpler and easier way; it's basically just
 > > > expanding the couple of bullet points above about 
 > configured tunneling
 > > > set-up methods.  In the case of 3GPP, only proto-41 
 > would be necessary
 > > > -- basically just configured tunneling at the UE, and 
 > some tricks at
 > > > the 3GPP operator side, depending on the mode in which 
 > it wishes to
 > > > operate.
 > > 
 > > Sorry, I read the document really, really quickly. It is an
 > > interesting document and we should discuss the different solutions
 > > if we decide to go to the solutions space (not wearing chair hat-I
 > > think it would be time). Of course, we have to consider all
 > > solutions.
 > 
 > I'm not sure if it makes sense to look into solutions too much yet
 > (but soon would be time for 3GPP I guess), as it clearly seems that 
 > the scenario is not spelled out clearly enough.
 > 
 > -- 
 > Pekka Savola                 "You each name yourselves king, yet the
 > Netcore Oy                    kingdom bleeds."
 > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
 > 
 >