Subject: RE: [netlmm] Network-based mobility - NETLMMDT Solution VsAsolutionbased on MIP6

From: "Faccin, Stefano M" <[email-masked]>
Date: Fri, 27 Oct 2006 18:55:28 -0700

Vidya,
I agree with you, since I believe we are a bit more professional than
what is given credit to us by statements like "you didn't pick my
favorite solution, so I'm going to give you a hard time about it". 

The first key point here is that, round after round of discussion, there
is still a huge resistance to answer the open question on what were the
reasons for not basing the protocol on MIP6. 

The second key point is what you mention about a request and interest
for a solution based on MIP6. Perhaps Henry is correct, we need to
review the requirements document and then verify if the current result
of the DT is satisfying the new requirements. However, that also means
for the time being it would make no sense to adopt the current DT design
as WG draft. 

My concern is whether there is indeed openness in the WG to reopen the
requirements draft. Based on the type of comments on this list and the
strong resistance to this discussion, I'd like to hear from the WG
chairs what they think about that. If the answer is not, perhaps we
should indeed consider doing the work suggested in our discussion thread
in another WG, like MIP6 (as originally proposed). 

Stefano

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Friday, October 27, 2006 5:16 PM
To: Henrik Levkowetz
Cc: [email-masked]
Subject: RE: [netlmm] Network-based mobility - NETLMMDT Solution
VsAsolutionbased on MIP6

Hi Henrik,
I don't want to spend time on this kind of debate. I keep hearing that
the DT already debated the issue of basing the protocol on MIP6 and
decided against it. And those reasons are unknown to the rest of the
group at the moment. Now, there is a request for standardization of a
solution based on MIP6 by several people, citing industry direction. And
the proponents of that are being asked to prove why they prefer that
over the DT solution. That is clearly unfair - if we differ in that
view, we have to agree to disagree. I think the rest of the group
deserves to understand the reasons behind the DT choice. Going down the
number of possible combinations is not a useful exercise.  

Vidya

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Friday, October 27, 2006 3:25 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject 2006 18:55:28 -0700
Content-class: urn:content-classes:message
Subject: RE: [netlmm] Network-based mobility -
	NETLMMDT	Solution	VsAsolutionbased on MIP6
Date: Fri, 27 Oct 2006 18:55:28 -0700
To: "Narayanan, Vidya" <[email-masked]>,
	"Henrik Levkowetz" <[email-masked]>
Cc: [email-masked]

Vidya,
I agree with you, since I believe we are a bit more professional than
what is given credit to us by statements like "you didn't pick my
favorite solution, so I'm going to give you a hard time about it". 

The first key point here is that, round after round of discussion, there
is still a huge resistance to answer the open question on what were the
reasons for not basing the protocol on MIP6. 

The second key point is what you mention about a request and interest
for a solution based on MIP6. Perhaps Henry is correct, we need to
review the requirements document and then verify if the current result
of the DT is satisfying the new requirements. However, that also means
for the time being it would make no sense to adopt the current DT design
as WG draft. 

My concern is whether there is indeed openness in the WG to reopen the
requirements draft. Based on the type of comments on this list and the
strong resistance to this discussion, I'd like to hear from the WG
chairs what they think about that. If the answer is not, perhaps we
should indeed consider doing the work suggested in our discussion thread
in another WG, like MIP6 (as originally proposed). 

Stefano

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Friday, October 27, 2006 5:16 PM
To: Henrik Levkowetz
Cc: [email-masked]
Subject: RE: [netlmm] Network-based mobility - NETLMMDT Solution
VsAsolutionbased on MIP6

Hi Henrik,
I don't want to spend time on this kind of debate. I keep hearing that
the DT already debated the issue of basing the protocol on MIP6 and
decided against it. And those reasons are unknown to the rest of the
group at the moment. Now, there is a request for standardization of a
solution based on MIP6 by several people, citing industry direction. And
the proponents of that are being asked to prove why they prefer that
over the DT solution. That is clearly unfair - if we differ in that
view, we have to agree to disagree. I think the rest of the group
deserves to understand the reasons behind the DT choice. Going down the
number of possible combinations is not a useful exercise.  

Vidya

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Friday, October 27, 2006 3:25 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [netlmm] Network-based mobility - NETLMM DT 
> Solution VsAsolutionbased on MIP6
> 
> 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:[email-masked]]
> >> Sent: Friday, October 27, 2006 2:28 PM
> >> To: Henrik Levkowetz
> >> Cc: Narayanan, Vidya; [email-masked]
> >> 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 : Re: [netlmm] Network-based mobility - NETLMM DT 
> Solution VsAsolutionbased on MIP6
> 
> 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:[email-masked]]
> >> Sent: Friday, October 27, 2006 2:28 PM
> >> To: Henrik Levkowetz
> >> Cc: Narayanan, Vidya; [email-masked]
> >> 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
> >> > [email-masked]
> >> > https://www1.ietf.org/mailman/listinfo/netlmm
> >> 
> >> 
> > 
> 

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

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

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
> >> > [email-masked]
> >> > https://www1.ietf.org/mailman/listinfo/netlmm
> >> 
> >> 
> > 
> 

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

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