Subject: RE: [Capwap] Re: SLAPP and IETF DS Interoperability Requirement (was: Re: [Capwap] Comments on objectives draft)

From: "Partha Narasimhan" <[email-masked]>
Date: Thu, 7 Apr 2005 12:42:19 -0700

More imporantly, SLAPP is a proposal that attempts to move away from a single monolithic protocol that claims to address multiple differing requirements of the archtitectures that CAPWAP has documented so far. 

We are providing a common underlying framework that has the ability to discover, authenticate, and negotiate a control protocol that will be used. This enables us to have multiple solutions that are simpler because they may choose to address a subset of the CAPWAP architectures, but the union of these may addresses everything under the CAPWAP sun. Of course, it does not preclude a control protocol that does attempt to solve the entire problem.

There are some benefits to doing this:

- anyone desiring to solve a simpler WLAN problem (i.e. a subset of the CAPWAP architectures) is not necessarily burdened with implementing and complying with a single complex control protocol. 

- it does not restrict innovation either now or in the future since someone that figures out a newer way (including adding color to our mundane RF lives :-)) could very easily publish their protocol.

- we can restrict ourselves to solving 802.11 problems of today without worrying about how to address future work for other access technologies. 

- other groups that are not associated with CAPWAP, but could benefit from a discovery and authentication process.

We are currently faced with multiple proposals that all have their pros and cons. Instead of requiring every one of them to present "the most complete" CAPWAP solution or get dropped from consideration (an all-or-nothing approach), we could have them address a complete solution to one or more of the CAPWAP architectures. And negotiate support for these within SLAPP.

Thanks
partha

-----Original Message-----
From:	[email-masked] on behalf of [email-masked]
Sent:	Thu 4/7/2005 11:38 AM
To:	Partha Narasimhan; [email-masked]
Cc:	[email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject:	RE: [Capwap] Re: SLAPP and IETF DS Interoperability Requirement (was: Re: [Capwap] Comments on objectives draft)
Partha-

As you admit, SLAPP is not a complete solution to the CAPWAP problem, nor does it address a control and provision protocol as described in our charter.

I would be more likely to consider the ideas you propose in SLAPP, to be solutions to individual objectives, rather than a protocol for CAPWAP itself. 

Dorothy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of ext Partha Narasimhan
Sent: Thursday, April 07, 2005 11:17 AM
To: James Kempf
Cc: Wijnen, Bert (Bert); Pat Calhoun; 'Dan Harkins'; [email-masked]
Subject: [Capwap] Re: SLAPP and IETF DS Interoperability Requirement
(was: Re: [Capwap] Comments on objectives draft)

James

Thanks for your comments.

Your conclusion is a bit premature, though.

The goal of SLAPP is not to provide the most complete solution to 
the CAPWAP problem. Instead we started with the premise that there is more
than one way to solve the CAPWAP problem, especially if one wants to
address just a subset of the multiple documented architectures. 
We can either start with trying to limit choices in the proposed solution 
or go ahead and standardize a large number of architectural permutations. 
Neither of these two seemed acceptable.

So we decided to take a divide and conquer approach and specify a 
common framework using which multiple (hopefully simpler) control 
protocols can be applied for solving the CAPWAP interoperability problem. 
This way a control protocol that wishes to address say just the local MAC 
architecture can be negotiated during the SLAPP phase and then used 
without the burden of implementing an entire set of features that will not 
be used in that network. Our assumption is that these control protocols 
would be published ones and not proprietary to any specific vendor. In 
fact, any or all of the other three CAPWAP proposals can be a control 
protocol that can be negotiated using SLAPP.

This also has the added benefit that since SLAPP is completely access
technology independent, it could be used as a framework for other
technologies for discovery and authentication and then go on to execute
the control protocol defined and published for that specific access
technology. That way we can currently focus on solving the current WLAN
problems without worrying about future UWB problems about which we dont have
enough information.

In the end, we are proposing a framework where we can have multiple simpler
published control protocols that solve smaller problems instead of one 
big, more complex control protocol solving multiple problems. The 
image download protocol defined in the draft is NOT mandatory for SLAPP.

Thanks
partha

On Thu, 7 Apr 2005, James Kempf wrote:

> So in line with Bert's comments, I've been pondering whether it would be
> possible for SLAPP to achieve the interoperability requirement that IETF has
> for moving a protocol from Proposed Standard to Draft Standard (I'm assuming
> other people in the WG care about the protocol ultimately going to Draft
> Standard, I certainly do). The requirement is that there need to be two
> independently built interoperable implementations done from the
> specification that is being put forward for advancement to Draft Standard.
> It is one of the few hard and fast rules that IETF has.
>
> As I see it, the basic issue is this:
>
>    Is it possible for two AC implementors and two AP implementors
>    *using the SLAPP spec* to achieve independently implemented
>    interoperable implementations *of the control protocol* without
>    reference to any other specification except those that are listed
>    as Normative References in the specification and without
>    exchanging any code?
>
> The answer I think is clearly "no". This is because the SLAPP spec doesn't
> address the control protocol, it just addresses discovery, negotiation of a
> (probably proprietary) control protocol, and download of code to run the
> control protocol, as Partha mentioned in his email. In order to actually
> achieve interoperablity *on the control protocol*, the AC and AP vendors
> would have to exchange an additional specification that would not be part of
> the Normative References in the specification being put forward for
> advancement to Draft Standard.
>
> From this, I conclude that SLAPP does not address the goals of the CAPWAP
> charter, since the CAPWAP charter clearly defines an interoperable control
> protocol as one of the deliverables for the Working Group. Therefore, I
> would venture that SLAPP is not a valid candidate for consideration as a
> CAPWAP protocol, and it should not be considered in the upcoming protocol
> decision phase (whatever that might be).
>
> Comments?
>
>            jak
>
>
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
>
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 7 Apr 2005 13:19:08 -0700

> In the end, we are proposing a framework where we can have 
> multiple simpler published control protocols that solve 
> smaller problems instead of one big, more complex control 
> protocol solving multiple problems. The image download 
> protocol defined in the draft is NOT mandatory for SLAPP.

I understsand the motivation much better now, but would like to 
state that I have participated in many working groups in the past
decade where multiple protocols competed for standardization. I
think that in the end, a WG is much better off coming up with a
solution that enables for interoperability, than to simply give
up early with the notion that solving the problem is too
difficult. 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems