Subject: [netlmm] PMIP6-MIP6 Interactions - Binding Cache Entry Management - Please comment

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 29 Sep 2008 17:57:33 -0700

Hi,
At the Dublin meteing, we discussed the issue of having one vs. two separate binding cache entries for PMIP6 and MIP6 bindings of an MN.  Vijay and George presented the cases for having a single vs. separate BCE for the two respectively.  Following that, we tried to get a sense of the room on the topic.  At the meeting, we had about 15 or so people who were in favor of having separate BCE's for PMIP6 and MIP6 bindings of an MN, about 10 people who didn't care how it was done and about 5 people who were in favor of having a single BCE for both.  Jari also suggested that the single BCE support appears fairly complicated and needs further clarity to see why that should be supported.

In order to make progress on the interactions document, please provide input on the mailing list on whether you would like to see Scenario C supported with a single BCE or separate BCE's.  The slides presented at Dublin are at http://www.ietf.org/proceedings/08jul/slides/netlmm-3.pdf and http://www.ietf.org/proceedings/08jul/slides/netlmm-4.pdf for your review.

Please provide rationale with your choice - we are not looking for a vote on this topic.  Please also talk about what you don't like in the alternative.  Without rationale, please note that your views cannot contribute towards consensus here.

Please write to the list by October 10th, 2008.

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

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 30 Sep 2008 17:03:13 +0200

Hello Vidya, all,

in my opinion, single vs. separate BCE implementation is just internal
in the HA/LMA and may not be so relevant for standardization. What is
more important from standardization point of view is the external
behaviour of the co-located HA/LMA, such as where the HA should send the
data when a valid PBU is received after valid BU or vice versa. 

In my understanding, the two approaches presented by George and Vijay
differ from this external HA behaviour point of view as follows:

1) Data forwarding is always done according to MIP6 BCE, if exists, no
matter whether PMIP6 BCE exists or not. Only if MIP6 BCE is empty, PMIP6
BCE is used (i.e., MIP6 BCE always has priority over PMIP6 BCE).

2) Data forwarding is done according to last received registration
(i.e., MIP6 and PMIP6 BCE have equal priority). 

A major difference of the two HA behaviours exists in the MIP6->PMIP6
transition case: When a valid PBU is received, in 1) PMIP6 tunnel is
created and HNP is stored in PMIP6 BCE, but HA/LMA still forwards data
packets according to the MIP6 BCE. Only after BU de-registration is
received, the MIP6 BCE is deleted and data packets are forwarded
according to the PMIP6 BCE. In approach 2), when a PBU is received,
HA/LMA can immediately start forwarding data packets according to the
PMIP6 BCE. No need to wait for the BU de-registration to delete the MIP6
BCE. 

Approach 1) is only possible with separate BCE, whereas 2) is possible
with both separate and single/shared BCE. 

Hence, IMHO single vs separate BCE implementation does not need to be
mandated in the spec. It is more important to discuss and specify the
external behaviour of the HA, e.g., whether data forwarding is done
according to 1) or 2).

BTW, the HA/LMA behaviour in PMIP6-MIP6 interactions scenario C is
currently discussed in 3GPP CT1. So 3GPP (probably the main customer of
this spec) may have decided this before IETF comes to a conclusion.

Regards,

Kilian  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> Sent: Dienstag, 30. September 2008 02:58
> To: [email-masked]
> Subject: [netlmm] PMIP6-MIP6 Interactions - Binding Cache 
> Entry Management - Please comment
> 
> Hi,
> At the Dublin meteing, we discussed the issue of having one 
> vs. two separate binding cache entries for PMIP6 and MIP6 
> bindings of an MN.  Vijay and George presented the cases for 
> having a single vs. separate BCE for the two respectively.  
> Following that, we tried to get a sense of the room on the 
> topic.  At the meeting, we had about 15 or so people who were 
> in favor of having separate BCE's for PMIP6 and MIP6 bindings 
> of an MN, about 10 people who didn't care how it was done and 
> about 5 people who were in favor of having a single BCE for 
> both.  Jari also suggested that the single BCE support 
> appears fairly complicated and needs further clarity to see 
> why that should be supported.
> 
> In order to make progress on the interactions document, 
> please provide input on the mailing list on whether you would 
> like to see Scenario C supported with a single BCE or 
> separate BCE's.  The slides presented at Dublin are at 
> http://www.ietf.org/proceedings/08jul/slides/netlmm-3.pdf and 
> http://www.ietf.org/proceedings/08jul/slides/netlmm-4.pdf for 
> your review.
> 
> Please provide rationale with your choice - we are not 
> looking for a vote on this topic.  Please also talk about 
> what you don't like in the alternative.  Without rationale, 
> please note that your views cannot contribute towards consensus here.
> 

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

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 30 Sep 2008 11:52:05 -0400

Hi Vidya,

I don't think it is any longer a simple choice of picking one approach
vs the other. 

There are valid deployment scenarios where the mobile node is allowed
access through only one access network at a time. 3GPP release 8 has
already assumed this. The mobile node getting access through two
different links at the same time is simply not allowed. For these
deployments having two separate binding cache entries on the combined
HA/LMA entity introduces complexity, more memory requirements, etc.. So
most of the HA/LMA combined entity implementations, IMO, will still go
ahead with a single binding cache entry per mobile node irrespective of
what we decide here. 

At the same time, I don't think any one wants to prevent the
"multi-homing scenarios" that George presented. I think the mobile node
should be allowed access through multiple access networks. But this will
be more like a feature addon that would come later. Maybe 3GPP release 9
will allow this. For the mobile node to access the home agent through
the home or the visited link, it is best that we use the approaches
presented in section 5.6 of
http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-09.tx
t. FWIW, I am strongly opposed to solving scenario C of the PMIPv6-MIPv6
interactions document with the hierarchical use of PMIPv6 and MIPv6.

Perhaps it would be better if we focus on how to support both scenarios.

Vijay

> Sent: Monday, September 29, 2008 5:58 PM
> To: [email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 30 Sep 2008 11:56:06 -0400

Hi Vidya, 

> why that should be supported.

I remember Jari saying that is complicated and we cannot decide yet in
the meeting room. I don't rememeber him saying that the single BCE
approach is fairly complicated. Jari is cc'ed on the email. 

> looking for a vote on this topic.  

Hmm.. Why not? Folks who were not in the meeting room should be allowed
to vote and their votes counted towards the overall consensus, right? We
have always allowed this. FWIW, of the 15 votes for the separate BCE
approach, I saw at least 9 votes from folks from just two companies. 

Vijay

Please also talk about

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 01 Oct 2008 02:03:39 +1000

Hi Vidya, 

I was one of the people supporting the separate BCE in the meeting. My
rationale is very simple:
- The natural way of supporting this would use separate BCE. Deviating from
this, requires rationale by the people suggesting that. The only rationale I
heard so far is memory consumption. This is an extremely weak argument.
- Having one BCE introduces a number of complications that were discussed in
the presentation by George. Why should we support it? No strong reasons are
given here. 
- Just because someone decided to not use multihoming doesn't mean we close
other options. We know how 3GPP works and how releases introduce major
changes. Since the separate BCE solution costs us nothing and is more
flexible for supporting multiple scenarios, I don't see why we should
deviate from it. 
- In IETF we should be picking solutions consistent with our assumptions
about the Internet. We're not designing products or architectures and often
protocol use cases turn on a dime. We all know IETF is not the fastest place
for new specs and certainly cannot move very quickly. Hence, it is always
better to go for maximum flexibility provided that there is no significant
cost. This is the case here.

Hesham

On 30/09/08 10:57 AM, "Narayanan, Vidya" <[email-masked]> wrote:

> Hi,
> At the Dublin meteing, we discussed the issue of having one vs. two separate
> binding cache entries for PMIP6 and MIP6 bindings of an MN.  Vijay and George
> presented the cases for having a single vs. separate BCE for the two
> respectively.  Following that, we tried to get a sense of the room on the
> topic.  At the meeting, we had about 15 or so people who were in favor of
> having separate BCE's for PMIP6 and MIP6 bindings of an MN, about 10 people
> who didn't care how it was done and about 5 people who were in favor of having
> a single BCE for both.  Jari also suggested that the single BCE support
> appears fairly complicated and needs further clarity to see why that should be
> supported.
> 
> In order to make progress on the interactions document, please provide input
> on the mailing list on whether you would like to see Scenario C supported with
> a single BCE or separate BCE's.  The slides presented at Dublin are at
> http://www.ietf.org/proceedings/08jul/slides/netlmm-4.pdf for your review.
> 
> Please provide rationale with your choice - we are not looking for a vote on
> this topic.  Please also talk about what you don't like in the alternative.
> Without rationale, please note that your views cannot contribute towards
> consensus here.
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 30 Sep 2008 10:13:29 -0700

Hi Vijay,

Some small clarifications inline

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Vijay Devarapalli
> Sent: Tuesday, September 30, 2008 8:52 AM
> To: Narayanan, Vidya; [email-masked]
> Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Binding Cache Entry
> Management - Please comment
>
> Hi Vidya,
>

Just for the records, this is only partially true. The multihoming case is not fully specified and not "not allowed". Moreover for Release 9 3GPP started a study item on multiple connectivity and IP flow mobility.

Having said this, I think we should absolutely not consider 3GPP as the main customer here. We need to find an IETF solution for this which is flexible and not bound to what 3GPP or any other SDO requires in Release X (we all know in Release X+1 they will require something different)

> interactions document with the hierarchical use of PMIPv6 and MIPv6.

Multiple CoAs is not needed to be multihomed in particular in the case where the home link is a p2p link. The MN may just attach to the home link (e.g. for handover preparation) but still keeping the DSMIPv6 binding valid (i.e. avoid using directly the HoA and letting the HA intercepting packets). This was discussed several times and has nothing to do with MCoAs.

Gerardo

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 30 Sep 2008 10:21:48 -0700

Hi Vidya,

I was not present at the Dublin meeting so I could not express my opinion. So here it is :-)

I think that Kilian's made a good point in his email that the issue is probably not about separate vs single BCEs but more about how the HA routes the packets.

Based on his analysis I think we should specify that "Data forwarding is always done according to MIP6 BCE, if exists, no matter whether PMIP6 BCE exists or not". This seems to be the most flexible solution as it works in any scenario. Moreover, we will not need to revisit any specification when multiple CoAs and IP flow mobility will come into the picture.

I understand that there are scenarios where single radio MN will never be multihomed. These scenarios can be still enabled as the MN will send a de-registration BU as soon as it connects to the home link. I don't any issue with that.

Thanks
Gerardo

> Behalf Of Narayanan, Vidya
> Subject: [netlmm] PMIP6-MIP6 Interactions - Binding Cache Entry
> At the Dublin meteing, we discussed the issue of having one vs. two
> separate binding cache entries for PMIP6 and MIP6 bindings of an MN.
> Vijay and George presented the cases for having a single vs. separate
> BCE for the two respectively.  Following that, we tried to get a sense
> of the room on the topic.  At the meeting, we had about 15 or so people
> who were in favor of having separate BCE's for PMIP6 and MIP6 bindings
> of an MN, about 10 people who didn't care how it was done and about 5
> people who were in favor of having a single BCE for both.  Jari also
> suggested that the single BCE support appears fairly complicated and
> needs further clarity to see why that should be supported.
>
> In order to make progress on the interactions document, please provide
> input on the mailing list on whether you would like to see Scenario C
> supported with a single BCE or separate BCE's.  The slides presented at
> Dublin are at http://www.ietf.org/proceedings/08jul/slides/netlmm-3.pdf
> and http://www.ietf.org/proceedings/08jul/slides/netlmm-4.pdf for your
> review.
>
> Please provide rationale with your choice - we are not looking for a
> vote on this topic.  Please also talk about what you don't like in the
> alternative.  Without rationale, please note that your views cannot
> contribute towards consensus here.
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 30 Sep 2008 10:24:40 -0700

Hi Vijay

One point on the complexity of the solution below

> HA/LMA entity introduces complexity, more memory requirements, etc..

This sounds like a very weak argument. How do you measure complexity? Based on the number of BCEs? It seems to me that having a common BCE requires to handles some race conditions described in the draft which implies definitely more complexity that just having two BCEs at the HA. Can you please clarify to what complexity you are referring to?

Thanks
Gerardo

> So

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 30 Sep 2008 13:35:13 -0400

HI Gerardo,

Giaretta, Gerardo wrote:

>> Behalf Of Vijay Devarapalli Sent: Tuesday, September 30, 2008 8:52 AM
>> I don't think it is any longer a simple choice of picking one
>> approach vs the other. 
>> 
>> So most of the HA/LMA combined entity implementations, IMO, will
>> still go ahead with a single binding cache entry per mobile node
>> irrespective of what we decide here. 
>> 
> 
> Just for the records, this is only partially true. The
> multihoming case is not fully specified and not "not
> allowed". Moreover for Release 9 3GPP started a study item on
> multiple connectivity and IP flow mobility.
> 
> Having said this, I think we should absolutely not consider
> 3GPP as the main customer here. We need to find an IETF
> solution for this which is flexible and not bound to what
> 3GPP or any other SDO requires in Release X (we all know in
> Release X+1 they will require something different)

Disagree. 3GPP is the only customer for scenario C. I don't think any
body else would ever deploy a combined LMA+HA entity. Come on, for the
longest time, you were arguing for removing scenario C saying it doesn't
make sense. :)

Who else wants to use scenario C?

>> "multi-homing scenarios" that George presented. I think the mobile
>> node should be allowed access through multiple access networks. But
>> this will be more like a feature addon that would come later. Maybe
>> 3GPP release 9 will allow this. For the mobile node to access the
>> home agent through the home or the visited link, it is best that we
>> use the approaches presented in section 5.6 of
>> t. FWIW, I am strongly opposed to solving scenario C of the PMIPv6-
>> MIPv6 interactions document with the hierarchical use of PMIPv6 and
>> MIPv6. 
>> 
> 
> Multiple CoAs is not needed to be multihomed in particular in
> the case where the home link is a p2p link. The MN may just
> attach to the home link (e.g. for handover preparation) but
> still keeping the DSMIPv6 binding valid (i.e. avoid using
> directly the HoA and letting the HA intercepting packets).
> This was discussed several times and has nothing to do with MCoAs.

The above does not require the HA+LMA entity to maintain two separate
binding cache entries since this is for a short transition period during
a handover. You can delay the PBU on the MAG, until the attachment is
complete.

If you want to do anything more, for example the mobile node is attached
to the home link and wants to use the visited link for sending/receiving
packets, then you do need MCoA extensions.
draft-ietf-monami6-multiplecoa-09.txt explicitly talks about one link
being the home link and the other being the visited link. But the mobile
node can choose use one or both links. This is exactly the scenario we
have here.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 30 Sep 2008 13:44:41 -0400

Gerardo,

[email-masked] wrote:

> I understand that there are scenarios where single radio MN
> will never be multihomed. These scenarios can be still
> enabled as the MN will send a de-registration BU as soon as
> it connects to the home link. I don't any issue with that.

But what we need here for a single radio MN that is not multihomed is
for the LMA+HA entity to start forwarding the packets as soon as the MAG
sends a PBU when the MN attaches to the home link. Not wait for the MN
to send a de-registration BU. There will be some packet loss otherwise.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 30 Sep 2008 12:47:28 -0500

Vijay,

> longest time, you were arguing for removing scenario C saying it doesn't

Why do you believe that there is no reason for a combined LMA+HA? I think
every LMA is pretty much already a MIP6 HA as well. So the protocol should
support the functionality by which the same enitity behaves as an HA or an
LMA simultaneously and for the same MN as well.

> Who else wants to use scenario C?

An MN can connect via multiple interfaces to the network. This is possible
today. And you could have an LMA+HA offer the MN a PMIP6 prefix for IF1 and
a MIP6 HoA on IF2. This is a valid use case that needs to be supported.

-Raj

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 30 Sep 2008 10:52:03 -0700

Hi Vijay,

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Tuesday, September 30, 2008 10:45 AM
> To: Giaretta, Gerardo; Narayanan, Vidya; [email-masked]
> Subject: RE: [netlmm] PMIP6-MIP6 Interactions - Binding Cache Entry

The de-registration BU will be the first packet sent by the MN. The difference in terms of packet loss may be just insignificant and if one is concerned about packet loss then buffering of packets after a PBU is received can be performed. But I don't think that would be even needed: for example in E-UTRAN (as you like the 3GPP example) the uplink link is established before the downlink one so the de-registration BU will not add any significant delay.

Gerardo

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 30 Sep 2008 12:53:02 -0500

Just a comment about the single radio case:

Why is there an assumption that just because the MN can only operate a
single radio (interface) it is limited to only using PMIP6? A single radio
MN can have multiple service flows or PDN bearers (3GPP terminology) and
there is no reason why you cannot have PMIP6 and MIP6 operation over
different service flows. Whether it makes practical sense is a different
matter. But if policy allows, the MN can be assigned a PMIP6 prefix over PDN
bearer 1 and a MIP6 HoA over PDN bearer 2.

I agree that a single radio MN cannot be multi-homed in the sense that it is
connected via different physical interfaces to the network. But given that a
PDN bearer is equivalent to a virtual interface the MN can be attached to a
PMIP6 LMA and a MIP6 HA via a single physical radio/interface.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 30 Sep 2008 12:56:46 -0500

Inline:

On 9/30/08 12:52 PM, "Giaretta Gerardo" <[email-masked]> wrote:

> The de-registration BU will be the first packet sent by the MN. The difference
> in terms of packet loss may be just insignificant and if one is concerned
> about packet loss then buffering of packets after a PBU is received can be
> performed. But I don't think that would be even needed: for example in E-UTRAN
> (as you like the 3GPP example) the uplink link is established before the
> downlink one so the de-registration BU will not add any significant delay.

The delay in receiving the dereg message or packet loss as a result is a
corner case and insignificant. The LMA+HA can do some buffering to mitigate
such a scenario. The race condition itself is a corner case.

-Raj

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 30 Sep 2008 13:58:17 -0400

Hi Raj,

Basavaraj Patil wrote:
>> body else would ever deploy a combined LMA+HA entity. Come on, for
>> the longest time, you were arguing for removing scenario C saying it
>> doesn't make sense. :) 
>> 
> 
> Why do you believe that there is no reason for a combined LMA+HA? I
> think every LMA is pretty much already a MIP6 HA as well. So the
> protocol should support the functionality by which the same enitity
> behaves as an HA or an LMA simultaneously and for the same MN as well.

I meant 3GPP is the only customer for scenario C. Scenario C, in
addition to having a combined HA+LMA entity also has the mobile node
moving in and out of the PMIPv6 domain. When it is attached to the
PMIPv6 domain, it is on the home link. I don't think anyone else would
want to deploy something like this. 3GPP chose to do this, because they
wanted to avoid MIPv6 tunneling overhead over GERAN/UTRAN/E-UTRAN.

I was responding to Gerardo claim about we should not consider 3GPP as
the main customer for scenario C. IMO, it is the only customer .

> An MN can connect via multiple interfaces to the network. This is
> possible today. And you could have an LMA+HA offer the MN a PMIP6
> prefix for IF1 and a MIP6 HoA on IF2. This is a valid use case that
> needs to be supported. 

Sure. The MCoA draft supports this scenario very well.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 30 Sep 2008 13:10:24 -0500

Vijay,

> the main customer for scenario C. IMO, it is the only customer .

Why would a similar scenario not be applicable in WiMAX for example? It is
IMO a valid use case to consider there as well. It may be a bit too early to
claim that the applicability is limited to only 3GPP.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 30 Sep 2008 14:03:15 -0500

An entity can behave as a MIP6 HA and a PMIP6 LMA at the same time. The
question is whether the binding cache entries need to be maintained
separately.
The argument for separating the binding cache entries (from what I
understand) is based on the scenario of an MN moving from a PMIP6
domain to an AR and registering with the MIP6 HA a CoA and
vice-versa. 
The other argument is that separating BCEs is necessary to support
multihoming. Multihoming can be supported without having to specify
how the BCEs are implemented. I do agree with Kilian that it is an
implementation issue about how the BCEs for the LMA and HA are
handled. An MN which is multihomed and has a PMIP6 prefix assigned via
the PMIP6 domain and a CoA registed with the MIP6 HA in a combined
LMA+HA enity will have two separate entries. Whether these entries are
in the scope of the same logical BCE or separate physical BCEs is upto
implementations. I dont see any valid reason for requiring specific
text about single or multiple BCEs to support multihoming.

Under what circumstances does a BCE get overwritten? The scenarios at
least IMO are corner cases and hence do not require the specification
to mandate logically separate BCEs. It would be good to understand via
a flow diagram the case where the BCE is overwritten and if solving
the issue is considered important enough, we can then look at possible
solutions. There were alternative approaches being discussed at the
Dublin IETF meeting (as per slides by Vijay and George).

In summary, I think that the Netlmm WG does not have to specify
explicitly how the BCEs in a combined HA+LMA are implemented or the
processing rules. If someone can explain what would break without such
explicit text, we could debate further.

-Raj

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 30 Sep 2008 17:14:56 -0400

Hi Vidya,

> At the meeting, we had about 15 or so people who were
> in favor of having separate BCE's for PMIP6 and MIP6 bindings of an
MN,
> about 10 people who didn't care how it was done and about 5 people who
>
[RKo:>] Well, "didn't care" is not actually accurate. At least I was one
of those who argued that the spec should have no normative text about
how it is implemented. Specify the behavior, but leave it to the
implementations - one or two BCE.

I believe this was the sense of "didn't care". And, I think this should
be the way forward. 

Regards,

-Rajeev

> were in favor of having a single BCE for both.  Jari also suggested
that
> the single BCE support appears fairly complicated and needs further
> clarity to see why that should be supported.
> 
> Dublin are at
http://www.ietf.org/proceedings/08jul/slides/netlmm-3.pdf
> Please provide rationale with your choice - we are not looking for a
vote
> on this topic.  Please also talk about what you don't like in the

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 01 Oct 2008 10:48:51 +1000

> bearer 1 and a MIP6 HoA over PDN bearer 2.

=> Amen! Just another example for why we shouldn't be doing thing so
restrictively. Single radio != single interface....

> PMIP6 LMA and a MIP6 HA via a single physical radio/interface.

=> that's right. Whether it's virtual or physical is not relevant.

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 30 Sep 2008 23:16:23 -0700

>
> I remember Jari saying that is complicated and we cannot
> decide yet in the meeting room. I don't rememeber him saying
> that the single BCE approach is fairly complicated. Jari is
> cc'ed on the email.

I have gone through the audio recording of the session just to be accurate and here is the actual exchange from the meeting:

"Jari: If there are implementation strategies that cause problems, we don't have to support all of them. I clearly haven't figured out all the details of this discussion.. Maybe the rest of you haven't either; but, this looks rather complicated;  I would rather drop things that look complicated than attempt to support them.

Vidya: So, Jari, your recommendation is to drop Scenario C?

Jari: No, the implementation approach;  there are many approaches and if we need race condition mechanisms for the single BCE approach, I don't know why we need to support that approach."

The audio recording is available at http://www.ietf.org/proceedings/08jul/index.html for anyone who would like to verify.

> Hmm.. Why not? Folks who were not in the meeting room should
> be allowed to vote and their votes counted towards the
> overall consensus, right? We have always allowed this.

I don't know what "we" is in the above sentence, but, I am not willing to entertain making technical decisions based on blind votes.  The people in the room in Dublin sat through a 40-minute discussion on the topic before making a choice.  Of course, the whole point here is to allow other people to voice their opinion on the list - but, we cannot make technical choices without reasoning - so a "vote" without explanation doesn't contribute towards consensus.  It also doesn't help the chairs in any way to help determine the technical merits of a solution.

> FWIW,
> of the 15 votes for the separate BCE approach, I saw at least
> 9 votes from folks from just two companies.
>

That's not a data point we look for and it is really quite irrelevant at the IETF.

Thanks,
Vidya

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 1 Oct 2008 16:35:59 +0900

Hi Raj,
　　

> text about single or multiple BCEs to support multihoming.

agree, it's kind of implementation issue.

To me, more important thing is how to lookup BCE.
The BC lookup is same for data packets, but not for signaling (PBU or  
BU).
Since different lookup key is used between PMIP and MIP,
it might be difficult to find an BCE of MIP6 with proxy binding update  
due to lack of fields in MIP6 BCE.

regards,
ryuji

ps. You can have multiple routing tables (FIBs) on LINUX:-)

>> separate

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 1 Oct 2008 16:38:45 +0900

Vijay,

> HA/LMA entity introduces complexity, more memory requirements, etc..  

One question. Two BCE are not managed all the time in Scenario-C if we  
don't consider multihoming.
Two BCEs are appeared for a moment, only when MN handover between PMIP- 
MIP.
I am not sure how much additional memory you need for separate BCE.

ryuji

> node
> MIPv6

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 01 Oct 2008 18:22:57 +1000

> due to lack of fields in MIP6 BCE.

=> As long as you know the mapping between the MNID and HoA you should be
able to lookup either BCE without much trouble, right?
But I'm not sure about the scenario you have in mind. Are you thinking of a
scenatio where a BU modifies the BCE for PMIPv6?

Hesham

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 1 Oct 2008 10:38:27 +0200

Hi Gerardo, 

> I think that Kilian's made a good point in his email that the 
> issue is probably not about separate vs single BCEs but more 
> about how the HA routes the packets.
> 
> Based on his analysis I think we should specify that "Data 
> forwarding is always done according to MIP6 BCE, if exists, 
> no matter whether PMIP6 BCE exists or not". This seems to be 
> the most flexible solution as it works in any scenario. 
> Moreover, we will not need to revisit any specification when 
> multiple CoAs and IP flow mobility will come into the picture.

Can you explain why one data forwarding option is more flexible than the
other and how the data forwarding options are related to MCoA?

One benefit of the "Data forwarding is done according to last received
registration" option is that the handover performance in terms of delay
is typically faster. 

> The de-registration BU will be the first packet sent by the 
> MN. The difference in terms of packet loss may be just 
> insignificant and if one is concerned about packet loss then 
> buffering of packets after a PBU is received can be 
> performed. But I don't think that would be even needed: for 
> example in E-UTRAN (as you like the 3GPP example) the uplink 
> link is established before the downlink one so the 
> de-registration BU will not add any significant delay.

Of course packet loss can be prevented by buffering, but packet delay
cannot. 

Regarding your argument about E-UTRAN, as far as I know this is not
fully correct. There are two options for PMIP case: Depending on whether
S-GW (MAG) receives UE (MN)'s IP address via PCC or not, the S-GW sends
PBU before or after radio bearer establishment (see section 8.2.1.2 in
TS 23.402). So your argument does apply for only one option in E-UTRAN
(i.e., only if no PCC is used). And it does not apply to handovers to
other access technologies.

So in the general case, handover performance in terms of delay is better
with the option "Data forwarding is done according to last received
registration". 

Regards,

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 1 Oct 2008 10:38:29 +0200

Hi Gerardo, 

> This was discussed several times and has nothing to do with MCoAs.

IMHO, supporting this scenario is not related to CMIP PMIP interactions.
The scenario is that the MN is attaching to a new MAG, but the LMA is
still forwarding data to the old location. This is also not possible in
pure PMIP (MAG1->MAG2) handover scenarios. The reason is that layer 2
and layer 3 handover currently cannot be done independently in PMIP.
Hence, this is a pure PMIP problem. 

In my opinion, if you want to support this scenario, you should propose
a PMIP extension. Once this extension is specified, your scenario is
supported in all PMIP handover scenarios and also automatically in the
PMIP CMIP handover case.

Regards,

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 1 Oct 2008 10:38:31 +0200

Hello Hesham, 

> heard so far is memory consumption. This is an extremely weak 

I think this is really debatable. Another point of view is that PMIP6 is
a MIP6 extension, i.e., PMIP6 uses the same protocol messages and data
structures than MIP6. This would mean the natural way is to use a
single/shared BCE.

Regards,

Kilian

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 1 Oct 2008 17:45:53 +0900

Hi Hesham,

> able to lookup either BCE without much trouble, right?

HoA? PMIP does not deal with HoA, but with HNP, right?

There is a case where HNP is not available to lookup BCE.
In the initial proxy binding registration, MAG may not know HNP for  
the MN and sends HNP option with ALL_ZERO.
HNP might not be available for BC lookup. LMA should allocate the same  
home prefix of MIP6-binding as a HNP.

If MIP6 BU carries MN-ID option, MN-ID can be used to identify BCE all  
the time!?

> scenatio where a BU modifies the BCE for PMIPv6?

Yes, I was thinking the case of a single BCE for both PMIP and MIP.
i.e. The use of MIP6 BU to overwrite the PMIP BCE.

regards,
ryuji