Subject: RE: [Capwap] Interoperability reqs into Objectives draft (was: Comments on objectives draft)

From: "Partha Narasimhan" <[email-masked]>
Date: Sat, 9 Apr 2005 08:54:03 -0700

> The difference with CAPWAP is that there is a basic disagreement about the
> architecture, and entrenched commercial interests on both sides. Much harder
> to achieve agreement in a short period. Too bad 802.11 didn't see fit to
> nail down the architecture more tightly initially, it would have made the
> RAN protocol standardization process much easier.
> 
> 
>             jak

This is precisely the reason why I think the "one and only one" model will not work. I have no trouble with a proposal attempting to be "the one", but the problem I have is with the "only one" part since as James points out above there is disagreement in the architectural details for one protocol to address all of them. I am not even sure I agree with James' "both sides" since I see more than two. 

I am not saying that a proposal should not be allowed to attempt to cover all the architectures. I am just saying that, IMHO, such a solution may be more complicated than the sum of its parts. So we should have a framework where simpler solutions that seek to address a subset of the CAPWAP architectures be allowed to exist. And leave the door open for future innovation that may solve the problem in ways that we havent documented in the architecture taxonomy document today. 

Thanks
partha

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Pat Calhoun" <[email-masked]>
Date: Sun, 10 Apr 2005 12:00:16 -0700

> This is precisely the reason why I think the "one and only 
> one" model will not work. I have no trouble with a proposal 
> attempting to be "the one", but the problem I have is with 
> the "only one" part since as James points out above there is 
> disagreement in the architectural details for one protocol to 
> address all of them. I am not even sure I agree with James' 
> "both sides" since I see more than two. 

Partha, there have been plenty of instances within the IETF where
requirements were such that protocols designed had to support 
different architectures. I can't speak for all protocols in CAPWAP,
but I can tell you that my company has a product that addresses
both the local and split MAC, with a single protocol - all in a
lighweight AP.

> 
> I am not saying that a proposal should not be allowed to 
> attempt to cover all the architectures. I am just saying 
> that, IMHO, such a solution may be more complicated than the 
> sum of its parts. So we should have a framework where simpler 
> solutions that seek to address a subset of the CAPWAP 
> architectures be allowed to exist. And leave the door open 
> for future innovation that may solve the problem in ways that 
> we havent documented in the architecture taxonomy document today. 

I would argue that for a WG to design more than a single protocol
would not only be a waste of IETF engineering resources, but it would
also significantly increase the time to market. Further, attempting to
solve problems that are not documented, which we've all agreed upon is
pointless. I'm sure one could cook up several "possible" scenarios that
could significantly increase our protocol development time, but this
doesn't really help the internet community, which is asking for a 
solution.

As I mentioned above, there is at least one protocol that is capable
of addressing the architectures identified in the taxonomy specification,
and I would even go as far as to say that this has been done in a way that
is extensible and allows for future (and past) innovation.

I say let's focus on a single protocol that can guarantee interoperability
and the show market that the IETF can make progress.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems