Subject: Re: [Monami6] Problem with MCoA draft?!

From: Ken Nagami <[email-masked]>
Date: Fri, 07 Apr 2006 17:56:12 +0900

Hi Heikki,

>>The important aspect of bulk BU is that the address changes must be
>>happened at the same time. Otherwise, the MN shouldn't send BUs for
>>multiple CoAs.
>
>==> OK! I originally meant that the CoA1 and CoA2 are CoAs from the 
>same interface. So let me clarify my example. You have one HoA, 
>three CoAs and two interfaces. Two of the CoAs are from the same 
>interface. So even  when the CN or HA does not know based on the 
>CoAs or BIDs which address is from which MNs interface the BC would 
>look like this.
>
>BID1, HoA, CoA1 (WLAN)
>BID2, HoA, CoA2 (WLAN)
>BID3, HoA, CoA3 (EVDO)
>
>So now when your WLAN interface makes a handover from a link with 
>two prefixes to a link with only one prefix the CoA1 and CoA2 needs 
>to be "updated" to CoA4 which is now the new CoA of the WLAN 
>interface. In this case you can only reuse one of the BIDs (either 
>BID1 or BID2) for the CoA4 and you have to do something else to 
>remove the binding with the leftover BID. So this is why I make such 
>a fuss about this what if you have this many CoAs and they are 
>changed to this many CoAs. =) But OK, if you only want to support 
>one CoA per interface then this is no problem at all.

CoA of BID1 or BID2 needs to remove. MN sends BU with lifetime 0 and BID-option.
In this case, I think it does not have a problem.
MN needs to send bulk BU with reused BID and removed BID separately 
in the current draft.

BID1, HoA, CoA1  -> CoA4
BID2, HoA, CoA2  -> remove
BID3, HoQ, CoA3

Regards,
Ken Nagami 

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Heikki Mahkonen <[email-masked]>
Date: Wed, 12 Apr 2006 11:56:18 +0300

Hi Ken,

Ken Nagami wrote:
> MN needs to send bulk BU with reused BID and removed BID separately in 
> the current draft.
> 
> BID1, HoA, CoA1  -> CoA4
==> Yes I know that the current draft supports this option that you send 
BU with lifetime 0 for the BIDs you want to remove. However, my original 
point was that it cannot be done with bulk BU! I mean you cannot say in 
this case that it is a bulk BU if you send atleast two BUs. Ok, you can 
say that its a bulk update BU (multiple CoAs/BIDs updated) and bulk 
remove BU (multiple CoAs/BIDs removed) but it is not bulk BU to update 
all the invalid CoAs and BIDs.

So the difference here is that I'm talking about bulk BU which means 
that what ever kind of handover happens the MN only needs to send one BU 
to do all the updates and removals of BIDs (CoAs). Do you understand 
what I mean?

Thats why I was talking about adding the lifetime field to the new BID 
option! If the MN would add the lifetime to the new BID option, it would 
get bindings for all ats CoAs as described in the RFC 3775 and could 
send just one bulk BU to update/remove all the CoAs. I understand if you 
have made a decision that the MCoA does not have to support bindings 
(binding lifetiemes) as described in the RFC 3775 but can you describe 
why this is? If the lifetime is out of the question you could add flag 
to the BID option which says that remove this BID.

OK! So I am talking about real bulk BU registration/update meaning that 
the MN only sends on BU nad this BU can be answered with one BA. I think 
you still have not clearly thought what this bulk BU means. It does not 
mean anything like what is right now specified in the MCoA draft!!

BR,

Heikki Mahkoenen

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 17 Apr 2006 22:42:33 +0900

Hi Heikki

On 2006/03/29, at 17:13, Heikki Mahkonen wrote:

> Hi Ryuji,
>
> Thank you for your reply. I have included my (hopefully) clarifying  
> comments inline.
>
> Ryuji Wakikawa wrote:
>> You don't need to de-register CoA1 and CoA2, but only update CoA1  
>> and  CoA2 to CoA4 by two BUs.
>> HA can update the correspondent binding with the new CoA (i.e.  
>> CoA4)  because of BID.
>
> ==> OK! When I wrote the original mail I didn't take into acount  
> that it is possible to reuse BIDs. This I think is what you are  
> talking about in your reply, aren't you? I originally had the  
> misunderstanding that you create new BID for every CoA. So what you  
> do is you rather make one BID for the first CoA you register and  
> when this CoA changes you use the same BID for updating the  
> binding, right? This is a good mechanism but I still see a problem  
> with it and I try to clarify what I think the problem is.

ok

>> Anyway, your scenario may happen, but imagine when a MN has three   
>> different interfaces,
>> the address change will not be often occurred at the same time.
>
> ==> Yes it actually can, because ( I have a good imagination, no  
> =) ), you might have multiple CoAs per interface in this scenario  
> as well. So when you make a handover from one access network to  
> another and you had or now have multiple CoAs you end up sending  
> either one bulk BU or many BUs. So you could say that in this  
> scenario as well multiple CoAs are changing at the same time.

hmm, don't know how many access network distribute multiple prefixes.

>
>> For example, WLAN and EVDO are different coverage and handover  
>> timing  is also different.
>> That's why we only support separate BUs.
>
> ==> By saying this do you also say that you only want to support  
> one CoA per interface?

No.

> I have been focusing on this subject in more general level and  
> thinking how this would work for the different scenarios described  
> in the Analysis of Multihoming in Mobile IPv6 draft (draft-ietf- 
> monami6-mipv6-analysis-00.txt). There you also have scenarios where  
> you have more than one CoA in one interface (for instance more than  
> one prefix in the access network).

The point is that the current CoA can handle this case without any  
problem.  The optimization to the protocol is important, but the  
overhead should be considered.
If the chance to optimization is rare, additional spec. for  
optimization leads just complexity to the protocol.

You scenario above is valid, but the point is how necessary we  
optimize this case.

>
>> The important aspect of bulk BU is that the address changes must  
>> be  happened at the same time. Otherwise, the MN shouldn't send  
>> BUs for  multiple CoAs.
>>
>
> remove the binding with the leftover BID. So this is why I make  
> such a fuss about this what if you have this many CoAs and they are  
> My opinion is that you can't make the assumption that MNs are only  
> using one CoA per interface. At least, this assumption should be  
> clearly stated in the draft.

I didn't. My problem is whether this scenario is often happened or  
not. I think nobody knows at this point.

>
>>> One option could be for the MN to always add all the valid CoAs   
>>> into the BU message with lifetime 0 and when CN or HA receives  
>>> this  BU message it would
>> why lifetime zero?
>
> ==> =) I don't know, beats me (who wrote this?)! =) OK, I was  
> clearly thinking something else and writing something completely  
> different.
> My point which I tried to make (and clearly did not make) is that  
> when in a situation where you are replacing N bindings with N-M  
> (M>0) bindings you can't reuse all the BIDs and therefore you  
> cannot update all the BC entries. This is why you would need some  
> other means of removeing the bindings you don't need anymore and  
> updating them with the new ones and also leave the bindings still  
> valid (from different interfaces) in to the BC.

ok

>> No.
>> If MN has three CoAs, MN can send two BUs (a BU for CoA1 and a BU  
>> for  CoA2 and CoA3).
>
> ==> Hmmm... I don't understand this. Do you mean one BU for CoA1  
> and one for CoA2? Because the CoA3 should be left into the BC as it  
> is still valid because the EVDO interface did not move. Therefore,  
> no BUs should be sent with BID3 or how do you see this? So after  
> the update the binding cache should look like this, right.
>
> BID4, HoA, CoA4 (WLAN)
> BID3, HoA, CoA3 (EVDO)
>
> Now the BID4 could be BID1 or BID2 but one of these BC entries  
> needs to be removed by some other means.
>> deregistration and registration are occurred at once as same as  
>> MIP6.  i.e. Updating binding.
>
> ==> Actually I have to disagree here also. This is not always the  
> case!
>
> I think that there are three cases which need to be thought of:
>
> case 1:
> You have the same amount of CoA(s) in the new access network as you  
> had in the previous access network. In this case yes you can simply  
> update the binding and reuse the BID(s) for this. This is the same  
> as in MIP6 (RFC 3775). So no problem here! Other than the fact that  
> you need bulk registration to minimize the signaling overhead if  
> you have more than one CoA.
ok

> case 2:
> You have more CoAs in the new access network than you had in the  
> previous access network. In this case you can update the existing  
> bindings by reusing the BIDs and allocate new BID(s) for the  
> additional CoAs. So no problem here other that the possible  
> signaling overhead.

ok:-)

> case 3:
> You have less CoAs in the new access network than you had in the  
> previous access network. In this case you can only reuse some of  
> the BIDs to update the binding but have to have some mechanism to  
> remove the  not valid CoAs as well. So this case is the problem I'm  
> talking about.

I see.

>>> Do you or anybody have any thoughts about this?
>> I don't know if I understand your point
>
> ==> I hope you now see what I tried to explain in the original  
> mail? If you choose to only support one CoA per interface and this  
> is also WG's decision then I think this should also be stated in  
> the drafts which are writen for this WG.

I understood your problem, but I want to know how this optimization  
is important since this leads just small advantage with addition  
modification.

ryuji

> Best regards,
> Heikki Mahkonen