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

[Ryuji Wakikawa <[e-mail]>]

Hi Vidya

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

At Thu, 27 Oct 2005 14:38:04 -0500,
Vidya Narayanan wrote:
> 
> I apologize for not paying attention to the first 3 revisions of this draft
> :) Here are some comments I have on the draft.

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

>  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.

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

>  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.

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.

>  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.

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.

>  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.

interesting. This type of optimization may be useful.

>  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.

OK. 

>  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.

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


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