Re: laugh test - capwap

[Thomas Narten <narten@us.ibm.com>]

I have not been following this effort at all. But my read of the
charter, it has vague written all over it. Hmm, one needs to read the
problem statement ID. Assuming it is representative and is pretty good
description of the actual problem, I can see the need for work in this
space.

Some general thoughts.

Isn't the AR/AP functionality split IEEE business? Why is it to become
IETF business? And what is the scope of the problem that IETF will
need to solve? (I can live with the IETF deciding the split, so long
as IEEE is OK with us owning this part of the problem - though it
seems a bit odd for us to take this on.)

Note: how is this really different than layer 2 switches, that
presumably have many of the same issue with regards to
functionality/split/mangement/etc.?

Note: For a long while, I've had trouble understanding whether an AP
is an L2 or an L3 thingie. That is important, because IMO, L2 stuff
generally isn't IETF business. But folk in many camps seem to talk
about APs as if they were L3 thingies, even though this has not been
clear to me. The problem statement seems to say they are L3
thingies. And the need for the IETF to be involved is then presumably
that IP protocols will be used in preference to L2 protocols, even
though a lot of what those protocols carry will be L2-specific stuff.

Note: one reason I am concerned about the AP vs. AR differences is
that if APs are IP devices and a part of the general architecture,
folk become tempted to have clients distinguish between APs and
ARs. This (IMO) complicates clients/protocols, maybe in ways we don't
like. This sort of thing is to some extent assumed by groups like
seamoby and/or fast handoffs in MIP and temps folk greatly when
looking for optimizations...

> As the size and complexity of IEEE 802.11 wireless networks have
> increased, problems in the deployment, management, and usability of
> these networks have become evident.
> draft-calhoun-capwap-problem-statement-00.txt describes some of
> those problems.  In addition, security considerations have become
> increasingly important as IEEE 802.11 networks have been deployed
> in situations where their use in accessing sensitive data must be
> restricted for business or other reasons.

I don't immediately see this in the problem statement. Discussion
there seem to be restricted to making sure APs are authenticated
before being allowed to join the network. Is this item about replacing
WAP with something better? (I can read it this way...)
 
> While there are many
> possible approaches to solving these problems, most of them involve
> IP-level protocols in some fashion.  To the extent changes to
> existing IETF protocols are necessary or new IP-level protocols
> must be standardized to facilitate interoperability, this work is
> an appropriate topic for the IETF.

> [ note that the last sentence makes no sense to me.  i suspect that
>   there is an s/IETF/IEEE/ needed somewhere in it. ]

My take is that there will need to be MIB (or related) work, maybe
secure download (which would be an IETF issue at L3). I guess  I see
potential work items here, but I'd be a bit concerned that any work
done is done generically (e.g., secure download) and not just for this
effort. But this will conflict with "need solution yesterday".

> The charter of the CAPWAP Working Group is to investigate and
> design a protocol for the purpose of simplifying the deployment,
> management, and usability of IEEE 802.11 wireless networks for
> Internet use.

Wording seems to presume new protocols are needed. Case needs to be
made, IMO.

> The Working Group will attempt to utilize existing
> IETF protocols where possible, but will engage in new design if
> necessary.  The Working Group's designs will focus on the "split
> AP" architecture.  The split AP architecture centralizes processing
> of access point (AP) management functions, such as inter-AP
> configuration and control, and non-realtime host functions, such as
> data transport and host authentication, in a management entity,
> typically an access router (AR).  The IEEE 802.11 APs continue to
> perform real-time host functions.  The split AP architecture does
> not involve any changes in IEEE 802.11 standards, since the IEEE
> 802.11 specification says nothing about the architecture of the
> IEEE 802.11 access point.  This new architecture has been adopted
> by many manufacturers, each with some variation.  Creating an
> interoperable protocol between the AP and the AR will benefit the
> network operator community by allowing operators to build networks
> with equipment from a variety of conforming vendors.

Seems to be that one of the highest priority (and possibly most
contentious) things to get done is get agreement on the functionality
split. Until this is done, it will remain unclear what protocols are
needed. 

> Specific Working Group work items are:
>   - Clear problem statement and description of the split AP
>     architecture,

Seems OK to me.

>   - CAPWAP security requirements, defining the needs for security
>     between the AP and the AR both for host data transport and for
>     AP-AR signalling and control,

Not sure why "host data transport" is included here. Will user data be
tunneled in IP protocols? Fine with me, but this seems like an odd
thing to do at this level. I.e., I wouldn't have assumed this is a
desired starting point.

>   - A protocol for implementing the split AP architecture,
>     including the following functionality:

I'd remove all of this from the charter until the previous work has
been done. 

>     . Discovery of ARs by APs (this work should point to existing
>       IETF standards, if possible)

Indeed, I wonder how this relates to the device discoery BOF that
wasn't held last time around (and for which the propoents have been
completely silent since the Vienna...)

>     . Auto-organization of APs and ARs into a managed wireless
>       access network, including failover if an AR should fail,
>     . A tunneling protocol for IEEE 802.11 non-realtime
>       host-related signalling and data between the AP and the AR,
>     . Support for configuration of the AP by the AR, including
>       secure download and booting of code to the AP (some aspects
>       of this task may involve existing IETF standards),
>     . Security for both tunneled host data and AR-AP signaling, as
>       necessary to address the requirements (this work may involve
>       utilizing existing IETF standards).

Again, I'd leave this all out until the split/problem statement are
mostly done.

> The intent of the CAPWAP Working Group is to complete the protocol
> specification as quickly as prudently possible and to serve as a
> forum for discussion of issues found when testing interoperability,
> in typical IETF fashion.

Here is the dilemma. Needed Yesterday.

> While not specifically a work item, the Working Group will attempt
> to make all designs as independent of the IEEE 802.11 radio
> protocol as possible, so that the protocol might, in the future be
> used with other radio protocols.  However, in any situation where a
> tradeoff between simplicity/speed of design completion and
> extensibility is required, the Working Group will opt for the
> former.

Seems like an odd thing to write into the charter. Seems like an item
that people will be able to use to shut people up who raise issues
about basic design tradeoffs.

> The Working Group will also co-ordinate closely with the
> IEEE 802.11 WG.

> Specific non-goals of this work are:

>   - Support for general, inter-subnet micromobility,
>   - Interoperable APIs for downloaded AP code images,
>   - Any IP-layer work that would require changes to the IEEE 802.11
>     MAC layer,
>   - Dependence on yet to be approved IEEE 802.11 work or drafts,
>   - Support for an inter-AP communication protocol, like IEEE
>     802.11f, 
>   - Direct joint development of protocols with the IEEE 802.11 WG.

> Working Group protocol documents and the security requirements will
> be sent to the Security Area Advisory Group (SAAG) for review prior
> to submission to the IESG.

> Goals and Milestones:

> Mar 2004 Complete problem statement draft and architecture
>          description and submit to IESG for publication as
>          Informational.

> Mar 2004 Complete security requirements and submit to SAAG for
>          review.  Submit to IESG for publication as Informational
>          when SAAG review is complete.

Seems like a good time for recharter/recheck.

> Nov 2004 First draft of CAPWAP protocol complete and ready for
> 	 review.

> Mar 2005 Complete CAPWAP protocol and submit to SAAG for review.
>          Submit to IESG for publication as Proposed Standard when
>          SAAG review is complete.

Just to be clear, this protocol seems to have been needed yesterday,
and speed is more important than anything else according to some of
the charter wording. Yet, I see a (probably realistic) target of
almost 2 years from now. I hope everyone is on the same page here.

Thomas