Subject: [Monami6] Comments on draft-wakikawa-mobileip-multiplecoa-04

From: Vidya Narayanan <[email-masked]>
Date: Thu, 27 Oct 2005 14:38:04 -0500

I apologize for not paying attention to the first 3 revisions of this draft
:) Here are some comments I have on the draft.
 1. I don't understand why each binding must be registered separately by the
MN. This forces the MN to send a separate BU for every CoA everytime. I
would have liked to see an approach that either extends the Alternate CoA
option to allow inclusion of multiple such options in a BU or define a new
option (say, Secondary CoA option) that can carry these additional CoAs from
the MN. I see that the draft mentions the limitation of the current MIP6
specification as a reason for this - but, in my view, this is not a good
reason for designing multiple CoA registration with separate BUs :) I think
that the limitation must be addressed if need be - especially given that
multiple CoA registration has very practical use cases and is likely to be
used a lot.
 2. According to the draft, the MN registers a particular CoA as the primary
CoA and if that CoA becomes unavailable or changes, it needs to register
another CoA as the primary one. This is ok, but it would be nice to have a
priority field associated with each CoA - I would not expect this draft to
define how these priorities are determined or how they are used, but it can
be seen to have some obvious uses.
 3. The section on returning home says that if the MN is attached to the
home link via one of the non-primary interfaces, it must not use the home
link (and continue using its primary CoA and hence have the HA continue
sending proxy NA for the MN). I don't understand the motivation for this. It
might make total sense for the MN to start using the home link, even though
it was not a previously preferred interface. It would be much better for the
MN to make that decision - i.e., it should be allowed to indicate whether or
not it wants the HA to continue doing proxy NA or not and accordingly, the
behavior will differ.
 4. On a related note, can an MN indicate while de-registering a CoA with
the HA to request that all other CoAs be "suspended" - this will allow the
MN to not have to register all the CoAs again when it moves away from the
home link - it only has to register the one belonging to the interface with
which it attached to the home link.
 5. A wildcard value (or the like) supported for the BID field will allow
things like de-registration of all CoAs simultaneously - that can be viewed
as a useful thing. Of course, this hinges on allowing registration of
multiple CoAs in one BU.
 6. It would be good to remove the text relating to QoS/policies from the
core of the draft - it may be okay to have that in the intro or something,
but given that the draft is not meant to address any details on that, it
would be good to get rid of that in the main part describing the protocol.
 Thanks,
Vidya
_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sun, 30 Oct 2005 20:43:28 +0900

Hi Vidya

Thanks for all the detailed comments.
Please find my comments inline.

At Thu, 27 Oct 2005 14:38:04 -0500,
> :) Here are some comments I have on the draft.

Finally, we successfully launched the discussion. 
I'm happy for that:-)

> multiple CoA registration has very practical use cases and is likely to be

OK. I was waiting for such comments:-p
I already replied this point in previous mail. 
Please check the mail replied to Shubhranshu.

> be seen to have some obvious uses.

priority for each interface was defined in the previous draft. 
see
http://www.wakikawa.org/docs/ietf/draft-wakikawa-mobileip-multiplecoa-01.txt

When we presented this draft in MIP6 WG, we had some comments that
this draft should deal with only registration management and not with
priority, flow movement, etc. 

Anyway, this can be easily fixed.

> not it wants the HA to continue doing proxy NA or not and accordingly, the

The primary interface is basically introduced for the operation of
returning home. 

If we can simplify the case that the use of HOME is always better,
this draft gets much simpler.  However some users may keep using other
interfaces even though MN is back to the home.

> which it attached to the home link.

interesting. This type of optimization may be useful.

> as a useful thing. Of course, this hinges on allowing registration of

OK. 

> would be good to get rid of that in the main part describing the protocol.

Yes. 

Before Monami6 WG, we needed to show the usability of the draft.  

Many texts were already merged to
draft-montavont-mobileip-multihoming-pb-statement 
and
draft-multihoming-generic-goals-and-benefits

I can fix this in the next revision. 

thanks,
ryuji

---

From: Vidya Narayanan <[email-masked]>
Date: Sun, 30 Oct 2005 13:26:51 -0500

> Please check the mail replied to Shubhranshu.

Personally, this is an area where I think changes to 3775 should be
considered. I see multiple CoA support as something that will be used
quite a bit in practical mip6 deployments - so, I feel this is a
useful discussion to have.

> Anyway, this can be easily fixed.

I agree that this draft shouldn't define what to do with the priority
- but, in order to take advantage of the multiple CoAs registered, I
think this is useful. Of course, it can be left to future work to
define an option to do this too. So, it is fine with me to leave this
out.

> The primary interface is basically introduced for the operation of

Interesting. I would imagine the primary CoA to indicate a CoA that
the HA/CN can use by default (instead of picking the first matching
CoA).

> interfaces even though MN is back to the home.

In some cases, yes. However, lets say I am connected to my home
network via one of my non-primary interfaces. If I want to get to some
local servers and my home link is secure, I may want to use that to
get to those servers rather than go through my primary interface that
isn't on my home link and isn't secure. I think you will find use
cases for both and that is why I think leaving that as an option that
the MN decides makes sense. I am not sure if it is really complicating
the protocol that much.

Thanks,
Vidya