Subject: [Gen-art] Gen-ART Last Call Review of draft-ietf-netext-redirect-07

From: Pete McCann <[email-masked]>
Date: Thu, 14 Apr 2011 14:23:24 -0500

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-netext-redirect-07
Reviewer: Pete McCann
Review Date: 2011-04-14
IETF LC End Date: 2011-04-10 (sorry this is late)
IESG Telechat date: (unknown)

Summary: Has Issues

Major issues:

Section 5.4:
You should add a paragraph on the possibility of loops in the
LMA assignment operation and specify that the MAG must
take some action to detect and terminate such loops, such
as a maximum redirection count or tracking the IP addresses
of the LMAs it has been assigned so far and looking for duplicates.

Section 6: (Multi-Homing)
This section makes a major assumption that all of the MN's
sessions are somehow able to be correlated and that all MAGs
will direct their tunnels back to the same LMA.  In fact this may
not be possible when the MN has interfaces on multiple different
technologies with multiple different network operators and different
subscriber credentials.  There is no way to enforce that all sessions
go to the same LMA.  Besides, why is this even necessary?  The
section does not give a concrete justification for why all the sessions
need to go through the same LMA.

Minor issues:

Section 5.2:
   Otherwise, the rfLMA MUST act as a normal RFC 5213
   defined LMA for the MAG.
The sentence just prior talks about rejecting the PBU with
a PBA 130 Insufficient resources.  I think you need an extra
if clause here:
   If the rfLMA is able to make the assignment to an r2LMA,
   it returns a PBA with the Redirect extension as defined
   below.  Otherwise, the rfLMA MUST act as a normal RFC 5213
   defined LMA for the MAG.

You need a paragraph at the end of Section 5.2 that describes
what is about to happen in the document:
   We next describe two models for the runtime assignment of
   the LMA.  In Section 5.3, we describe a model where the
   assignment by the rfLMA and the binding at the r2LMA are
   created at the same time.  This scenario is optimized for
   the case where the rfLMA and r2LMA are co-located or
   integrated by a "proxy MAG" protocol which is described
   in Section 5.3.4.  In Section 5.4, we describe a mode where
   the assignment by the rfLMA takes place first, and then the
   binding at the r2LMA is created by a separate PBU/PBA
   exchange that happens in a second round-trip.
When I first read Section 5.3 I thought it was the only model
being supported and was quite concerned.

Nits/editorial comments:

Section 1:
   reasons, why
SHOULD BE:
   reasons why

   practise
SHOULD BE:
   practice

   in-line what
SHOULD BE:
   in-line with what

Section 3:
   domain, is not
SHOULD BE:
   domain is not

   assignment, unless
SHOULD BE:
   assignment unless

Section 4.1:
   There can zero
SHOULD BE:
   There can be zero

Section 5.1:
   the of the
SHOULD BE:
   the

Section 5.2:
   a reason or other
SHOULD BE:
   some reason

   The rfLMA MUST only assign the MAG with a new r2LMA that it knows the
   MAG has a SA with or the MAG and the r2LMA are able to create it
   dynamically.
SHOULD BE:
   The rfLMA MUST only assign the MAG to a new r2LMA with which it knows
   the MAG has an SA or with which it knows the MAG can establish an SA
   dynamically.

   and the r2LMA, are again deployment
SHOULD BE:
   and the r2LMA are again deployment

   transport, if the MAG
SHOULD BE:
   transport if the MAG

Section 5.3.1:
   Address where the PBU was sent to
SHOULD BE:
   Address to which the PBU was sent

Section 5.3.2:
   considerations has to taken
SHOULD BE:
   considerations have to be taken

   BUL to correspond the r2LMA address
SHOULD BE:
   BUL to contain the r2LMA address

Section 5.3.4:
   then the proceeds as mentioned in Section 5.2),
SHOULD BE:
   then the PBU is processed as described in Section 5.2,

Section 5.4.1:
   Address where the PBU was sent to
SHOULD BE:
   Address to which the PBU was sent

---

From: jouni korhonen <[email-masked]>
Date: Fri, 22 Apr 2011 15:40:30 +0300

Thanks Pete for extensive review. I'll come back to your major issues in a bit.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Sat, 23 Apr 2011 02:17:17 +0300

Pete,

See my comments inline:

> of the LMAs it has been assigned so far and looking for duplicates.

Section 3 says:

   ...
   functionality.  MAGs and LMAs implementing the runtime LMA assignment
   functionality MUST support the runtime LMA assignment during the
   initial PBU/PBA exchange which creates a new mobility session.  A
   mid-session LMA assignment may make use of [RFC5142]

I thought this was clear enough already. However, I am OK to add a new configuration knob for maximum number of consecutive assignments. How about:

In Section 5.4.2:

   Each time the MAG receives a PBA with the Status Value set to
   Rejected_but_Redirected, it MUST check whether the 
   maximum runtime assignment count value (initialized to the
   MaxRedirectCount when a new mobility session establishment
   starts) is greater than zero. If the counter value is greater
   than zero, it is decreased by one and the MAG can proceed with
   the runtime assignment. If the counter value is zero, then the
   MAG MUST treat the PBU was rejected by the LMA and log the event.

In Section 7:

   MaxRedirectCount

      This configuration variable is available in a MAG and tells
      the maximum number of allowed consecutive runtime assignments.
      When the EnableLMARedirectFunction is TRUE, the MaxRedirectCount
      MUST be set to one or more. When the EnableLMARedirectFunction
      is FALSE, the MaxRedirectCount MUST be zero.

> will direct their tunnels back to the same LMA.  In fact this may

This is how real deployments plan to do stuff..

> subscriber credentials.  There is no way to enforce that all sessions

Ok. My assumption was that there is one subscriber identity (but possibly multiply credentials) that maps/leads to a single "home network". This would be e.g. how things get done in real world.

> need to go through the same LMA.

Justification is rather simple. Inter-technology handovers become impossible if different accesses are hosted in different LMAs. 

How about the following clarification to Section 6:

Old text:

   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.

   One possible solution already supported by this specification is
   applying the runtime LMA assignment 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.

New text:

   A MN can be multi-homed i.e. have network connectivity over multiple
   interfaces connected one or more accesses).  A single LMA entity SHOULD
   have the control over all possible multi-homed mobility sessions the MN
   has or otherwise handovers between different accesses and interfaces
   become challenged, if not impossible.  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.

   One possible solution already supported by this specification is
   applying the runtime LMA assignment 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. Discovering the same r2LMA each time
   has an assumption that the MN has an identity that can always point
   to the same policy profile independent of the used access.

>   below.  Otherwise, the rfLMA MUST act as a normal RFC 5213

OK.

>   exchange that happens in a second round-trip.

Sound good. Thanks.

> being supported and was quite concerned.

Above NITs are OK.

>   the MAG has an SA or with which it knows the MAG can establish an SA

Ok.

>   Address to which the PBU was sent

Above are OK.

Thanks,
	Jouni