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

[[e-mail] (Arnaud Ebalard)]

Hi,

Ryuji Wakikawa <[e-mail]> writes:

> 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

                                                        s/node/nodes/

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

Fine with me (would just change "node" into "nodes").


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

Ack.

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

Ok, thanks for the background. That's what I was looking for.

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

Ack.

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

I have not checked if this is specified but what will the peer do if the
address (if provided, obviously) is not the current one? If the address
is not used for the deletion and can just create trouble, a MUST would
just help.

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

   - Returning Home with complete ownerhsip of the HoA
or - Returning Home with full de-registration with the HA

something like that, which explains what really happens.

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

Thanks for the pointer. Interesting slides.

> If you were there, we might beat this simultaneous things:-p
> At that time, I was alone to be against this.

Too bad, indeed. I was writing a comment about the impact of 3GPP
architecture in the spec, but I just erased it. It's in fact pointless
to discuss that here :-|

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

MCoA is clear on the expected format. I just say that you reuse a packet
format which in 3775 expresses just the reverse.

Cheers,

a+