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

From: Hesham Soliman <[email-masked]>
Date: Wed, 01 Oct 2008 21:05:41 +1000

>> => As long as you know the mapping between the MNID and HoA you
>> should be
>> able to lookup either BCE without much trouble, right?
> 
> HoA? PMIP does not deal with HoA, but with HNP, right?

=> Right HNP, same logic applies though.

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

=> Are you asking me to making a statement? The scenario you mention seems
to already assume a single BCE, which is a premise that I disagree with.

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

=> Right, but this discussion is about whether this is a good idea in the
first place. My opinion is that it's a bad idea and that we should have two
BCEs. 

Hesham

> 
> regards,
> ryuji
> 
> 
> 
>> 
>> 
>> Hesham
>>> 
>>> regards,
>>> ryuji
>>> 
>>> ps. You can have multiple routing tables (FIBs) on LINUX:-)
>>> 
>>>> 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
>>>> 
>>>> 
>>>> On 9/29/08 7:57 PM, "ext 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-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
>>>> 
>>>> _______________________________________________
>>>> netlmm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>> 
>>> _______________________________________________
>>> netlmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>> 
>> 
> 

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

---

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

One typo below

On 1/10/08 9:05 PM, "Hesham Soliman" <[email-masked]> wrote:

> => Are you asking me to making a statement? The scenario you mention seems to
                       ^^ "or"
> already assume a single BCE, which is a premise that I disagree with.
> 
>>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 01 Oct 2008 11:58:45 -0500

Hesham,

> first place. My opinion is that it's a bad idea and that we should have two

But why? I do not see any reason to have explicit decoupling of the BCEs for
the HNP and HoA in the LMA+HA entity. Does something break if the BCEs are
not maintained separately. I think implementations will need to handle how
the mappings in the BCE are maintained and what causes the BCEs to be
updated. 
You could very well implement two separate BCEs or a single BCE (physically,
logically.. Whatever your choice) and still achieve the same behavior for
the LMA+HA entity when the MN moves from a PMIP6 domain to a non-PMIP6
domain. The only thing that I can think would be useful is to specify the
scenario of an MN moving between domains which causes mobility signaling
switching from PMIP6 to (DS)MIP6 and vice versa and what the LMA behavior
ought to be. 

-Raj

---

From: "Genadi Velev" <[email-masked]>
Date: Wed, 1 Oct 2008 19:34:14 +0200

Hi Raj, Hesham,
 
> domain. 

If I understand correctly, a single BCE means that e.g. the PMIPv6
mobility signalling would overwrite the MIPv6 BCE and vice versa -- the
MIPv6 signalling overwrites the PMIPv6 BCE. Is my understanding correct?
If it is correct, the overwriting could cause a problem. For example
having a MIPv6->PMIPv6 transition, the PMIPv6 PBU would update/overwrite
the MIPv6 BCE with the MAG's address. When a BU deregistration sent by
the MN arrives at the HA, there is no BCE matching to the BU dereg, the
BU dereg is silently discarded. The MN starts to send BU deregs
periodically, which is not desired. Therefore I think e.g. an incoming
PBU should set the MIPv6 BCE in deprecated/deactivated state, i.e. the
data packets are forwarded according the PMIPv6 BCE and incoming BU
dereg is processed by the MIPv6 BCE. Please see below.

> The only thing that I can think would be useful is to 
> specify the

This is exactly what this thread is about -- scenario C :-)

Therefore I agree with Kilian that it is better to discuss how the
PMIPv6 and MIPv6 signalling is processed in the HA/LMA, that means
whether MIPv6 has higher priority or whether MIPv6 and PMIPv6 has equal
priority. I prefer the latter approach. 

Genadi

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

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: Wed, 1 Oct 2008 14:30:41 -0400

Hi Ryuji

>>> 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.
>> 
>> should be able to lookup either BCE without much trouble, right?
> 
>> thinking of a scenatio where a BU modifies the BCE for PMIPv6?
> 

The binding cache lookup issues and the solution for that in the single
BCE approach is already described in
draft-giaretta-netlmm-mip-interactions-02. See sections 3.3, 4.3.1 and
4.3.2 of
http://tools.ietf.org/html/draft-giaretta-netlmm-mip-interactions-02

Let us know if you find anything broken, with respect to the binding
cache lookup mechanism, in the above draft.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 01 Oct 2008 13:36:20 -0500

Hi Genadim

> MIPv6 signalling overwrites the PMIPv6 BCE. Is my understanding correct?

That would be the case in the case of a single BCE implementation used by
LMA and HA with no rules on how the BCE is updated.

> the MIPv6 BCE with the MAG's address.

Assuming that the Dereg BU arrived after the MAG PBU at the LMA+HA. Or as
has been suggested by Vijay and others, specify a timer which does not
immediately deprecate the BCE. Or as you suggest below mark the BCE as
deprecated but do not delete it so that the HA can send an ACK on receving
the Dereg BU and only then deleting the BCE. However in such a case a new
BCE entry with the HNP is created and used for forwarding the traffic to the
MN while the BCE marked as deprecated is ignored.

> When a BU deregistration sent by

What you suggest above is one approach that would work.

> priority. I prefer the latter approach.

I agree that there should not be any specific priority in terms whether the
HA processing is done first or the LMA. It is implementation specific.

-Raj

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 2 Oct 2008 19:01:38 +0900

Hi Raj and Genadim,

> What you suggest above is one approach that would work.

If we pick the single BCE, this is one we have to specify.

> HA processing is done first or the LMA. It is implementation specific.

agree

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 2 Oct 2008 19:10:43 +0900

Hi Vijay,

> cache lookup mechanism, in the above draft.

If MN-ID is always available, it should be OK.

Don't you consider the prefix match to find BCE?
HNP is always available for both PBU and BU.
Is this because of HNP assignment at the first PBU?

regards,
ryuji

ps. MIP6 BU de-registration will be mandatory. The draft discuss the  
de-registration as an option in RFC3775.

---

From: "BLUME, Oliver" <[email-masked]>
Date: Thu, 2 Oct 2008 14:44:06 +0200

Hi Genadi and Patil,

> Therefore I agree with Kilian that it is better to discuss how the PMIPv6 
> and MIPv6 signalling is processed in the HA/LMA, that means whether MIPv6 
> has higher priority or whether MIPv6 and PMIPv6 has equal priority. I prefer 
> the latter approach. 

For the choice of propper priorisation I miss a discussion on the requirements. Let me try to sketch some points:

1) If one wants to proiorize the latest request, this may require to question a previous MIP BU. Fot this, a revocation message with indication of race condition will have to be defined for client MIP. Any chance for that?

2) Is there good reason to assume that a BU of a MN has higher relevance or tends to be faster (regarding DAD I doubt that a BU will be faster than a PBU), thus provocing a race condition.

3) Are there other means to discriminate between the two bindings in race condition? As I just posted in a response to Vidja, the handoff indicator may be of help: A PBU with handoff indication may have higher relevance than a refreshing PBU (Hi=5). Vice versa, it makes a difference if the client BU cahnges the MIP CoA or just refreshed the lifetime.

Probably there are many more acpects. 

Oliver   

>-----Ursprüngliche Nachricht-----
>Von: [email-masked] [mailto:[email-masked]] 
>Im Auftrag von Genadi Velev
>Gesendet: Mittwoch, 1. Oktober 2008 19:34
>An: Basavaraj Patil
>Cc: Netlmm
>Betreff: Re: [netlmm] PMIP6-MIP6 Interactions - Binding Cache 
>EntryManagement - Please comment
>
>Hi Raj, Hesham,
> 
>> But why? I do not see any reason to have explicit decoupling of the 
>> BCEs for the HNP and HoA in the LMA+HA entity. Does 
>something break if 
>> the BCEs are not maintained separately. I think implementations will 
>> need to handle how the mappings in the BCE are maintained and what 
>> causes the BCEs to be updated.
>> You could very well implement two separate BCEs or a single BCE 
>> (physically, logically.. Whatever your choice) and still achieve the 
>> same behavior for the LMA+HA entity when the MN moves from a PMIP6 
>> domain to a non-PMIP6 domain.
>
>If I understand correctly, a single BCE means that e.g. the 
>PMIPv6 mobility signalling would overwrite the MIPv6 BCE and 
>vice versa -- the
>If it is correct, the overwriting could cause a problem. For 
>example having a MIPv6->PMIPv6 transition, the PMIPv6 PBU 
>would update/overwrite the MIPv6 BCE with the MAG's address. 
>When a BU deregistration sent by the MN arrives at the HA, 
>there is no BCE matching to the BU dereg, the BU dereg is 
>silently discarded. The MN starts to send BU deregs 
>periodically, which is not desired. Therefore I think e.g. an 
>incoming PBU should set the MIPv6 BCE in 
>deprecated/deactivated state, i.e. the data packets are 
>forwarded according the PMIPv6 BCE and incoming BU dereg is 
>processed by the MIPv6 BCE. Please see below.
>
>> The only thing that I can think would be useful is to specify the 
>> scenario of an MN moving between domains which causes mobility 
>> signaling switching from PMIP6 to (DS)MIP6 and vice versa 
>and what the 
>> LMA behavior ought to be.
>
>PMIPv6 and MIPv6 signalling is processed in the HA/LMA, that 
>means whether MIPv6 has higher priority or whether MIPv6 and 
>PMIPv6 has equal priority. I prefer the latter approach. 
>
>Genadi
>
>> 
>> -Raj
>> 
>> > 
>> > Hesham
>> > 
>> >> 
>> >> regards,
>> >> ryuji
>> >> 
>> >> 
>> >> 
>> >>> 
>> >>> 
>> >>> Hesham
>> >>>> 
>> >>>> regards,
>> >>>> ryuji
>> >>>> 
>> >>>>> specification to mandate logically separate BCEs. It would be 
>> >>>>> good to
>> understand
>> >>>>> via
>> >>>>> possible solutions. There were alternative approaches being
>> discussed at the
>> >>>>>> 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.
>> >>>>>> 
>> >>>>>> 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

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 2 Oct 2008 11:36:16 -0400

Ryuji Wakikawa wrote:
>> The binding cache lookup issues and the solution for that in the
>> single BCE approach is already described in

If the HNP is available all the time, then you do the BCE lookup with
that. If you allocate a HNP for both MIPv6 and PMIPv6 registrations,
then it would work.

> de-registration as an option in RFC3775.

Oh, I agree. But some folks have argued that since RFC 3775 says MN
"SHOULD" send the de-registration BU when it attaches to the home link,
it is not mandatory. RFC 3775 does not say "MUST".

Vijay

---

From: "Genadi Velev" <[email-masked]>
Date: Sat, 4 Oct 2008 19:25:57 +0200

Hi Oliver,

I'm going directly to your questions.   

> 1) If one wants to proiorize the latest request, this may 
> require to question a previous MIP BU. Fot this, a revocation 
> message with indication of race condition will have to be 
> defined for client MIP. Any chance for that?

Yes, a revocation for the MIP client is needed. The current BRI draft defines a Binding Revocation Indication (BRI) message with a Revocation Trigger field set to 10 ("Possible Out-of Sync BCE State"). If the MN wants to keep its registration in the HA, the MN can send a Binding Revocation Acknowledgement (BRA) message with Status field set to 6 ("Revocation Failed, MN is Attached"). 

> 
> 2) Is there good reason to assume that a BU of a MN has 
> higher relevance or tends to be faster (regarding DAD I doubt 
> that a BU will be faster than a PBU), thus provocing a race condition.

This a question that has been discussed on this thread: whether the MIP has a higher priority, or the PBU and BU (and therefore the MIP BCE and PMIP BCE) has equal priority. Regarding which message (BU or PBU) is faster, it is difficult to say. It depends on the deployment scenario, network load etc.  

> 
> 3) Are there other means to discriminate between the two 
> bindings in race condition? As I just posted in a response to 
> Vidja, the handoff indicator may be of help: A PBU with 
> handoff indication may have higher relevance than a 
> refreshing PBU (Hi=5). Vice versa, it makes a difference if 
> the client BU cahnges the MIP CoA or just refreshed the lifetime.

I think this a bit tricky. If we assume a MIP->PMIP handover, the PBU sent by the MAG has an HI field set to "Handoff between two different interfaces" (HI=2) or "Handoff state unknown" (HI=4). The latter includes a handover with the same interface, but changing mobility mechanism from MIP to PMIP (HI value is not defined for this case). So, what you are proposing works in some cases, but not in all. The solution described by Vijay would work always. Anyway, if your solution is applied, then equal priority between PBU and BU (meaning between PMIP BCE and MIP BCE) is assumed, i.e. not the hierarchical model giving higher priority to MIP BCE proposed by George and Hesham. 

Genadi

> >Von: [email-masked] [mailto:[email-masked]] Im 
> >Auftrag von Genadi Velev
> vice versa 
> >-- the
> >having a MIPv6->PMIPv6 transition, the PMIPv6 PBU would 
> >update/overwrite the MIPv6 BCE with the MAG's address.
> there is no 
> >BCE matching to the BU dereg, the BU dereg is silently 
> discarded. The 
> >MN starts to send BU deregs periodically, which is not desired. 
> >Therefore I think e.g. an incoming PBU should set the MIPv6 BCE in 
> >deprecated/deactivated state, i.e. the data packets are forwarded 
> >according the PMIPv6 BCE and incoming BU dereg is processed by the 
> >MIPv6 BCE. Please see below.
> >
> >whether MIPv6 has higher priority or whether MIPv6 and