Subject: [mobile-ip] multiple CoAs registration

From: Nicolas Montavont <[email-masked]>
Date: Thu, 17 Jul 2003 10:41:45 +0200

Hi Ryuji,

I read your draft on multiple CoAs registration and I also think that we 
really need to define a solution to use MIPv6 with a multiple interfaces 
MN.

Here are some comments on your draft:

   - Why do you introduce the interface identification (IFID) ? It could 
be sufficient to only register a CoA with the associated priority. 
Therefore, when the MN has to choose the destination address for a HoA, 
it can take the most preferred CoA, which is bound to the most preferred 
interface of the MN.

Anyway you use a one-to-one mapping between a CoA and a IFID, therefore 
you don't need both, or I missed a point ?

IMO, this is easier than all the mechanism to manage the IFID 
(generation, maintenance...)

   - If I well understand your draft, when the MN registers a CoA with a 
CN, the MN has to first register the primary CoA. Then it can send a 
Binding Update (after the RR procedure) to regsiter other CoA(s), with 
the associated priority. However, you say that the lowest priority is 
the preferred CoA/IF, and that the primary CoA has the priority 0. 
Therefore, each CN will use the primary CoA with the MN. Then, you are 
not able to perform load balancing, aren't you ?

   - Last point: If you return home with your primary interface (you 
connect to your home network with P-IF), do you have to de-register all 
CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ?

Regards,
Nicolas

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 17 Jul 2003 23:19:51 +0900

Hello Nicolas

thanks for comments.

> it can take the most preferred CoA, which is bound to the most preferred 

Priority can be changed by some reason during communication, but IFID
can not be changed until MN want to change it.

> (generation, maintenance...)

could be,  but I don't know why the maintenance and generation are so
difficult.

> not able to perform load balancing, aren't you ?

Well, the draft does not mention about how to utilize multiple care-of
addresses. I don't think MIP is only way to manage policy sets to divide
flows to each CoAs. If you really want load-balancing, you need some
mechanism to maintain policy sets between MN and CNs.

Load-balancing, for example, can be supported by upper
layers.
The point is that CN must be able to accept packets sent from multiple
.CoAs of MN. 

> CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ?

You are right. I personally got the same comment. 
I just keep protocol simple. 
I will update the draft before the next meeting.

thanks again!

regards,
ryuji

---

From: Nicolas Montavont <[email-masked]>
Date: Fri, 18 Jul 2003 18:36:14 +0200

Hi Ryuji,

I carry on my remarks... hope it helps !

>can not be changed until MN want to change it.
Ok, I understand that. But what I mean is that I don't see the 
requirement to have the IFID... In the Binding Cache, an entry could be 
identified by both the Home address and the CoA. It is sufficient to 
distinguish tow different entries. The priority field is then used to 
choose the CoA, i.e. the interface. No need to have the IFID I guess.

>could be,  but I don't know why the maintenance and generation are so
I don't say they are so much difficult, but they are not useful, since 
the IFID is not necessary (from my point of view). Maybe you can explain 
me when the IFID is useful ?

>The point is that CN must be able to accept packets sent from multiple
Ok I agree with you. But is it necessary to impose that a MN MUST 
register the pCoA with the highest priority with CN ? I thnik it is 
important that the MN does it with the HA, but I don't think it is 
necessary with CN.

If you have the choice to register the pCoA with a different priority 
with different CNs, you let an open door for upper layers to decide some 
load balancing policies.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 19 Jul 2003 21:15:50 +0900

Hello Nicolas

> choose the CoA, i.e. the interface. No need to have the IFID I guess.

I disagree.
ID is needed when CoA is changed.
If CoA1 is changed to CoA2, MN sends a BU with CoA2 to CN.
Before receiving the BU, CN has the binding entry which associate with
CoA1 and HoA, but BU carries new CoA2 in it. CN can not know which
binding cache entry should be updated for the BU. 

CN might create a new entry for the BU, because the pair of CoA1 and HoA
is different from CoA2 and HoA.

ID is enable CN to update the correspondent binding entry even if CoA is
changed.

> me when the IFID is useful ?

see above.
 
> important that the MN does it with the HA, but I don't think it is 

I got comments from WGchair whether I need priority field or not.
Policy can be treated as one of policy. I might remove the priority
field and keep the field as reserved.  

If there are no policies and priority values on CN, CN uses the first
matched BC entry for outgoing packets.

> with different CNs, you let an open door for upper layers to decide some 

This management is difficult. 
How does MN give different priority for each CNs. 
One of my intention is to eliminate these MN's decision from the draft.
I am interested in the policy management and notification, but it should
be described in a separate draft.

anyway, the issue of priority field is in my todo lists. 
I appreciate if anybody has comments on this

regards,
ryuji

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 21 Jul 2003 08:16:23 +0200

Hi Ryuji,

>ID is enable CN to update the correspondent binding entry even if CoA is
OK, now I get your point ! Do you think that this explanation should be 
introduced in the draft ?

>How does MN give different priority for each CNs.
This is exactly what is out of scope of the draft. But this would allow 
upper layers to take decision on flows mapping on interfaces and then to 
apply it.

>I appreciate if anybody has comments on this
My personal feeling is that your draft should specify that the MN can 
send different priorities on its interfaces to different CNs. But, the 
attribution of the priority is out of scope of the draft.

Regards,
Nicolas