Subject: RE: [Monami6] Accept draft-wakikawa-mobileip-multiplecoa-04.txt asMonami6 WG Document

From: Gerardo Giaretta <[email-masked]>
Date: Fri, 28 Oct 2005 10:44:24 +0200

Hi Vijay,

one comment below.. 

> Thierry Ernst wrote:
> > 
> > Dear all,
> > 
> > The WG has been formed with the following deliverable on 
> the charter:
> > 
> > - A protocol extension to Mobile IPv6 (RFC 3775) and NEMO Basic
> > Support (RFC 3963) to support the registration of multiple Care-of
> > Addresses at a given Home Agent address [Standard Track].
> > 
> > Jun 05	  	Submit Multiple CoA Registration to IESG
> > 
> > Chairs of the Monami6 WG would like to propose to move
> > draft-wakikawa-mobileip-multiplecoa-04.txt has the proposed 
> solution for
> > this deliverable, and we are therefore seeking consensus of 
> the Monami6
> > WG. We would like the discussion to happen from now on the 
> mailing list
> > and conclude it at next IETF meeting in Vancouver.
> 
> in general, I agree with the draft. it should be made
> a WG document.
> 
> but it needs some work. here is one of the issues.
> 
> when a mobile node reverse tunnels a packet to the
> HA, the HA performs a number of checks, which include
> checks on the outer source address (CoA). sometimes
> the tunnel decapsulation is done by IPsec code on
> the HA. the tunnel mode IPsec SA is typically keyed
> on the home address, but the CoA is stored in the
> SPD/SAD entries. we could store multiple CoAs in the
> binding cache, but it is not a standard IKEv2/IPsec
> practice to store multiple outer tunnel source
> addresses. we need to figure out a way to make this
> work.
> 
> other minor issues.
> 
> 1. the use of a flag in the binding update to
> indicate multiple CoA registrations. perhaps we could
> use a mobility option. flags are scarce.
> 
> 2. do we need to really extend DHAAD? we can have
> some kind of a reject status in the BAck if the HA
> does not support this option. or have the HA echo
> something back if it supports multiple CoA
> registration and has processed the BU successfully.
> 
> 3. I dont understand the need for a BID. the draft
> says
> 
> >          The BID is an identification number used to distinguish
> >          multiple bindings registered by the mobile node.  
> Assignment of
> >          distinct BID allows a mobile node to register 
> multiple binding
> >          cache entries for a given home address. 
> 
> doesnt the HoA/CoA pair uniquely identify a binding?

yes, but after a handoff in the BU the old CoA is not included. How do
you identify the BC entry that needs to be updated? 

> do you want a unique identifier for a particular
> binding even when the CoA changes? 

yes, I think this is needed. In my view, a binding should refer to a
particular interface of the MN. This is also needed if you want to
convey some flows to one interface rather than to another one (say WLAN
rather than GPRS).

--Gerardo

> in that case why
> not associate the interface with a particular binding?
> maybe I am missing something.
>
> 
> 
> _______________________________________________
> Monami6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/monami6
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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