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

[jouni korhonen <[e-mail]>]

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