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

"Kilian Weniger" <Kilian.Weniger@eu.panasonic.com> Wed, 25 July 2007 21:05 UTC

Return-path: <mobopts-bounces@irtf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo3R-0001K6-CG; Wed, 25 Jul 2007 17:05:57 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo3Q-0001Hw-72 for mobopts@irtf.org; Wed, 25 Jul 2007 17:05:56 -0400
Received: from cluster-b.mailcontrol.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDo3O-0004Ss-O9 for mobopts@irtf.org; Wed, 25 Jul 2007 17:05:56 -0400
Received: from rly29b.srv.mailcontrol.com (localhost.localdomain []) by rly29b.srv.mailcontrol.com (MailControl) with ESMTP id l6PL5rhV017869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <mobopts@irtf.org>; Wed, 25 Jul 2007 22:05:53 +0100
Received: from submission.mailcontrol.com (submission.mailcontrol.com []) by rly29b.srv.mailcontrol.com (MailControl) id l6PL5Ts6016978 for mobopts@irtf.org; Wed, 25 Jul 2007 22:05:29 +0100
Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com []) by rly29b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l6PL5SRU016916; Wed, 25 Jul 2007 22:05:29 +0100 (BST)
Received: from eundadmi01.pan.eu( by hhe500-02.hbg.de.pan.eu via smtp id 2a02_71504918_3af1_11dc_91be_0030482aac25; Wed, 25 Jul 2007 22:55:57 +0200
Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007072523052646-68015 ; Wed, 25 Jul 2007 23:05:26 +0200
X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.114,BAYES_00: -1.665,TOTAL_SCORE: -1.551
Received: from localhost ([]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 25 Jul 2007 23:05:13 +0200
MIME-Version: 1.0
x-mimeole: Produced By Microsoft Exchange V6.5
In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301F27330@SEHAN021MB.tcad.telia.se>
Thread-Topic: About draft-weniger-mobopts-mip6-cnlocpriv
thread-index: AcfO8LHeHi9zbBq7Q2Wl9glwlUq7fwACmwpw
References: <59D7431DE2527D4CB0F1EFEDA5683ED301F27330@SEHAN021MB.tcad.telia.se>
To: jouni.korhonen@teliasonera.com, Kilian.Weniger@eu.panasonic.com, mobopts@irtf.org
Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB3B07FC@lan-ex-02.panasonic.de>
Date: Wed, 25 Jul 2007 23:05:07 +0200
From: Kilian Weniger <Kilian.Weniger@eu.panasonic.com>
Content-class: urn:content-classes:message
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Subject: [Mobopts] RE: About draft-weniger-mobopts-mip6-cnlocpriv
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Errors-To: mobopts-bounces@irtf.org

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:

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



> 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