Re: [netext] draft-ietf-netext-redirect-10

[<[e-mail]>]

Thanks Jouni for bringing these clarifications to the attention of the WG.
I have no specific comments or suggestions regarding the proposed changes.
Please note that there will not be any additional WG last call to this I-D
as a result of these changes.

-Raj

On 9/5/11 1:56 AM, "ext jouni korhonen" <[e-mail]> wrote:

>Folks, 
>
>Based on implementation experience we felt there really is a need to
>shape up few places in the draft-ietf-netext-redirect-09 and also fix
>some overlooked details. This is done with a knowledge of our AD. See
>recently posted draft-ietf-netext-redirect-10 for exact text
>changes/modifications.
>
>First, a bunch of clarifications:
>
>o In section 1 the text is slightly modified to clarify that AAA/DNS
>support
>  is not needed for the initial discovery & selection of the (rf)LMA. Once
>  the MAG learns a number of r2LMAs it does not actually need to contact
>the
>  rfLMA every time thus bypassing the rfLMA as soon and often as possible.
>
>o In Section 1 we also clarified that all MAGs and LMAs that can do
>  "redirection" have to belong to the same PMIP6 domain.
>
>o In Section 4 we remind that all values and numbers are actually in
>network
>  byte order.
>
>o in Section 4.2 it was clarified (or rephrased actually) that the
>Redirect
>  option in a PBA contains IPv6 address of the r2LMA when the
>corresponding
>  PBU source IP address was IPv6 address. And the same for IPv4 as well.
> 
>o In multiple places we included a reference to RFC5844 just to remind
>that
>  the solution is also applicable when IPv4-HoA and/or IPv4 transport is
>  used.
>
>o Figure 1 was modified so that MAG-rfLMA and rfLMA-r2LMA steps are
>  actually logically separate independent whether the rfLMA and r2LMA are
>  collocated or separate.
>
>o In Section 5.2 we emphasize that MAG must ignore unsolicited Redirect
>  option and continue PBA processing as described in RFC5213.
>
>o In Section 5.2 we added a mention of tunnel creation and a reference to
>  MAG tunnel creation procedures in RFC5213.
>
>o In Section 5.3.1 we added Figure 2 to show an example signaling in case
>  of 'collocated rfLMA and r2LMA'.
>
>o In Section 5.3.2 we added Figure 3 to show an example signaling in case
>  of 'separate rfLMA (proxy-MAG) and r2LMA'.
>
>o In Section 5.3.2 we clarify what addresses go into PBUs/PBAs.
>
>o Section 6 is renamed to "Handoff and Multi-Homing Considerations" as it
>  is about both, not just about multi-homing.
>
>o In Section 7 we state that for a rfLMA most of the RFC5213 configuration
>  objects do not apply when an LMA is in rfLMA role.
>
>Second, an enhancement to distribute load information around which helps
>MAGs and proxy-MAGs to select r2LMAs. This is to make the solution more
>standalone and not to mandate an introduction of some "load distribution"
>protocol as a part of the package:
>
>o Section 4.3 introduces a new Load Information mobility option that
>  contains basic key performance indicators of r2LMAs for MAGs to check
>  the load of the box and possibly prioritize them based on that
>  information. The use of option is optional.
>
>Third, fixes to flaws & found issues:
>
>o In Section 5.3.1 the reference to LMA tunnel creation procedures into
>  RFC5213 was actually pointing to MAG procedures.
>
>o Since -08 we do not have need for redirect related Status Values. Some
>  of those were left in the document due to sloppiness of the editor *g*
>  when doing -08. Thus 'Accepted_and_Redirected_with_Binding' is now also
>  removed. To find out whether a redirection took place, Redirect option
>  in a PBA is sufficient. This is also required to make the redirect
>  compliant with e.g. RFC5845.
>
>o Then a bigger one, which concerns the use of Alternate Care-of Address
>  in RFC5844 & IPv4 transport scope. There is actually no exact text
>  anywhere (in RFC5844 or RFC5555) what goes in that mobility option when
>  IPv4 transport is used. Our initial reaction (and actually was the
>  assumption of some authors) was that IPv4-mapped addresses are just
>fine.
>
>  Anyway, as we cannot really be sure we felt that we really need to have
>  a new mobility option for Alternate IPv4 Care-of Address and define the
>  the exact behavior for it. In this way we can actually make sure a LMA
>  understood the Alternate IPv4 Care-of Address. Section 4.4 describes
>  the new option. We know this is late in document cycle and adds a new
>  MUST into Section 5.3.2 but it is more or less required.
>
>Phew..
>
>- Jouni
>_______________________________________________
>netext mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/netext