Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals

[Ryuji Wakikawa <[e-mail]>]

Hi Arnaud,

On 2009/05/07, at 2:46, Arnaud Ebalard wrote:
>>
>>   The mobile node may return to the home link through one of its
>>   interfaces.  There are two options possible for the mobile node  
>> when
>>   its returns home.  Section 5.6 and Section 5.5.1 describe the
>>   returning home procedures in more detail.
>>
>>   1.  The mobile node uses only the interface with which it  
>> attaches to
>>       the home link.
>
> I think that first sentence is a bit misleading w.r.t. the content of
> the paragraph. The whole idea of option 1) is just that the MN
> de-registers all bindings with the HA and takes back full ownership of
> its HoA. Binding with CN may remain in place. What about (just a
> proposal) saying just that, i.e. use the following to describe that
> setup:
>
>     1. The mobile node de-registers all bindings with the HA related  
> to
>        all care-of addresses it has and takes back full ownership of
>        its HoA on the home link. The net effect of this de- 
> registration
>        is that it no more receives any encapsulated traffic from the
>        Home Agent on any of its interfaces. In parallel, the mobile
>        node can still use the interfaces attached to foreign networks
>        for route-optimized communications with correspondent nodes
>        (from/to CoA1 and CoA2). This setup is illustrated in Figure 2.
>
>
> This is while rewriting this paragraph that I thought it would be a  
> good
> idea for the MN to be able to express to CN the fact that some flows
> should be directly sent to the HoA. Hence, the idea of asosciating  
> BID 0
> to that feature.

Thanks for texts. However, I would limit the number of changes in the  
doc at this stage.
I slightly modify the text according to your points.

    1.  The mobile node uses only the interface with which it attaches  
to
        the home link and takes back full ownership of its HoA on the
        home link.  This is illustrated in Figure 2.  It de-registers  
all
        bindings with the home agent related to all care-of addresses.
        The interfaces still attached to the visited link(s) are no
        longer going to be receiving any encapsulated traffic from the
        home agent.  On the other hand, the mobile node can continue
        communicating with the correspondent node from the other
        interfaces attached to foreign links by using route  
optimization.
        Even if the mobile node is attached to the home link, it can
        still send Binding Updates for other active care-of addresses
        (CoA1 and CoA2) to correspondent nodes.  Since the correspondent
        node has bindings, packets are routed from and to each Care-of
        Addresses directly.

>>   Binding ID (BID)
>>
>>      The BID which is assigned to the binding indicated by the care- 
>> of
>>      address in the Binding Update or the Binding Identifier mobility
>>      option.  The BID is a 16-bit unsigned integer.  The value of  
>> zero
>>      is reserved and MUST NOT be used.
>
> The value MUST NOT be used. 2 questions:
>  - maybe the rationale for that decision could be provided
>  - what if a peer receives a BID with that value. What behavior is
>    specified in that case and what will it allow if at some point that
>    reserved value needs to be used?

This is actually SHOULD NOT.
This is error when I updated the document.

In section 5.1, we've had the update texts.
    "A mobile node assigns a BID to each care-of address when it wants  
to
    register them simultaneously with its home address.  The BID MUST be
    unique for a given home address.  The value is an integer between 1
    and 65535.  Zero value SHOULD NOT be used as BIDs.  If a mobile node
    has only one care-of address, the assignment of a BID is not needed
    until it has multiple care-of addresses to register with, at which
    time all of the care-of addresses MUST be mapped to BIDs."

Any future document can overwrite this spec.
As for MCoA, we don't use zero value.

There is background story here. The flow binding document needs  
default binding.
We had used zero value to specify the default binding in MCoA.

After the long discussion in WG, we agreed not to have this value in  
MCoA.
The default binding should be defined in the flow binding.

>>      This flag is valid only for a Binding Update sent to the home
>>      agent.
>>
>>   Reserved
>>
>>      7 bits Reserved field.  The value MUST be initialized to zero by
>>      the sender, and SHOULD be ignored by the receiver.
>
> Why not a MUST for the receiver?

This is error, too. It should be MUST

>>   If a mobile node wants to delete a particular binding(s) from its
>>   home agent and correspondent nodes, the mobile node sends a Binding
>>   Update with lifetime set to zero and includes a Binding Identifier
>>   mobility option(s) with the BID(s) it wants to de-register.  The
>>   receiver will remove only the care-of address(es) that match(es)  
>> the
>>   specified BID(s).  Since de-registration attempts to remove a BID
>>   that already exists, the care-of addresses field in each binding
>>   identifier option can be omitted by the sender as defined in
>>   Section 5.1.
>
> why not change the last 'can' to a MUST then?

This is just optimization. It's up to MN whether saving bits or not.

>
>> 5.5.  Returning Home: Using Single Interface
>
> The title of this subsection is not very explicit, is it?

any proposal?

>
>>   The mobile node may return to the home link, by attaching to the  
>> home
>>   link through one of its interfaces.  When the mobile node wants to
>>   return home, it should be configured with information on what
>>   interface it needs to use.
>>
>> 5.5.1.  Using only Interface attached to the Home Link
>>
>>   The mobile node returns home and de-registers all the bindings as
>>   shown in Figure 2 and as defined in [RFC-3775].
>
> Should be more explicit: "The mobile node returns home and de- 
> registers
> all the bindings it has with the home agent as shown in Figure 2 and  
> as
> defined in [RFC-3775]."

ok, fixed.

>> 5.5.2.  Using only Interface attached to the Visited Link
>>
>>   The mobile node returns home physically but shuts down the  
>> interface
>>   attached to the home link.  As a result, a mobile node does not
>>   return home even though it attaches to the home link by one of
>>   interfaces.  Before shutting down the interface, any binding for  
>> the
>>   care-of address previously associated with the interface should be
>>   deleted as defined in .
>
>     this sentence ends badly ...

right, there was typo at xml tag.

>>   In this scenario, despite the fact that the mobile node is  
>> connected
>>   to its home link, all of its traffic is sent and received via the
>>   home agent and its foreign links.
>
> After reading those two paragraph, this "functionality" seems weird,  
> to
> say the least. Can someone provide any rationale? or network
> architecture where it is beneficial to do that? In that case, would it
> not be better to consider the MN is never at home, i.e. has no home
> network instead of that trick?

again, this was also discussed.
Please check my slide at IETF 67 monami's WG meeting at 2006 Nov.
http://www.ietf.org/proceedings/06nov/slides/monami6-0.pdf

If you were there, we might beat this simultaneous things:-p
At that time, I was alone to be against this.
>>
>> 5.6.3.  Home Binding Support
>>
>>   When the home binding is used, the mobile node MUST send a
>>   registering binding update with a Binding Identifier mobility  
>> option
>>   whith H flag set.  The lifetime MUST be set to a non-zero  
>> lifetime of
>>   the home binding, and the care-of address MUST be set to the home
>>   address.
>
> as discussed 2 days ago on the list, it may be good to explicitly  
> states
> the fact that this specific format of a de-registration BU in 3775 and
> that the draft changes that behavior.

The de-registration BU is obvious from the spec.
I don't know we should have all the possible packet formats.
Specially this packet is somehow clear from the texts.

We did the same for binding update. The differences are same for both  
BUs (registering/de-registering).

Thanks for the detailed comment!

regards,
ryuji