Subject: RE: [netlmm] RE: PMIP follow-up questions (was RE: Why is PMIP...)

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 1 Nov 2006 17:21:02 -0800

> > I think you simply don't want to accept the reusability 
 > argument and
 > > it's probably easier for the WG if you just tell us that. 
 > Any objective
 > > implementer would tell you that adding a few number of 
 > lines of code
 > > makes a cheaper implementation/testing/support/upgrade/OAM 
 > ....etc than
 > > adding an entirely new protocol. If you call that 
 > splitting hairs then
 > > it's hard for me to make a case that you will find acceptable. So
 > > there's not much I can add to this aspect of the discussion.
 > 
 > Now here I have to object.  Your assertion with respect to what 'any
 > objective implementer would tell you' simply doesn't hold.
 > 
 > 
 > I've spent ~20 years with commercial software development 
 > (and started
 > doing software development 37 years ago).  I should have some idea of
 > what it takes to do this or that.  To implement a clean design from
 > scratch, and test it, can be substantially faster than to shoehorn
 > additional features into a large codebase, especially when 
 > that codebase
 > hasn't been designed and structured for those features from 
 > the start.

=> Well, you're assuming that you'd be shehorning stuff that doesn't
fit. I didn't make that assumption. Also, for the sake of argument, do
you think that adding 100 lines of code to an existing base is more
expensive in terms of design/testing/support/OAM than writing a new 1000
line code? I don't think so.

 > 
 > There are some basic differences in assumptions, with regards to both
 > the authentication model and with respect to where the options end up
 > (MN or AR) between MIPv6 and PMIPv6 which makes it far from 
 > trivial to
 > just plug in a MIP solution with a few added lines of code in a PMIP
 > context.

=> I don't agree with that assumption. Could you elaborate? 

 > 
 > So it's not at all as simple and plain as you make it sound.
 > 
 > With respect to the re-use argument -- I buy the idea that in *some*
 > contexts, *software* and *hardware* re-use will make sense.  However,
 > the case for re-use of a *internet protocol* in a context 
 > for which it
 > wasn't designed is not obvious, and can't be assumed as an 
 > extension of
 > software or hardware re-use.

=> Well, you're making the assumption of the context here and I don't
know why you're assuming the worste in this case. 

 > 
 > I know that you guys have a HA implementation that you probably would
 > like to sell to a larger market, but I don't necessarily see that as
 > a good basis for a design decision when considering what 
 > would be good
 > for the internet over many years to come.

=> I don't know where you got that from either. Please feel free to
check with me or others before you assert this information. The
information above is completely false. We don't have an HA and my
arguments here are not motivated by any product on offer by my employer.
I don't appreciate the mind reading Henrik, please don't do that.

 > 
 > If I were to argue in the same vein, I should be pushing hard to get
 > GTP accepted -- that would provide a fabulous amount of re-use, from
 > a certain perspective.  But I don't necessarily think that would be a
 > good thing for the internet, either.

=> At least we agree on that. I don't think UDP encapsulation is such a
great idea when no NATs are involved. 

Hesham

 > 	Henrik

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 02 Nov 2006 10:05:48 +0100

on 2006-11-02 02:21 Soliman, Hesham said the following:
> 
>> > I think you simply don't want to accept the reusability  argument and
>> > it's probably easier for the WG if you just tell us that.  Any objective
>> > implementer would tell you that adding a few number of  lines of code
>> > makes a cheaper implementation/testing/support/upgrade/OAM  ....etc than
>> > adding an entirely new protocol. If you call that  splitting hairs then
> Well, you're assuming that you'd be shehorning stuff that doesn't
> fit. I didn't make that assumption.

Well, maybe you should have.

> Also, for the sake of argument, do

Actually, even adding 10 lines to a large codebase can be more expensive
than 1000 lines in a fresh application.  Especially testing effort is
proportionate to the number of combinations of features, rather than
number of added lines.  And it is very likely that adding the 10 lines is
going to break something when you are trying to force together things that
don't really fit, such as for instance the very different authority
relationships which you have in MIP and PMIP.

> I don't agree with that assumption. Could you elaborate? 

???

Are you saying that you believe the authentication and authority
model in MIP and in PMIP are the same?

> Well, you're making the assumption of the context here and I don't

I'm not assuming anything.  I'm stating that the contexts are far
from the same, and you can't afford to assume that everything will
just work out when that's the case.

> I don't know where you got that from either. Please feel free to

Oh, it wasn't mind reading, you don't have to worry about that.

I apologize for the erroneous assumption.

But if Flarion didn't have a HA implementation, I'm afraid I have been
sorely misled by your indications of knowledge and understanding of
what's needed to build, maintain and extend a MIP HA software
implementation.

Of course Flarion could have had one, and Qualcomm could have ditched
it.  I didn't think of that.  But I really thought from comments from
you over the last 3 or 4 years that you had had experience from working
with HA software, both v4 and v6.

	Henrik