[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Going forward with zero-config tunneling requirement



Pekka, Jordi,

> 
> Jordi,
> 
> I think you were missing one assumption about 3GPP, that their 
> solution would only be needed when there is no NAT traversal or 
> proto-41 forwarding, i.e., the 3GPP operator provides the tunnel 
> endpoint.  If that's not the case, all bets are off.  Below..
> 
> On Thu, 30 Sep 2004, JORDI PALET MARTINEZ wrote:
> > My view actually is that 2 & 3 could be the same, specially because
> > in the real world I've seen GPRS deployment both with no-NAT (public
> > addresses) and using NAT (with private addresses). But in the later
> > case, NAT traversal was not required because proto-41 forwarding
> > worked. Of course, this may be not the case all the time !
> > 
> > I also understand that having a zero configuration solution w/o NAT
> > traversal could be technically very difficult and probably 
> will mean that
> > the solution will not be "simple" as required by 3GPP (no 
> new "whatever" in
> > the existing infrastructure). Of course, everything needs 
> to be balanced and
> > considered.
> 
> The assumption of '3GPP' case is that even if private addresses are
> used, there is no need for NAT traversal, because the
> zero-configuration tunnel server is provided in the 3GPP network,
> i.e., in the same 'addressing domain'.
> 
> The zero-configuration solution for 3GPP does not try to solve the
> case where the 3GPP operator does not provide the tunnel endpoint.  
> [Karen: maybe this should be made more explicit in the requirements]
> 

Agreed. Especially now that we are restricting the doc to this case only.

> That would be rather close to the 'ISP' zero-config situation.
> 
> (FWIW, I think it's certainly a consideration whether a 3GPP UE could
> work even when the 3GPP operator does not provide this capability, or
> in an enterprise's WLAN environment, or whatever -- in that sense,
> having a more generic solution would seem to be rather helpful.  But
> that's something that needs to be debated later.)
> 
> > Finally, my opinion is that a single document can take both 3GPP and
> > non-3GPP zeroconfig, but may be we need to progress a 
> little bit on the
> > solution or candidate solutions to assert that ?
> 
> Could be (I personally thought so), but there was reluctance to this, 
> but we need to make progress in the requirements, and this is one 
> approach to accomplish it.
> 

By referencing to the 3GPP case, the new zeroconfig document does not
explicit exclude the 3GPP case. To me then we are simply isolating the 3GPP case 
first and foremost because of its critical timing requirements. To what extend
it deserves to be isolated also from a pure technical perspective remains to be seen..

BR, Karen