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

[Hesham Soliman <[e-mail]>]

>> 
>> => But why would the MN want to do that? The scenario you're suggesting
>> means that there is effectively one binding, so why do we need to allocated
>> two BIDs to the same CoA? If there is a reason then I think your proposal is
>> fine, although it will be tricky to implement. But I'd like to see a
>> plausible scenario first.
>> 
> 
> Suppose the MN is connected to access 1 and access2 and has two flow bindings
> with two different CoA
> 
> HoA, BID=1, CoA1, FID1, FID4, FID6
> HoA, BID=2, CoA2 FID2, FID3, FID5
> 
> When the MN loses access 2 coverage it can do two things to keep the flows
> active:
> - send a BU with HoA, BID=1, FID2, FID3, FID5 to add those flows to the first
> binding
> - send a BU with HoA, BID=2, CoA1 to update the CoA of the second binding
> 
> The second has advantages in terms of signaling overhead. This is true in
> particular if then the MN moves back to access2 and wants to re-establish the
> flow bindings as previously. In that case just a new CoA update is needed
> instead of re-registering the flows again.

=> That's right, I guessed this is why you and Christian were asking for it.
But I think it's strange to have a binding id if it's not unique because
it's basically replicating the binding in case we need to change the CoA. It
makes things more complex and error prone in the implementation for a small
difference of bytes that will be sent. After all, you're not eliminating the
need to send another BU, you're just sending a smaller BU. So if you're
lucky, you'll save tens of bytes. It's not worth it IMHO.

Hesham

> 
> If the second approach is used you will have up giving two different BIDs for
> which the CoA is the same. But this should not be an issue as the bindings are
> treated independently, they just happen to point to the same CoA
> 
> Gerardo
> 
>>> 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 is basically asking for a permanent binding. Again, I'd like to
>> understand why this is needed, compared to what the draft says now.
>> 
>> Hesham
>> 
>> 
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext


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