Subject: [MEXT] IETF-80 meeting minutes posted

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Apr 2011 08:14:40 -0700

http://www.ietf.org/proceedings/80/minutes/mext.txt

---

From: <[email-masked]>
Date: Wed, 20 Apr 2011 10:14:52 +0200

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

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

Hope that clarifies.

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Julien Laganier
> Envoyé : mardi 19 avril 2011 17:15
> À : [email-masked]
> Objet : [MEXT] IETF-80 meeting minutes posted
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 20 Apr 2011 13:31:25 -0700

Hello Pierrick,

Allow to jump into the discussion, I have a couple of questions regarding this draft.

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

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? 

Regards,
Romain

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Thu, 21 Apr 2011 09:09:14 +0200

On 4/20/11 10:14 AM, [email-masked] 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: <[email-masked]>
Date: Thu, 21 Apr 2011 12:51:51 +0200

Hi Romain,

Thanks for the feedback. Please see inline.

Regards,
Pierrick

> De : Romain KUNTZ [mailto:[email-masked]]
> Envoyé : mercredi 20 avril 2011 22:31
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]
> Objet : Re: [MEXT] IETF-80 meeting minutes posted / clarifications on
> draft-liu-mext-distributed-mobile-ip
> 
> Hello Pierrick,
> 
> On Apr 20, 2011, at 1:14, <[email-masked]>
> <[email-masked]> 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:
> 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.
> 

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

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.

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 21 Apr 2011 09:56:15 -0700

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

Regards,
romain

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 28 Apr 2011 13:29:12 -0700 (PDT)

Hi Romain,

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

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