Re: [Int-area] Discovering a Location Server in the Access Network

[Alexandru Petrescu <[e-mail]>]

Hi Hannes, let me try to give some thoughts.  But your mail is such a
concentrate of information to newcomers to GEOPRIV.

I'm not sure I get everything right, but anyways, here goes.

Hannes Tschofenig wrote:

> 
> A year ago I lead a design team that captured the problem statement
> and requirements. The document is available here: 
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt
draft-ietf-geopriv-l7-lcp-ps-05.txt:
> 3.2.  Moving Network
> 
>    An example of a moving network is [...]

(As a side note, I'm happy that the GEOPRIV L7 PS and reqs document 
mentions moving networks and describes them.  I'm already happy with the 
terminology, because many people I'm talking to seem to refuse to accept 
this 'moving network' term and prefer 'mobile network' ignoring the 
potential clash with 'mobile networks' that don't move but support 
mobility of hosts.

One would also maybe cite "mobile network" of RFC4885 "Network Mobility 
Support Terminology" and "Mobility Terminology" RFC3753 and last but not 
least rfc2002 Mobile IPv4 probably the first to mention "mobile 
networks" in its section 4.5.  I think MANET documents may too.

Technically, the 'moving networks' you describe are a little bit 
different than the 'mobile networks' which run Mobile IP NEMO 
extensions.  Your movnets have the LFN (your Ethernet laptop) do the 
PPPoE game and use the MR (your NTE) as a modem I believe.  A multi-host 
WiMax deployment.  The 'mobile networks' have the Mobile Router (your 
NTE) do the dialup, eventually PPPoE but any other PtP or shared media, 
for the access.

But, I think 'moving networks' per your definition and 'mobile networks' 
per Mobile IP stuff are conceptually the same thing.  I'd like to be 
able to call the Mobile IP NEMO-based 'mobile networks' - 'moving networks'.

Anyways, just a digression.)

>  In short, the current proposal (see 
> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt;
>  ignoring Section 2 which defines the DHCP portion) essentially does 
> the following:
> 
> * Discover the public IP address of the end point

I think it should say 'Discover ... address of the LIS', right?   And
not 'of the end point'(?)

[...]
> We have investigated other solutions as well (see Section 4 of 
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt)
>  but the group (or at least a few folks) believes that this is a 
> "good" approach.

Section4:
> DHCP-based discovery, DNS-based discovery, Redirect [HTTP or AAA] 
> rule, multicast DNS queries, anycast and Teredo discovery.

That's fine it covers all I could think of, but there's (1) the
EXPERIMENTAL IPv6 Node Information Queries RFC4620 as well.  It's
limited to link-local multicast but I think that would be an advantage
(and not an inconvenient) because one would want that LIS server to be
as close to the querier, for geographical precision, I think.

Some IKEv2 extension possibility for discovering parameters too, and
BOOTP and last but not least Service Location Protocol RFC2165.

draft-thomson-geopriv-lis-discovery-02:
> 1.2. U-NAPTR Discovery
> 
> Where DHCP is not available, the DNS might be able to provide a URI.

If DHCP is not available then the host doesn't have the DNS Server
address either, thus no way to obtain that URI, right?

If I can manually configure the DNS Server address then I can manually
configure its location info as well, right?

Alex

> 
> I had a chat with Jari and we both agree that this topoic falls into 
> the expertise of the Internet Area. Hence, I would like to solicit 
> feedback from you.
> 
> Ciao Hannes
> 
> 
> 
> _______________________________________________ Int-area mailing list
>  [e-mail] 
> https://www1.ietf.org/mailman/listinfo/int-area
> 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area