[Mobopts] RE: About draft-weniger-mobopts-mip6-cnlocpriv

Hi Jouni,

Thanks for the comments. Please see my replies below. 

> -----Original Message-----
> From: jouni.korhonen@teliasonera.com 
> [mailto:jouni.korhonen@teliasonera.com] 
> Sent: Mittwoch, 25. Juli 2007 21:19
> To: Kilian.Weniger@eu.panasonic.com; mobopts@irtf.org
> Subject: About draft-weniger-mobopts-mip6-cnlocpriv
> 
> Hi Kilian,
> 
> I think it would be useful to add some text and discuss a bit of the
> issues related to the assumptions that the I-D makes regarding the
> discovery of an optimal HA / MSP for a given CN / CN domain.
> 
> Mainly because.. It was stated during the prez that a visited 
> MSP domain
> and a CN domain does not need to have any relation with each other. I
> would
> like to understand how a MN can figure out reliably, even to some
> extent,
> that the visited MSP and the CN domain are topologically close to 
> each other. The MN cannot trust much to prefix information 
> (e.g. if CNs
> use PI blocks) and the MN cannot trust much to DNS (as operators or
> service
> providers do play a lot with DNS). As stated during the prez the

This all depends on the ORHA discovery mechanism in use. 

One option that the draft discusses is DNS-based ORHA discovery with DNS
entries maintained by the MSA, such as "<CNdomain>.ORHA.<MSAdomain>".
The MSA providing the ORHA service would be able to know which of its
MSPs/Has are close to some popular CN domains/prefixes. 

I assume that "play a lot with DNS" means that the IP address that a
client gets back from DNS for a specific FQDN depends on the client's
location? Since the MSA would specifically maintain DNS entries for the
purpose of discovering ORHAs, the operator should not "play" with such
DNS entries of course. So I don't think that "playing with DNS" is a
problem here. I can add some text to make it explicit that an operator
should not "play" with these DNS entires.

> situation gets even trickier when the CN is also mobile. Do you have
> any reliable methods in mind that could be used to verify the close
> proximity of the MSP and the CN?

Optimizing the route further when the CN is mobile is a different
scenario, which is out of scope of the draft. Note that RFC3775 also
doesn't consider mobile CNs and that the RFC3775 RO mode path is
suboptimal in mobile CN case, so this is not an issue that is specific
to this draft.

> 
> I also highly doubt that an operator who has nothing to do with a CN
> domain would populate its DNS with any information that would allow
> finding the closest HA to the said CN domain. And wise versa a CN
> domain populating DNS with information of random MSPs is imho at least
> questionable.

I think this just depends on the business model (which of course is out
of scope of the draft). However, the draft has some text on this:

   "Since
   location privacy can be seen as a value-added service, a user may be
   willing to pay for this service.  This may be an incentive for an MSA
   to offer this service and delegate the mobility management to an MSP
   located close to the correspondent node."

> 
> The situation is of course different if the MSP and the CN domain are
> 'the same domain', which is a typical local HA allocation case..

Thanks,

Kilian

> 
> Cheers,
> 	Jouni
> 
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts