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

From: <[email-masked]>
Date: Thu, 7 Apr 2005 11:38:41 -0700

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

---

From: "Victor Lin" <[email-masked]>
Date: Thu, 7 Apr 2005 11:47:10 -0700

Here is what I read from the e-mail thread:

1. The goal of CAPWAP is to define a "Control and Provisioning Protocol"
to achieve multi-vender interoperability.

2. SLAPP provides building blocks to achieve this goal - discovery,
authentication, and optional image management. But you will need to
define other protocols to achieve objective states above.

From my perspective, I rather like to see a proposal that can address
all the problems we need to solve based on the charter of the CAPWAP.

Victor 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of 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

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.

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

---

From: <[email-masked]>
Date: Thu, 7 Apr 2005 13:14:07 -0700

Partha,

This WG has been chartered by the IESG to produce a protocol that incudes control.  This is what we are chartered to do in this CAPWAP WG.   

Dorothy

-----Original Message-----
From: ext Partha Narasimhan [mailto:[email-masked]]
Sent: Thursday, April 07, 2005 12:42 PM
To: Gellert Dorothy (Nokia-ES/MtView); [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)

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-

Dorothy 

-----Original Message-----

James

Thanks
partha

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 8 Apr 2005 15:21:28 -0400

Dan Harkins writes...

> In -01 of SLAPP these are handled through a vendor specific 
> extension--the image download. 

Now that's what I call some whopping "extension" -- an operating image
"transplant operation".  :-)  Or was that intended as humor?

---

From: <[email-masked]>
Date: Mon, 11 Apr 2005 21:02:22 -0700

Mani, we as chairs do not have consensus on this.    There may be cases where a protocol submitted for evaluation does not
meet the goal or Charter of the WG and therefore will not be considered for evaluation.

Such cases are fair to be brought up and discussed on the list.

-Dorothy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of ext Mani, Mahalingam (Mahalingam)
Sent: Monday, April 11, 2005 7:59 PM
To: James Kempf; Wijnen, Bert (Bert); Pat Calhoun; Dan Harkins
Cc: [email-masked]
Subject: RE: SLAPP and IETF DS Interoperability Requirement (was: Re:
[Capwap] Comments on objectives draft)

The proposals being up - they are fair game for critical analysis in the
list. However,

More inline...

-mani
======

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

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.

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).

[Mani, Mahalingam (Mahalingam)] we will not presuppose the evaluation
process for lack of meeting Objectives criteria - which will be part of
evaluation process. We should hold such judgments until the protocol
evaluation process starts. It is fair to provide at least until after
Objectives WGLC for all protocol drafts to make course corrections
before sitting in judgment over their suitability. That is not to
discourage debating the merits, demerits, lack or richness of features.

-mani

Comments?

            jak

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 11 Apr 2005 22:36:40 -0700

Hi,

A similar way of doing extensions is there in IS-IS too
http://www.ietf.org/internet-drafts/draft-ietf-isis-experimental-tlv-04.
txt.

I think the "message type" should also allow such extensions in the
below mentioned protocol and not just TLV's.

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Kempf
Sent: Tuesday, April 12, 2005 2:57 AM
To: Dan Harkins
Cc: [email-masked]
Subject: Re: SLAPP and IETF DS Interoperability Requirement (was: Re:
[Capwap] Comments on objectives draft) 

Because I looked at the LWAPP spec for the first time in a while, and
saw
that the vendor extensions were more like Diameter AVPs than commands.
:-)

Being on two IETF design teams, monitoring Mobike, and trying to make
sure
that CAPWAP results in a true interoperable standard, sometimes I end up
shooting from the hip due to lack of time.

Dan, people change their minds all the time. Think about it, could make
CAPWAP converge faster...

            jak

----- Original Message ----- 
From: "Dan Harkins" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 11, 2005 9:49 AM
Subject: Re: SLAPP and IETF DS Interoperability Requirement (was: Re:

>   James,
>
> On Sun, 10 Apr 2005 18:22:15 PDT you wrote
> >
> > Here's what I want: no vendor specific extensions that change the
state
> > machine, which I think was the same criteria for Diameter
(vendor-specific
> > AVPs are OK since they get processed within the existing state
machine,
new
> > commands which would require new code in peers need IETF standards
action)
> > which is what I said in my original post. And, yes, the LWAPP
extensions
> > don't seem to change the current state machine, they are like
Diameter
AVPs.
> > SLAPP vendor extensions, on the other hand, result in a
vendor-specific
> > state machine being installed onto the WTP.
>
> That's not what you said in your original post. What you said was,
>
> "Actually, I *do* want the vendor specific extensions removed from
LWAPP,
so
> we'll have to disagree here."
>
> You then went on to justify this statement by describing LWAPP's
vendor
> extensions as the same sort of vendor extensions that have caused
problems
> for service providers:
>
> "Such vendor extensions have caused no end of problems for service
providers
> over the years in RADIUS, to the point that when Diameter was
standardized,
> the IESG specifically mandated that any Diameter command extensions
(which
> would require different code in the AAA server) must have IETF
approval."
>
> But now you're saying that LWAPP's vendor extensions are not like
those
> that have caused problems in the past and you don't want them removed
> from LWAPP.
>
> So what happened? Why did you change your mind?
>
>   Dan.
>
>