Subject: RE: [Monami6] Acceptdraft-wakikawa-mobileip-multiplecoa-04.txtasMonami6WG Document

From: "Koojana Kuladinithi" <[email-masked]>
Date: Tue, 1 Nov 2005 08:09:03 +0100

>
>
> > > => You essentially have the default operation: "replace" 
>today.  > > You can also add a new operation: "add" in the 
>signalling.  > 
> > Well, MIP6 has "add" function for the first binding:-)
> > We also need something to identify which CoA in bindings 
> > should be replaced.
> > 
>
>=> I think I skipped a couple of steps. I assumed that we can 
>do this with one BU. Based on that assumption, you could 
>send all CoAs in one BU to replace the existing ones. 
>I know that this is not how the draft works but this was my
>way of doing it. 

If you do this when registering with CN, is there any implication on
return routability procedure (you are sending more CoAs on one binding)?

Koojana

>
>===========================================================
>This email may contain confidential and privileged material 
>for the sole use  of the intended recipient.  Any review or 
>distribution by others is strictly  prohibited.  If you are 
>not the intended recipient please contact the sender  and 
>delete all copies. 
>===========================================================
>
>
>_______________________________________________
>Monami6 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/monami6
>

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 2 Nov 2005 15:43:52 +0100

On Monday 31 October 2005 23:18, Soliman, Hesham wrote:
>  > > today. You can also add a new operation: "add" in the
>  > > signalling.
>  >

FWIW, in the HIP mobility and multi-homing support, updates contain 
'full set' of adresses, as opposed to 'incremental set' with 
add/replace semantics. So update messages contains all addresses, 
amongst which one is primary. That was thought to be easier to 
implement and less prone to confusion, without significant drawbacks.

Given the size of an IP address, I don't think it is a problem to send 
all of them at once in a BU. This is also more efficient as noted by 
Vidya.

--julien

---

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Nov 2005 16:12:15 +0100

In your previous mail you wrote:

=> MOBIKE did the same choice so we know the two drawbacks:
 - it is really painful with a long list of addresses
 - if the list is only about additional addresses, an "empty list"
   is needed.
BTW in the case of MCoA it is useful to give a global (i.e., known
by both peers) number to a tunnel/CoA. On the other side the primary
CoA is very easy to recognize.

=> IMHO it is a matter of taste.

Regards

[email-masked]

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 04 Nov 2005 00:31:54 +0900

Hello Hesham

At Mon, 31 Oct 2005 17:18:35 -0500,
Soliman, Hesham wrote:
> 
> 
> 
>  > > => You essentially have the default operation: "replace" today.
>  > > You can also add a new operation: "add" in the signalling.
>  > 

The replace/add management has disadvantages.
If there are many care-of addresses, single BU becomes
overhead. (Vidya also commented) 
Large packet size should be avoided in wireless link (for no L2
retransmission), especially if the link is unstable.

If 4 addresses in BU and 2 of the addresses are invalid, it is
troublesome to reply BA status for the two addresses.  For example,
the status value: 128,129,130,and 137 are possible status per CoA.

However, it seems that single BU for multiple CoAs are also efficient
(not bothering multiple BUs). But this can be easily supported by
the MCoA.

> BTW, my initial comment was about the usefulness of this draft
> on its own. Could you shed some light on that? Why is this 
> useful/needed?

I believe this is written in the draft:-)
some texts from the draft.

   However, according to section 11.5.3 of the Mobile IPv6 specification
   [5], a mobile node is not allowed to register multiple care-of
   addresses bound to a single home address.  If a mobile node sends
   Binding Updates for each care-of address, correspondent nodes would
   always overwrite the care-of address recorded in the binding cache
   with the one contained in the latest received binding update.  It
   is thus impossible for a mobile node to register multiple care-of
   addresses in the correspondent node's binding cache.

   A user of a mobile node may be able to bind some policies to a BID.
   The policy is used to divide flows to multiple network interfaces
   by flow type, port number, or destination address, etc.  How to
   distribute or configure policies is not within the scope of this
   document.

hope it helps.

regards,
ryuji

> Hesham
> This email may contain confidential and privileged material for the sole use
>  of the intended recipient.  Any review or distribution by others is strictly
>  prohibited.  If you are not the intended recipient please contact the sender
>  and delete all copies.