Subject: [netlmm] PMIP6-MIP6 Interactions - Take 2

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 28 Oct 2008 14:13:20 -0700

All,
<Chair Hat On>
A few weeks ago, we had a discussion on supporting the colocated LMA/HA case (Scenario C in draft-ietf-netlmm-mip-interactions-00) with a single vs. separate BCE to manage the MIP6 and PMIP6 entries.  I have reviewed all the emails on this topic from a few weeks ago and note that we do not have consensus yet on this topic.  I will attempt to summarize the main points raised here and see if we can get to some form of consensus.  If this try results in lack of consensus again, the chairs and the AD will review all the technical points and make a decision on the way forward. 

First, before moving to a summary of the points, I want to note a few things. 

- This discussion is about what we need to specify at the IETF.  Please refrain from specific discussions on what has been done in 3gpp or WiMAX or any other SDO.  We can get requirements from other SDOs, but, ultimately, we decide what to specify in our specs with a discussion here. 

- As IETF, we need to specify what works for the general Internet, with regular IP and MIP6 capable nodes.  We cannot assume SDO-specific solutions or any restrictions on managing interfaces at the MN to be in place.   

- The support for this scenario is based on a desire to support packet delivery without tunnel headers (or ROHC, necessarily) while the MN is on the home link (by extending the home link to be a home network using PMIP6).  We are not supporting this scenario just because 3gpp has chosen this scenario - if there was no logical explanation for supporting this, we'd be specifying a 3gpp specific document for this or just leave it to 3gpp to specify it in their specs. 

On to technical points, here is a brief summary to help the discussion: 

- It may help to view the discussion in terms of processing behavior of the HA/LMA.  This leads to the following two options - a) always use the MIP6 BCE and only use the PMIP6 BCE when there is no MIP6 BCE vs. b) forward using the most recently updated BCE.  

- The issue of the separate vs. same BCEs is also relevant from the point of view of whether the MIP6 BCE is going to be overwritten by the PMIP6 BCE or not.  

Summarizing concerns with a), we have: 

- Additional memory needed to maintain both the MIP6 and PMIP6 BCE during the time of transition 

- Additional 1RT delay between the MN and LMA before packets can be forwarded to the new CoA when compared to b) 

Summarizing concerns with b), we have: 

- There is no way to tell if the MN intended to handoff or be multihomed with the new CoA.  Hence, if the BCE is overwritten, it may have incorrectly eliminated the multihoming for the MN. Packets sent from the MN using the old CoA will now be dropped. 

If there are additional concerns with either approach that I have failed to note, please let me know.  

Please respond to this email selecting option a) or b) and providing reasons why the corresponding concerns either do not apply or how they can be mitigated.  

</chair hat on>

Thanks,
Vidya

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

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 28 Oct 2008 18:22:13 -0400

Hi Vidya,

> If there are additional concerns with either approach that I have failed to note, please let me know.  

With b) an additional concern is that a reordered BU/PBU can result in a 
complete loss of connectivity (absent any yet to be specified mitigation 
measures).

Thanks
Suresh

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 28 Oct 2008 19:12:18 -0400

Hi Vidya,

> - There is no way to tell if the MN intended to handoff or be
multihomed
> with the new CoA.  Hence, if the BCE is overwritten, it may have
> incorrectly eliminated the multihoming for the MN. Packets sent from
the
> MN using the old CoA will now be dropped.

[RKo:>] I am not sure I follow the multihoming argument. If the MN uses
two different interfaces, there will be two different BCEs, right? If it
has a single interface that transitions from PMIP6 to MIP6 (or vice
versa), it would be handover. I might be missing something..

Regards,

-Rajeev

> 
> If there are additional concerns with either approach that I have
failed
> to note, please let me know.
> 
> Please respond to this email selecting option a) or b) and providing
> reasons why the corresponding concerns either do not apply or how they
can
> be mitigated.

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 29 Oct 2008 16:28:45 +0100

Vidya,

> multihomed with the new CoA.  Hence, if the BCE is 
> overwritten, it may have incorrectly eliminated the 
> multihoming for the MN. Packets sent from the MN using the 
> old CoA will now be dropped. 

BCE overwriting is not a property of approach "b) forward using the most
recently updated BCE", so this can't be a concern for b). 

I guess you mixed up "single BCE" implementation option and approach "b)
forward using the most recently updated BCE"?

BR,

Kilian

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

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 29 Oct 2008 16:28:43 +0100

Hi Suresh,
 
> complete loss of connectivity (absent any yet to be specified 

Actually, this concern is not serious in my opinion, because the
mitigation measure can be very simple and can be done using already
specified protocols. For instance, LMA can just send BRI message with
revocation trigger "Possible Out-of Sync BCE State" as specified in
draft-ietf-mext-binding-revocation-01, when PBU/BU arrive consecutively.

BR,

Kilian

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 29 Oct 2008 14:21:07 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Koodli, Rajeev
> Sent: Tuesday, October 28, 2008 4:12 PM
> To: [email-masked]
> Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2
> 
> 
> Hi Vidya,
> 
> [RKo:>] I am not sure I follow the multihoming argument. If 
> the MN uses two different interfaces, there will be two 
> different BCEs, right? If it has a single interface that 
> transitions from PMIP6 to MIP6 (or vice versa), it would be 
> handover. I might be missing something..
> 

There is no way for the network to know whether the MN acquired that new CoA on the same or different interface.  Worse still, the MN may have configured an additional address on the same interface.  

Regards,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 29 Oct 2008 14:28:55 -0700

> From: Kilian Weniger [mailto:[email-masked]] 
> Sent: Wednesday, October 29, 2008 8:29 AM
> To: Narayanan, Vidya; [email-masked]
> Subject: RE: [netlmm] PMIP6-MIP6 Interactions - Take 2
> 
> Vidya,
> 
> overwritten, it may 
> > have incorrectly eliminated the multihoming for the MN. 
> Packets sent 
> > from the MN using the old CoA will now be dropped.
> 
> BCE overwriting is not a property of approach "b) forward 
> using the most recently updated BCE", so this can't be a 
> concern for b). 
> 
> I guess you mixed up "single BCE" implementation option and 
> approach "b) forward using the most recently updated BCE"?
> 

With the base PMIP6 spec, there can only be one CoA for a given HNP.  Same is the case with RFC3775 for MIP6 (for a HoA).  Hence, in a way, regardless of whether the entry is overwritten or not, it is not straightfoward within the scope of these specs to maintain two CoAs for the same HoA/HNP.  

Even if we chose to maintain multiple CoAs, the network will be making the assumption that the latest CoA is the primary CoA, which may or may not be correct.  For example, if the MN is using MIP6 over its WLAN interface and now adds a 3G interface and suddenly all of the video downloads switch to the 3G interface, that would be a bad thing.  Further, it is a bit premature to design it that way, since, we don't yet know what an MCoA solution for a combined PMIP6/MIP6 system will look like.  

Regards,
Vidya

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 30 Oct 2008 08:53:27 +0800

Hi Vidya,

I agree with Rajeev. For multihoming case we need both BCEs(PMIP and
MIP)
to be present at LMA/HA and moreover both should be valid. 

This issue we are discussing is for single interface case. Having both
caches simultaneously available at LMA and yet using only MIPv6 or PMIP
when MIPv6 cache is not there does not achieve multihoming. As you have
mentioned, we have not discussed multihoming in a PMIP and MIP scenario
yet. Thus all the discussion should focus on handover or some other
PMIP/CMIP switch (perhaps due to roaming) for a single interface case. 

Thanks.

BR,
Mohana

 > There is no way for the network to know whether the MN 
> acquired that new CoA on the same or different interface.  
> Worse still, the MN may have configured an additional address 
> on the same interface.

> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> Sent: Thursday, October 30, 2008 5:21 AM
> To: Koodli, Rajeev; [email-masked]
> > [RKo:>] I am not sure I follow the multihoming argument. If the MN 
> > uses two different interfaces, there will be two different BCEs, 
> > right? If it has a single interface that transitions from PMIP6 to 
> > MIP6 (or vice versa), it would be handover. I might be missing 
> > something..
> > 
> 
> There is no way for the network to know whether the MN 
> acquired that new CoA on the same or different interface.  
> Worse still, the MN may have configured an additional address 
> on the same interface.  
> 
> Regards,
> Vidya
> 
> > Regards,
> > 
> > -Rajeev
> > 
> > >

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 29 Oct 2008 21:27:37 -0400

> There is no way for the network to know whether the MN acquired that
new
> CoA on the same or different interface.  Worse still, the MN may have
> configured an additional address on the same interface.
> 

[RKo:>] On PMIP BCE, you would have ATT. Are you saying that on the same
interface (represented by ATT), you could have the MN obtain a CoA?

(I thought the problem scope was transitioning from a PMIP domain, where
the MN does not obtain CoA and perform MIP BU, to MIP domain)

-Rajeev

---

From: Christian Vogt <[email-masked]>
Date: Thu, 30 Oct 2008 13:10:20 +0200

On Oct 30, 2008, Mohana Jeyatharan wrote:

> MIP) to be present at LMA/HA and moreover both should be valid.

Mohana and Rajeev,

a general comment:  The simultaneous use of two mobility protocols
without coordination is bound to be problematic if you don't define a
clear precedence of one mobility protocol over the other.

This directly applies to the specific case of MIP/P-MIP co-existence:
Both mobility protocols run simultaneously, yet there is no coordination
between the entities who initiate mobility signaling, i.e., mobile hosts
and MAGs.

You don't need two BCEs to see why lack of precedences for the mobility
protocols could be a problem for multi-homing:  As a simple example,
consider a host with 3G and WLAN interfaces, of which only the 3G
interface has a home address with mobility support.  The host may create
a MIP binding to redirect traffic for its home address from 3G to WLAN.
In that case, the host certainly wouldn't want the network to remove
that binding due to subsequent movements of the 3G interface.

Overall, I would recommend that, if two protocols for the same purpose
(such as mobility) operate simultaneously, it should be clear which
protocol takes precedence over the other.  In the specific case of
MIP/P-MIP co-existence, that could mean that P-MIP pauses as long as a
MIP binding is active.  Without such precedences, the two protocols will
end up fighting each other (namely, over BCEs), and you will likely end
up with undesired side effects.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 30 Oct 2008 13:19:49 +0200

Hi Kilian -

> draft-ietf-mext-binding-revocation-01, when PBU/BU arrive  

The tricky question then, of course, is how you resolve an out-of-sync
situation once you have detected it.

Referring to the email I sent a minute ago:  Again, the straightforward
approach to solve this problem would be to clearly define which mobility
protocol takes precedence over the other.

- Christian

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 30 Oct 2008 09:59:41 -0400

Hi Christian,
   I agree and this is described in section 5.3 of the draft George and 
I wrote

http://tools.ietf.org/html/draft-tsirtsis-logically-separate-lmaha-00

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 30 Oct 2008 10:03:38 -0400

Hi Kilian,

> forward using the most recently updated BCE"?

If I understand Vidya correctly, she is trying to get consensus on the 
behavior of the LMA rather than the single BCE/multiple BCE 
implementation detail.

Otherwise, I could argue that the multiple BCE approach would solve both 
a) and b) but the single BCE approach can only solve b) :-)

Thanks
Suresh

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 30 Oct 2008 11:20:17 -0400

Christian,
 
> clear precedence of one mobility protocol over the other.

[RKo:>] My comment was specific to what was proposed; if you have two
different interfaces, you will have two different BCEs.

Of course we do not want unpredictable behavior. As a general comment,
it is agreed.

-Rajeev

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 30 Oct 2008 16:46:09 +0100

Hi Christian, 

> protocols could be a problem for multi-homing:  As a simple example,

Multi-homing is such a broad topic. If you talk about multihoming, what
kind of multi-homing do you mean? 
1. Multiple interfaces are up, but only one CoA/Proxy-CoA registered at
HA/LMA
2. Multiple interfaces are used simultaneously to route traffic 
	a. Multiple CoA 
	b. Multiple Proxy-CoA

> that binding due to subsequent movements of the 3G interface.

I think this scenario can be solved even with approach "b) forward using
the most recently updated BCE" by considering other info in PBU such as
Handoff Indicator. The "subsequent movements of 3G interface" would be
"Handoff between mobile access gateways for the same interface". So the
HA/LMA would just not activate the PMIP BCE, if the MIP BCE is active
and PBU arrives with HI flag set to "3: Handoff between mobile access
gateways for the same interface".

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 30 Oct 2008 16:46:11 +0100

Hi Suresh, 

generally, scenarios where the MN has multiple interfaces up
simultaneously and wants to move the traffic to a specific interface
without newly attaching with this interface are out of scope of this
discussion IMHO. Such scenarios are also not (yet) supported by PMIP, so
why should we support them now in PMIP/MIP interaction scenarios? 

With PMIP multihoming and flow filtering, I guess we will support such
scenarios for PMIP. Then, they are automatically supported for MIP/PMIP
interaction (if we keep MIP interactions in mind during design), no
matter whether we choose approach "a) always use the MIP6 BCE and only
use the PMIP6 BCE when there is no MIP6 BCE" vs. "b) forward using the
most recently updated BCE."

Cheers,

Kilian

> [mailto:[email-masked]] On Behalf Of Suresh Krishnan
> Sent: Donnerstag, 30. Oktober 2008 15:00
> To: Christian Vogt
> Cc: NETLMM Mailing List; Mohana Jeyatharan

---

From: Christian Vogt <[email-masked]>
Date: Thu, 30 Oct 2008 19:25:06 +0200

Kilian -

> 2. Multiple interfaces are used simultaneously to route traffic

I meant all of them. :-)  The example I gave illustrates your case (1).
And things don't seem to become any easier for your case (2).

> Handoff Indicator.

You are assuming that a MAG has the knowledge to set the Handoff  
Indicator
correctly.  But in general it does not have this knowledge because it  
may
not know about a mobile host's additional interfaces.

> The "subsequent movements of 3G interface" would be

Hold on, now you are back to case A ("Always use the MIP6 BCE and only  
use
the PMIP6 BCE when there is no MIP6 BCE"), aren't you?

- Christian

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 30 Oct 2008 10:54:49 -0700

Hi Kilian,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kilian Weniger
> Sent: Thursday, October 30, 2008 8:46 AM
> To: Suresh Krishnan; Christian Vogt
> Cc: Mohana Jeyatharan; NETLMM Mailing List

I think this is exactly the point why people don't agree in my view. 

This cannot be out of scope of the discussion. This scenario is possible when MIP is used if the home link is not a PMIP domain. It must be possible in the same way also in case the home link is a PMIP domain as the intent of that is to hide some movements to the IP stack of the MN. The fact that the home link is a PMIP domain must not put any limitations of scenarios which can be enabled by MIP. 

I think this is the main point and the solution you propose does not satisfy that requirement. 

Gerardo

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 30 Oct 2008 10:56:44 -0700

> Christian Vogt
> Sent: Thursday, October 30, 2008 10:25 AM
> To: Kilian Weniger

I think this is a key point Christian brought up. I understand 3GPP can assume that the HI is always set appropriately as it controls the L2 protocols used for attaching to the network but we cannot make that assumption in IETF. 

Gerardo

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 31 Oct 2008 09:18:42 +0800

Hi Christian,

Please see reply in-line.

Thank you.

BR,
Mohana 

> [mailto:[email-masked]] On Behalf Of Christian Vogt
> Sent: Thursday, October 30, 2008 7:10 PM
> To: Mohana Jeyatharan; Rajeev Koodli
> Cc: NETLMM Mailing List
> a general comment:  The simultaneous use of two mobility 
> protocols without coordination is bound to be problematic if 
> you don't define a clear precedence of one mobility protocol 
> over the other.

[Mohana] I don't see why it is a issue if case b is used. Always use the
latest one. Also, a MN
Shouldn't have any confusion as to who is managing the mobility. It is
either the MN or the network
at any specific new attachment. The SDP such as 3GG had mobility mode
selection
For this purpose and there is no issue or confuaion as to who is
managing the mobility.
> Both mobility protocols run simultaneously, yet there is no 
> coordination between the entities who initiate mobility 
> signaling, i.e., mobile hosts and MAGs.
> 
> You don't need two BCEs to see why lack of precedences for 
> the mobility protocols could be a problem for multi-homing:  
> As a simple example, consider a host with 3G and WLAN 
> interfaces, of which only the 3G interface has a home address 
> with mobility support.  The host may create a MIP binding to 
> redirect traffic for its home address from 3G to WLAN.
> In that case, the host certainly wouldn't want the network to 
> remove that binding due to subsequent movements of the 3G interface.

[Mohana] Of course you are right to say that 3G interface mobility
should not
Overwrite the WLAN binding. But, why would the LMA remove the WLAN
binding when
3G PMIP PBU is done and LMA has multihoming functionality(not yet
defined)? If LMA has information 
that this is not a single interface mobility but it is multiple
interface mobility,
then such overwriting will not happen. 

However, I understand your point. Since we do not have 
a PMIP/CMIP multihoming support *yet*, you are saying that PMIP PBU
should
not overwrite the CMIP BU. All this is because that PMIP/CMIP for multi
interface is not solved yet. Anyway, if you want certain flows to always

come via 3G interface how can you solve if you always give precedence
to CMIP BU? I think using the current mechanisms and solving multihoming
issue is 
not possible. We need further work and that is why we already have some 
multihoming drafts which highlights these issue. The case 'a' only
highlight 
solving the case of the scenario you have described. But it does not
solve the 
case of flow preference via 3G (PMIP mobility mode) or Simultaneous
usage: that is 
a flow is required to be tarversed via all interfaces to achieve
benefits of aggre
gated bandwidth.

So, that is why I mentioned that for multihoming case multiple binding
cache is 
essential and there is no overwriting of one with the other. We cannot
use the cuurently
Available model to solve such advanced multihoming.

Overwriting happens only for a secific interface and that is what we are
discussing.
For example, WLAN interface had switched to PMIP mobility mangement,
then the lastest PMIP binding
as in case 'b' will over write the CMIP binding that you have mentioned
in your explanation.

> Overall, I would recommend that, if two protocols for the 
> same purpose (such as mobility) operate simultaneously, it 
> should be clear which protocol takes precedence over the 
> other.  In the specific case of MIP/P-MIP co-existence, that 
> could mean that P-MIP pauses as long as a MIP binding is 
> active.  Without such precedences, the two protocols will end 
> up fighting each other (namely, over BCEs), and you will 
> likely end up with undesired side effects.

[Mohana]In my opinion you can have separate caches to maintain binding
for a single inetrface. 
But, there needs to be a mechanism such as in case b, that what ever
signaling comes 
first should be Given precedence. For me this looks more appropriate
rather than mandating 
MIPv6 always higher priority.

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Fri, 31 Oct 2008 10:38:05 +0200

Hi,

First of all, I think the Scenario C where LMA and HA are in a single box,
is a valid case, and should be documented. I have thought about the
implications on trying to combine the BCEs and make the LMA and HA to be
"logically" the same box. It seems that you need a lot of "assumptions" to
make it work, and you might break or limit functionality in ways that we
might not even know, yet.

I really think that the possible savings or optimizations in working further
with combining "logically" LMA and HA are not worth the effort. So, my
opinion is to keep Scenario C, but not try to combine LMA and HA logically
to a single element.

Cheers,

Jonne.

On 10/30/08 7:56 PM, "ext Giaretta, Gerardo" <[email-masked]> wrote:

> I think this is a key point Christian brought up. I understand 3GPP can assume
> that the HI is always set appropriately as it controls the L2 protocols used
> for attaching to the network but we cannot make that assumption in IETF.
> 
> Gerardo
> 
>  

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 31 Oct 2008 10:07:55 +0100

Hi Gerardo,

> This cannot be out of scope of the discussion. This scenario 
> is possible when MIP is used if the home link is not a PMIP 
> domain. It must be possible in the same way also in case the 
> home link is a PMIP domain as the intent of that is to hide 
> some movements to the IP stack of the MN. The fact that the 

That is one way of viewing this but I think your view already has the
implicit assumption that MIP6 has higher priority than PMIP6. 

> home link is a PMIP domain must not put any limitations of 
> scenarios which can be enabled by MIP. 

Where is this specified? And what exactly do you mean by "enabled by
MIP"? Obviously you refer to the MIP multihoming/MCoA extension, so I
guess you also refer to MIP extensions in general. So do you say that
FMIP and all other MIP extensions shall work for a PMIP link without any
changes?

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 31 Oct 2008 10:08:03 +0100

Hi Christian, 

> > 1. Multiple interfaces are up, but only one CoA/Proxy-CoA 
> registered  
> > at
> > HA/LMA
> I meant all of them. :-)  The example I gave illustrates your 

ok :)

However, I would prefer to discuss specific scenarios and concerns such
as the one below, otherwise it is very difficult to understand the core
issue.

> case (1).

As I wrote in another email and as Mohanna explained, im my opinion
multihoming scenarios that are not yet supported by PMIP should be out
of scope of this discussion. Once PMIP is extended to support this,
MIP/PMIP
handover scenarios also support this, no matter whether we choose
approach b) or a) now for single-interface scenarios. 

> > the most recently updated BCE" by considering other info in 
> PBU such  
> > as
> > Handoff Indicator.
> 

You brought up a specific scenario of 3G interface movements. In this
scenario, HI flag is set correctly by the MAG.

> > "Handoff between mobile access gateways for the same 
> interface". So  
> > the

Not really ;) 

In case the MN moves from WLAN to 3G interface, the HI flag can be set
to "1: Attachment over a new interface" or "2: Handoff between two
different interfaces of the mobile node". In this case traffic would be
directed to 3G interface (i.e., forwarding according to PMIP BCE) once
PBU arrives at LMA.

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 31 Oct 2008 10:07:55 +0100

Hi Gerardo,

Kilian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Oct 2008 12:12:10 +0200

Mohana -

> latest one. Also, a MN Shouldn't have any confusion as to who is
> managing the mobility. It is either the MN or the network at any
> specific new attachment.

You /can/ create confusion for multi-homed mobile hosts, as my previous
example shows.  Again, the problem is that a new attachment of one
interface can redirect traffic going via another interface.

> The SDP such as 3GG had mobility mode selection For this purpose and
> there is no issue or confuaion as to who is managing the mobility.

Absolutely right:  As I said in my previous email, coordination between
mobile hosts and the network would eliminate the issue I mentioned.
Unfortunately, we cannot assume that such coordination always exists...

...unless we specify it, of course.  In fact, the prioritization of MIP
BCEs over P-MIP BCEs -- as per case (a) -- is a form of coordination.

> should not Overwrite the WLAN binding. But, why would the LMA remove  
> the
> WLAN binding when 3G PMIP PBU is done and LMA has multihoming
> functionality(not yet defined)? If LMA has information that this is  
> not
> a single interface mobility but it is multiple interface mobility,  
> then

I am arguing that this should not even happen if the LMA does not have
complete information about all interfaces of a mobile host.  You cannot
assume, in the general case, that the LMA has this information.

> The case 'a' only highlight solving the case of the scenario you have
> described. But it does not solve the case of flow preference via 3G
> (PMIP mobility mode) or Simultaneous usage: that is a flow is required
> to be tarversed via all interfaces to achieve benefits of aggre gated
> bandwidth.

Mohanna, I don't think the granularity of mobility management matters in
this regard -- it could be per flow or for all traffic on a given
interface.  I am saying that, if both, hosts and network, are capable of
initiating mobility management actions, then there needs to be
coordination between the hosts and the network.  This coordination could
be implicit, such as by prioritization for either the actions of hosts
or the actions of the network.  In fact, I think that implicit
coordination is the way to go because we cannot assume that all mobile
hosts could participate in a newly defined explicit coordination
protocol.  And as for implicit coordination, I think the prioritization
should be for the actions of host.  The reason is that, since P-MIP is
designed to operate transparently to hosts, you better ensure that it
does not interfere with actions of the host.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Oct 2008 12:29:14 +0200

Hi Kilian -

> of scope of this discussion. [...]

I don't think it matters whether or not P-MIP supports multi-homing.
Option (a) has a potential to break multi-homing in either case.  In
fact, the issue only comes up if multi-homing is handled by (host-based)
MIP.  The example I gave shows this:  The mobile host uses MIP to make
use of a second interface, and P-MIP still interferes with this.

- Christian

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 31 Oct 2008 10:02:01 -0400

Hi Kilian,

> why should we support them now in PMIP/MIP interaction scenarios? 

I think this is where we have a disconnect. MIPv6 does support these 
scenarios and, in the presence of PMIPv6 with b) MIPv6 multihoming 
breaks. I would like to summarize my position like this.

if (foo works in the absence of PMIP)
{
  foo MUST work in the presence of PMIP;
}

replace foo with your favorite technology or use case.

Thanks
Suresh

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 01 Nov 2008 01:09:21 +1100

I agree with Suresh's comment.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 01 Nov 2008 01:18:52 +1100

Option a). Do you really want me to repeat all the reasons ? :) It's because
of multihoming. 

On 29/10/08 8:13 AM, "Narayanan, Vidya" <[email-masked]> wrote:

> All,
> <Chair Hat On>
> A few weeks ago, we had a discussion on supporting the colocated LMA/HA case
> (Scenario C in draft-ietf-netlmm-mip-interactions-00) with a single vs.
> separate BCE to manage the MIP6 and PMIP6 entries.  I have reviewed all the
> emails on this topic from a few weeks ago and note that we do not have
> consensus yet on this topic.  I will attempt to summarize the main points
> raised here and see if we can get to some form of consensus.  If this try
> results in lack of consensus again, the chairs and the AD will review all the
> technical points and make a decision on the way forward.
> 
> - This discussion is about what we need to specify at the IETF.  Please
> refrain from specific discussions on what has been done in 3gpp or WiMAX or
> any other SDO.  We can get requirements from other SDOs, but, ultimately, we
> decide what to specify in our specs with a discussion here.
> 
> - As IETF, we need to specify what works for the general Internet, with
> regular IP and MIP6 capable nodes.  We cannot assume SDO-specific solutions or
> any restrictions on managing interfaces at the MN to be in place.
> 
> - The support for this scenario is based on a desire to support packet
> delivery without tunnel headers (or ROHC, necessarily) while the MN is on the
> home link (by extending the home link to be a home network using PMIP6).  We
> are not supporting this scenario just because 3gpp has chosen this scenario -
> if there was no logical explanation for supporting this, we'd be specifying a
> 3gpp specific document for this or just leave it to 3gpp to specify it in
> their specs. 
> 
> - It may help to view the discussion in terms of processing behavior of the
> HA/LMA.  This leads to the following two options - a) always use the MIP6 BCE
> and only use the PMIP6 BCE when there is no MIP6 BCE vs. b) forward using the
> most recently updated BCE.
> 
> - The issue of the separate vs. same BCEs is also relevant from the point of
> view of whether the MIP6 BCE is going to be overwritten by the PMIP6 BCE or
> not.  
> 
> - There is no way to tell if the MN intended to handoff or be multihomed with
> the new CoA.  Hence, if the BCE is overwritten, it may have incorrectly
> eliminated the multihoming for the MN. Packets sent from the MN using the old
> CoA will now be dropped.
> 
> Please respond to this email selecting option a) or b) and providing reasons
> why the corresponding concerns either do not apply or how they can be
> mitigated.  
> 
> </chair hat on>
> 
> Thanks,
> Vidya
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 31 Oct 2008 16:08:08 +0100

Hi Suresh, 

> scenarios and, in the presence of PMIPv6 with b) MIPv6 multihoming
breaks.

I prefer to talk about specific scenarios ;) I assume that "MIPv6
multihoming" refers to the scenario in section 5.3 of your draft that
you referenced in an earlier email. So the scenario you want to support
is that a MN attaches to a PMIP home link with a second interface, but
wants to direct the traffic to this interface later (i.e., not at time
of attachment), right?

What I don't understand are two things:
1.) why this scenario is essential to be supported. 
2.) why is it only essential for MIPv6 handover scenarios and not for
PMIPv6 (i.e., MAG1->MAG2) handover scenarios? Because PMIPv6 does not
support this scenario.

Anyway, this scenario can be supported with approach b) in interaction
scenarios or even in pure PMIP scenarios, when PMIP is extended to allow
the MN to signal during attach that PBU shall be delayed by some time or
until MN explicitly triggers it.

Kilian

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 31 Oct 2008 16:14:02 +0100

I'm for the option a). I share the opinion that the other approach has issues with multihoming while the option a) handles this in a clean way.

I also think that a) should allow for simulatenous use of MIP6 and PMIP6 BCEs. The MN's may register its /128 HoA, and at the same time there may be a PMIP6 BCE for the MN's /64 HNP. If the downlink packet received at the LMA matches the /128 HoA from the MIP6 BCE, it is forwarded using the MIP6 BCE. Otherwise, it "falls through" to the PMIP BCE and gets forwarded via PMIP6 BCE. 

domagoj

> Sent: 28. listopad 2008 22:13
> To: [email-masked]
> Subject: [netlmm] PMIP6-MIP6 Interactions - Take 2
> 
> All,
> <Chair Hat On>
> A few weeks ago, we had a discussion on supporting the 
> colocated LMA/HA case (Scenario C in 
> draft-ietf-netlmm-mip-interactions-00) with a single vs. 
> separate BCE to manage the MIP6 and PMIP6 entries.  I have 
> reviewed all the emails on this topic from a few weeks ago 
> and note that we do not have consensus yet on this topic.  I 
> will attempt to summarize the main points raised here and see 
> if we can get to some form of consensus.  If this try results 
> in lack of consensus again, the chairs and the AD will review 
> all the technical points and make a decision on the way forward. 
> 
> - This discussion is about what we need to specify at the 
> IETF.  Please refrain from specific discussions on what has 
> been done in 3gpp or WiMAX or any other SDO.  We can get 
> requirements from other SDOs, but, ultimately, we decide what 
> to specify in our specs with a discussion here. 
> 
> - As IETF, we need to specify what works for the general 
> Internet, with regular IP and MIP6 capable nodes.  We cannot 
> assume SDO-specific solutions or any restrictions on managing 
> interfaces at the MN to be in place.   
> 
> - The support for this scenario is based on a desire to 
> support packet delivery without tunnel headers (or ROHC, 
> necessarily) while the MN is on the home link (by extending 
> the home link to be a home network using PMIP6).  We are not 
> supporting this scenario just because 3gpp has chosen this 
> scenario - if there was no logical explanation for supporting 
> this, we'd be specifying a 3gpp specific document for this or 
> just leave it to 3gpp to specify it in their specs. 
> 
> - It may help to view the discussion in terms of processing 
> behavior of the HA/LMA.  This leads to the following two 
> options - a) always use the MIP6 BCE and only use the PMIP6 
> BCE when there is no MIP6 BCE vs. b) forward using the most 
> recently updated BCE.  
> 
> - The issue of the separate vs. same BCEs is also relevant 
> from the point of view of whether the MIP6 BCE is going to be 
> overwritten by the PMIP6 BCE or not.  
> 
> - Additional 1RT delay between the MN and LMA before packets 
> can be forwarded to the new CoA when compared to b) 
> 
> Please respond to this email selecting option a) or b) and 
> providing reasons why the corresponding concerns either do 
> not apply or how they can be mitigated.  
> 
> </chair hat on>
> 
> Thanks,
> Vidya
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 31 Oct 2008 10:02:09 -0700

I agree too. This is the point I was trying to make in my earlier email. Thanks Suresh to make it clearer :-)

Gerardo

> Hesham Soliman
> Sent: Friday, October 31, 2008 7:09 AM
> To: Suresh Krishnan; Kilian Weniger
> Cc: Christian Vogt; Mohana Jeyatharan; NETLMM Mailing List

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 31 Oct 2008 13:24:55 -0400

Hi Vidya,

I object to the way you have classified the options below. I don't
believe anyone is against supporting a multi-homed mobile node. It
should be made to work. At least I had made this very clear at the
Dublin IETF meeting.

You have to clearly describe what you mean by a multi-homed mobile node.
Is it support for using multiple interfaces at the same time? This is
very easily doable. The Multiple CoA draft that the MEXT WG is working
on allows the mobile node to be connected through the home link and
visited link at the same time and use them simultaneously. We just need
to make sure the mechanisms specified in that draft (sending a BU with
the 'H' bit set in the BID option from the home link) works well with
the PMIPv6 Proxy BU that the MAG sends when the MN is attached to the
PMIPv6-based home link.

You have completely ignored some of the scenarios that were presented in
the previous discussions. I had brought up a scenario called the single
radio handover, where the MN can only have one interface up at any time.
For this handover scenario, it makes sense to go with the solution where
the binding at the HA/LMA is updated according to the most recent
signaling message (BU or PBU) that was received. This scenario is the
one that is likely to be deployed with PMIPv6 initially.

We shouldn't try to design in a vacuum. IMO, we should take into
consideration what is being considered for practical deployment. Not
just say "To break or not to break multi-homing"? :)

What I see in the email below is that you are trying to force a
consensus by making this is a "support for multi-homing" issue. I DO NOT
like that.

Vijay

[email-masked] wrote:
> BCE when there is no MIP6 BCE vs. b) forward using the most recently
> updated BCE. 
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 31 Oct 2008 13:26:10 -0400

[email-masked] wrote:
> Hi Vidya,
> 
> Narayanan, Vidya wrote:
> 
>> If there are additional concerns with either approach that
> I have failed to note, please let me know.
> 
> With b) an additional concern is that a reordered BU/PBU can result
> in a complete loss of connectivity (absent any yet to be specified
> mitigation measures).

Suresh, you know very well that the solution for the singe BCE approach
involves sending a binding revocation either to the MAG or the mobile
node when the binding cache is being over-written. So I don't know what
you are talking about.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 31 Oct 2008 13:29:18 -0400

[email-masked] wrote:

> With the base PMIP6 spec, there can only be one CoA for a
> given HNP.  Same is the case with RFC3775 for MIP6 (for a
> HoA).  Hence, in a way, regardless of whether the entry is
> overwritten or not, it is not straightfoward within the scope
> of these specs to maintain two CoAs for the same HoA/HNP.
> 
> Even if we chose to maintain multiple CoAs, the network will
> be making the assumption that the latest CoA is the primary
> CoA, which may or may not be correct.  For example, if the MN
> is using MIP6 over its WLAN interface and now adds a 3G
> interface and suddenly all of the video downloads switch to
> the 3G interface, that would be a bad thing.  Further, it is
> a bit premature to design it that way, since, we don't yet
> know what an MCoA solution for a combined PMIP6/MIP6 system will look
> like. 

You need to use the MCoA solution with the flow filters draft to direct
certain flows to a certain interface. We have the tools.

FWIW, Jari brought this during his AD review of MCoA. We are trying to
revise the MCoA draft to add text about how it will work with
PMIPv6-MIPv6 interactions scenario C.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 31 Oct 2008 13:40:14 -0400

Christian, Gerardo,

On the topic of how the MAG knows what to set the 'HI' to, I agree that
RFC 5213 does not specify this. But that was deliberate. 

3GPP, the only customer for handovers across interfaces using PMIPv6,
has specified this. The mobile node when it attaches to the MAG
indicates via a link layer mechanism whether it is an initial attach or
a handover. 

Proposals have been made in the past to the NETLMM WG during the
re-chartering process. There were proposals on indicate mobile node
capability, on conveying information on whether it is a handover or an
attach, etc.. They had quite a bit of support, but were still not added
to the charter. The MIPSHOP WG is also working on a standards track
document to transfer context from the one MAG to the other. This would
also help in determining if the mobile node is performing a handover to
another interface or if it is an attach through another interface. 

I don't understand why we should make an assumption that the MAG would
be clueless on what to set 'HI' to. It would result in specifications
that won't get used by anyone. WE shouldn't waste time on those.

Vijay

[email-masked] wrote:
>>> Multi-homing is such a broad topic. If you talk about multihoming,
>>> what kind of multi-homing do you mean?
>>> registered at HA/LMA
a.
>>> 	Multiple CoA b. Multiple Proxy-CoA
>> 
>> I meant all of them. :-)  The example I gave illustrates your case
>> (1). And things don't seem to become any easier for your case (2).
>> 
>>>> interface has a home address with mobility support.  The host may
>>>> create a MIP binding to redirect traffic for its home address from
>>>> 3G to WLAN. In that case, the host certainly wouldn't want the
>>>> network to remove that binding due to subsequent movements of the
>>>> 3G interface. 
>>> 
>>> I think this scenario can be solved even with approach "b) forward
>>> using the most recently updated BCE" by considering other info in
>>> PBU such as Handoff Indicator.
>> 
>> Indicator correctly.  But in general it does not have this knowledge
>> because it may not know about a mobile host's additional interfaces.
>> 
> 
> I think this is a key point Christian brought up. I
> understand 3GPP can assume that the HI is always set
> appropriately as it controls the L2 protocols used for
> attaching to the network but we cannot make that assumption in IETF.
> 
> Gerardo
> 
> 
>>> "Handoff between mobile access gateways for the same interface". So
>>> the HA/LMA would just not activate the PMIP BCE, if the MIP BCE is
>>> active and PBU arrives with HI flag set to "3: Handoff between
>>> mobile access gateways for the same interface".
>> 
>> Hold on, now you are back to case A ("Always use the MIP6 BCE and
>> only use the PMIP6 BCE when there is no MIP6 BCE"), aren't you?
>> 
>> - Christian
>> 
>>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 31 Oct 2008 13:48:16 -0400

[email-masked] wrote:
>> multihoming scenarios that are not yet supported by PMIP should be
>> out of scope of this discussion. [...]
> 
> fact, the issue only comes up if multi-homing is handled by
> (host-based) MIP.  The example I gave shows this:  The mobile host
> uses MIP to make use of a second interface, and P-MIP still
> interferes with this. 

It doesn't if the HA/LMA entity is made aware of this. The HA/LMA entity
would maintain both bindings if that is what the mobile node wants to
do. The mobile node just needs to send a BU, with the 'H' flag set in
the BID option to make sure it can be connected via the home link and
the visited link at the same time. See
draft-ietf-monami6-multiplecoa-09.txt. Version 10 will be submitted very
soon.

Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 31 Oct 2008 10:53:28 -0700

Hi Vijay,

I know 3GPP has defined a way to indicate the handover from the terminal. However we cannot assume this is a general solution and IETF cannot work on a solution based on 3GPP layer 2 protocols. 

The point made by Christian is valid: we cannot assume the MAG knows how to set the HI. This is captured also in the RFC 5213. So we need a solution which works with any type of link layer, considering also link layer or accesses which don't support any type of handover indication (e.g. WLAN).

The multihoming scenario is not only about MCoAs as we discussed several times. It is more in general the case where the MN has more than one interfaces up at the time and only one CoA is registered. Only the mobile knows which interface it wants to register as primary CoA. 

Moreover, when we consider MCoA and flow mobility, PMIPv6 and option b) breaks that and I think this is not acceptable.  

On the single radio terminals: first of all we cannot defined solutions which are different for single radio and multiple radio terminals. IETF protocols should remain hopefully agnostic of that. Second, I think the approach a) work perfectly also with a single radio terminal so I don't see any issue there.

Cheers
Gerardo

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Friday, October 31, 2008 10:40 AM
> To: Giaretta, Gerardo; Christian Vogt; Kilian Weniger

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 31 Oct 2008 11:01:01 -0700

Kilian,

PMIPv6 was specified in order to provide mobility transparently to the MN. This is achieved by RFC 5213. The fact that a home link is a PMIPv6 domain must be transparent to the MN. This implies that everything the MN can do without PMIPv6, it must be able to do with PMIPv6 in the home link. I think this is a pretty reasonable principle and it is in line with the principles of NETLMM charter. 

Gerardo

> Sent: Friday, October 31, 2008 2:08 AM
> To: Giaretta, Gerardo; Kilian Weniger; Suresh Krishnan; Christian Vogt
> Cc: Mohana Jeyatharan; [email-masked]; List

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 31 Oct 2008 11:01:01 -0700

Kilian,

Gerardo

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 31 Oct 2008 14:03:05 -0400

Hi Gerardo, 

> From: Giaretta, Gerardo [mailto:[email-masked]] 
> Sent: Friday, October 31, 2008 10:53 AM
> To: Vijay Devarapalli; Christian Vogt; Kilian Weniger
> I know 3GPP has defined a way to indicate the handover from 
> the terminal. However we cannot assume this is a general 
> solution and IETF cannot work on a solution based on 3GPP 
> layer 2 protocols. 

The only folks interested in using PMIPv6 for a handover across
interfaces is 3GPP. I don't believe anyone else will do this. I expect
PMIPv6 to be used for local mobility management within a single access
domain. So who are we designing this for?

And you ignored what I wrote in my previous email. I said there were
proposals during the NETLMM re-chartering process to make sure the HI is
always set correctly during a handover. These proposals are still
around. We just need to complete them and not claim that things are
broken and so we should design a certain way.

Vijay
 
> The point made by Christian is valid: we cannot assume the 
> MAG knows how to set the HI. This is captured also in the RFC 
> 5213. So we need a solution which works with any type of link 
> layer, considering also link layer or accesses which don't 
> support any type of handover indication (e.g. WLAN).
> 
> The multihoming scenario is not only about MCoAs as we 
> discussed several times. It is more in general the case where 
> the MN has more than one interfaces up at the time and only 
> one CoA is registered. Only the mobile knows which interface 
> it wants to register as primary CoA. 
> 
> Moreover, when we consider MCoA and flow mobility, PMIPv6 and 
> option b) breaks that and I think this is not acceptable.  
> 
> On the single radio terminals: first of all we cannot defined 
> solutions which are different for single radio and multiple 
> radio terminals. IETF protocols should remain hopefully 
> agnostic of that. Second, I think the approach a) work 
> perfectly also with a single radio terminal so I don't see 
> any issue there.
> 
> Cheers
> Gerardo
> 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 31 Oct 2008 14:01:49 -0400

Hi Vijay,

> node when the binding cache is being over-written. So I don't know what

And hence the qualifier "(absent any yet to be specified mitigation 
measures)" in my statement. I consider the BRI a mitigation measure. 
What else would you call it?

Cheers
Suresh

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 31 Oct 2008 11:07:34 -0700

Hi Vijay,

As you know I am deeply involved in 3GPP standardization on these issues. But I disagree we should solve the issue in IETF just keeping 3GPP in mind. That is not why IETF develop protocols; we need to have a broader view.

About the HI, I still did not see any proposal which works for any type of access so in my opinion there is not any generic solution to provide the HI to the MAG.

Gerardo

> Sent: Friday, October 31, 2008 11:03 AM

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 31 Oct 2008 11:09:33 -0700

> What else would you call it?

Sending a binding revocation message *is* part of the solution to avoid 
the race condition. The text that describes how to avoid the race 
condition for scenario C in the single BCE approach was proposed more 
than a year ago. You made it sound as if there is an additional concern 
that has not been addressed yet.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 31 Oct 2008 14:11:17 -0400

Hi Gerardo, 

> Sent: Friday, October 31, 2008 11:08 AM
> As you know I am deeply involved in 3GPP standardization on 
> these issues. But I disagree we should solve the issue in 
> IETF just keeping 3GPP in mind. That is not why IETF develop 
> protocols; we need to have a broader view.

I know that. I don't why you keep repeating that. But in this case, the
only folks interested in a handover across interfaces with PMIPv6 is
3GPP. So we do need to take into consideration what they have in their
specs.

Vijay

> 
> About the HI, I still did not see any proposal which works 
> for any type of access so in my opinion there is not any 
> generic solution to provide the HI to the MAG.
> 
> Gerardo
>

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 01 Nov 2008 11:02:18 +1100

Killian,

> 1.) why this scenario is essential to be supported.
=> It's a no brainer IMO. There is a high percentage of *existing* 3G
devices that are capable of multihoming today. I'm using two of them right
now. Project that to the time of deployment of what we're doing here and it
becomes an essential requirement.

Hesham