RE: [Mip4] Updated draft for Mobile IPv4 NAI-based Home AddressAssignment...

["Chowdhury, Kuntal" <kchowdhury at starentnetworks.com>]

Kent,

Please see my comments inline...

> -----Original Message-----
> From: Kent Leung (kleung) [mailto:kleung at cisco.com]
> Sent: Wednesday, March 15, 2006 12:18 PM
> To: Hans Sjostrand
> Cc: Chowdhury, Kuntal; naveen Paulkandasamy (naveenpk); mip4 at ietf.org
> Subject: RE: [Mip4] Updated draft for Mobile IPv4 NAI-based Home
> AddressAssignment...
> 
> Hi Hasse.
> 
> The draft is based on the assumption that there are commercial
> deployments using Mobile IP implementations which are based on
> interpretions of ambiguous specifications in RFC 2794.  Given that,
any
> changes to the operation of the mobility entities should be backwards
> compatible.
> 
[KC>] Yes, breaking existing/deployed implementations should be avoided.

> How do you interpret when Home Address is non-zero in the RRQ with NAI
> extension?  Is it a "hint" like in DHCP or a mandate (which is implied
> in the discussions)?  RFC 2794 does not _specify_ which way to go.
> 
[KC>] NAI extension should be included regardless of the value in the
HoA field, IMHO. NAI is a good way to identify the user, simply
including HoA may not be sufficient to identify the user. So, I would
prefer to de-couple the use of NAI from HoA value in the MIP messages.
Regarding HoA, 
HoA=0.0.0.0 means: the MN is requesting a dynamic HoA assignment. HoA=
non-zero address means: the MN is requesting the HA to assign the
specified non-zero address. 

I am OK if you want to clarify this in the I-D. Do you need anything
more for the purpose of clarification?

> Should re-registration include the NAI extension? Is this covered
> clearly in an RFC?
> 
[KC>] Yes. It is OK to clarify this in an IETF document.

> I would agree with you if evidence is supplied which has explicit text
> in RFC to cover the ambiguities we've identified in the draft.  I'm
not
> looking for interpretation of the language.  Until then, I believe we
do
> need new specification to clarify all the scenarios relevant to
dynamic
> home address assignment.
> 
[KC>] Sure, if something is ambiguous, we should clarify it. But, we
should be very careful about not introducing new concepts along with
this clarification exercise.


> Kent
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Hans Sjostrand [mailto:hans at ipunplugged.com]
> > Sent: Wednesday, March 15, 2006 3:45 AM
> > To: Kent Leung (kleung)
> > Cc: Chowdhury, Kuntal; naveen Paulkandasamy (naveenpk);
mip4 at ietf.org
> > Subject: Re: [Mip4] Updated draft for Mobile IPv4 NAI-based
> > Home AddressAssignment...
> >
> > Hi Kent,
> >
> > I agree with Kuntal, I can't see any reason why adding a new
> > extension is needed  ?
> >
> > There are a problem, and that is that there are no specific
> > error code for address management errors. Henrik started to
> > address that problem last year when requested additional
> > error codes. Don't know exactly what happened with the code
> > points after that.
> >
> > But a new extension is a overkill solution to a problem that
> > atleast I can't understand from reading the draft. The
> > existing 3344 and 2794 mechanisms are enough in the cases
> > I've seen. Although the RFC's lack some implementation detail
> > on how this could be achieved. Thats understandable.
> >
> > Starting to assign new addresses instead of the ones
> > requested, thus breaking RFC3344, is a bad idea for a number
> > of reasons. Using some "ADDR_ALLOC_FAILED" error code and
> > then let the MN retry with 0.0.0.0 is a lot better. And no
> > new extension or new specification at all is needed.
> >
> > Regards
> > /// Hasse
> >
> > On 2006-03-09 02:17, Kent Leung (kleung) wrote:
> > > Hi Kuntal.  Comments below.
> > >
> > >
> > >> -----Original Message-----
> > >> From: Chowdhury, Kuntal [mailto:kchowdhury at starentnetworks.com]
> > >> Sent: Wednesday, March 08, 2006 4:00 PM
> > >> To: naveen Paulkandasamy (naveenpk); mip4 at ietf.org
> > >> Cc: Kent Leung (kleung)
> > >> Subject: RE: [Mip4] Updated draft for Mobile IPv4 NAI-based Home
> > >> AddressAssignment...
> > >>
> > >> "
> > >> If the home address field is 0.0.0.0 and the request has a NAI
> > >>     extension as well the Dynamic-HoA extension,
> > indicating that the
> > >>     mobile node is capable of dynamic home address
> > assignment, then
> > >> the
> > >>     home agent tries to assign a new address for the
> > mobile node and
> > >>     return a reply with the home address field containing the
> > >> assigned
> > >>     address. If the home agent is unable to assign an address, it
> > >>     rejects the request with the code ADDR_ALLOC_FAILED.
> > >> "
> > >>
> > >> HoA=0.0.0.0 in the RRQ means the MN is dynamic HoA capable.
> > >> So, why any other extension would be needed for the HA to
> > figure it
> > >> out?
> > >>
> > >>
> > >
> > > The HoA field was overloaded with both dynamic address
> > assignment flag
> > > and HoA of the MN.  The new extension is used to specify the logic
> > > described in this draft for dynamic address assignment, and be
> > > backward compatible since there are implementations based on
> > > interpretation of RFC 2794, which lacked some details.  These were
> > > identified in the draft.
> > >
> > >
> > >
> > >> "
> > >>     If the home address field is non-zero and the request
> > has a NAI
> > >>     extension as well as the Dynamic-HoA extension,
> > indicating that
> > >> the
> > >>     mobile node is capable of dynamic home address assignment,
the
> > >> home
> > >>     agent tries to assign the requested address specified
> > in the home
> > >>     address field and return the same address in the reply.
> > >> If the home
> > >>     agent is unable to assign the requested address, the
> > home agent
> > >>     tries to assign an alternative address and return the
> > alternative
> > >>     address in the reply. If the home agent is unable to assign
an
> > >>     alternative address, it rejects the request with the code
> > >>     ADDR_ALLOC_FAILED.
> > >>
> > >> "
> > >>
> > >> It seems you are proposing to piggyback MN's capability hint with
> > >> Dynamic-HoA extension. But, the I-D is about using NAI
> > extension to
> > >> assist HA to process the RRQ. Hence, I am confused about
> > the role of
> > >> NAI here. If the NAI is known, the HA can contact the AAA to and
> > >> download user/MN specific info which may very well include MN's
> > >> capability (i.e.
> > >> whether the MN can handle dynamically assigned HoA). That is more
> > >> in-line with the goal of the I-D, I think.
> > >>
> > >>
> > >
> > > The intent is not the MN's capability.  I think the
> > confusion is the
> > > wording of "
> > > mobile node is capable of dynamic home address".  What's
> > meant is that
> > > MN is requesting dynamic home address assignment as
> > indicated in the
> > > Dynamic-HoA extension.
> > >
> > > Kent
> > >
> > >
> >



--
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/