Re: [netlmm] Network-based mobility - NETLMM DT Solution VsAsolutionbased on MIP6

[Henrik Levkowetz <[e-mail]>]

Hi Vidya,

on 2006-10-27 23:55 Narayanan, Vidya said the following:
> To add to what Vijay has said here, it appears that the onus is being
> placed on the PMIP proponents to explain why that is preferable over the
> NETLMM DT solution. This is just plain wrong - it should be the other
> way around, given that one PMIPv6 solution and one other MH-based
> solution was already "input" to the DT.

Why, oh why, should it be so??

There were many solutions input to the design team.  The design team has
tried to do good work, and offered its best to the working group.  The
design team has nothing to prove or disprove.  It has simply attempted
to offer good work for consideration.

I'm trying to point out that this should really be about fulfilling the
requirements, not about 'this protocol against that'.

I count about 8 proposals for the netlmm protocol (not counting the design
team's) -- my apologies if I've missed anyone -- and the design team has
tried to take the known material into consideration.  It seems that the
logic you are proposing would ultimately lead to having a trial of all
against all...

  draft-akiyoshi-netlmm-protocol
  draft-giaretta-netlmm-protocol
  draft-gundavelli-netlmm-mip6-proxy
  draft-raman-netlmm-protocol
  draft-templin-autoconf-netlmm-dhcp
  draft-vidya-netlmm-netmob
  draft-wanghui-netlmm-protocol
  draft-wood-netlmm-emp-base
  draft-giaretta-netlmm-dt-protocol

With 9 proposals, that gives us 9*8=72 trials.  Let's go for it.


	Henrik.


> 
> Vidya 
> 
>> -----Original Message-----
>> From: Vijay Devarapalli [mailto:[e-mail]] 
>> Sent: Friday, October 27, 2006 2:28 PM
>> To: Henrik Levkowetz
>> Cc: Narayanan, Vidya; [e-mail]
>> Subject: Re: [netlmm] Network-based mobility - NETLMM DT 
>> Solution VsAsolutionbased on MIP6
>> 
>> Henrik,
>> 
>> IMO, Vidya's question is perfectly valid.
>> 
>> when a design team is formed to work on a solution for a 
>> particular problem and if there are multiple solutions to the 
>> problem, one of the first things the design team is supposed 
>> to do is to evaluate if any of the existing solutions 
>> suffices. if none of the solutions satisfy the basic 
>> requirements, then the design team should of course work on a 
>> new solution from scratch.
>> 
>> sure, it is preferable to always do only "engineering", but 
>> you do have to deal with the "other" questions sometimes.
>> 
>> note that the design team solution is after all
>> *just* another solution.
>> 
>> Vijay
>> 
>> Henrik Levkowetz wrote:
>> > Hi Vidya,
>> > 
>> > on 2006-10-27 20:54 Narayanan, Vidya said the following:
>> >> I fully agree with Hesham here. I think the NETLMM DT 
>> really needs to 
>> >> provide an explanation of why a PMIP-like solution was not 
>> chosen as 
>> >> the network-mobility protocol. The answer that "the DT 
>> deliberated it 
>> >> and decided against it" is unacceptable. Clearly, the 
>> folks outside 
>> >> the DT have no visibility to this. And, having talked to 
>> folks from 
>> >> the DT, I'm still not clear on the reasons.
>> >>
>> >> I think this is the responsibility of the DT to prove to 
>> the rest of 
>> >> the community why the solution chosen best satisfies the 
>> requirement 
>> >> for network-based mobility.
>> > 
>> > No.  You're right about looking at what best satisfies the 
>> > requirements, but not on it being up to the design team to 
>> "prove" the 
>> > proposed solution against arbitrary other solutions.  On 
>> the contrary, 
>> > if any "proving" should be done, it should be up to all people 
>> > interested in the work to hold up all the potential 
>> proposed solutions 
>> > against the *requirements agreed on*; or if needed, go back 
>> and revise 
>> > the requirements, establish consensus for the revised 
>> requirements, and then compare the solutions against those.
>> > 
>> > In the first paragrap above, you seem to be arguing as if this is a 
>> > trial, rather than engineering.
>> > 
>> > It seems to me that nobody has had complaints about the proposed 
>> > solution not fulfilling the requirements, or about the requirements 
>> > being incomplete or wrong; the discussion up to now has 
>> sounded more 
>> > like "you didn't pick my favourite solution, so I'm going 
>> to give you a hard time about it".
>> > 
>> > So if the DT 'defends' itself against one charge ("You 
>> didn't propose
>> > PMIPv6!") the next will maybe be "You didn't propose GTP", 
>> followed by 
>> > "You didn't propose PMIPv4, which is much more proven than PMIPv6", 
>> > followed by "You didn't propose OSPF, which was used for LMM over 4 
>> > years ago, and proven to work", and so on...
>> > 
>> > And if we would accept this mode of working, any future 
>> proposal would 
>> > be open to the same kind of attack.  That wouldn't be 
>> engineering, either.
>> > 
>> > This isn't the way to argue, and it isn't a way that leads forward.
>> > 
>> > What's really relevant to the Internet Engineering Task 
>> Force is what 
>> > the requirements are, and how well the proposed solution(s) 
>> fulfil the 
>> > requirements.  That's engineering.
>> > 
>> > Can we get back to doing engineering, please?
>> > 
>> > 
>> > 	Henrik
>> > 
>> > _______________________________________________
>> > netlmm mailing list
>> > [e-mail]
>> > https://www1.ietf.org/mailman/listinfo/netlmm
>> 
>> 
> 

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