From julien.ietf@gmail.com Tue Apr 19 08:14:41 2011 Return-Path: X-Original-To: mext@ietfc.amsl.com Delivered-To: mext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F206BE0777 for ; Tue, 19 Apr 2011 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAn4ZH6FUKMr for ; Tue, 19 Apr 2011 08:14:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 69824E0769 for ; Tue, 19 Apr 2011 08:14:40 -0700 (PDT) Received: by iwn39 with SMTP id 39so6417617iwn.31 for ; Tue, 19 Apr 2011 08:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=akJCQG7vFn6FsabWqHld9fe9MDNRcxWcpGCqbaWy0NM=; b=jOHYcUIyAV7XT+MKPrZe1lCuHbe1MyBvwQo/ysmzPbDWOU1NqXlL5JlqqyBciymr60 x4vtfmYsVzZqpkoWkHhJLh/J3UVZ3Qqe6oXV2RZuIlCmVsng+lDvoGjAQNNbE13RUv6z ygFYUf7wXwyeGxKIVoMMuF1AoNy5vSsWX67sc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=kh5uVXLOFAYVkAKk5bbULychtZbvC9RJngRl73qrkLPEL7/vy1ICYfCC0kO077yFe3 PETDu6ZZHIZhbPvzT3xx5J6iEINDUcBzz64YNFhZ8BmUFbyxj9Jpjtwgagz7vqRV27lZ jy09yCTx0hfGbIgg5C42VoBQywMhju6kZ7S0s= MIME-Version: 1.0 Received: by 10.42.131.133 with SMTP id z5mr8042391ics.40.1303226080055; Tue, 19 Apr 2011 08:14:40 -0700 (PDT) Received: by 10.42.161.197 with HTTP; Tue, 19 Apr 2011 08:14:40 -0700 (PDT) Date: Tue, 19 Apr 2011 08:14:40 -0700 Message-ID: From: Julien Laganier To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [MEXT] IETF-80 meeting minutes posted X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:14:41 -0000 http://www.ietf.org/proceedings/80/minutes/mext.txt From pierrick.seite@orange-ftgroup.com Wed Apr 20 01:18:24 2011 Return-Path: X-Original-To: mext@ietfc.amsl.com Delivered-To: mext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 81A52E0670 for ; Wed, 20 Apr 2011 01:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ktcp7fonVLNC for ; Wed, 20 Apr 2011 01:18:23 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfc.amsl.com (Postfix) with ESMTP id 26ACAE067C for ; Wed, 20 Apr 2011 01:18:06 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3A81B73800E; Wed, 20 Apr 2011 10:17:39 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id C53226C0035; Wed, 20 Apr 2011 10:15:51 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 10:14:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 10:14:52 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A55BA2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IETF-80 meeting minutes posted / clarifications on draft-liu-mext-distributed-mobile-ip Thread-Index: Acv+pw/2z91/Q/w7T+KOC7ggghYB5QAi0vLw References: From: To: , X-OriginalArrivalTime: 20 Apr 2011 08:14:53.0587 (UTC) FILETIME=[06FD4E30:01CBFF33] Subject: Re: [MEXT] IETF-80 meeting minutes posted / clarifications on draft-liu-mext-distributed-mobile-ip X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:18:24 -0000 Hi guys, Julien, thanks for the minutes. I didn't attend the meeting but I went through the recorded session and = it seems there is couple of misunderstanding on item 5. Distributed = Deployment of Mobile IPv6 (draft-liu-mext-distributed-mobile-ip-00). So, = please let me, as co-author of this draft, try to clarify things: This draft includes considerations on deployment of current mobile IP in = distributed mobile architecture. This is a basic deployment where each = access router supports the HA function. Maybe it's not optimal but it = does not require modifications of MIP. The use-case is as follows: Consider a MN attached to the access router AR1. If the MN initiates a = flow (flow#1), flow#1 is routed in a standard way as long as the MN = remain attached to AR1. If the MN performs handover to a new access router, AR2:=20 - flow#1 remains anchored to AR1, which now plays the role of HA. Data = are tunnelled between AR1/HA1 and the MN. - If the MN initiates a new flow (flow#2), flow#2 is routed in a = standard way as long as the MN remain attached to AR2. In other words, one flow is anchored (flow#1) and the other flow = (flow#2) is not anchored. If the MN performs handover to a new access router, AR3: - Flow#1 remains anchored to HA1/AR1. Data are still tunnelled between = HA1/AR1 and the MN. - mobility support of AR2 comes into play and flow#2 is anchored to = AR2/HA2. Data are tunnelled between AR2/HA2 and the MN. In other words, both flows are anchored to two different HAs (flow#1 on = AR1/HA1 and flow#2 AR2/HA2). Here, there is no HA selection issue since, when the MN performs = handover, the previous AR becomes the mobility anchor for IP flows = initiated on it.=20 IMHO, the "multiple home addresses" feature was misunderstood during the = meeting. It is not require that a MN attached to a HA uses severals = HoAs. Actually, the MN can use several home addresses only when attached = to several HAs. Considering the use-case above, it means: - Flow#1 served by HA1/AR1 and uses HoA1 - flow#2 served by HA2/AR2 and uses HoA2 Home address selection: there was a confusion with source address = selection. Some applications can survive to IP handover and, thus, do = not need mobility support. We just say that these applications should = use a local address (CoA) as source address instead of an anchored = address (HoA).=20 Hope that clarifies. Regards, Pierrick > -----Message d'origine----- > De=A0: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part = de > Julien Laganier > Envoy=E9=A0: mardi 19 avril 2011 17:15 > =C0=A0: mext@ietf.org > Objet=A0: [MEXT] IETF-80 meeting minutes posted >=20 > http://www.ietf.org/proceedings/80/minutes/mext.txt > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From rkuntz@us.toyota-itc.com Wed Apr 20 13:31:37 2011 Return-Path: X-Original-To: mext@ietfc.amsl.com Delivered-To: mext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFF84E0753 for ; Wed, 20 Apr 2011 13:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm19yGlHLzNv for ; Wed, 20 Apr 2011 13:31:35 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfc.amsl.com (Postfix) with SMTP id 55D00E0669 for ; Wed, 20 Apr 2011 13:31:34 -0700 (PDT) Received: from mail-pv0-f170.google.com ([74.125.83.170]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTa9CpsekAeqg2FeDLLaGpe15bEToNmsx@postini.com; Wed, 20 Apr 2011 13:31:35 PDT Received: by mail-pv0-f170.google.com with SMTP id 16so826285pvg.15 for ; Wed, 20 Apr 2011 13:31:34 -0700 (PDT) Received: by 10.68.5.168 with SMTP id t8mr979322pbt.342.1303331494280; Wed, 20 Apr 2011 13:31:34 -0700 (PDT) Received: from orii-lt2.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id m10sm824568pbn.97.2011.04.20.13.31.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 13:31:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Romain KUNTZ In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201A55BA2@ftrdmel0.rd.francetelecom.fr> Date: Wed, 20 Apr 2011 13:31:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15658A73-D07B-4011-809F-4375F213EA9A@us.toyota-itc.com> References: <843DA8228A1BA74CA31FB4E111A5C46201A55BA2@ftrdmel0.rd.francetelecom.fr> To: "pierrick.seite@orange-ftgroup.com> X-Mailer: Apple Mail (2.1084) Cc: mext@ietf.org Subject: Re: [MEXT] IETF-80 meeting minutes posted / clarifications on draft-liu-mext-distributed-mobile-ip X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 20:31:37 -0000 Hello Pierrick, Allow to jump into the discussion, I have a couple of questions = regarding this draft. On Apr 20, 2011, at 1:14, = wrote: > IMHO, the "multiple home addresses" feature was misunderstood during = the meeting. It is not require that a MN attached to a HA uses severals = HoAs. Actually, the MN can use several home addresses only when attached = to several HAs. Considering the use-case above, it means: > - Flow#1 served by HA1/AR1 and uses HoA1 > - flow#2 served by HA2/AR2 and uses HoA2 Still, how does a CN that wishes to contact a MN selects the correct = Home Address? The MN would need to be always anchored to one HA in order = to keep at least one stable HoA over time.=20 Also, how would you prevent a malicious node to register 2 symmetric = bindings at 2 different home agents (say HoA1<->HoA2 at HA1, and = HoA2<->HoA1 at HA2), which could potentially lead to a routing loop = between both HAs?=20 Regards, Romain= From jan@go6.si Thu Apr 21 00:04:36 2011 Return-Path: X-Original-To: mext@ietfc.amsl.com Delivered-To: mext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1983DE071B for ; Thu, 21 Apr 2011 00:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG-sc0fI+M9U for ; Thu, 21 Apr 2011 00:04:35 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C8F3E0713 for ; Thu, 21 Apr 2011 00:04:35 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2001:1470:8000:566:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id CDBC52378033 for ; Thu, 21 Apr 2011 09:04:32 +0200 (CEST) Message-ID: <4DAFD81A.8060307@go6.si> Date: Thu, 21 Apr 2011 09:09:14 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext@ietf.org References: <843DA8228A1BA74CA31FB4E111A5C46201A55BA2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201A55BA2@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MEXT] IETF-80 meeting minutes posted / clarifications on draft-liu-mext-distributed-mobile-ip X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 07:04:36 -0000 On 4/20/11 10:14 AM, pierrick.seite@orange-ftgroup.com wrote: > IMHO, the "multiple home addresses" feature was misunderstood during > the meeting. It is not require that a MN attached to a HA uses > severals HoAs. Actually, the MN can use several home addresses only > when attached to several HAs. Considering the use-case above, it > means: - Flow#1 served by HA1/AR1 and uses HoA1 - flow#2 served by > HA2/AR2 and uses HoA2 Hi, From my point of view and how we are deploying mobility here it is desirable (or for our case mandatory) for MN to use only one stable HoA at all times, not many of them. At the same time it would be very nice to have multiple HAs, so you could connect to nearest one and optimize the path. My thought was to anycast HA address where MN connects and deal with HoA advertising on network side with dynamic routing protocols. Still need to think about that. Cheers, Jan From pierrick.seite@orange-ftgroup.com Thu Apr 21 03:51:54 2011 Return-Path: X-Original-To: mext@ietfc.amsl.com Delivered-To: mext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E5D41E06E1 for ; Thu, 21 Apr 2011 03:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_BACKHAIR_44=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylT7Qc3zgJdX for ; Thu, 21 Apr 2011 03:51:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfc.amsl.com (Postfix) with ESMTP id 33E05E06CD for ; Thu, 21 Apr 2011 03:51:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AD627858002; Thu, 21 Apr 2011 12:58:19 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A6070858001; Thu, 21 Apr 2011 12:58:19 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 12:51:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2011 12:51:51 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A55F7D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <15658A73-D07B-4011-809F-4375F213EA9A@us.toyota-itc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IETF-80 meeting minutes posted / clarifications on draft-liu-mext-distributed-mobile-ip Thread-Index: Acv/mfkp9vsSR9QdQS6W77oLMHGwWAAYRU9A References: <843DA8228A1BA74CA31FB4E111A5C46201A55BA2@ftrdmel0.rd.francetelecom.fr> <15658A73-D07B-4011-809F-4375F213EA9A@us.toyota-itc.com> From: To: X-OriginalArrivalTime: 21 Apr 2011 10:51:53.0062 (UTC) FILETIME=[1FD8E060:01CC0012] Cc: mext@ietf.org Subject: Re: [MEXT] IETF-80 meeting minutes posted / clarifications on draft-liu-mext-distributed-mobile-ip X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 10:51:55 -0000 Hi Romain, Thanks for the feedback. Please see inline. Regards, Pierrick > -----Message d'origine----- > De=A0: Romain KUNTZ [mailto:rkuntz@us.toyota-itc.com] > Envoy=E9=A0: mercredi 20 avril 2011 22:31 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: mext@ietf.org > Objet=A0: Re: [MEXT] IETF-80 meeting minutes posted / clarifications = on > draft-liu-mext-distributed-mobile-ip >=20 > Hello Pierrick, >=20 > Allow to jump into the discussion, I have a couple of questions = regarding > this draft. >=20 > On Apr 20, 2011, at 1:14, > wrote: > > IMHO, the "multiple home addresses" feature was misunderstood during = the > meeting. It is not require that a MN attached to a HA uses severals = HoAs. > Actually, the MN can use several home addresses only when attached to > several HAs. Considering the use-case above, it means: > > - Flow#1 served by HA1/AR1 and uses HoA1 > > - flow#2 served by HA2/AR2 and uses HoA2 >=20 > Still, how does a CN that wishes to contact a MN selects the correct = Home > Address? The MN would need to be always anchored to one HA in order to > keep at least one stable HoA over time. >=20 Right, reachability is an issue. Section 4.2 of = http://tools.ietf.org/html/draft-yokota-dmm-scenario gives clues for = solution. Relying temporally on a centralized mobility anchor point = could be also a solution. Anyway, we have to think more about that. > Also, how would you prevent a malicious node to register 2 symmetric > bindings at 2 different home agents (say HoA1<->HoA2 at HA1, and = HoA2<- > >HoA1 at HA2), which could potentially lead to a routing loop between = both > HAs? >=20 Good point. But, IMHO, this issue is not specific to a distributed = mobility architecture. For instance, = http://tools.ietf.org/id/draft-ng-intarea-tunnel-loop-00.txt discusses = the issue and proposes solution. > Regards, > Romain From rkuntz@us.toyota-itc.com Thu Apr 21 09:56:22 2011 Return-Path: X-Original-To: mext@ietfc.amsl.com Delivered-To: mext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54671E07D7 for ; Thu, 21 Apr 2011 09:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOKPRaEnkE7I for ; Thu, 21 Apr 2011 09:56:21 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfc.amsl.com (Postfix) with SMTP id C09BEE07C5 for ; Thu, 21 Apr 2011 09:56:20 -0700 (PDT) Received: from mail-pz0-f48.google.com ([209.85.210.48]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTbBhtFsN1s+JJ78ghU5XwxQ8MYSUJdWm@postini.com; Thu, 21 Apr 2011 09:56:20 PDT Received: by mail-pz0-f48.google.com with SMTP id 10so1233745pzk.7 for ; Thu, 21 Apr 2011 09:56:20 -0700 (PDT) Received: by 10.68.33.137 with SMTP id r9mr253229pbi.101.1303404979921; Thu, 21 Apr 2011 09:56:19 -0700 (PDT) Received: from orii-lt2.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id t6sm1414181pbi.64.2011.04.21.09.56.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2011 09:56:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Romain KUNTZ In-Reply-To: <4DAFD81A.8060307@go6.si> Date: Thu, 21 Apr 2011 09:56:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <98550E8B-9F06-4719-981C-D6D5FD11FCB8@us.toyota-itc.com> References: <843DA8228A1BA74CA31FB4E111A5C46201A55BA2@ftrdmel0.rd.francetelecom.fr> <4DAFD81A.8060307@go6.si> To: Jan Zorz @ go6.si X-Mailer: Apple Mail (2.1084) Cc: mext@ietf.org Subject: Re: [MEXT] IETF-80 meeting minutes posted / clarifications on draft-liu-mext-distributed-mobile-ip X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 16:56:22 -0000 Hello Jan, On Apr 21, 2011, at 0:09, Jan Zorz @ go6.si wrote: > =46rom my point of view and how we are deploying mobility here it is = desirable (or for our case mandatory) for MN to use only one stable HoA = at all times, not many of them. At the same time it would be very nice = to have multiple HAs, so you could connect to nearest one and optimize = the path. >=20 > My thought was to anycast HA address where MN connects and deal with = HoA advertising on network side with dynamic routing protocols. You may have a look at Global HAHA: http://tools.ietf.org/html/draft-wakikawa-mext-global-haha-spec-01 Regards, romain= From behcetsarikaya@yahoo.com Thu Apr 28 13:29:17 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366D7E06A6 for ; Thu, 28 Apr 2011 13:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEEQAkg4wyIe for ; Thu, 28 Apr 2011 13:29:15 -0700 (PDT) Received: from nm24.bullet.mail.sp2.yahoo.com (nm24.bullet.mail.sp2.yahoo.com [98.139.91.94]) by ietfa.amsl.com (Postfix) with SMTP id D3508E0679 for ; Thu, 28 Apr 2011 13:29:15 -0700 (PDT) Received: from [98.139.91.67] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 20:29:13 -0000 Received: from [98.139.91.52] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 20:29:13 -0000 Received: from [127.0.0.1] by omp1052.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 20:29:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 190222.13953.bm@omp1052.mail.sp2.yahoo.com Received: (qmail 72708 invoked by uid 60001); 28 Apr 2011 20:29:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304022552; bh=ZYL/J/l70hWP6WBLdIQFPgNpK9yYLjKL43KEI37aPVc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hFe7nNTsCTcgueYE9P6pCfhDtl2u92KtR1Z757CS76wP0QCuYvXJ+oSxnSwW3gWpLNHah7HMspMw/zUrFXnT2T40raFzODfl3ZG6y31ICSTfVN0MGFlZUBYWUn1ARmqUMdPoHfaH+FKhfxDAeVIWPu97PR8R0wjKG5Df8LU16Y0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4Se9hMQ6GJ3c3CY8UcE1DZnagaaiJ38J6KIP/evNEEeJrvX/JnJ3fwk0PldBb8Caf/iGQf1As4i4tH9IH6FBfZV9Ds4Jvvia5y4D8X7FOoxyX9d9YSWLjtA1MWJieHEvwwp+AG4+9pOl/W5M9AfmEfXbnL6OoZjENxN+Fv0AC4U=; Message-ID: <684224.63702.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: x_0mJyAVM1lSQYGC_kiSt6xYgDmix5u.bQalFU4.Wdo2aoe aqbrcZBrjS_tXoNvFIWhBHdp_iiVXfUaRX4qlk7X6t64wWrJSQtTabl1oJwy 17jSMtoKnXM1ptifmt7kwgfky2mCOtLTxJ88zR5a7zkqDnRTht_0lT8SGp6E RleC1jfeveAlGfRMhZPLXl_YpHmhUlqkRu9_LzJa_K5QtoXNsYwnCXLMb8L1 fb6qCqy54g72DwcXbfoYnHeBRisihUUv9sJ3N6.6agREArkh51LEi3ZkCEye bpy4z7T72v4Wj7agkpfTkOw1Ob_eiY_bdmQbGSIqgbzE70GCjwXP._P1_yKS E_bN.FxajRTC9VtlbOqXSVJUveJWo2iuQr49xuPnXY1ReVd4AUpVO95sd_Fo UXkXEq8JUY1UzHw-- Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Thu, 28 Apr 2011 13:29:12 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <843DA8228A1BA74CA31FB4E111A5C46201A55BA2@ftrdmel0.rd.francetelecom.fr> <4DAFD81A.8060307@go6.si> <98550E8B-9F06-4719-981C-D6D5FD11FCB8@us.toyota-itc.com> Date: Thu, 28 Apr 2011 13:29:12 -0700 (PDT) From: Behcet Sarikaya To: Romain KUNTZ , "Jan Zorz @ go6.si" In-Reply-To: <98550E8B-9F06-4719-981C-D6D5FD11FCB8@us.toyota-itc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] IETF-80 meeting minutes posted / clarifications on draft-liu-mext-distributed-mobile-ip X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:29:17 -0000 Hi Romain, > > Hello Jan, > > On Apr 21, 2011, at 0:09, Jan Zorz @ go6.si wrote: > > From my point of view and how we are deploying mobility here it is desirable >(or for our case mandatory) for MN to use only one stable HoA at all times, not >many of them. At the same time it would be very nice to have multiple HAs, so >you could connect to nearest one and optimize the path. > > > > My thought was to anycast HA address where MN connects and deal with HoA >advertising on network side with dynamic routing protocols. > > You may have a look at Global HAHA: > http://tools.ietf.org/html/draft-wakikawa-mext-global-haha-spec-01 Thanks for pointing this out, I was almost reading another draft. I think Global HAHA is good, it solves almost all problems we have in DMM maybe the expense of introducing a fairly complicated protocol and a lot of configuration requirements. Regards, Behcet