[Netext] review of draft-gundavelli-netext-extensions-motivation Re: Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt
tsirtsis at googlemail.com (George Tsirtsis) Tue, 19 May 2009 15:34 UTC
From: "tsirtsis at googlemail.com"
Date: Tue, 19 May 2009 11:34:25 -0400
Subject: [Netext] review of draft-gundavelli-netext-extensions-motivation Re: Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt
Message-ID: <d3886a520905190834nee22363s3f232ad75d274d40@mail.gmail.com>
Sri, et.al.,
First of all thanks for putting this together. You seem to have done
this reluctantly implying that you had to waste your time doing this.
This is sad by itself, but it also compound by a number of sniping
comments and cheap shots which I am generally trying to ignore.
Believe it or not, however, your draft indicates progress in the
quality level of this discussion, which in general has been rather
low.
In draft-tsirtsis I had to spend an inordinate amount of time and
effort proving self-evident facts, like the fact that the
controversial extensions to PMIPv6 REQUIRE the definition of an MN-MAG
interface. This has been continually disputed by part of this
community, and it has consumed large amount of time during mailing
list discussions and even during the NETEXT BOF). The situation in
NETEXT BOF was actualy truly appalling with even the BOF chairs
refusing to recognize this as a fact, and even Jari being tentative
about it.
You of course are trying to make it look like that this was the plan
all along, which is nonsense but that's OK. I am glad that at least
your draft openly and finally states that an MN-AR interface is indeed
needed.
So, please NETEXT funs, I do not want to have to argue another time
that inter-tech handoffs, multihoming, and flow movement need MN
involvement and MN-MAG signaling.
Now our disagreement seems to be WRT what this MN-AR protocol is all
about, and how it compares to client Mobile IP. In my responses below
I am attempting to make you understand another obvious fact, one that
I hope will take less time to absorb than the need for the MN-MAG
protocol did. I summarise this here too:
You state that the MN-MAG protocol is needed so that the MN can:
- Provide its interface ID(s), and (I am extrapolating) the presence of VIs etc
- Indicate whether it wants to handoff or not
- Register multiple IFs at the same time (multihoming)
- Indicate which flow should be routed to which MAG (flow movement)
I agree that all of this is needed to have a complete solution and had
to wrote draft-tsirtsis partly to prove this point. In
draft-gundavelli, however, you talk about these functions somewhat
dismissively as if they are trivial and not a big deal. If you
actually think for a minute you will realize this:
1) This MN-MAG protocol will be client initiated i.e., the MN will be
requesting various things from the MAGs
2) All of these functions are exactly what client Mobile IP provides,
MIPv4 to the FA, MIPv6 directly to HA.
3) When you add security all of the above becomes more complex than you think
Why do you think this is going to be ?simpler? than client Mobile IP?
What I am claiming in draft-tsirtsis (section 5) is that the
functionality you require results in a protocol very much like MIPv4
FA-mode, except maybe that security is likely to become a
chain-of-trust model with MN-MAG and MAG-LMA legs instead of the usual
end-to-end security used by MIP. I think such security model might
face some interesting challenges ahead, but thats a discussion for
another day.
In the end you will end up with a lot (if not all) of the complexity
you allegedly trying to avoid.
This is why the comparison to client based mobility is relevant and
important, and why the bar for a new protocol must be high. This is
why once you introduce MN-MAG interface you have to question why this
is not just reintroduction of the FA in the MIPv6 architecture and if
it is really needed how it would be best introduced in the MIP
architecture.
Have a nice day.
George
P.S.: See more comments inline.
---------------------------------------------------------------------------------------------------------------------------------
NETEXT WG S. Gundavelli
Internet-Draft Cisco
Intended status: Informational May 05, 2009
Expires: November 6, 2009
Extensions to Proxy Mobile IPv6 - Motivation
draft-gundavelli-netext-extensions-motivation-00.txt
?
6. Response to draft-tsirtsis-netext-controversy
The [draft-tsirtsis-netext-controversy] argues that IETF should not
allow the proposed new extensions to Proxy Mobile IPv6. It is
unfortunate that the draft was not written in a constructive and an
impartial manner. Its clear, the basic purpose of the draft is to
favor client-based solution. That is fine. One can certainly
disregard these comments as one's opinion, affiliation or attachment
to a specific technology as the reason for strong and a one sided
view. But, to an innocent reader who may not know all the technical
details may be misled reading such views. So, its important to
respond to these comments.
GT> I am glad you decided to speak for the ?innocent reader?. I will
try hard to ignore sniping comments like that letting your innocent
reader decide what they say about their author.
The draft mostly argues on legal grounds and makes number of
assumptions which are incorrect and continues to build the case based
on those assumptions and finally arrives at its own conclusions. To
state a few:
o The draft assumes that the mobile node in a Proxy Mobile IPv6
domain has no ability, or it should not be able to express
attachment, handoff or flow preferences to the network. The
document builds the entire case based on this argument. It
completely ignores the operating environment and does not even
mention about the MN-AR Interface document
[draft-ietf-netlmm-mn-ar-if-03], or the SDO specific interfaces,
which was always considered in the protocol design.
GT> Maybe you should read draft-tsirtsis more carefully. Draft-tsirtsis
a) states the undisputed fact that the MN was never supposed to be
involved (this still the case according to NETLMM charter)
b) it then proves that the desired extensions require that the MN
is involved (e.g., in section 4). This which was necessary to do since
the need for MN involvement has been disputed multiple times,
including during the NETEXT BOF. So, I am now glad you finally agree
and openly state that this is really unavoidable.
c) The draft also talks about the implications of MN involvement
(e.g., section 5)
o The draft fails to differentiate between a mobile node expressing
minimal hints to the network, such as attachment, connection or
flow preferences, to a full blown mobile node with all the complex
software requiring massive system resources and performing all
aspects of mobility management.
GT> I happen to work for a company that builds such functionality in
mobile phones for a living; It might be reasonable to assume that I
know something about what such devices can do. I suggest that you
might be a bit behind in your appreciation of what such devices are
capable of these days.
It equates both as one and the
same with the conclusion that any software on the host is the same
as client-based mobility. But, it does not see the difference,
boiling a glass of water to boiling an ocean.
GT> You may want to consider that comparison yourself. Based on what
you want to do in section 5 you will have to define a protocol that
can handle:
- roaming,
- inter-tech handovers,
- multihoming, and
- flow movement.
You will have to do this interoperably and securely. Why do you think
that this is going to be a ?simple? protocol? Where do you think the
perceived complexity involved with say MIPv6 coming from, if not from
the fact that it needs to support all of the above functions?
o The draft reviews some of the multihoming and flow mobility
scenario's and makes a case that it is not possible to perform
flow mobility or support complex handoff scenario's without the
mobile node being aware and which is correct. Ack ! But, again
it ignores the MN-AR Interface or SDO specific layer which can be
used for such purpose.
GT> Perfect, as I said many people in NETEXT BOF and in the mailing
list have been trying to dodge the issue claiming that MN involvement
may not actually be needed.
o The draft ignores the market direction and the industry
preferences for network-based mobility management, either in the
form of Proxy Mobile IPv6 or Generic Tunneling Protocol [GTP], and
the resulting benefits in that approach.
GT> The draft does not ignore them at all. Markets, rarely ask for
specific protocols. They mostly ask for functionality which we then
have to provide with ?reasonable? protocol designs, which is what this
discussion is all about.
o The draft disregards the amount of scrutiny, reviews and the
external validations that went into the base protocol design for
ensuring the protocol followed the IETF design principles.
GT> The draft does not ignore that either. On the contrary is fully
aware of the resistance experienced during PMIPv6 base protocol design
to even add basic requirements like the Handoff Indication to the
design, and the fact that the same attitude of not facing up to issues
is repeated now with further controversial extensions.
The following sections respond to more specific comments, on section
by section basis.
6.1. PMIP with Host Signaling & Historic Reasons - Clarification
There is a comment, a mobile node in a Proxy Mobile IPv6 domain is
not allowed to have any intelligence. And there will point you to
some incomplete and ambiguous line in the charter that was never ever
discussed widely during the formation of NETLMM working group and
which went practically unnoticed. Even if it did, it does not mean
much and is not relevant. In any case, following is the response to
that comment.
Proxy Mobile IPv6 was certainly created with the goal that the mobile
node will not perform any mobility signaling with its local mobility
anchor.
GT> This is the only thing draft-tsirtsis says. It says nothing about
mobiles being ?stupid?, ?dumb? or anything like that.
So far it is correct. However, no where in the base
protocol specification, it ever stated and assumed that:
o that the mobile node that attached to a Proxy Mobile IPv6 domain
will be a dumb and a stupid terminal which can do only a single
attachment, cannot dynamically manage its interfaces or cannot
configure an address dynamically on a real or on a virtual
interface.
o that it will be disallowed from providing handoff, attachment or
flow preferences to the network, through a SDO specific interface
layer.
o that an operator cannot install any intelligent application
software, such as connection manager which using the configured
policies or user inputs, makes the network attachment decisions.
o that it will be disallowed from being aware of the operating
environment.
GT> I am not sure what the above list proves and draft-tsirtsis does
not contradict any of the above.
These restrictions do not make any sense and are not needed.
Providing attachment and handoff preferences was always factored in
to the design. The MN-AR Interface document
[draft-ietf-netlmm-mn-ar-if-03] which was a working document prior to
the adoption of the initial Proxy Mobile IPv6 document, was specified
for that purpose. The protocol also allowed this interface to be
defined in a SDO specific manner, specifying the protocol between the
network nodes only by reacting to the provided events. This is not a
design flaw, but allowing the room for all the extensions to come in
place in a evolutionary manner.
An application software such as connection manager is a basic host
requirement for any multihomed terminal and is not a Proxy Mobile
IPv6 requirement. This component cannot be avoided on any multihomed
host. The behavior of any host will be unpredictable and unreliable
with respect to the choices it makes for all its network connections.
Proxy Mobile IPv6 only requires few additional hooks on such software
module, that too for supporting some features.
GT> A Connectivity manager, is typically self-contained, in-box,
implementation specific software, which does not produce any
out-of-box signaling. What you are talking about here is MN to AR
signaling which is clearly beyond the remit of what a normal
connectivity manager normally is all about. This is not a bad thing
by-itself but you keep talking about this as if existing connectivity
manager will just provide the PMIP-hooks for free.
6.2. MAG ... the new FA ?
Section 5.2.2 of [draft-tsirtsis-controversy-00] tries hard to imply
that functional element, mobile access gateway is the same as foreign
agent in Mobile IPv4, with the objective to prove that any software
requirement on the client maps to Mobile IPv4 model. Sure, the
models map in the mobility element count, but there are role
differences in each of those models and the argument completely
discounts this aspect.
In a network-based mobility model, there is an element on the network
that is designated to perform the mobility management functions. We
can call this a foreign agent, mobile access gateway or a mobility
proxy, but the functional role has a specific purpose and the model
is not Mobile IPv4. The functional role of the mobile node is not
beyond than managing its interfaces, address configuration and
expressing handoff and flow preferences to the network.
GT> Are you actually reading what you are writing? You claim that with
PMIP the MN?s role is *passive*, and yet you also say it is
?expressing handoff and flow preferences to the network. ?. What does
client Mobile IP do beyond that??
It plays a
mere passive role and allowing the mobile access gateway to play the
active role on the aspects of mobility management. So, there is a
fundamental difference between this when compared to the Mobile IPv4.
In any case, the comparison that is needed is in relation to client-
based mobility. Following are the fundamental differences between
all the three models:
o In Mobile IPv4 (FA-CoA Mode), the mode of active client and
passive network node, the mobile node plays an active role,
performs all aspects of mobility management, while the foreign
agent plays mere passive role
o In Proxy Mobile IPv6, the mode of passive client and active
network node, the mobile node plays a mere passive role in the
mobility management. It does not perform any mobility signaling
with the local mobility anchor. It is only expected to provide
attachment, handoff and flow preferences to the network, while the
mobile access gateway is responsible for performing all aspects of
mobility management.
GT> Again, according to this the MN is *passive* but it performs all
sorts of active functions like handoff and flow movement. You do
realize that you are making no sense right?
o In Mobile IPv6, the mode of active client, the mobile node plays
the active role and performs all aspects of mobility management.
It requires Mobile IPv6 client [RFC-3775], DSMIP6 [ID-DSMIP6],
MCOA [ID-MCOA6], IKEv2 [RFC-4306] and IPsec [RFC-4301] stacks.
Its requires significant amount of software and system resources
on the client.
6.3. The Internet, the Interface, and the Host
And we got a ticket ! We are breaking the Internet building blocks.
Section 3.0 of [draft-tsirtsis-controversy-00] is not clear on what
the concern is. Following are the clarifications.
o The IP mobility is above network layer, it is a service layer and
as specified in Section 6.6 of [RFC-5213], a mobile node on
attaching to the Proxy Mobile IPv6 network is required to present
its identify.
GT> Except it does not say how?.which is why I call RFC5213 ?incomplete?.
So, the mobile access gateway has a clear relation
between a mobile node's identify, its link-layer identifier and on
the offered mobility service along with the assigned prefix. But,
this relation is preserved in an application layer and at the IP
layer its just the standard protocol operation confirming to all
the standard IETF protocols.
o When looked at from the perspective of IP layer, the MN-AR link is
any other IP link. Its a point-to-point link and with the mobile
access gateway functioning as the IPv6 router on the link. The
prefix set that it projects on the link is always tied to that
mobile node's interface, but that relation is preserved in
application layer and the network layer has no understanding of
any of this relation. Its a normal IPv6 link with the presence of
two nodes on the link and a set of hosted IPv6 prefixes.
GT> Which as draft-tsirtsis indicates is fine as long as the MN has a
single interface.
o The comment on NDP operation for multihomed hosts is not
applicable. The MN-AR link is a point-to-point link, with only
one interface of the mobile node, either real or a virtual
interface, is present. So, the protocol does not modify the low
level building blocks of the Internet and so the allegation is not
correct.
6.4. What is wrong with PMIP so far ? Nothing !
Clarifications to Section 4.0 of [draft-tsirtsis-controversy-00] in
the same order.
1. The absence of MN-AR interface, as an IETF specified interface
does not imply the protocol is broken. For example, the IP layer
is built with the assumption that the layer-2 driver for a given
access technology will provide the required hooks for the IP
layer. Its the same thing here. A given SDO can define such
interface.
GT> Yes, this is the definition of ?broken? or at least the definition
of ?incomplete? as I call it in draft-tsirtsis. One of the major flaws
of PMIPv6 is that it is NOT self-contained.
2. It is indeed correct that there is no concept of a MAC address in
certain link-layer technologies, but that's only in CDMA and in
LTE.
GT>So all the 3GPP and 3GPP2 interfaces?you call that ?only??
The absence of such semantic in these two technologies is
not a problem for the current operating environment.
- the protocol uses the Access Technology Type for the
uniqueness and for a dual-mode terminal that are going to be
in the market, it is highly unlikely there are multiple
radio's of the same type.
- even otherwise, a simple semantic allowing the mobile node
to present an identifier as part of the attachment preferences
will be just fine.
GT> sure, which will then have to be secured appropriately, you also
want to add flow movement and handoff indications etc, as I said this
is not as simple as you try making it out to be.
3. The use of virtual interfaces is a host specific semantic. It is
perfectly valid for a host to use the physical interfaces in a
bridged mode and present a virtual link-layer identifier. This
is perfectly valid and many protocols such as HRRP or VRRP use
such mode. This has no implication on the IPv6 link or on the
link neighbors.
GT> Did anyone say this is a problem? On the contrary draft-tsirtsis
says this is necessary, and it had to say this since a lot of PMIP
folks have been arguing forever that somehow it might not be needed.
You of course continue to pretend that you are oblivious to the fact
that there is no way to signal the fact that a VI exists or that two
specific interfaces are under a given VI.
4. It is true that the mobile node can potentially specify if the
given attachment is due to an handoff or as result of a new
interface bringup. But, the absence of such event is fine in
most cases. The network through context transfer procedures or
through other means, can derive that information. We can
certainly add this in the IETF specified MN-AR interface layer.
6.5. Its not a Tool Proliferation !
A comment was made in Section 5.2.3 of
[draft-tsirtsis-controversy-00], that allowing host participation in
any level, is equivalent to client performing all aspects of mobility
management and results in redundant tool proliferation.
Its not always a binary logic. No host involvement in mobility
management does not imply the host has zero awareness of the
operating environment, or that it is disallowed from running any
intelligent software such as connection manager, or that is a
violation for it express its connection or flow preferences to the
network. That was never a basis for the design of the Proxy Mobile
IPv6 protocol. Allowing the host to have such capabilities only
improves the protocol and cannot be considered as a tool
proliferation.
Even otherwise, new ideas, fresh discoveries on how to deploy a
technology in a real-world network and when coupled by urgent
customer needs, always can re-shape a technology. A technology
solution that start with Protocol-A need not be restricted to that
protocol, but instead can go with Protocol-B, if that happens to be a
better protocol and if market wants that solution. There are many
instances in IETF, where it allowed multiple technologies to co-exist
and let the market adopt what is right, to name a few:
GT> This is of course true. What I claim is not that this is never
allowed, but that the bar for new entrants must be high and the
reasons and architectural implications must be understood before
creating yet another protocol that does the same thing with an
existing one.
On Tue, May 5, 2009 at 10:51 PM, Sri Gundavelli <sgundave at cisco.com> wrote:
>
>
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>> Sent: Thursday, April 16, 2009 3:39 AM
>> To: netext at mail.mobileip.jp
>> Subject: [Netext] Fwd: I-D
>> Action:draft-tsirtsis-netext-controversy-00.txt
>>
>> This draft is relevant to the discussion regarding the more
>> controversial proposed extensions of PMIPv6.
>>
>
> I tried to respond to all the comments raised in this document.
> The draft talks about the motivation for the new features and responds to
> the comments mentioned in draft-tsirtsis-netext-controversy-00.txt.
>
> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motiv
> ation-00.txt
>
> Hopefully, both the drafts dont go for -01 version, I really had to struggle
> to
> find the time for this.
>
> Sri
>
>
>
>
>
>> I hope this helps.
>>
>> Regards
>> George
>>
>>
>> ---------- Forwarded message ----------
>> From: ?<Internet-Drafts at ietf.org>
>> Date: Thu, Apr 16, 2009 at 11:00 AM
>> Subject: I-D Action:draft-tsirtsis-netext-controversy-00.txt
>> To: i-d-announce at ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>>
>> ? ? ? ?Title ? ? ? ? ? : Discussion of Controversial PMIP Extensions
>> ? ? ? ?Author(s) ? ? ? : G. Tsirtsis
>> ? ? ? ?Filename ? ? ? ?: draft-tsirtsis-netext-controversy-00.txt
>> ? ? ? ?Pages ? ? ? ? ? : 17
>> ? ? ? ?Date ? ? ? ? ? ?: 2009-04-16
>>
>> This document discusses the recent controversy regarding PMIP
>> extensions for inter-technology handoffs and multihoming. ?Many of
>> the arguments presented below have been discussed in NETEXT BOF and
>> subsequent discussions on the mailing list. ?They are written here in
>> an attempt to explain why some of the proposed PMIP extensions are so
>> controversial.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-tsirtsis-netext-cont
>> roversy-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce at ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>
>
- [Netext] review of draft-gundavelli-netext-extens… Sri Gundavelli
- [Netext] review of draft-gundavelli-netext-extens… George Tsirtsis