Hi George,
appreciate your comments on the draft!
please see inline at [NAV]...
Tsirtsis, George wrote:
>Hi ghandi/Kent,
>
>This is a good and well overdue draft...we have been
dancing around
>these issues in the field for long time and it will be
good to have at
>last some clarity.
>
>In section 7.1.2 you require that the MN includes the
Dynamic-HoA
>extension in all re-registrations. Why is that? This
makes it hard for
>the HA to differentiate between the MN requesting
address allocation
>with a preferred address from the case where the MN has
already been
>allocated an address.
>
>
>For example consider Case 2 of Section 6.1:
>
>" Scenario : HA reboots after a MN
successfully registered and
> then receives a re-registration from
the MN and the
> HA is unable to assign the RRQ(HoA) to
the MN.."
>
>In this case you say:
>
>" HA Behavior : The HA MUST try to assign an
alternative address and
> if successful, it MUST create a new
binding entry and
> MUST return a RRP with HoA containing
the alternative
> address. If the HA is unable to assign
an alternative
> address, it MUST return a RRP with the
code
> ADDR_ALLOC_FAILED and RRP(HoA) set to
0.0.0.0. "
>
>Changing the address of the MN when the MN has not
explicitly requested
>such action sounds like a bad idea to me.
>
>Have you considered immediately returning a RRP with a
different error
>code, say something like "ADDR_UNAVAILABLE",
instead of attempting to
>reallocate an address? If the HA indicates what
happened, the MN is then
>free to do as it sees fit, including going through
another registration
>in which it includes the Dynamic-HoA extension leading
to the desired
>result.
>
>
>
[NAV] the idea behind including the Dynamic-HoA extension in
all
re-registrations is
as follows. basically in the HA reboot case, there are two
possible
actions that the MN can take,
when the HA informs the MN that it cannot support the MN's
old HoA anymore:
(i) the MN can request a new HoA from the HA using
Dynamic-HoA as per
this draft.
(ii) the MN can resort to some other means and prefers not
to get its
HoA from the HA immediately ?
we felt that, case (i) might be more common than (ii) and
so, we
preferred to optimize case (i)
to avoid the extra RRQ round trip by just letting the HA
allocate the
address if the old HoA
is not available. and in the case where the MN received a
new HoA but
wants to follow case (ii),
it can deregister the new HoA with an additional
deregistration, which
we felt was okay, if this
does not happen to be in the majority of the cases.
so, we think, it would be helpful to know more opinions from
you and the
group on
- what are the possible other actions that the MN can resort
to, in the
case (ii) scenario ? and,
- which scenario (case (i) or (ii)) would be the most
common scenario
so that we can optimize
or default to it?
also, if there is a consensus that, we want the MN to choose
the HA
behavior and make
case (ii) as the default , then we can change the MN
behavior to :
(i) can include the Dynamic-HoA extn in the RRQ, if it wants
it address
reassigned whenever
the HA cannot support the MN's old HoA.
(ii) can exclude the Dynamic-HoA extn in the RRQ and follow
the default
RFC 3344 behavior,
if it wants the HA to reject the RRQ with a error code (as
per rfc
3344 for downward
compatibility since the HA would not know if the MN is
compliant with
this draft, if it
has lost its previous binding ?) and the MN can then send a
RRQ again with
Dynamic-HoA if needed ?
please let us know what you think...
thanks,
ghandi.
>Thoughts?
>
>George
>
>-----Original Message-----
>From: ghandi Paulkandasamy [mailto:ghandipk cisco.com]
>Sent: Wednesday, March 08, 2006 5:14 PM
>To: mip4ietf.org
>Cc: Kent Leung
>Subject: [Mip4] Updated draft for Mobile IPv4 NAI-based
Home
>AddressAssignment...
>
>Hi All,
>
>we have submitted the updated draft for Mobile IPv4
NAI-based Home
>Address Assignment
>based on the comments received for the last version...
please let us
>know your comments...
>
>http://www.ietf.org/internet-drafts/draf
t-paulkandasamy-mobileip-nai-bas
>ed-home-addres-01.txt
>
>Abstract
>
> With the introduction of NAIs for identifying Mobile
Nodes, RFC
> 2794 also enabled the Home Agents to be able to
assign IP addresses
> to Mobile Nodes during their initial registration.
Though the
> concept of NAI-based home address assignment is
referenced in both
> RFC 2794 and RFC 3344, a comprehensive procedure for
achieving such
> a NAI-based home address assignment has not been
outlined. More
> particularly, the Home Agent and Mobile Node
behaviors including
> the error recovery mechanisms for various scenarios
related to NAI-
> based home address assignment have not yet been
specified. This
> document specifies a procedure that the Mobile IP
entities should
> follow in order to facilitate NAI-based home address
assignment
> under various circumstances.
>
>thanks,
>ghandi.
>
>
>
--
Mip4 mailing list: Mip4ietf.org
Web interface: https://w
ww1.ietf.org/mailman/listinfo/mip4
Charter page: h
ttp://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/
|