Re: [Mip4] Updated draft for Mobile IPv4 NAI-based Home AddressAssignment...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mip4] Updated draft for Mobile IPv4 NAI-based Home AddressAssignment...
Hi Kent,
After re-reading my message I noticed that the tone was very harsh. That
was not my intention and I apologize for it.
I just wanted to clarify my position on HoA==0 and HoA!=0 and I think
that it's important that we don't re-classify those basic indicators.
I think it's admirable to do an effort to clarify, educate and improve
interoperability. Sorry if I just complained, instead of contributing.
Best regards
/// Hasse
On 2006-03-21 11:13, Hans Sjostrand wrote:
> Hi Kent,
>
> I do not think that the draft clarified some ambiguities, instead it
> created ambiguities. I believe that the RFC3344 is quite clear and
> leaves no ambiguity on "that HA couldn't assign a different Home Address
> when the requested one"
>
> 3.7.3.1. Validity Checks
>
>> When a foreign agent receives a Registration Reply message, it MUST
>> search its visitor list for a pending Registration Request with the
>> same mobile node home address as indicated in the Reply. If no such
>> pending Request is found, and if the Registration Reply does not
>> correspond with any pending Registration Request with a zero mobile
>> node home address (see section 3.7.1), the foreign agent MUST
>> silently discard the Reply.
>>
>
> If you want to create another draft to clarify this again, please feel
> free. But do not alter the MUST statements in RFC3344.
>
> Best regards
> /// Hasse
>
>
> On 2006-03-16 00:22, Kent Leung (kleung) wrote:
>
>> Hi Kuntal.
>>
>> So let me try explain our original goal in the draft, which was
>> published back in
>> Mar 25, 2004.
>>
>> The draft clarified some of the ambiguities in RFC 2794. Since we
>> weren't clear how the spec was interpreted in implementations, we
>> decided to introduce the new extension to specify exactly how the
>> mobility entities should operate for dynamic home address assignment and
>> still be backward compatible to existing behavior. Nothing in RFC 2794
>> say that that HA couldn't assign a different Home Address when the
>> requested one is in use. If someone was already taking advantage of
>> such a feature, we didn't want to break that.
>>
>> I'm fine with avoiding the new extension if we can still achieve
>> backward compatability. Suggestions welcomed and always appreciated. :)
>>
>> Kent
>>
>>
>>
>>> -----Original Message-----
>>> From: Chowdhury, Kuntal [mailto:kchowdhury at starentnetworks.com]
>>> Sent: Wednesday, March 15, 2006 1:28 PM
>>> To: Kent Leung (kleung); Hans Sjostrand
>>> Cc: naveen Paulkandasamy (naveenpk); mip4 at ietf.org
>>> Subject: RE: [Mip4] Updated draft for Mobile IPv4 NAI-based
>>> Home AddressAssignment...
>>>
>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> "This email message and any attachments are confidential
>>> information of Starent Networks, Corp. The information
>>> transmitted may not be used to create or change any
>>> contractual obligations of Starent Networks, Corp. Any
>>> review, retransmission, dissemination or other use of, or
>>> taking of any action in reliance upon this e-mail and its
>>> attachments by persons or entities other than the intended
>>> recipient is prohibited. If you are not the intended
>>> recipient, please notify the sender immediately -- by
>>> replying to this message or by sending an email to
>>> postmaster at starentnetworks.com -- and destroy all copies of
>>> this message and any attachments without reading or
>>> disclosing their contents. Thank you."
>>>
>>>
>>>
>>
>>
>
>
>
--
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/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
