Re: CAPWAP BOF follow up: nmrg - CAPWAP

[Randy Bush <randy@psg.com>]

> From: "Bernard Aboba" <bernard_aboba@hotmail.com>

> there seems to be a need for a very clear (and focussed!) problem
> statement, as well as a demonstration of understanding of
> management requirements.  A charter that focussed on those things
> might channel the energy that currently exists in a productive
> direction while also providing more evidence that the group has
> the "genetics" to survive if it is turned loose on protocol
> design.

that's for sure, if bert or i are being asked to sponsor this.
very clear, very targeted, and with the folk clearly on hand to hit
those targets in sufficient time that we don't lose their interest
and attention.  see following response to james.

> IEEE 802.11f was no more successful than SEAMOBY for some of the
> same reasons -- lack of vendor interest in encouraging the
> deployment of heterogeneous AP networks.

is this effort different?

> I suggest that we need to think more about the problem and what
> kinds of resources we'd need to be successful.  The issue that
> I've heard is not that CAPWAP is being proposed in the wrong
> place, but that the design has a poorly thought out security and
> deployment model.

imiho, this caused the biggest core damage to aaa/diameter.  e.g.,
the proxy model could not be removed and it vastly complicated
everything.

> From: "James Kempf" <kempf@docomolabs-usa.com>

>> There might be areas where research is needed (e.g. load
>> balancing algorithms) but management of IEEE 802 wireless
>> networks seems a bit practical for that.
> The specification would not be for algorithms but for the
> interoperable protocol to distribute the information. The
> algorithms are for proprietary innovation, and don't really need
> a standard for interoperability. Or, at least, that is my
> understanding of what the supporters want.

so i won't be able to load balance in a multi-vendor environment?

> CAPWAP doesn't change the roaming (actually, in IETF we call this
> handover) model. The host still makes the ultimate decision. It's
> like ICMP Redirect.  If a router doesn't want to handle a
> particular host's traffic, it sends a Redirect and tells the host
> to go elsewhere. The host can still hit on the router with its
> traffic, but if the router won't route it, then the traffic won't
> go anywhere.

is this a feature?

> My inclination would be to tell the group that wants to do this
> to work on the problem statement and requirements before the WG
> is formed, to provide them with an incentive to agree (after bad
> experiences with trying to do problem statements and requirements
> in a WG).  Randy, Bert, what do you think? Should I send a note
> to the list suggesting a couple drafts in this area?

let's think of it as requirements and road map, where are we going,
why, and how are we going to get there.  and maybe where are we NOT
going, why, and how do we plan to not get there.  and keep it
simple.  if the requirements and road map can not be simple and
done in a few weeks, then how will the results of the wg be simple
enough to be achievable?

>>> Since IEEE doesn't have a good track record above the MAC
>>> layer, if IETF decided to do this, we could try to run this
>>> with heavy IEEE involvement, possibly as a joint activity.
>> A joint effort seems too unwieldy, but if the problem could be
>> clearly partitioned between the two bodies that might be more
>> workable.
> Any suggestion about how to best achieve that partitioning?

partitioning of what?  i.e., lets see the requirements and road
map, and maybe we'll have some idea of how to divide the workload
appropriately.

>> The issue that I've heard is not that CAPWAP is being proposed
>> in the wrong place, but that the design has a poorly thought out
>> security and deployment model.
> You mean LWAPP, not CAPWAP. The whole point of naming the BOF
> CAPWAP was not to tie it to the currently proposed protocol, but
> to give it some space to develop into what IETF wants.

call it whatever you want, but i heard one presentation at the bof
in wien that set off major security alarms, and a few others that
made one cautious.

> the issue of how to do wireless network managment (and by that I
> mean certain real time functions like dynamic power control as
> well as the typical kinds of monitoring functions that are done
> with SNMP) is one that we need to figure out, together with IEEE
> if that makes sense.

dynamic power control is one area where the ietf is known for deep
expertise, just ask dave crocker. :-)

> OK. I'm open to suggestions about how to proceed. There is a lot
> of industry interest in this, which doesn't mean IETF needs to do
> it.

i would like to hear that there is a lot of USER interest in this
too, not just vendors.  i suspect there is, but as bernard says,
today users are trapped in a single vendor environment if we want
it to work.  i keep hammering on it as i don't want the user
component left out of the focus.

randy