[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: laugh test - capwap

Isn't the AR/AP functionality split IEEE business?

Yes, it is.

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

It's a quagmire because IEEE 802.11-1999 didn't adequately specify the required architecture of the "MAC entities" on the wired and wireless sides. For example, does the AP have distinct MAC addresses on the DS and WM ports, and if not, how is the relay function and VLAN tagging/untagging function specified in IEEE 802.1D carried out? Since APs don't run spanning tree or implement learning according to IEEE 802.1D, clearly something else is going on. One has to dig into the SDL in IEEE 802.11-1999 to figure out exactly what that is -- 802.11 AP learning is handled via the Association/Reassociation exchanges. But when security is added, things can't quite work this way because those exchanges are unsecured, but the 4-way handshake is secure. Therefore you can't send multicast "Association" announcements on the wired side until the 4-way handshake completes, and there is an implicit assuming that learning table entries need to be delayed, etc.

IEEE 802.11 is having a devil of a time getting all this specified to the point that IEEE 802.1 can understand how an AP works and the IEEE 802.11 specs are internally consistent. If IEEE 802 has questions about how this works (e.g. we had to have an hour discussion with Mick Seaman just to convince him that it was possible to do VLAN tagging/untagging and pre-authentication together correctly) I doubt IETF can contribute much other than confusion.

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

It's different because an AP is *not* a bridge as defined in IEEE 802.1D.

Note: For a long while, I've had trouble understanding whether an AP
is an L2 or an L3 thingie.

It doesn't fit cleanly into either category. It is not a classic L2 bridge, since it doesn't conform to IEEE 802.1D, and uses IEEE 802.11 management frames for functions that would be accomplished via IEEE 802 data frames in 802.1D. At the same time, some 802.11 APs do include bridge functionality such as spanning tree. Similarly, an IEEE 802.11-1999 AP is not a router, although many implementations do include routing and/or NAT functionality.

The problem statement seems to say they are L3 thingies.

Yes, it seems to assume that -- and doubt that IEEE 802 would agree.

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.

This is not sufficient justification because IEEE 802 WGs such as 802.11f *can* specify IP protocols. After all, IAPP runs over IP.

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

Yes, I think this could be very damaging. We'd effectively have two competing AP architectures before IEEE 802.11 can even agree on what the L2 architecture is. There has already been talk about setting up a competing group in IEEE 802.11

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

It will inevitably interact with IEEE 802.11i security. And authenticating APs to the network is already something specified in IEEE 802.11f.

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

Yup. I'd prefer to see work on "secure download" explicitly excluded from the charter.

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

Yes.

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.

Yes. Why don't they just focus on an architecture/framework document?

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

Seems OK to me.

Yes.

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.

On the criticisms of the CAPWAP approach is that it isn't clear why the tunneling needs to occur from an AP to a remote AR multiple hops away. If it is only a single hop, why won't L2 encapsulation suffice? Is L3 being used here solely to justify doing work in the IETF, or is there a technical reason for the choice? The IEEE 802.11 folks seem convinced that L2 is the way to go.

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

Yes. It's the only hope of achieving focus.

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

Answer: it overlaps. We already have proposals for 4 different discovery protocols to handle this, between IETF (DDP, CARD), and IEEE (LLDP, LINKSEC discovery). No way shoudl this be included in the charter.

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

Yes.

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.

Yes, I think that's the intent.

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

I'd like more detail on the coordination. Are we proposing that the architecture document be reviewed by IEEE 802.11?

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.

This seems like the kind of problem that neither the IEEE nor the IETF can handle well. It's very likely that multiple proprietary solutions will be shipped by the time this effort gathers any steam. And the IETF/IEEE split will guarantee multiple competing standards in this area.

End result: everyone can claim conformance to a "standard" with no real interoperability.

_________________________________________________________________
Get McAfee virus scanning and cleaning of incoming attachments. Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es