Subject: FW: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 19 Apr 2007 18:50:40 -0700

Hi Alice,

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Thursday, April 19, 2007 5:29 AM
> To: qinxia
> Cc: 'Sri Gundavelli'; [email-masked]
> Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt
> 
> >> [Sri]
> >> If multiple LMA's are configured to serve a mobile node, and 
> >> when the mobile node moves between the MAG's, the new MAG 
> >> would not be able to predictably identify the LMA that has 
> >> the BCE for the mobile node.
> >> This is not an issue in 3775, as the state moves with the 
> >> mobile. So, we either have context transfer procedures or the 
> >> MAG would not know where to send the PBU. Also, from routing 
> >> perspective, with the per-mn-prefix model and not having a 
> >> physical link that can be shared by two LMA's, both the LMA's 
> >> have to advertise the aggregated prefix into IGP and it can 
> >> get tricky as where the packets get directed.
> >>
> > [qx]: How to detect whether the share tunnel is still 
> alive? How to get to know the
> > LMA does not go kaput? Does it depend on PBU/PBA or other? 
> How long it takes by
> > PBU/PBA?
> 

As Christian says, the fail-over is not in scope. Now, if the
question on how the mobile detects if the tunnel is alive
or not, that is under the generic 3775 guidance. Its mostly
from ICMPv6 host unreachable messages for the tunneled
data packet or even for the BU/BA control messages. That's
one of the indicators. So, this is a general issue applicable
to 3775 mobile nodes and to 3963 mobile routers, not just
specific to PMIP6.

Regards
Sri 

> Alice,
> 
> fail-over is really too complex to be included into the base protocol
> specification.  One cannot just rely on the PBU/PBA exchange during
> registration, as LMA failure between successive registrations would
> remain undetected or get detected only late.  Especially with 
> localized
> mobility management, users would rightly expect fail-over to 
> happen very
> efficiently.
> 
> Beyond failure detection, LMA fail-over would need to include routing
> updates so as to direct packets destined to the MN via the new LMA.
> This might require updates to IGP, as Sri has mentioned, or
> other mechanisms that are transparent to routers outside the localized
> mobility management domain.
> 
> Finally, fail-over includes updating the MN's serving MAG.  If the
> policy store holds the MN's assigned LMA, then the store must 
> be updated
> as well.
> 
> These are just some topics to be considered, and the devil is, of
> course, in the details.  So I would really recommend not to 
> discuss LMA
> fail-over at this point, but attend to it at a stage when the base
> protocol is out.  As I mentioned in an earlier mail, lack of 
> a fail-over
> mechanism doesn't necessarily prevent the base protocol from allowing
> multiple LMA per domain.  Just the number of LMAs assigned to 
> a given MN
> should be limited to a single one, which in turn could be 
> identified in
> the MN's policy store entry.
> 
> Does this sound reasonable to you?
> 
> - Christian

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 19 Apr 2007 18:55:11 -0700

Hi JinHyeock,

> From: JinHyeock Choi [mailto:[email-masked]] 
> Sent: Wednesday, April 18, 2007 6:17 PM
> To: Sri Gundavelli
> Cc: [email-masked]
> > 1. An MN with a home network prefix roams and attaches to 
> an another MAG.
> > 2. The MAG contacts the policy store.
> > 3. The policy store
> >   SHOULD (MAY) provide the MN's LMA address (existing home 
> network prefix).
> >
> > [Sri] It SHOULD. Certain access technologies may be using 
> some context
> > transfer procedures and the serving MAG MAY have this 
> information from
> > other sources and in that case, the LMA address need not be 
> present in
> > the policy store.
> 
> I see. 'The procedure to acquire MN's profile', is this out of scope?
> Will the draft just mention that MAG gets MN's profile with either
> Context Transfer or Policy Store?
> 

Yes. How the MAG obtains the mobile node's profile is implementation
specific, it MAY be from a Local/Remote Policy Store or as part of
a context transfer trigger, and is not in the scope of this work.

Regards
Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Apr 2007 09:00:09 -0700 (PDT)

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: JinHyeock Choi <[email-masked]>
Cc: [email-masked]
Sent: Thursday, April 19, 2007 7:40:18 PM
Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

Hello JinHyeock,

Sorry for disappearing from this thread for a while.

JinHyeock Choi wrote:

>> The default would be to *not* store the MN's home prefix
>> in any "policy store". The default would be for the LMA
>> to assign this prefix when it receives a proxy BU from a
>> MAG for the first time for a particular mobile node.
>>
>> Once the MAG obtains the prefix, it will start emulating
>> the MN's home network. This also means the router advert
>> is sent after receiving the proxy Binding Ack.
> 
> As I wrote to Sri, we'd better deal with this in two separate cases 1)
> initial attachment & 2) roaming inside PMIPv6 domain.
> 
> I can see how your description will work for the initial attachment
> case but can't be sure of the roaming case.

The same mechanism can be used in the handover case too.
(lets not call it roaming).

> Assume an MN is allocated prefix 1 as its home network prefix. When it
> moves to a new MAG inside the same PMIPv6 domain, how can the new MAG
> know the MN's current home network prefix, prefix 1?

MAG2 would also get the home prefix for the mobile node
from the LMA. MAG2 will not start emulating the home link
until it gets the prefix from the LMA.

Having the MN's prefix in the policy store is a bit
cumbersome. I would rather see the LMA dynamically
managing the prefixes for the mobile node. After all
the routing in a network, where the LMA sits, is setup
so that packets meant for the MN's prefix reach a
particular LMA.

[behcet] I think that the techniques we presented on our draft 
draft-sarikaya-16ng-prefix-delegation
can be used by HA acting as AR of this draft, as 
the draft gives a design for prefix assignment of per-MN prefixes
in p2p links.
If there is a need we can write a draft with details for netlmm.

There should also be an ability to dynamically assign
an LMA to a mobile node. Having prefixes stored in a
policy store and dynamically assigning LMAs don't go
together.

Vijay

> Or, if the MAG doesn't know the MN's current home network prefix, how
> can it emulate its home network and send PBU?
> 
> I think that we'd better clarify
> 1) how to assign a home network prefix to an MN when it attaches to
> PMIPv6 domain for the first time &
> 2) how can a new MAG acquire an MN's existing home network prefix when
> the MN roams inside PMIv6 domain.
> 
> Thanks for your kind consideration.
> 
> Best Regards
> 
> JinHyeock