Subject: Re: Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 03 May 2010 13:45:25 -0700

Hello folks,

Here is a first installment of comments on the
abovementioned Internet Draft.

====================================================================

 >                                                  The list is not
 >    meant to be exhaustive.  Moreover, this document presents and
 >    identifies all issues pertained to these scenarios and discusses
 >    possible means and mechanisms that are recommended to enable them.

These two sentences clash, even though it's true
a logician can make sense of them.

Figure 2 is out of order.

The captions to all figures ought to be centered.

 >    The following figure illustrates an example

"following figure" --> "Figure 3 below"

 >    of this scenario, where the MN is moving from an access network
 >    where PMIPv6 is supported (i.e.  MAG functionality is supported)
 >    to a network where PMIPv6 is not supported (i.e.  MAG
 >    functionality is not supported by the AR).  This implies that the
 >    home link of the MN is actually a PMIPv6 domain.

It's true that the figure is drawn this way, but there
might be an unwanted inference that such heterogeneous
network support _always_ requires PMIP support in the
home network.  I reckon that was not intended.

 >    This scenario is very similar to other hierarchical mobility
 >    schemes, including a HMIPv6-MIPv6 scheme.

Please make the relevant citations.

 >    Note that a race condition where the MN registers the
 >    CoA at the HA before the CoA is actually bound to the MAG at the
 >    LMA is not possible.

Better:
      Note that there is no race condition whereby the MN registers
      the CoA at the HA before the CoA is actually bound to the MAG
      at the LMA.

 >                                   In particular, based on the base
 >           specification [RFC3775],

Better:
                                     In particular, based on [RFC3775],
Or, even better:
                                     In particular, the base
           specification [RFC3775] doesn't require the MN to include any
           identifier, such as the MN-ID [RFC4283], in the Binding Update
           message other than its Home Address.

 >                                               As described in
 >         [RFC4877], the identifier of the MN is known by the Home Agent
 >         after the IKEv2 exchange, but this is not used in the MIPv6
 >         signaling, nor as a lookup key for the binding cache.

Which naturally leads to the question, "Why Not?"!
This is a problem that really needs to be fixed.

 >                                  Therefore PMIPv6 and MIPv6 will
 >         always create two different binding cache entries in the HA/
 >         LMA which implies that the HA and LMA are logically separated.

I think this statement is too strong.  If I were building such
a system, my HA/LMA would probably be aware that the MN-ID was
tightly bound to the MN-HoA.  So I would almost certainly make
sure that there was a single binding cache entry.

If you replace "will always" by "might well", and "are"
by "might be", then I would agree.

Also, it's unfortunate if the typography separates "HA" from
"LMA" in "HA/LMA".

 >    *  When the mobile node moves from a MIPv6 foreign network to the
 >       PMIPv6 home domain, the MAG registers the mobile node at the
 >       LMA by sending a Proxy Binding Update.  Subsequently, the LMA
 >       updates the mobile node's binding cache entry with the MAG
 >       address and the MAG emulates the mobile node's home link.
 >       Upon detection of the home link, the mobile node will send a
 >       de-registration Binding Update to its home agent.  It is
 >       necessary to make sure that the de-registration of the MIPv6
 >       BU does not change the PMIPv6 binding cache entry just created
 >       by the MAG.

To me this looks like a major design flaw.

It would be better if the mobile node were aware that its
registration authority was delegated to the MAG on the home link.
Then it would know to avoid this problem.

Stated another way, this would be a requirement induced by
PMIP on MIPv6-compliant nodes.  Asking the obvious, one
wonders why an operator of a home network would
a) assume that the nodes were MIPv6-unaware, necessitating
    a PMIP solution, and yet
b) assume that the nodes might be MIPv6-aware, so that there is
    danger of conflict with a PMIP solution.

What am I missing?

 >      *  MIPv6 and PMIPv6 use different mechanisms for handling re-
 >         ordering of registration messages and they are sent by
 >         different entities.

Looks like another design flaw to me.  If the HA/LMA
is aware of MIPv6 sequence numbers (i.e., actually _is_
a HA), why not require the MAG to _use_ sequence
numbers?  This would be a trivial matter of inclusion
into the PBA.

"(or binging cache)" --> "(or binding cache)"
	:-)  thanks, I needed that  :-)
	:-)  in fact, I need more $$ for my binges  :-)

 >      *  In this mixed scenario, both host-based and network-based
 >         security associations are used to update the same binding
 >         cache entry at the HA/LMA (but see the first bullet of this
 >         list, as the entry may not be the same).

Yet more proof that the binding cache entries should
be the same.

====================================================================

On 5/3/2010 7:24 AM, The IESG wrote:
> The IESG has received a request from the Network-based Localized Mobility
> Management WG (netlmm) to consider the following document:
>
> - 'Interactions between PMIPv6 and MIPv6: scenarios and related issues '
>     <draft-ietf-netlmm-mip-interactions-05.txt>  as an Informational RFC
>
> 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
> [email-masked] mailing lists by 2010-05-17. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mip-interactions-05.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17831&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 03 May 2010 14:59:26 -0700

Hello folks,

Here are the rest of my comments on the
abovementioned Internet Draft.

 >           For this reason, it is recommended that when the MIPv6 home
 >  link is implemented as a PMIPv6 domain, the HA/LMA implementation
 >  treats the two protocol as independent.

Why not first recommend that the HA/LMA implement some
platform-specific mechanism for identifying the alternate
identifiers (e.g., MN-ID and MN-HoA)?

 >    "More in details the following principles ..."

-->  "In more detail, the following principles ..."

 >    "   ...  The mobile node needs to bootstrap"

-->  "   ...  The mobile node may need to bootstrap"

 >  service continuity.  Therefore the following steps must be performed
 >  by the UE:

-->

    service continuity.  Therefore the following steps might be
    performed by the MN:

In the following steps one and two: "needs to" --> "may need to"
In step three: "assign" --> "may assign"

"Since all these steps must" --> "If all these steps must"

"that the mobile node establishes" --> "that the mobile node establish"
or, better:
 >                                               it is recommended
 >    that the mobile node establishes
-->
                                  "the mobile node SHOULD establish"
along with a little rewording of the next subordinate clause.

"has Mobile IPv6 stack active"
--> "continues to make use of Mobile IPv6"

"as if it is attached" --> "as if it were attached"
-- BUT: in the scenario under discussion, isn't it?

[boot-integrated]:
	This citation needs to be updated; and, apparently it now
	has a distinguished author as well as an editor.  But, it's
	been in the RFC editor's queue for TWO YEARS?!  That's a
	new one on me.

"MN-HoA.For" --> "MN-HoA.  For"
	is this a bug in xml2rfc?

 >                                          For this reason, the mobile
 >  node must be configured to propose MN-HoA as the home address in the
 >  IKEv2 INTERNAL_IP6_ADDRESS attribute during the IKEv2 exchange with
 >  the HA/LMA.

I think this qualifies as another requirement placed by PMIP
on MIPv6 nodes.  Maybe it would be a good idea to make a new
section and list these requirements newly placed by PMIP.

I'm starting to wonder whether these new mandates might
belong in rfc3775bis.

"When the mobile node hands over" --> "When the mobile node migrates to"
	<basestations perform handovers, not mobile nodes>

 >                                                                The
 >    mobile node may set the R bit defined in NEMO specification

a) citation required for "NEMO specification"
b) "NEMO specification" --> "the NEMO specification"
c) _ouch_!  Now we have a new mandate placed by PMIP onto NEMO.<!>

"is created irrespective" --> "may be created regardless"
	<I think it is unwise to prohibit implementers from
	 coordinating the binding cache entries of PMIP and
	 MIPv6 if they serve the same mobile node, as I have
	 mentioned earlier>

"In this section it is assumed"
-->
"In this section we consider the case where"

 > 4.3.  Solutions related to scenario B

This conflicts with the sentence in section 1:

 >                                        this document presents and

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 May 2010 10:58:23 +0300

I support what Vidya said about opening that one issue. However, I think 
we should address Charlie's other comments.

Jari

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 17 May 2010 08:17:51 -0700

Thanks Charlie for the comments and sorry for the delay in addressing them. Most of your comments are editorial and I can produce a new revision since I received also comments from Gen-Art review. 

You have one comment on the recommendation in the draft to have separate binding cache entries. This was extensively discussed in the NETLMM WG and also at the IETF Dublin meeting. There was a mailing list discussion after that in September/October 2008 which led to the conclusion in the current version of the draft. 

You can find more information in the archives at: http://www.ietf.org/mail-archive/web/netlmm/current/msg05533.html 

Thanks
Gerardo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Charles E. Perkins
> Sent: Monday, May 03, 2010 1:45 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions
> (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to
> Informational RFC
> 
> 
> Hello folks,
> 
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 17 May 2010 09:49:06 -0700

Hello Gerardo,

Comments below...

On 5/17/2010 8:17 AM, Giaretta, Gerardo wrote:

> You have one comment on the recommendation in the draft to have
> separate binding cache entries. This was extensively discussed
> in the NETLMM WG and also at the IETF Dublin meeting. There was
> a mailing list discussion after that in September/October 2008
> which led to the conclusion in the current version of the draft.
>
> You can find more information in the archives at:
> http://www.ietf.org/mail-archive/web/netlmm/current/msg05533.html

Thanks for that link.  It was most enlightening,
especially in the context of the ensuing discussion.

Having reviewed the latter, it seems to me quite likely
that the consensus call was (at least) premature.

For instance:

> I object to this. There was absolutely no consensus on this for
> you guys to decide. There were clarifying questions that people
> had on what exactly you meant by multi-homing. You didn't respond
> to any of those emails.

and

> I am sorry, but I thought the discussion was either incomplete or did
> not steer towards one particular way or the other. For instance, I
> didn't get a clear answer for my question on why there would be a single
> BCE when two different interfaces are in use. Could you please clarify?

I could go on.  And, without naming names, I want to emphasize
that the abovementioned objections were made by some real experts.

Do you have any links to discussion that _supports_
the consensus call?

Furthermore, I still suggest (constructively) that
_at the minimum_ a system architect ought to be allowed
to have the design freedom to identify the two mobile
node identities (and thus the relevant BCEs).
What is the downside of enabling new systems to
offer such obvious improvements?

Or, would it be better to start writing the ...bis
document already (just kidding...)?

Regards,
Charlie P.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 18 May 2010 00:12:38 -0700

Charlie,
Thank you for your review and comments. Please note that the WG has spent a lot of time on this topic of same vs. separate BCEs. We have had two consensus calls on it after discussion at a meeting.  As you have seen from the thread, the chairs did see rough consensus to move on (specifically, please see http://www.ietf.org/mail-archive/web/netlmm/current/msg05551.html).  Explicit text on this topic was also provided to our AD along with the shepherding write-up: 

"There have been some disagreements on the approach used to solve the collocated LMA and HA case in the document.  The present approach uses logically separate binding cache entries for the LMA and HA, which is based on consensus.  Some members of the WG strongly preferred the approach of having the same binding cache entry for the LMA and HA - however, the approach needed additional solutions to address race conditions that arose from it and it did not gain consensus in the WG. It should be noted that this was not raised by anyone in the WG during WGLC of the document and the document as a whole had strong consensus to be published."

As you see, the disagreement has been noted and we've moved on. We don't plan on re-opening this discussion at this time. Let's resolve any remaining issues with the document. 

Thanks,
Vidya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: Monday, May 17, 2010 9:49 AM
To: Giaretta, Gerardo
Cc: [email-masked]; [email-masked]
Subject: Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC

Hello Gerardo,

Comments below...

and

Regards,
Charlie P.