Subject: [netext] Review of draft-ietf-netext-redirect-01

From: Qin Wu <[email-masked]>
Date: Thu, 15 Apr 2010 10:49:00 +0800

Hi,
In Anaheim I volunteered to review this I-D. I think this I-D has been in good shape. Here is my review of redirection document.
---------------------------------------------------------------------------------------------------------------------------------
In the section 1:
   o  LMAs with multiple IP addresses: a cluster of LMAs or a blade
      architecture LMA may appear to the routing system as multiple LMAs
      with separate unicast IP addresses.  A MAG can initially select
      any of those LMA IP addresses as the LMA Address using e.g., DNS-
      and AAA-based solutions.  However, MAG's initial selection may be
      suboptimal from the LMA point of view and immediate redirection to
      a "proper LMA" would be needed.  The LMA could use [RFC5142] based
      approach but that would imply unnecessary setting up of a mobility
      session in a "wrong LMA" with associated backend support system
      interactions, involve additional signaling between the MAG and the
      LMA, and re-establishing mobility session to the new LMA again
      with associated signaling.
      
      [Qin]: As described in [RFC5142], it seems changing the home agent 
      of mobile node is mainly becos load balance consideration or overloaded
      factor. Therefore not sure whether the bullet one(LMAs with multiple IP
      address) overlaps with bulltet two(Bypassing a load balancer).
      [Qin] In the section 5.4, it mentioned that Mobility Session can be Created 
      After the Redirection. Not sure whether additional signaling between the MAG
      and the redirected LMA is required?

   o  Independence from DNS: DNS-based load balancing is a common
      practise.  However, keeping MAGs up-to-date with LMA load status
      using DNS is hard e.g., due caching and unpredictable zone update
      delays. Generally, LMAs constantly updating [RFC2136] zone's
      master DNS server might not feasible in a large PMIPv6 domain due
      to increased load on the master DNS server and additional
      background signaling.  Furthermore, MAGs may do (LMA) destination
      address selection decisions that are not in-line what the DNS
      administrator actually wanted [RFC3484].

      [Qin]: Are you saying DNS-based LMA discovery is independent from
      runtime LMA assignment described in this document? In some cases, DNS-based
      LMA discovery may cost too much. Then we can choose runtime LMA assignment instead of
      DNS-based approach. 
      If in this way, I am not really clear what the DNS-based load balancing is here?
      Are you saying we need tradeoff between DNS based approach and runtime LMA assignment?

   o  Independence from AAA: AAA-based solutions have basically the same
      arguments as DNS-based solutions above.  It is also typical that
      AAA-based solutions offload the initial LMA selection to the DNS
      infrastructure.  The AAA infrastructure does not return an IP
      address or a Fully Qualified domain Name (FQDN) to a single LMA,
      rather a FQDN representing a group of LMAs.

      [Qin] It is better to have references to AAA based solution and DNS based solution.

   o  Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6
      specification does not specify how the PMIPv6 protocol should
      treat anycast addresses assigned to mobility agents.  Although
      [RFC4291] now allows using anycast addresses as source addresses,
      it does not make much sense using anycast addresses for the MAG to
      the LMA communication after the initial PBU/PBA exchange.  For
      example, a blade architecture LMA may appear to the routing system
      as multiple LMAs with separate unicast IP addresses and with one
      or more "grouping" anycast addresses.   

      [Qin]: Not sure [RFC4291] allow using anycast address as source adresses or destination adress?
      [Qin]: I don't really understand what this paragraph want to deliver?
             The mechanism for Runtime LMA assignment does not support IPv6 anycast addressing?
             It seems this parpagraph is not the reason for using runtime assignment? am I right?

In section 3:
   The LMA MUST NOT include the Redirect mobility option in the PBA and
   perform the redirection, unless the MAG indicated the redirection
   functionality support in the corresponding PBU using the Redirection-
   Capability mobility option.  The LMA MUST NOT include the Redirect
   mobility option unsolicited even if the MAG had earlier indicated
   support for the redirection functionality.

   [Qin] It seems to me that this assumption is too strict. What if MAG and LMA have a prioor aggreement that
   MAG support Rediction functionality?

In section 4.2:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Option Type   | Option Length |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      IPv6 r2LMA Address                       |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Optional IPv4 r2LMA Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Redirect Mobility Option

   o  Option Type: 8-bit identifier set to TBD2.

   o  Option Length: 8-bit unsigned integer, representing the length of
      the Redirect mobility option in octets, excluding the Option Type
      and Length fields.  If the IPv4 LMA Address is included in the
      option, the Option Length MUST be set to 22.  Otherwise, the
      Option Length MUST be set to 18.

   o  Reserved: This field is reserved for future use.  MUST be set to
      zero.

   o  IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA.

   o  Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA.  This
      value is present if the r2LMA IPv4 address is available.

    [Qin]: I think whether IPv4 r2LMA address is included depends on 
    a) the r2LMA IPv4 address is available by rfLMA b) 'F'flag is set
    to 1 in the Redirect-Capability Mobility Option? what am I missing?

In section 6:
   A MN can be multi-homed.  A single LMA entity should have the control
   over all possible multi-homed mobility sessions the MN has.  All
   mobility sessions a multi-homed MN may have SHOULD be anchored in the
   single LMA entity.  Therefore, once the MN has established one
   mobility session with one LMA, the subsequent mobility sessions of
   the same MN SHOULD be anchored to the LMA that was initially
   assigned.
   [Qin]: Little confused here. If MN has changed from 
   rfLMA to r2LMA, there are two choices ensuing :
   a) all the mobility sessions should be moved from rfLMA to r2LMA.
   b) all the mobility sessions will still stay at rfLMA?
   which one is correct?

   One possible solution already supported by this specification is
   applying the redirection only for the very first initial attach a
   multi-homed MN does towards a PMIPv6 domain.  After the initial
   attach, the assigned r2LMA Address has been stored in the policy
   profile.  For the subsequent mobility sessions of the multi-homed MN,
   the same assigned r2LMA Address would be used and there is no need to
   contact the rfLMA.

   [Qin]: What if r2LMA is overloaded again and need to rediret the mobility session
   to another new r2LMA?

In Section 8:
   If a PMIPv6 domain deployment with a redirection requires that a
   rfLMA has to modify a received PBU in any way e.g., by changing the
   destination IP address field of the outer IP header, then the
   security mechanism (such as possible authentication options) used to
   protect the PBU must not cover the outer IP header on those parts
   that might get modified.  Alternatively, the rfLMA can do all
   required security mechanism processing on the received PBU and remove
   those security related options from the PBU that would cause the
   security check to fail on the r2LMA.

   [Qin]: It seems to me changing the security part in the PBU is a big challenging to runtime assignment.
   So I think maybe it is simpler to add another outer IP header which may sacrifice some processing overheads at rfLMA.

---

From: jouni korhonen <[email-masked]>
Date: Fri, 16 Apr 2010 19:01:46 +0300

Hi Qin,

Thanks for the review! See my initial responses inline:

> In Anaheim I volunteered to review this I-D. I think this I-D has been in good shape. Here is my review of redirection document.

These are two different cases. Bullet one is about a wrong LMA selection decision made by a MAG that needs to be "corrected" by a LMA.. using excess signaling and unnecessary intermediate, yet complete, state creation in a LMA. Bullet two is about how to avoid a load balancing entity becoming a bottleneck.

>       and the redirected LMA is required?

If you are referring to RFC5142 here, then before you can do the HA switch you need to setup a mobility session in both MAG and LMA before you can actually send HA switch messages followed by closing the old mobility session & creating a new one. Also, in real systems setting up a mobility session in a LMA would involve a huge amount of additional signaling toward subscriber management systems and such. These are "additional signaling" what we want to avoid.

>       LMA discovery may cost too much. Then we can choose runtime LMA assignment instead of

Hmm.. not entirely sure what you are after here. However, typical DNS-based load balancing solutions just use a round-robin feature when returning multiple A records, thus spreading load among a number of LMAs.

The solution described in the draft does not need DNS for its load balancing/redirection decision. Even if DNS pointed MAG to a certain rfLMA, the rfLMA can still does a redirection decision independent what DNS does..

>       Are you saying we need tradeoff between DNS based approach and runtime LMA assignment?

See above. Also, we need a solution that does not depend on DNS at all.

>       [Qin] It is better to have references to AAA based solution and DNS based solution.

Ok. What about:
  AAA solution -> RFC5779 ?
  DNS solution -> maybe ietf-draft-netlmm-lma-discovery ??

>       [Qin]: Not sure [RFC4291] allow using anycast address as source adresses or destination adress?

RFC4291 Appendix B first bullet says that anycast address restrictions of RFC3515 were removed. In RFC3515 Section 2.6 use of anycast addresses as a source address or as an address of an IPv6 host were explicitly prohibited.

>              It seems this parpagraph is not the reason for using runtime assignment? am I right?

Nop. A pool of (rf)LMAs may have anycast address. Once you contact such LMA, you better be redirected to a unicast address of a LMA.. otherwise stuff breaks.

>    MAG support Rediction functionality?

That is a normal way we indicate support for certain new features in protocols. That allows mixing MAGs and LMAs e.g. with different software releases in a PMIPv6 Domain.

> In section 4.2:

You are right about the 'F' flag missing in the selection rule description, thanks. Actually, this whole option has to be modified slightly. The ipv4-support-18 now defines that in case of IPv4 transport we do not carry IPv6 proxy-CoA and LMAA anywhere anymore. Effectively this means the IPv6 r2LMA address should also be optional in Redirect Mobility Option. The new Redirect Mobility option will have IPv6 LMAA or IPv4 LMAA or both.

>    b) all the mobility sessions will still stay at rfLMA?

c) all subsequent mobility sessions established for the same multi-homed MN (independent which access/MAG/interface is used) should to be created on the r2LMA that was initially assigned to the MN.

>    [Qin]: What if r2LMA is overloaded again and need to rediret the mobility session

We do not support mid-session redirection by the request by the WG. That means new mobility sessions for the same multi-homed MN will be anchored to the existing r2LMA. If that fails due overload, then the new mobility session gets rejected.

>    So I think maybe it is simpler to add another outer IP header which may sacrifice some processing overheads at rfLMA.

I don't think so. When the rfLMA PMIPv6 "process" received the PBU, IPsec or other security processing has already been done and the PMIPv6 "process" sees the plain PBU. After that modifying PBU outer IP header is no issue. Within a Redirection Domain there is no issue of rfLMA to forward plain PBU to r2LMA. Alternatively, the rfLMA can re-protect the PBU using the SA between rfLMA and r2LMA. This is bound to work, *if* the PBU/PBA do not contain some authenticating mobility option covering also outer transport IP headers. Whatever happens here is transparent to MAG or r2LMA.

- Jouni

> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Qin Wu <[email-masked]>
Date: Tue, 20 Apr 2010 10:25:01 +0800

Hi,Jouni:
----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, April 17, 2010 12:01 AM
Subject: Re: [netext] Review of draft-ietf-netext-redirect-01

Hi Qin,

[Qin]: Okay, Would you like to clarify in which scenario will the wrong LMA selection happen?
a) In the exception case
In this case, why will MAG choose the wrong LMA?
b) load balance case
In this case, the candiate LMA to which the MAG is going to register intend to offload to the other backup LMAs. Do you think this candidate LMA can be looked as
wrong LMA?
c) or overloaded situation
In this case, the candiate LMA to which the MAG is going to register is overloaded and need to transfer the load out.Do you think this candidate LMA can be looked as
wrong LMA?

[Qin]: Thank for your clarification. That is to say, In contrast with HA switch described in RFC5142, the Redirection mechanims descibeds in the section 5.4 does not need additional
signaling to setup mobility session at the rfLMA. 

[Qin]: I agree. That is to say, Redirection based load balancing is more effective and efficient than DNS-based load balancing. 

[Qin]: Okay, that is what you said in the draft.

Ok. What about:

[Qin]: Sounds good to me.

[Qin]: Thank for your clarification by providing references. I agree it doesn't make sense when MAG use anycast address as source address.
However I am wondering whether it makes sense to use ancast address for the LMA, in other words, when the MAG forwards the data to the LMA, is it possible
for MAG to generate one data packet with anycast address of LMA as destination address? 

[Qin]: I agree. But it seems a little confusing to use "Support for IPv6 anycast addressing" as title of this bullet. People will thought MAG or LMA can support IPv6 anycast 
addressing when communciation between MAG and LMA? am I right?

[Qin]: Okay.

[Qin]: Good.

[Qin]: Good, I think that is reasonable to me.

[Qin]: Okay.

[Qin]; Okay, Does it mean only transport mode ESP can be used to protect PBU exchanged between MAG and rfLMA if IPSEC protection is employed and there are some authentication mobility option in such PBU. Becos in the AH or tunnel mode ESP, the outer IP header will be protected. am I right?

As regarding to what security mechanism can be used between rfLMA and r2LMA, if we assume plain PBU is protected by transport mode ESP, 
then whatever security mechanism is used does not matter, Since it has been assumed that there are trust relationship between rfLMA and r2LMA.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 20 Apr 2010 17:28:11 +0300

Hi Qin,

See my further comments inline.

> In this case, why will MAG choose the wrong LMA?

Typical example: load sharing based on DNS round-robin. LMA has no proper way to feed up to date load information to global/local DNS so that it would actually have any relevance (say.. caching times are too long) or some vendor MAGs cache DNS responses outside the stub resolver. Now it is rather likely that the LMA selected selected by the MAG is not the most optimal seen by the "cluster" of LMAs.

> In this case, the candiate LMA to which the MAG is going to register is overloaded and need to transfer the load out.Do you think this candidate LMA can be looked as

I am slightly confused by the "candidate LMA" as I don't fully understand what it means in this context.

> for MAG to generate one data packet with anycast address of LMA as destination address? 

MAG would not use anycast address as a source address, rather as a destination address for a LMA. The bullet above explains the use case when anycast could be used. Probably the text is confusing. How about:

   o  Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6
      specification does not specify how the PMIPv6 protocol should
      treat anycast addresses assigned to mobility agents. For example, a
      blade architecture LMA may appear to the routing system as multiple
      LMAs with separate unicast IP addresses and with one or more "grouping"
      anycast addresses. A MAG could then initially send a PBU to an anycast
      LMA address and receive a PBA from an anycast LMA address. Although
      [RFC4291] now allows using anycast addresses without restrictions, it
      does not make much sense for MAGs and LMAs to continue using anycast
      addresses beyond the initial PBU/PBA exchange but rather use node
      specific unicast addressing as soon as possible.

> addressing when communciation between MAG and LMA? am I right?

See above.

> [Qin]; Okay, Does it mean only transport mode ESP can be used to protect PBU exchanged between MAG and rfLMA if IPSEC protection is employed and there are some authentication mobility option in suc…

Tunnel mode ESP is fine. Tunnel mode ESP does not cover outer tunneling IP header.  AH has issues but then again, who even uses AH? The bigger problem would actually be possible security options that are mobility options and cover also e.g. some kind of pseudo header of the original encapsulating packet. Such options would break what we are doing here.

- Jouni

---

From: Qin Wu <[email-masked]>
Date: Wed, 21 Apr 2010 19:03:23 +0800

Hi, Jouni:
----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 20, 2010 10:28 PM
Subject: Re: [netext] Review of draft-ietf-netext-redirect-01

Hi Qin,

[Qin]: Thank for your clarification. That is to say, If MAG choose the out of date LMA using DNS based LMA discovery, it may result in sub-optimal LMA selection. This sub-optimal LMA can be looked as "wrong LMA". Right?

[Qin]: I just try to figure out how to understand "wrong LMA" and what cause wrong LMA selection.
I think if DNS based LMA discovery only provides sub-optimal LMA or out of date LMA, we can use Redirection
mechanism described in the draft-ietf-netext-redirect to re-choose the best choice or optimal LMA for the MAG.
But when MAG obtain one new LMA using DNS based approach, I believe the MAG didn't know if this LMA obtained using DNS is optimal LMA or wrong LMA.
Only when MAG register to this  new LMA by sending PBU, this new LMA can tell the MAG whether the LMA chosed by MAG is the optimal LMA. 
So what is the criterial to judge whether the LMA is wrong LMA or optimal LMA? I think the only criteria is look at whether the new LMA is overloaded 
or need to do load balance. 
In summary: 
1) I think the MAG can not know if the LMA obtained using DNS is the wrong LMA. Only the LMA itself know.
2) The only criteria to judge if the LMA is the wrong LMA is based on load balance consideration.

[Qin]: Good. I am okay with your change.

See above.

[Qin] Thank for correcting me, I agree.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 27 Apr 2010 12:20:07 +0300

Hi Qin,

On Apr 21, 2010, at 2:03 PM, Qin Wu wrote:

[snip]

> [Qin]: Thank for your clarification. That is to say, If MAG choose the out of date LMA using DNS based LMA discovery, it may result in sub-optimal LMA selection. This sub-optimal LMA can be looked…

Yes.

> 2) The only criteria to judge if the LMA is the wrong LMA is based on load balance consideration.

You can reason it in this way. However, I don't think we should explicitly state overload/load balancing as the only reason why to runtime assignment. 

- Jouni

[snap]