-----Original Message-----
From: netlmm-bounces(_at_)ietf(_dot_)org
[mailto:netlmm-bounces(_at_)ietf(_dot_)org] On
Behalf Of Charles E. Perkins
Sent: Monday, May 03, 2010 1:45 PM
To: ietf(_at_)ietf(_dot_)org; netlmm(_at_)ietf(_dot_)org
Subject: Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions
(Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to
Informational RFC
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
ietf(_at_)ietf(_dot_)org mailing lists by 2010-05-17. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
netlmm mailing list
netlmm(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/netlmm