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

From: Soliman Hesham <[email-masked]>
Date: Wed, 26 Nov 2003 06:16:02 -0500

> > => 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, 

=> Of course it knows it but it will know it in a different
box (i.e. GGSN and DHCP for v4) but the tunnel end point
is not on either one of those boxes.

   if for no other reason, but because it's tunneled back from the 
 > foreign network.  

=> I don't get this.

 > >  > 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 doesn't exist today in routers AFAICS. And there is 
no reason to introduce it when we can do with other mechanisms
in products that people seem to prefer.

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

=> We can't assume that it is not well understood
because one person made a mistake. It is implemented
on 4 different products that I know of (2 host platforms
and two router platforms) and are all interoperable. 

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

=> And vice versa. 

Hesham

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Nov 2003 14:30:03 +0200 (EET)

> is not on either one of those boxes.

Certainly.  But this is no problem.  You can get that information
using some means, e.g. SNMP.  I don't know which kind of interfaces
3GPP boxes have, and which kind management systems they connect to,
but I'm pretty sure there can be ways to extract that information.

>  > if for no other reason, but because it's tunneled back from the 

I mean, I understand foreign 3GPP operators use something like L2TP to 
transport the IPv4 packets back to the home operator, correct?  The 
home operator has to have some kind of policy to who will be allowed 
in its network, i.e., when decapsulating the L2TP stream from the 
foreign operator, the 3GPP operator should check the source addresses 
of the packets (or at least do something to check that the packets are 
valid, for billing etc. reasons if for nothing else).

> => It doesn't exist today in routers AFAICS. 

Pretty close to trivial to implement.

> And there is no reason to introduce it when we can do with other
> mechanisms in products that people seem to prefer.

On the contrary, there is no reason to bless a solution (and impose
the burden of the solution on everyone eelse) that some have chosen
because they didn't think of alternative ways to achieve the result.

> because one person made a mistake.

I can read myself, and I can say for sure that it isn't well 
understood. :-)

> It is implemented

Implementatable & interoperable is VERY FAR from being well
understood.