When the next version of the draft is issued, incorporating
all the agreed resolutions of WG last call comments, we'll
post a note to the ipng mailing list summarizing the requirements
that the MIP WG is recommending.

Phil


> -----Original Message-----
> From: Jari Arkko [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 18, 2002 12:50 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: summary of HAO, BE processing discussion
> 
> 
> 
> I'm trying to summarize the discussion on the HAO and BE
> processing.
> 
> Here's a few things that came up in the discussion:
> 
> * MUSTs should be used only if interoperability is
>    at danger, or if the health of the internet is
>    in question even if protocols would operate
>    correctly.
> 
> * There will be existing IPv6 nodes that do not
>    yet have MIPv6 support, and not all of them can
>    be changed overnight when a new IPv6 RFC comes out.
> 
> * The current MIPv6 protocol works technically even
>    with non-MIPv6 nodes. The MNs will not normally
>    attempt to use HAO without establishing a binding.
>    If the CN does not support MIPv6 RR, it sends back
>    an ICMPv6 parameter problem. And even if the MN
>    went ahead and used HAO (as in with IPsec, for instance),
>    the CN would also respond with a parameter problem.
> 
>    This is in the current draft*.
> 
> * There are two potential node requirements from the
>    MIPv6 functionality:
>      - Route optimization, the main benefit (section 8.2)
>      - Basic HAO supported, a subset of the above and
>        used for HAO under IPsec with triangular routing
>        (8.1). Includes also BEs.
> 
> * The current draft does not state what the keyword
>    is for the RO functionality (so far left for the node
>    requirements team to decide, yet we intend to recommend
>    something). The draft does say MUST for basic
>    HAO support, however.
> 
> * The IETF is free to decide what kind of requirement to
>    place on nodes for these functions, since there are
>    no interoperability concerns.
> 
> * IPv6 WG has in the past accepted the HAO as a mandatory
>    feature for all IPv6 nodes. Arguments have been made,
>    however, that the processing of the HAO has been changed
>    and the situation may now be different.
> 
> * Arguments have been raised that the basic HAO support does
>    not fullfil conditions to be a MUST.
> 
> * Earlier discussions have looked upon what is the right
>    level of support for RO. Proposals ranging from MAY to
>    MUST were then mentioned, and arguments about congestion-like
>    effects of non-optimal routing were used among others.
> 
> Jari
> 
> * A last call comment requested more text for the HAO-without-RO case.
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to