Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6
draft-ietf-netext-redirect-12

[Ballot discuss]
There has been quite a bit of discussion about the Gen-ART Review by
  Pete McCann on 14-Apr-2011, yet the biggest issues have not yet been
  resolved.  I do not understand why this document needs to state any
  requirements for connections on different access technologies back to
  the "home" LMA.  Why not allow handoffs with a client-based solution
  without this requirement?  Doesn't this approach prevent the MN from
  subscribing to different operators for each access technology.

[Ballot discuss]
Some pretty substantive changes have been made since revision -07 that came out of the WG, went to IETF last call, and was reviewed by the IESG. For example, sections 4.3 and 4.4 introduce new protocol elements.

Surely these changes should at least get sign-off by the WG, and probably should be subject to renewed WG and IETF last calls.

[Ballot discuss]
There has been quite a bit of discussion about the Gen-ART Review by
  Pete McCann on 14-Apr-2011, yet the biggest issues have not yet been
  resolved.  I do not understand why this document needs to state any
  requirements for connections on different access technologies back to
  the "home" LMA.  Why not allow handoffs with a client-based solution
  without this requirement?  Doesn't this approach prevent the MN from
  subscribing to different operators for each access technology.

This document will be on the next IESG telechat, in a bit over a week.

Jouni has told me that there is one change that he would like to add, based on implementation experience: adding a field on the return messages so that the delegating entity may find out what the load was on the selected device. I think it is reasonable to add this small extension, even if we are at this stage.

Jouni, please revise the draft accordingly and post a new as soon as possible. You should also let the working group know that you want to do this.

[Ballot discuss]
I think the only remaining discuss point is this one:

(6) What happens if the new SA cannot be established? What should the MAG do?

Quoting a mail on this:

>>> I could add a sentence to the second bullet: "If the dynamic SA creation fails, the MAG SHOULD log the event."
>> Probably some more - for example the MAG needs to not update its BUL
>> as well? (1st bullet in 5.3.2)
>Hmm.. Seems I forgot to add the BULE related failure case text. In essence the BULE would just timeout after some >time, if no other actions are done when SA creation fails.


So I think that text still needs adding and then we're done.

[Ballot discuss]
I think the only remaining discuss point is this one:

(6) What happens if the new SA cannot be established? What should the MAG do?

Quoting a mail on this:

>>> I could add a sentence to the second bullet: "If the dynamic SA creation fails, the MAG SHOULD log the event."
>> Probably some more - for example the MAG needs to not update its BUL
>> as well? (1st bullet in 5.3.2)
>Hmm.. Seems I forgot to add the BULE related failure case text. In essence the BULE would just timeout after some >time, if no other actions are done when SA creation fails.


So I think that text still needs adding and then we're done.

IANA understands that, upon approval of this document, there are two
actions which IANA must complete.

First, in the Mobility Options registry of the Mobile IPv6 parameters
registry located at:

http://www.iana.org/assignments/mobility-parameters/mobility-
parameters.xml#mobility-parameters-2

the following mobility options will be added:

Value: TBD
Description: Redirect-Capability Mobility Option
Reference: [RFC-to-be]

Value: TBD
Description: Redirect Mobility Option
Reference: [RFC-to-be]

Second, in the Status Codes registry of the Mobile IPv6 parameters
registry located at:

http://www.iana.org/assignments/mobility-parameters/mobility-
parameters.xml#mobility-parameters-2

the following status code will be added:

Value: TBD (a number less than 128)
Description: Accepted_and_Redirected_with_Binding
Reference: [RFC-to-be]

IANA understands that these are the only actions that are required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Runtime LMA Assignment Support for Proxy Mobile IPv6) to Proposed Standard


The IESG has received a request from the Network-Based Mobility
Extensions WG (netext) to consider the following document:
- 'Runtime LMA Assignment Support for Proxy Mobile IPv6'
  as a Proposed Standard

This is a second last call that was performed as the draft had
been sent back to the working group after discovery of some
IPR on this topic. The changed document is now coming back
from the working group.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-08-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a runtime Local Mobility Anchor assignment
  functionality and corresponding mobility options for Proxy Mobile
  IPv6.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netext-redirect/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netext-redirect/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1405/
  http://datatracker.ietf.org/ipr/1559/

[Ballot comment]
Section 7. Configuration variables starts by mentioning that three configuration variables are defined in the document, and then defines ... two.

Also - why are these called 'configuration variables' and not 'configuration objects'?

[Ballot comment]
In section 4.1, the following text is unclear to me:

  When this
  option is included, the MAG may be assigned with another LMA, and the
  assigned LMA may simultaneously create a Binding Cache Entry (BCE).
  Hence, the MAG including this option MUST be able to support runtime
  LMA assignment with and without a creation of a BCE in the runtime
  assigned LMA.

As I understand the architecture of the LMA, the BCE is an
implementation structure in the LMA and not immediately visible to the
MAG.  What change in behavior on the part of the MAG is required to
support these two different scenarios?

Nits:

In section 4.1, BCE is expanded in RFC 5213, which is pointed to in
the Terminology section.  For consistency, no need to expand it here.

In section 4.1, s/There can  zero/There can be zero/

End of section 5.1, s/treat the of the PBA/process the PBA/

In section 5.2, is "LMA" as used in this section equivalent to
"runtime assignment domain" as defined in the terminology section?

Section 7 seems superfluous, and it mentions three configuration
variables but only lists two.

Is there a registry for the Status values defined in section 9?

[Ballot discuss]
1. I'd like to hear the motivation for what seems to be three
different (related) methods for LMA assignment:

a colocated rfLMA/r2LMA, with CBE passed through some unspecified
  mechanism
b separate rfLMA/r2LMA, with CBE created through proxy PBU/PBA
  exchange
c separate rfLMA/r2LMA, with MAG redirected to restart mobility
  session establishment with r2LMA

Am I summarizing the 3 methods correctlt?  I can understand method a
as taking advantage of more efficient/direct communication between
colocated devices.  Method c seems to have the virtues of simplicity
in design and operation.  Where does method b, which seems more
complex than c with none of the efficiencies of a, fit?


2. In section 3, paragraphs 3 and 5 appear to be redundant, specifying
protocol behavior.  I list this issue as a DISCUSS point, because
redenudancy in the specification can result in confusing or
conflicting text.  I suggest simply dropping those paragraphs.


3. If RFC 5142 can be used for mid-session LMA reassignment, why is
there a need for specification of a separate protocol extension for
LMA reassignment at session initiation time?


4. In section 4.1, why is "the MAG SHOULD include [...]" specified as
SHOULD rather than MUST?  This example of "SHOULD" seems to me to need
an explanation: under what circumstances would a MAG not include the
Redirect-Capability option; what is the effect of not including the
option?  This question is partially answered by some text in section
5.1, but that text is kind of redundant with this text in 4.1.  Might
be better to have this rule just in section 5.1 concerning MAG
behavior.

[Ballot comment]
(1) Last para of section 3 says "The LMA..." a couple of times.  It probably ok
but would that be better as "An rfLMA..."?

(2) Saying "MAY make use of [RFC5142]" is not very clear - why not describe
what may be used with more than just a reference and make it clear what you
mean?

(3) "The rfLMA MUST NOT assign a MAG using IPv6 transport with a new r2LMA
using IPv4 transport, if the MAG does not indicate support for IPv4 in the
Redirect-Capability mobility option, as there is no guarantee that the MAG
supports switching from IPv6 transport to IPv4 transport.  The same also
applies for assigning a MAG using IPv4 transport with a r2LMA supporting only
IPv6 transport." That could be a good bit clearer - but I think its saying only
provide an r2LMA address where you already know the MAG/rfLMA connection can
work using that address family.

(4) What's a "MAG-rfLMA-r2LMA proxy state"? Is that defined in 5213?

(5) The document could do with an editorial pass for English language
issues.

[Ballot discuss]
This is quite a long discuss, but probably a bunch of the points are related so
it may be less scary than it seems.

(1) " The trust relationship and coordination management between LMAs within a
PMIPv6 domain is deployment specific and not described in this specification."
Hard to buy that as a way to get interop and security. What if the rfLMA and
r2LMA and MAG are each from different vendors?  Put another way: "adequate
means to secure their inter-LMA communication" with interop implies this needs
to be specified.

(2) "That is, the runtime assignment functionality specified in this document
is not enabled in the r2LMA, or the r2LMA does not belong to the same runtime
assignment domain as the rfLMA, or the r2LMA is down or otherwise unreachable."
That doesn't seem to be a sentence and I don't understand it anyway.

(3) Section 3 says that rfc5142 may be used for a mid-session LMA assignment.
If that works, why bother defining this protocol?

(4) "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." The
grammar there is pretty bad, but aside from that *how*, in general, could the
rfLMA *know* that the MAG and r2LMA are able to setup an SA? That seems like an
intractable problem if different vendor implementations are in use for rfLMA,
MAG and r2LMA.  "These SA related knowledge issues and trust relationships are
deployment specific in a PMIPv6 domain and in a runtime assignment domain, and
out of scope of this specification. " Doesn't seem acceptable.

(5) 5.3.2 says the MAG "SHOULD" establish an SA with the r2LMA. Why is that not
a MUST and under what circumstances is it ok to not establish an SA? Is the the
ability to establish an SA mandatory to implement or not?

(6) What happens if the new SA cannot be established? What should the MAG do?

(7) 5.3.3 says to create a tunnel as specified in rfc 5213 - where in (the 89
pages of) 5213 is that specified?

(8) 5.3.1 has a ~~~~ line between rfLMA and r2LMA for LMA assignment, but 5.3.4
says that the r2LMA can be a "any 5213 compliant LMA".  I think that needs more
explanation. 

(9) I assume that this is not controversial for MIPv6 people but it seems quite
odd to me, so I wanted to check. Do you really expect that "A single LMA entity
should have the control over all possible multi-homed mobility sessions the MN
has." is likely to be the case? Seems unlikely to me, but I'll not insist if
told its a general assumption.

(10) "Alternatively, the rfLMA can do all required security processing on the
PBU/PBA, and the communication between the rfLMA and the r2LMA would be
unprotected at the PMIPv6 protocol level.  In this case the runtime assignment
domain MUST implement adequate level of security using other means, such as
layer-2 VPNs." So I don't get that. What data is sent from rfLMA to r2LMA
according to this spec?

[Ballot discuss]
The Gen-ART Review by Pete McCann on 14-Apr-2011 raised major
  concerns, yet there has been no respons to the review.  The major
  issues raised are:

  Section 5.4: please include a discussion of the possibility of loops
  in the LMA assignment operation and specify the actions that must
  taken by the MAG to detect and resolve them.

  Section 6: This section assues that all of the MN's sessions are able
  to be correlated and that all MAGs will direct their tunnels back to
  the same LMA.  There is no way to enforce that all sessions go to the
  same LMA.

[Ballot discuss]
(1) in section 4, why shouldn't the Redirect-Capability S &F bits or the Redirect K & N bits be set at the same time?  Does it break anything?  It seems like it should be allowed, with the LMA and MAG (respectively) able to determine which to use.

This seems to relate to the rule in section 5.2 about not cross-assigning IPv4-only LMAs to IPv6-only MAGs, and vice-versa.

Also, teh configuration variables in section 7 only refer to enable/disable controls without regard to IPv4 or IPv6, so how to operate with both seems unclear.



(2) in section 5.2, this paragraph and the decision to leave some of the prerequisite information needed for LMA assignment out of scope seems like it could lead to making it difficult to understand what is required for cross-vendor interoperability of rfLMA and r2LMA implementations.  This should at least be clarified in this document, which otherwise focuses on the LMA to MAG interaction.



(3) for the multihoming discussion in section 6, the requirement that all mobility sessions for an MN be under control of a single LMA seems to be unnecessary.  How could multiple providers over multiple interfaces be supported?  Is there motivation for this requirement?  If so, the document needs to include it, as it doesn't seem clear, and may lead to limits in applicability.

[Ballot comment]
Some typos:
-in section 1, "practise" -> "practice"
-in section 1, "due caching" -> "due to caching"
-missing period at end of section 3
-in section 5.1, "at time" -> "at a time"
-in section 5.1, "the of the" -> "the"

[Ballot discuss]
(1) in section 4, why shouldn't the Redirect-Capability S &F bits or the Redirect K & N bits be set at the same time?  Does it break anything?  It seems like it should be allowed, with the LMA and MAG (respectively) able to determine which to use.

This seems to relate to the rule in section 5.2 about not cross-assigning IPv4-only LMAs to IPv6-only MAGs, and vice-versa.

Also, teh configuration variables in section 7 only refer to enable/disable controls without regard to IPv4 or IPv6, so how to operate with both seems unclear.



(2) in section 5.2, this paragraph and the decision to leave some of the prerequisite information needed for LMA assignment out of scope seems like it could lead to making it difficult to understand what is required for cross-vendor interoperability of rfLMA and r2LMA implementations.  This should at least be clarified in this document, which otherwise focuses on the LMA to MAG interaction.



(3) for the multihoming discussion in section 6, the requirement that all mobility sessions for an MN be under control of a single LMA seems to be unnecessary.  How could multiple providers over multiple interfaces be supported?  Is there motivation for this requirement?  If so, the document needs to include it, as it doesn't seem clear, and may lead to limits in applicability.

IANA understands that, upon approval of this document, there are two
IANA Actions that need to be completed.

First, in the Mobility Options registry of the Mobile IPv6 parameters
registry located at:

http://www.iana.org/assignments/mobility-parameters/mobility-
parameters.xml#mobility-parameters-2

the following mobility options will be added:

Value: TBD
Description: Redirect-Capability Mobility Option is set to
Reference: [RFC-to-be]

Value: TBD
Description: Redirect Mobility Option is set to
Reference: [RFC-to-be]

Second, in the Staus Codes registry of the Mobile IPv6 parameters
registry located at:

http://www.iana.org/assignments/mobility-parameters/mobility-
parameters.xml#mobility-parameters-2

the following status codes will be added:

Value: TBD (a number less than 128)
Description: Accepted_and_Redirected_with_Binding is set to
Reference: [RFC-to-be]

Value: TBD (a number greater than 128)
Description: Rejected_but_Redirected is set to
Reference: [RFC-to-be]

IANA understands that these are the only actions that are required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Runtime LMA Assignment Support for Proxy Mobile IPv6) to Proposed Standard


The IESG has received a request from the Network-Based Mobility
Extensions WG (netext) to consider the following document:
- 'Runtime LMA Assignment Support for Proxy Mobile IPv6'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-04-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netext-redirect/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netext-redirect/

State changed to AD Evaluation from Publication Requested.
I have reviewed this draft. I believe it is in good shape and can move forward. I think I understand the entire operation and could not seen any issues. Just a minor editorial comment:

> following considerations has to taken into account
... has to be taken into account ...

I have asked for the IETF Last Call to be initiated for this document.

Jari

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Document shepherd: Rajeev Koodli
Yes, I have reviewed this version of the document and I believe it is
ready for IESG review and publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had adequate reviews by key WG members.
I do not have any concerns regarding the depth or breadth of the
reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I do not have concerns, but the document can benefit from a security review,
especially of one of the features ³Runtime Redirection with Binding
Creation².


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I do not have any specific concerns at this time regarding this
document. The document has been presented and discussed adequately in
previous WG meetings and on the mailing list.

I am aware of an IPR disclosures related to this I-D: ³Huawei Technologies
Cp. Ltd¹s Statement about IPR related to draft-ietf-netext-redirect-03²,
dated September 18, 2010.
URL:
http://datatracker.ietf.org/ipr/search/?option=document_search&id_document_t
ag=19240



(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong concurrence among active participants on the subject. I
believe the majority of the WG understands the ID and do not object.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No threats of appeal or extreme discontent have been expressed
regarding this I-D.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. I have run the I-D through the ID nits tool and found no issues.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split into normative and informative sections.
The normative references are published RFCs.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes, I have verified the IANA Considerations Section. The documents requires
IANA allocations for two new Mobility Options and two new Status Codes. The
respective registries are identified.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not applicable.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Proxy Mobile IPv6 is the IETF standard for network-based mobility
management. In Proxy Mobile IPv6, mobile nodes are topologically
anchored at a Local Mobility Anchor (LMA), while connected to a Mobility
Anchor Gateway (MAG).
There may be some deployments in which the LMA may wish to redirect a MAG to
an alternate LMA for session establishment. For such deployments, this
document specifies a new protocol between the MAG and the LMA to assist with
runtime LMA assignment (as opposed to LMA selection via DNS or AAA). In a
deployment where the MAG does not support the necessary extensions, the
behavior defaults to that specified in RFC 5213.

There is support in the WG to advance this work. There has not been any
major controversy.
No known public implementations.