Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments

[Ryuji Wakikawa <[e-mail]>]

Hi Gerardo,

On 2008/12/18, at 1:47, Giaretta, Gerardo wrote:

> Hi Ryuji,
>
>> -----Original Message-----
>> From: Ryuji Wakikawa [mailto:[e-mail]]
>> Sent: Tuesday, December 16, 2008 11:32 PM
>> To: Giaretta, Gerardo
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals  
>> and some
>> comments
>>
>> Hi Gerardo,
>>
>> Yes, I was reading the mail threads. sorry to catch up this thread
>> late. I was in Europe;-)
>>
>> I understand the reasons of BID for the home attached interface.
>>
>> MN keeps sending the BU (w/ non zero lifetime) from the home link?
>> It sounds like we'll remove de-registration operation from RFC-3775?
>>
>
> The point is that the MN does no de-register as in RFC-3775 if there  
> are other active interfaces. The MN will de-register only when only  
> the interface on the home link is active.

OK

>> As a result, HA will have a home binding for the interface attached  
>> to
>> home link,
>> but will not operate proxy ND and encapsulation for that binding.
>
> If the HA is the default router, the HA will still intercept all  
> packets as defined in the draft. It is true that there will be no  
> encapsulation, but again this is already mentioned in the draft.
>
>> I don't know this is reasonable modification to RFC-3775.
>>
>> My understanding was that, when MN is at home, most of traffic should
>> be sent directly from the home link.
>> I didn't see any strong reasons to use the interface attached to
>> foreign links.
>> Why not setting special flows which need to be sent from the foreign
>> link by flow binding and
>> rest of traffic are just sent from the home link. We don't need BID
>> for the home attached interface.
>> This is what I expected.
>>
>> Do you think there is a case where MN attaches to home link by
>> multiple interfaces?
>>
>
> Think about this scenario: the MN has a cellular interface and a  
> WLAN interface. Cellular is the home link.
> MN wants to do VoIP over cellular and all other traffic over WLAN.  
> In this case the MN will register a match-all
> filter for WLAN BID and more specific FIDs for the "home binding".  
> This is the main scenario studied in 3GPP for example.
>
> In my opinion, allocating a BID for the HoA in the home link sounds  
> like the cleanest way of solving this scenario.
> However I am open to other suggestions as soon as the scenario is  
> supported :-)

If we need a BID for the interface attached to the home link, we need  
a "binding".
I think we don't have any other alternative for this purpose.

I will update the document for this and will post the new version  
(including modifications of all other comments during last call).

ryuji

>
> Gerardo
>
>> regards,
>> ryuji
>>
>>
>>
>>
>>
>> On 2008/12/17, at 15:42, Giaretta, Gerardo wrote:
>>
>>> Hi Ryuji,
>>>
>>> one point related to Christian's comments is that we need a BID also
>>> for the interface which is on the home link. This is needed in order
>>> to associate FIDs to that interface. The rules to create/update/
>>> delete that BID should be the same as for any other binding
>>>
>>> Gerardo
>>>
>>> ________________________________________
>>> From: [e-mail] [[e-mail]] On Behalf Of
>>> Ryuji Wakikawa [[e-mail]]
>>> Sent: Tuesday, December 16, 2008 10:27 PM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals
>>> and some    comments
>>>
>>> Hi Christian,
>>>
>>> thanks for comments.
>>>
>>> At Thu, 11 Dec 2008 15:08:16 +0100,
>>> <[e-mail]> wrote:
>>>>
>>>> Assume a mobile node with home address HoA has two interfaces,
>>>> both attached to foreign links.  After exchange of binding update
>>>> and binding acknowledgement, the home agent's binding cache (at
>>>> least the snip of it related to HoA) will look like this
>>>>
>>>>   HoA, BID= 7, CoA1, other parameters like period of validity...
>>>>   HoA, BID=10, CoA2, other parameters ...
>>>>
>>>> The draft uses HoA=2001:db8::EUI.
>>>>
>>>> Draft 10, section 5.1 states, that a BID value must be unique for a
>>>> home address and care-of address pair.  This is satisfied above,  
>>>> but
>>>> it means, that the mobile station is not allowed to change the
>>>> second entry such that it also uses CoA1 as care-of address.
>>>>
>>>> Proposal:  I think it has merit to be able to allow more than
>>>> one BID value per pair of home address and care-of address.   
>>>> Consider
>>>> flow bindings (defined in draft-ietf-mext-flow-binding) where
>>>> a flow may refer to a BID, and thus there is a simple way to move
>>>> flows between interfaces: only updating the binding cache.
>>>
>>>
>>> Do you want these bindings?
>>>    HoA, BID= 7, CoA1, other parameters like period of validity...
>>>    HoA, BID=10, CoA1, other parameters ...
>>>
>>> From the protocol operational view, we don't have any issue to relax
>>> the BID assignment for this purpose.
>>>
>>>> Draft 10, section 4.2 (and other places) defines the H flag, which
>>>> when
>>>> set means the mobile node wants to use both its home link and one  
>>>> or
>>>> more of its foreign links.  The H flag is really an instruction to
>>>> the
>>>> home agent, that in addition to all the bidings currently defined
>>>> is shall have an extra binding where packets shall not be tunneled.
>>>>
>>>> Proposal:  The mobile node should be able to define a binding  
>>>> saying
>>>>
>>>>   HoA BID=0 HoA
>>>>
>>>> This is a kind of default binding to be used when any of the other
>>>> HoA-
>>>> bindings cannot be used.  I think the H flag is an indirect way of
>>>> saying there is an extra binding, whereas the binding above is
>>>> direct.
>>>> It also avoids continuously setting the H flag when both home link
>>>> and foreign links are active.
>>>
>>> This was originally proposed by Keigo from Panasonic and has been
>>> discussed it.
>>> You can check the discussion on ML archives.
>>>
>>>>
>>>> Other comments
>>>>
>>>> o Figure 1: In general I think it simpler for human readers to have
>>>>  the elements of the primary key to a database given first,
>>>>  therefore I suggest
>>>>
>>>>      binding [2001:db8::EUI  BID1  care-of address1]
>>>>
>>>>  to be used allover.
>>>
>>> OK, will fix this.
>>>
>>>>
>>>> o Figure 4: looks as if position 6 is followed by position 17.
>>>
>>> this is typo. i'll fix this.
>>>
>>>> o Section 4.2, O flag.  The O flag is carried in an Binding
>>>>  Identification mobility option, but really it a kind of global
>>>>  value to be understood by the receiver as "clean all HoA entries".
>>>>  If it really is too much to introduce a new mobility option,
>>>>  isn't it enough to set the O flag in the first Binding
>>>>  Identification mobility option?
>>>
>>> I'm updating the document after last call. the O flag is now defined
>>> in the BU itself, since this is global value for all bindings as you
>>> pointedout.
>>>
>>>> o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet
>>>> 2.
>>>>  If the care-of address is omitted, the care-of address is to be
>>>>  taken from the source address of the IPv6 header.
>>>>  When the binding update arrives at the home agent, the
>>>>  IPv6 header's source address is exactly the care-of
>>>>  address used by the mobile node, but when the home agent is
>>>>  actually able to understand the contents of the binding update,
>>>>  then the IPv6 headers source address has been swapped with the
>>>>  address found in the Destination Option extension header,
>>>>  and thus the care-of address is now found in the Destination
>>>>  Option extension header.
>>>
>>> In section 6.1.7 of RFc3775, it said
>>> "The care-of address is specified either by the Source Address field
>>>  in the IPv6 header or by the Alternate Care-of Address option, if
>>>  present. "
>>>
>>> So, I will fix this to
>>>
>>> the care-of address is to be taken from the source address of the
>>> IPv6 header "of the Binding Update".
>>>
>>>
>>>> o Section 5.6.2, bullet 2.  The term link-local address is used,
>>>> but I
>>>>  think this should be changed to be like in all the other places,
>>>>  using link-layer address.
>>>
>>> yes, thanks.
>>>
>>>> o Section 6.2, bullet 7, sub-bullet 1: I think the condition should
>>>> read
>>>>  "If one of the 'O' flags is set, then all of the 'O' flags must be
>>>>  set, else [MCOA MALFORMED] is returned."  But as suggested above,
>>>>  I don't think there is reason to enforce an all-or-none 'O' flags.
>>>
>>> right, see above.
>>>
>>>> o Section 8.2, para 2.  The text says, that the IPv4 Address
>>>>  Acknowledgement mobility option is included only if the mobile  
>>>> node
>>>>  requested a home address.  When I read
>>>> draft-ietf-mext-nemo-v4traversal,
>>>>  section 4.2.1, the IPv4 Address Acknowledgement mobility option
>>>>  is included always, indicating the home agent created a binding
>>>> cache
>>>>  entry for the IPv4 home address.
>>>
>>> correct. I will check dsmip and update it.
>>>
>>> thanks
>>> ryuji
>>>
>>>
>>>> Christian
>>>>
>>>>
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mext
>>> _______________________________________________
>>> MEXT mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mext
>

_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext