Localized Routing for Proxy Mobile IPv6
draft-ietf-netext-pmip-lr-10

[Ballot comment]
I've cleared my Discuss position and thanks for reconciling my concerns.

1. Fixed.

2. Fixed.

3. Fixed.

4. In section 4.1, does "LR state of the MAG" refer to the state in the
LMA?  Also, is pMAG == MAG?

5. Fixed.

6. In section 10.1, "for now" is unnecessary.  Why is the alignment
requirement mentioned here and not for the definitions in section 9?

[Ballot comment]
Having ploughed through the wdiff for the latest revision, and looking at the email thread between Suresh and Les, I believe all of my Discuss issues have been resolved. Thanks for the work.

[Ballot comment]
- LR with two MAGs implies that MAG1 knows that MAG2 is the CN's
location at the granularity of the MAG (MAG2) with which the CN
is associated.. Since there is a way for a MAG to initiate this
then a bad or compromised MAG could attempt to track any CN
for which LR is enabled who's address the bad MAG knows. That
is a privacy problem for the CN's. I noted this about the DIME WG
equivalent draft and the authors of tha suggested that text as per
the above would be better in this document. I'm not sure there's
a mitigation here really but I'd say its worth noting at least.

- Figures 1 and 2 have no real caption and aren't referred to
from the text so are less useful than they could be.

[Ballot discuss]
1. I think there is some confusion about the "R" flag.  The caption
for Figure 2 (and other Figures) includes:

  where R and U are the flags defined in Section 9.1 and 9.2.

but I don't see any definition of an "R" flag in section 9.1.  In my
opinion, the "R" flag is unneeded if the LRI and LRA messages each
have a separate header type code.

2. I don't see any text that describes how an LMA cancels local
forwarding service, as implied in this text in section 4:

  For instance, the LMA may
  send a LRI message with a request to cancel an existing local
  forwarding service.

3. In section 5, what happens if, for some reason, one of the MAGs
(e.g., MAG1) responds with a non-zero status code in its LRA to the LMA?
Does MAG2 need to be notified, perhaps because it has some state that
must be taken down?  This text should be extended to allow for error
cases:

  When the
  MAG IP Address option is present, each MAG MUST create a local
  forwarding entry such that the packets for the MN attached to the
  remote MAG are sent over a tunnel associated with that remote MAG.

The only mention of error cases in section 5 seems to be:

  Barring the error cases, all subsequent packets are routed between
  the MAGs locally, without traversing the LMA.

4. In section 5:

  It will hence initiate LR at nMAG1 and update the LR state
  of MAG2 to use nMAG1 instead of MAG1.

how does the LMA perform the state update and doesn't it also have to
update some state in MAG1?

5. The text in section 6.1 is completely lacking any description of
what the various participants should do in the case where an MN moves
to a new MAG.

6. I'm not sure section 7 gives enough detail into the various ways in
which an established LR situation must be torn down.  For example, in
the A11 case, does the LMA or the MAG determine that one of the MNs
has moved and the participants are now in A22?

7. In section 9, I can't find definitions for LRA_WAIT_TIME and
LRI_RETRIES.

[Ballot comment]
1. In section 4, what does it mean for a MAG to "statically initiate
LR"?

2. Also in section 4, does:

  It then verifies if the
  EnableMAGLocalRouting flag is set to 1.

refer to the EnableMAGLocalRouting flag for MAG?

3. Editorial nit: because there is only one MAG in the scenario in
section 4, the identifier MAG1 is probably unnecessary in Figure 2
and the related text.

4. In section 4.1, does "LR state of the MAG" refer to the state in the
LMA?  Also, is pMAG == MAG?


5. This text from section 6 seems awkward and the RFC 2119 language
seems unnecessary:

  Only after it receives both
  the LRA messages each with Status value set to zero (success) from
  the two different LMAs, the MAG MUST conclude that it can provide
  local forwarding support for the two Mobile Nodes.

6. In section 10.1, "for now" is unnecessary.  Why is the alignment
requirement mentioned here and not for the definitions in section 9,
and what does "8n+4" mean?

[Ballot discuss]
Updated Discuss and Comment to make it clearer which points I want
to see addressed, and which are just "desirable".

The issues come from the Routing Directorate review by Les Ginsberg
on 2/27/12.

You can engage with Les direct at ginsberg@cisco.com for clarification,
but the Discuss issues are mine.

- - - - -

Why are you not using the "MN-CN" terminology from RFC 6279? The fact
that you use "MN-MN" makes me think that you are only addressing cases
where both endpoints are MNs. Is this the case? If so, this should be
explicitly stated. If not, it would seem to be better to use the RFC
6279 terminology.

---

Section 5

I assume the lack of requirement for synchronization works because the
LMA will always forward packets regardless of whether it has sent an
LRI/received an LRA? This implies that MNs and MAGs may receive
duplicate packets at times - which presumably should be no problem. I am
wondering if it would be useful to discuss these points?

Similarly, in Section 6.1 it is assumed that LMAs always forward
inter-MN packets regardless of the state of LR?

[Ballot comment]
Nits:
A number of acronyms are used without definition. For example, in
Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not
represent a complete list. Can you please scrub the document for all
such occurences?

[Ballot discuss]
Please address the minor issues raised by Les Ginsberg in his Routing
Directorate review of 2/27/12. The entire review is reproduced here for
your convenience.

You can engage with Les direct at ginsberg@cisco.com

- - - - -

Summary:
I have some minor concerns about this document that I think should be
resolved before publication.

Comments:
This document is clearly written and easy to understand.
This is the first PMIP document I have reviewed, so I went back and read
some of the previous RFCs. Despite that it may mean that some of my
comments/questions are naive. Please indulge me.

Major Issues:
No major issues found.

Minor Issues:

Why are you not using the "MN-CN" terminology from RFC 6279? The fact
that you use "MN-MN" makes me think that you are only addressing cases
where both endpoints are MNs. Is this the case? If so, this should be
explicitly stated. If not, it would seem to be better to use the RFC
6279 terminology.

Section 5

I assume the lack of requirement for synchronization works because the
LMA will always forward packets regardless of whether it has sent an
LRI/received an LRA? This implies that MNs and MAGs may receive
duplicate packets at times - which presumably should be no problem. I am
wondering if it would be useful to discuss these points?

Similarly, in Section 6.1 it is assumed that LMAs always forward
inter-MN packets regardless of the state of LR?

Nits:
A number of acronyms are used without definition. For example, in
Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not
represent a complete list. Can you please scrub the document for all
such occurences?

[Ballot discuss]
The Gen-ART Review by Mary Barnes on 24-Feb-2012 includes many issues,
  and the authors have agreed to make fixes.  The revised document has
  not been posted yet.

IANA has a question.

Upon approval of this document we understand that 3 assignments are to
be made:

1) A Mobility Header Type for the Localized Routing Initiation (TBA1)
2) A Mobility Header Type for the Localized Routing Acknowledgment (TBA2)

These 2 registrations will be made in the "Mobility Header Types - for
the MH Type field in the Mobility
Header" registry found at:
http://www.iana.org/assignments/mobility-parameters

3) A Mobility Option for the MAG IPv6 Address (TBA3)

This registration will be made in the "Mobility Options" registry found at:
http://www.iana.org/assignments/mobility-parameters

NOTE: The second part of the IANA Considerations section says the following:

The MAG IPv6 Address requires a Mobility Option Type each (TBA3) from
the Mobility Options registry at
http://www.iana.org/assignments/mobility-parameters

Where it says "each", is there another type to be assigned? Please
confirm there is only 1 mobility option required.

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:  (Localized Routing 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:
- 'Localized Routing 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 2012-02-21. 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


  Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
  protocol that enables IP mobility for a host without requiring its
  participation in any mobility-related signaling.  PMIPv6 requires all
  communications to go through the local mobility anchor.  As this can
  be suboptimal, localized routing (LR) allows mobile nodes attached to
  the same or different mobile access gateways to route traffic by
  using localized forwarding or a direct tunnel between the gateways.
  This document proposes initiation, utilization and termination
  mechanisms for localized routing between mobile access gateways
  within a proxy mobile IPv6 domain.  It defines two new signaling
  messages, Localized Routing Initiation (LRI) and Local Routing
  Acknowledgment (LRA), that are used to realize this mechanism.




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

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


No IPR declarations have been submitted directly on this I-D.

I have reviewed the new version and it looks good. Thank you for the changes. I have asked for an IETF Last Call to be initiated.

I realized that I had not responded to a clarifying question from the authors on my AD review comments. I have now sent a response, hopefully Suresh will update the draft now.

I have reviewed this draft.

It is in good shape and almost ready to move forward. I did find a couple of issues, however, and the most serious one of these is the one about tear-down. Please fix this and submit a new draft so that I can initiate an IETF last call.

>    If a MAG is unable to deliver packets using the LREs, it is possible
>    that the MN is no longer attached to the MAG.  Hence, the MAG SHOULD
>    fall back to using the BUL entry, and the LMA MUST forward the
>    received packets using its BCE.

This seems wrong. First of all, there are two MNs. Maybe you should say "... that one of the MNs is no longer ...". Secondly, since you had a MUST earlier for use of the LRE, shouldn't the SHOULD be a MUST too?

>    If one of the MNs, say MN1, detaches from the MAG and attaches to
>    another MAG (say nMAG) the localized routing state needs to be re-
>    established.  When the LMA receives the PBU from nMAG for MN1, it
>    will see that localized routing is active for MN1.  It will hence
>    initiate LR at nMAG and update the LR state of MAG.  After the
>    handover completes, the localized routing will resemble Scenario A21.

I think you should explain how the state in the pMAG changes. I presume this is just standard RFC 5213 behaviour, but nevertheless it is important for the pMAG to know that it should no longer do RO.

> When a supported
>    scenario, such as Scenario A12, morphs into Scenario A22 the node
>    that initiated the localized routing session SHOULD tear it down in
>    order to prevent lasting packet loss.

Shouldn't this be a MUST?

> The node
>    that initiated the localized routing session SHOULD tear it down in
>    order to prevent lasting packet loss.
> In
>    deployments where Scenario A22 is possible, it is recommended that
>    localized routing not be initiated when packet-loss-sensitive
>    applications are in use.

There are *no* situations where lasting packet loss is acceptable. So I think you have to handle this. I don't mean that you have to be able to use RO in A22, but you have to be able to tear RO down when the situation changes.

I think this is doable, and a part of the tear-down in general happens. When the device that initiated RO realizes that one of the involved sessions is gone elsewhere, it MUST do a RLI with lifetime 0 to tear the session down in the other nodes.

>    PMIPv6 MNs can use an IPv4 HoA as described in [RFC5844].  In order
>    to support the setup and maintenance of localized routes for these
>    IPv4 HoAs in PMIPv6, MAGs must add the IPv4 HoAs into their LREs.
>    The MAGs MUST also support encapsulation of IPv4 packets as described
>    in [RFC5844].  The localized routing protocol messages MUST include a
>    IPv4 HoA option in their signaling messages in order to support IPv4
>    addresses for localized routing.
>
>    ...
>
>    Note that this document supports LR only for IPv6 traffic, and LR is
>    not supported for IPv4 traffic.

The last paragraph seems inconsistent with the first paragraph. Remove one of them?

>    All the Localized routing messages use a new mobility header type
>    (TBA1).
>    The Localized Routing Initiation, described in Section 9.1 and the
>    Localized Routing Acknowledgment, described in Section 9.2 require a
>    single Mobility Header Type (TBA1) from the Mobility Header Types
>    registry at http://www.iana.org/assignments/mobility-parameters

This seems odd. Usually, a message and its acknowledgment have different message types. TBA1 and TBA2... I can see that you have the R flag, but this isn't the usual way to define new MH messages.

>      Mobility Options: MUST contain the MN-ID, followed by one or more
>      HNPs for each of the MNs.  For instance, for Mobile Nodes MN1 and
>      MN2 with identifiers MN1-ID, MN2-ID and Home Network Prefixes
>      MN1-HNP and MN2-HNP, the following tuple in the following order
>      MUST be present: [MN1-ID, MN1-HNP], [MN2-ID, MN2-HNP].  The
>      MN-ID and HNP options are the same as in [RFC5213].  MAY contain
>      the remote MAG IPv6 address option, which is formatted identically
>      to the HNP option, except that it uses a different Type code and
>      the Prefix Length is always equal to 128 bits (see Section 10.1).

I think you could explain this better. My understanding is that there is only one option for MN-ID, so by repeating that option you will signal two identities.

"MUST contain two separate MN-iD options, followed by ..."

And you should define which one is which. The first one is the one that is always in the MAG that sends/receives the message?

> 11. Security Considerations
>
>
>    The protocol specified in this document uses the same security
>    association as defined in [RFC5213] for use between the LMA and the
>    MAG to protect the LRI and LRA messages.  This document also assumes
>    the pre-existence of a MAG-MAG security association if LR needs to be
>    supported between them.  No new security risks are identified as
>    compared to [RFC5213].  Support for integrity protection using IPsec
>    is required, but support for confidentiality is not necessary.

I think you should highlight one new risk, which is the risk of setting up a MAG-MAG tunnel. The document should also specify what packets are allowable to come from such tunnels (to prevent spoofing attempts).

> 12. IANA Considerations
>

What is the situation with the LRA Status field? Does it need its own registry, or are the values shared between PBA status values?

Please specify.

>  == The document seems to lack the recommended RFC 2119 boilerplate, even if
>      it appears to use RFC 2119 keywords -- however, there's a paragraph with
>      a matching beginning. Boilerplate error?

Please see if you can fix this idnits warning. Some wording difference between Section 3 and what 2119 uses, perhaps?

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?

I (Basavaraj Patil) am the document shepherd for this document. I have
reviewed this version of the I-Dand believe that it is ready to be
forwarded to the IESG for 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 review by key WG members. It has not had
any review by people outside the scope of the WG. I do not have
concerns about the depth or breadth of the reviews received.

(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 any concerns regarding the need for further review by
any specific group of experts.

(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 have no concerns with the content or quality of the document.

(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 sufficient WG consensus behind this document. The active
constituents of the Netext WG are in support of this document while
the rest are simply silent.

(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.

(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 document through the ID-Nits tools and apart from
a few warnings, there are no concerns.

(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].

The document has split references into normative and informative
sections. All references are published RFCs and hence there is no
concern about dependency on the referenced documents.

(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. The IANA section contains clear instructions for allocation of a
new mobility header type. The registryto be used is also provided in
the IANA section of the I-D.

(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?

There is no XML code or MIB definitions contained in the I-D.

(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:

Technical Summary

Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
protocol that enables IP mobility for a host without requiring its
participation in any mobility-related signaling. PMIPv6 requires all
communications to go through the local mobility anchor. As this can
be suboptimal, localized routing (LR) allows mobile nodes attached to
the same or different mobile access gateways to route traffic by
using localized forwarding or a direct tunnel between the gateways.
This document proposes initiation, utilization and termination
mechanisms for localized routing between mobile access gateways
within a proxy mobile IPv6 domain. It defines two new signaling
messages, Localized Routing Initiation (LRI) and Local Routing
Acknowledgment (LRA), that are used to realize this mechanism.

Working Group Summary

This document has been presented and discussed at length in the
working group. It includes multiple contributors who are listed in
the Authors section. There is sufficient consensus behind the
document. The authors could not agree on the tunnelling mechanism
to be used between the MAGs. This has however been resolved based
on the solution that is presented in RFC5949 (Fast Handovers for
Proxy Mobile IPv6).

Document Quality

There are no known implementation of the protocol at the present
time. However there is strong interest in utilizing the
optimization feature in the context of network based mobility
solutions. The document quality is good and provides reasonable
clarity for an implementer who understands PMIP6 (RFC5213).

This is a working group last call for the I-D:
Localized Routing for Proxy Mobile IPv6

Abstract:
  Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
  protocol that enables IP mobility for a host without requiring its
  participation in any mobility-related signaling.  PMIPv6 requires all
  communications to go through the local mobility anchor.  As this can
  be suboptimal, localized routing (LR) allows mobile nodes attached to
  the same or different mobile access gateways to exchange traffic by
  using localized forwarding or a direct tunnel between the gateways.
  This document proposes initiation, utilization and termination
  mechanisms for localized routing.
Date: June 9th, 2011
The I-D is intended for publication as a proposed standard.
The deadline for receiving comments (i.e end of WG LC) is June 24th,
2011.
Please send your review comments to the mailing list or authors.

-Chairs