Subject: [netlmm] Clarification of text in Section 5.4.1.2 of RFC5213

From: Conny Larsson <[email-masked]>
Date: Fri, 21 Nov 2008 22:13:00 +0100

Hi Sri,

I have difficulties to understand bullet 4 in Section 5.4.1.2. If no 
de-registration message is received within MaxDelayBeforeNewBCEAssign I 
would like the existing BC entry to be updated (not a new one created) 
and if the de-registration is received from the previous MAG I would 
like a new BC entry to be created (not updated since there is nothing to 
update).

Below is the text from RFC5213 that I'm referring to:

       *  The local mobility anchor MUST verify if there exists one and
          only one Binding Cache entry with the mobile node identifier
          matching the identifier in the Mobile Node Identifier option
          present in the request and for any link-layer identifier
          value.  If there exists only one such entry (matching the MN-
          Identifier), the local mobility anchor SHOULD wait until the
          existing Binding Cache entry is de-registered by the
          previously serving mobile access gateway, before the request
          can be considered as a request for updating that Binding Cache
          entry.  However, if there is no de-registration message that
          is received within MaxDelayBeforeNewBCEAssign amount of time,
          the local mobility anchor, upon accepting the request, MUST
          consider the request as a request for creating a new mobility
          session.  The local mobility anchor MAY also choose to create
          a new mobility session without waiting for a de-registration
          message, and this should be configurable on the local mobility
          anchor.

Could you please clarify the above text.

Regards
Conny

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

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 21 Nov 2008 19:14:27 -0800 (PST)

Hi Conny,

When the handoff hint is set to value of 4 (Unknown), the
link-layer id does not match and when there is no HNP present,
we cant definitively identify the session associated with that
request. In such scenario, we have to wait till the MAG that
created request performs a de-reg, or choose to create a new
session. But, we cant just update any of that MN's BCE, as we
dont have enough data to be sure its the same session. If you
remember the multi-homing discussions, we need some identifiers
or a handoff hint. So, your SGW needs a handoff hint, or some
session context.

Regards
Sri

On Fri, 21 Nov 2008, Conny Larsson wrote:

> de-registration message is received within MaxDelayBeforeNewBCEAssign I would 
> like the existing BC entry to be updated (not a new one created) and if the 
> de-registration is received from the previous MAG I would like a new BC entry 
> to be created (not updated since there is nothing to update).
>

---

From: Conny Larsson <[email-masked]>
Date: Sat, 22 Nov 2008 05:50:48 +0100

Hi Sri,

Thanks for your answer. It's not 100% clear to me and I have an 
additional question to you.

You are saying "In such scenario, we have to wait till the MAG that 
created request performs a de-reg, or choose to create a new session. 
But, we cant just update any of that MN's BCE, as we don't have enough 
data to be sure its the same session.".

But the RFC5213 text says that if a de-registration message is received 
from the previously serving MAG then the request from the new MAG can be 
considered as a request for updating the BC entry (i.e., the one that 
has been found).

In this case you are updating the BCE?

Regards
Conny

Sri Gundavelli wrote:
>> de-registration message is received within MaxDelayBeforeNewBCEAssign 
>> I would like the existing BC entry to be updated (not a new one 
>> created) and if the de-registration is received from the previous MAG 
>> I would like a new BC entry to be created (not updated since there is 
>> nothing to update).
>>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 21 Nov 2008 20:55:49 -0800 (PST)

Hi Conny,

If the prev MAG de-registered the session during this wait, that
session can be handed off to the new interface and the issue of
a multi-homed host ending up with same prefix ..etc ..wont arise.

So, either we are sure we can identify the session in question
for certain, or wait till dereg, before the session can be handed
off.

Regards
Sri

On Sat, 22 Nov 2008, Conny Larsson wrote:

> Hi Sri,
>
> Thanks for your answer. It's not 100% clear to me and I have an additional 
> question to you.
>
> You are saying "In such scenario, we have to wait till the MAG that created 
> request performs a de-reg, or choose to create a new session. But, we cant 
> just update any of that MN's BCE, as we don't have enough data to be sure its 
> the same session.".
>
> But the RFC5213 text says that if a de-registration message is received from 
> the previously serving MAG then the request from the new MAG can be 
> considered as a request for updating the BC entry (i.e., the one that has 
> been found).
>