Subject: RE: Issue 42 (was Re: [nemo] Including prefix information in BU inexplicit mode)

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 17 Aug 2004 09:16:57 +0200

If the MR has no prefix it can not add them. It needs to learn them. I'm not sure we ever said that explicit excluded implicit; If the HA has some prefixes for the MR, it can install them (e.g. static routes). If the MR claims others, then the HA can install them too. When the MR stops claiming prefixes it claimed before in explicit mode (HA knows because of prefix list) then the HA removes the forwarding states for those prefixes only. 

What do you think?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: lundi 16 août 2004 21:12
> To: Ryuji Wakikawa
> Cc: [email-masked]
> Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU inexplicit mode)
> 
> Ryuji,
> 
> I think we can avoid the additional "MUST". this MUST does not
> increase interoperability.
> 
> > We can also add MUST in section 5.2.
> >
> >       Explicit:
> >
> >          In this mode, the Mobile Router "MUST" include one or more Mobile
> >          Network Prefix Options in the Binding Update.  These options
> >          contain information about the Mobile Network Prefix(es)
> >          configured on the mobile network.
> 
> Vijay

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 17 Aug 2004 10:55:37 +0200

It is important that the HA and the MR has exactly the same perception 
on what prefixes are in use and what their respective registration 
lifetimes are.

IMHO I think it may be dangerous to mix explicit and implicit like you 
describe below. Do you think it will add functionality?

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 17 Aug 2004 12:23:27 +0200

An addition:

I had a closer look at the basic support spec. I'm a bit curious how an 
MR can register and deregister multiple MNPs independently of each other.

Is there ever a possibility that the MR can be registered with MNP1 and 
MNP2 and at some point chose to deregister MNP1, while keeping MNP2? 
Does MR send a BU with lifetime=0 and a prefix option with MNP1? Or does 
it have to first deregister all (set lifetime=0) and then make a fresh 
registration with MNP2 only?

Section 6.2. (see below) is a bit ambiguous about this. It says the 
deregistration _only affects_ the specified MNPs (but it says that the 
binding for the HoA should be removed).

Last sentence of Section 6.7. (see below) on the other hand says that HA 
will ignore _all_ MNP options (in explicit mode - but that's the only 
time they are used, isn't it?).

In addition to what I said in my quoted mail below about MR and HA being 
in complete agreement of what MNPs are bound, I think it is very useful 
to have a mechanism for registering and deregistering MNPs for MR 
independently.

Option 1:
In each BU, only the specified MNPs will be kept in the binding cache in 
the HA after a successful registration. All other MNPs not specified 
will be removed. In my example, MR would go from registering {MNP1, 
MNP2} to registering {MNP2} only. The binding for MNP1 will be removed 
immediately.

Option 2:
In a BU, the HA only updates the specified MNPs. This implicitly means 
that each MNP will have a lifetime. In my example, MR would go from 
registering {MNP1, MNP2} to registering {MNP2} only. To handle a quick 
transition, MR would also have to deregister MNP1 explicitly, by sending 
a BU with lifetime=0 and MNP1 as the only prefix option.

Does anyone else see the need for this? From Vijay's initial discussion, 
it seems so.

 From Section 6.2:
>    If the Lifetime specified in the Binding Update is zero or the
>    specified Care-of address matches the Home Address in the Binding
>    Update, then this is a request to delete the cached binding for
>    the home address and specified Mobile Network Prefixes.  The
>    Binding Update is processed according to the procedure described in
>    Section 6.7.

> 6.7. Mobile Network Prefix De-Registration
> 
>    The Mobile Router de-registers with the Home Agent by sending a
>    Binding Update with the lifetime set to zero.  When the Home Agent
>    successfully processes the de-registration BU, it deletes the Binding
>    Cache Entry for the Mobile Router's Home Address and stops proxying
>    the Home Address.  This is described in detail in the Mobile IPv6
>    specification [1].
> 
>    In addition, the Home Agent also removes the bi-directional tunnel
>    and stops forwarding packets to the mobile network.  The Home Agent
>    should keep all necessary information to clean up whichever routes it
>    installed, whether they come from implicit or explicit source.
>    In Explicit mode, the Home Agent MUST ignore any Mobile Network
>    Prefix Options present in the de-registration Binding Update.

In addition, Section 6.2. allows the MR to indicate deregistration by 
either setting lifetime=0 or set CoA=HoA. Section 6.7. only accepts 
lifetime=0.

/Mattias

Mattias Pettersson L (KI/EAB) wrote:
>>If the MR has no prefix it can not add them. It needs to learn them.
> 
> I'm not sure we ever said that explicit excluded implicit; If the HA has
> some prefixes for the MR, it can install them (e.g. static routes). If
> the MR claims others, then the HA can install them too. When the MR
> stops claiming prefixes it claimed before in explicit mode (HA knows
> because of prefix list) then the HA removes the forwarding states for
> those prefixes only. 
> 
>>What do you think?
>>
>>
> 
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 17 Aug 2004 12:44:23 +0200

Hi all,

> Does anyone else see the need for this? From Vijay's initial discussion, 

	Yes, I also see the need for this, and I prefer Option 1 (more
bits over the air, but less state is needed in the HA).

	C. J.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Aug 2004 14:10:30 +0200

Mattias Pettersson wrote:
> An addition:
> 
> I had a closer look at the basic support spec. I'm a bit curious how
> an MR can register and deregister multiple MNPs independently of each
> other.

I think it's not specified and there are many ways in which one could
implement the synchronization between MR's MNP's in its BU list and HA's
MNP's of this HoA in its BC.

> Is there ever a possibility that the MR can be registered with MNP1
> and MNP2 and at some point chose to deregister MNP1, while keeping
> MNP2? Does MR send a BU with lifetime=0 and a prefix option with
> MNP1? Or does it have to first deregister all (set lifetime=0) and
> then make a fresh registration with MNP2 only?
> 
> deregistration _only affects_ the specified MNPs (but it says that
> the binding for the HoA should be removed).
> 
> Last sentence of Section 6.7. (see below) on the other hand says that
> HA will ignore _all_ MNP options (in explicit mode - but that's the
> only time they are used, isn't it?).
> 
> In addition to what I said in my quoted mail below about MR and HA
> being in complete agreement of what MNPs are bound, I think it is
> very useful to have a mechanism for registering and deregistering
> MNPs for MR independently.
> 
> Option 1: In each BU, only the specified MNPs will be kept in the
> binding cache in the HA after a successful registration. All other
> MNPs not specified will be removed. In my example, MR would go from
> registering {MNP1, MNP2} to registering {MNP2} only. The binding for
> MNP1 will be removed immediately.
> 
> Option 2: In a BU, the HA only updates the specified MNPs. This
> implicitly means that each MNP will have a lifetime. In my example,
> MR would go from registering {MNP1, MNP2} to registering {MNP2} only.
> To handle a quick transition, MR would also have to deregister MNP1
> explicitly, by sending a BU with lifetime=0 and MNP1 as the only
> prefix option.
> 
> Does anyone else see the need for this? From Vijay's initial
> discussion, it seems so.

Indeed, there may be many ways in which MR may update its MNP's to the
HA.  Option 2 would require a new lifetime field for each MNP, thus
leaving me to prefer option 1.

Additionally, I think there may be other ways in which this can be done,
an Option 3 would require only one MNP per BU, easier to implement and
manage consistently.

Finally, a simpler and cleaner way is to use NEMO implicit mode and let
OSPF manage these prefixes.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 18 Aug 2004 19:10:34 -0700

> Does anyone else see the need for this? From Vijay's initial discussion, 

I agree there is a need for clarification. I prefer option 1. here is
some text

    If the Home Agent has a valid binding cache entry for the Mobile
    Router, it should compare the list of prefixes in the Binding Update
    against the prefixes stored in the binding cache entry.  If the
    binding cache entry contains prefixes that do not appear in the
    Binding Update, the Home Agent MUST disable forwarding for these
    Mobile Network Prefixes.

I was thinking of adding this to section 6.2. please see
http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre04.txt

it can also be added to section 6.7, instead. let me know.

however, I am not sure this change is minor enough to be done during
AUTH48 stage. otherwise we may have to drop this. WG chairs?

> either setting lifetime=0 or set CoA=HoA. Section 6.7. only accepts 

I just deleted the first sentence in section 6.7.

Vijay

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 19 Aug 2004 14:45:01 +0200

Vijay Devarapalli wrote:
>> In each BU, only the specified MNPs will be kept in the binding cache 
>> in the HA after a successful registration. All other MNPs not 
>> specified will be removed. In my example, MR would go from registering 
>> {MNP1, MNP2} to registering {MNP2} only. The binding for MNP1 will be 
>> removed immediately.
>>
>> Option 2:
>> transition, MR would also have to deregister MNP1 explicitly, by 
>> sending a BU with lifetime=0 and MNP1 as the only prefix option.
>>

It should be where it is now, Section 6.2. Thanks.

> I just deleted the first sentence in section 6.7.

Fine.

/Mattias

>>> It is important that the HA and the MR has exactly the same 
>>> perception on what prefixes are in use and what their respective 
>>> registration lifetimes are.
>>>
>>> IMHO I think it may be dangerous to mix explicit and implicit like 
>>> you describe below. Do you think it will add functionality?
>>>
>>> /Mattias
>>>