[Netext] review of draft-gundavelli-netext-extensions-motivation Re: Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt

[sgundave at cisco.com (Sri Gundavelli)]

Hi George,



On Tue, 19 May 2009, George Tsirtsis wrote:

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

Lets focus on the technicals. I tried to keep my responses in a
positive and an objective manner and not react to any provocative
comments, or provoke you either. I really mean it. If not, I failed
some where. Any case, lets move forward and identify what we agree
and what we disagree.

As I see it:


1.) Host awareness

We both agree that for supporting some of the new features, it
needs host awareness. Without qualifying the interface or how
that can be achieved.

2.) On the historical facts as we understand, if host changes
are allowed. We can disagree on this as we did all along. But,
lets look at this this way.

a.) If the initial NETLMM goal was only to support hosts (with
no additional software requirements, or MN-AR interface signaling),
we agree or not, the protocol supports many features under these
constraints. So, we cant argue much here.

b.) Now, the goal is to extend new feature support to hosts
with some software requirements. Lets say this is a new requirement.
Adding support for this, does not remove the support for #a. You
dont agree to this requirement.

3.) Requiring software on the host, is the same as CMIP

We disagreed on this point. I do not believe the required software
will be as complex as implementing 5 other RFCS. But, this issue is
mute, if we decide to support hosts with software requirements,
complex or simple, the support exists.


4.) MN-AR Interface was always present.

There is a disagreement here. You seem to say that this interface
was never present. But, there was a WG doc. We also assumed SDO
specific interface here.


So, it appears we just need to decide if PMIP needs to extend
support hosts with some software requirements. Thats the only
disagreement. Rest of the disagreement or agreements is to fight
for this one point. Secondly, on the interface layer, if IETF
MN-AR interface, or it should be left unspecified for SDO's specific
interface.



> Believe it or not, however, your draft indicates progress in the
> quality level of this discussion, which in general has been rather
> low.
>

Ok. Good.


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

I do not believe any one is saying for supporting the new features
such as flow mobility or some of the advanced inter-tech handoff
scenarios we dont require host awareness. We need some software
there. Offcourse, if the software requires changes to IETF protocols
such as RFC-4861 is subjective, that is debatable.


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

MN-AR interface doc was a WG doc. I'm not making this up now.
If you are saying we never planned for this interface, you
can search for the WG doc in the archives.

We did not pay attention to this as the base work, except for
the advanced inter-tech handoff scenarios did not require this
interface. And we also assumed the SDO specific layer to handle
this. But, for supporting the new features, leveraging this
interface makes sense.



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

I'm not sure about multihoming (unless you bring up the lack of
MAC address logic and the most interesting case of a dual-radio
of same type, even then it should still assign different prefixes),
But, flow movement or some of the inter-tech handoff requires the MN
to know when to do the switch. That trigger handling or the host
awareness is required.


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

Requiring the host to handle this is more complex than client mobile IP,
its again subjective. IMO, its lot simpler requiring the host to
express these preferences and manage its interfaces, to implementing
5 RFC's. To prove it, some one can publish some psuedo code.


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

If the complexity is so much, then PMIP will fail naturally, you dont
have to even worry about this discussion. The published specs will
not have any purpose.


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

Provocative

>
>   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)

But, this was disputed by many folks in the WG all along. Its ambiguous
and not clear. Client not involved in the signaling with the HA/LMA
or tunnel mgmt, to client managing its interfaces or flows is a
different thing.


I will leave it here.

Thanks
Sri