Capwap Mailing List: Re: So many architectures, so little time... - take 2

[James Kempf (kempf]

Ack.

            jak

----- Original Message ----- 
From: "Wijnen, Bert (Bert)" <bwijnen [at] lucent.com>
To: "'Yang, Lily L'" <lily.l.yang [at] intel.com>; "Burbank, Jack L."
<Jack.Burbank [at] jhuapl.edu>; "Victor Lin" <VLin [at] extremenetworks.com>; 
"Bob
O'Hara" <bob [at] airespace.com>; <capwap [at] frascone.com>
Sent: Monday, August 09, 2004 6:13 AM
Subject: RE: [Capwap] So many architectures, so little time... - take 2


> Not sure who is confused... probably me...
>
> My understanding was/is that IF we do re-charter for CAPWAP
> protocol work, that it is then a NM protocol for
> "Control and Provisioning" and not any of the related stuff
> that moves the data from WTP to AC.
>
> Is everybody in agreement with that understanding.
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Yang, Lily L [mailto:lily.l.yang [at] intel.com]
> > Sent: maandag 9 augustus 2004 08:14
> > To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap [at] frascone.com
> > Subject: RE: [Capwap] So many architectures, so little
> > time... - take 2
> >
> >
> > I think setting the re-charter scope to develop a single protocol that
> > allows interoperability between Local and Split MAC is a reasonable
> > tradeoff:
> > We exclude remote MAC because the constraint it imposes is very
> > different from the rest and the benefit of including it is
> > very little.
> > But Local and Split MAC are reasonably close and hence the
> > effort may be
> > incremental only.
> > As many people noted, as of today, there is no single clear definition
> > of what "Local MAC" and "Split MAC" really means yet. Each vendor has
> > different definitions and some debate needs to happen so that
> > the WG can
> > reach consensus on what exactly that means, and what kinds of
> > flexibility we want to retain within each class of architecture, and
> > what kind of differences we can to resolve and agree up front. That
> > should also be part of the work items for the new WG -- such agreement
> > on the details for each architecture must be documented somewhere, if
> > not separately, then as part of the Protocol document.
> >
> > -----Original Message-----
> > From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] 
> > frascone.com] On
> > Behalf Of Burbank, Jack L.
> > Sent: Thursday, August 05, 2004 12:14 PM
> > To: 'Victor Lin '; 'Bob O'Hara '; 'capwap [at] frascone.com '
> > Subject: RE: [Capwap] So many architectures, so little
> > time... - take 2
> >
> > I think that interoperability between different architectures
> > should be
> > a
> > requirement, if not the key requirement.  As was mentioned
> > yesterday, a
> > goal
> > of the IEEE is that they maintain flexibility in terms of how products
> > and
> > architectures are implemented.  I think we shouldn't do
> > anything that is
> > contrary to that goal (or at least we should minimize the impact).  I
> > think
> > that the goal of CAPWAP should be to retain this type of
> > flexibility by
> > designing a protocol that can maintain this implementation flexibility
> > but
> > enable interoperability between the various architecture
> > implementations
> > (that after all is the key problem with the deployment of
> > these various
> > architectures - lack of interoperability).  IMO, if we don't
> > design for
> > interoperability between the basic architecture types, it is debatable
> > if
> > something useful would have been accomplished.
> >
> > Jack Burbank
> >
> > -----Original Message-----
> > From: capwap-admin [at] frascone.com
> > To: Bob O'Hara; capwap [at] frascone.com
> > Sent: 8/5/2004 2:46 PM
> > Subject: RE: [Capwap] So many architectures, so little
> > time... - take 2
> >
> > I agree that we can design a protocol and implement the product that
> > works
> > all architectures. I think the question to CAPWAP is:
> >
> > Should we make it a requirement in CAPWAP protocol to achieve
> > interoperability between different architectures?
> >
> > It is definitely doable, but I'm not sure if that is the
> > right thing to
> > do..
> >
> > Victor
> >
> > -----Original Message-----
> > From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] 
> > frascone.com] On
> > Behalf
> > Of Bob O'Hara
> > Sent: Thursday, August 05, 2004 11:43 AM
> > To: capwap [at] frascone.com
> > Subject: RE: [Capwap] So many architectures, so little
> > time... - take 2
> >
> > I think that interoperability will depend on two things.
> > First, it will
> > depend on how we define the protocol and the flexibility for supported
> > architectures it incorporates.  Second, it will depend on what
> > manufacturers implement, i.e., the flexibility they build into their
> > products.
> >
> > I believe that it is possible to design the protocol for the required
> > flexibility.  I know it is possible to implement a product with the
> > required flexibility.
> >
> >  -Bob O'Hara
> >
> >
> > -----Original Message-----
> > From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] 
> > frascone.com] On
> > Behalf Of Abhijit Choudhury
> > Sent: Thursday, August 05, 2004 11:32 AM
> > To: James Kempf; Shehzad Merchant; capwap [at] frascone.com
> > Cc: bwijnen [at] lucent.com; mmani [at] avaya.com; david.kessens [at] 
> > nokia.com;
> > Dorothy.Gellert [at] nokia.com; Inderpreet Singh
> > Subject: RE: [Capwap] So many architectures, so little
> > time... - take 2
> >
> >
> > It may be possible to achieve such interoperability
> > within the split-MAC family or within the local-MAC
> > family.  It would sbe very hard to achieve
> > that between local and split MAC families.
> >
> > For example, if vendor X's WTP terminates 802.11 ctrl/mgmt
> > packets and vendor Y's AC expects the 802.11 mgmt packets
> > to come to it, there's no way you can be interoperable.
> >
> > Or are we planning to specify ONE architecture ?
> > The last thing IETF should do is mandate an implementation.
> >
> > I think a modest and reasonable goal is to come up
> > with a protocol that allows sufficient flexbility so
> > that vendors with splitMAC architectures can transfer
> > most of the information they care about between the WTP and AC.
> >
> > Just my $0.02 ...
> >
> >
> > Abhijit Choudhury
> >
> >
> > -----Original Message-----
> > From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] 
> > frascone.com] On
> > Behalf Of James Kempf
> > Sent: Wednesday, August 04, 2004 3:29 PM
> > To: Shehzad Merchant; capwap [at] frascone.com
> > Cc: bwijnen [at] lucent.com; mmani [at] avaya.com; david.kessens [at] 
> > nokia.com;
> > Dorothy.Gellert [at] nokia.com; Inderpreet Singh
> > Subject: Re: [Capwap] So many architectures, so little
> > time... - take 2
> >
> >
> > As a potential customer, let me put it concretely. I want to
> > be able to
> > buy my access points from Vendor X and my switch from Vendor
> > Y and plug
> > the two together and have them work without any
> > configuration. Also, I'd
> > like to be able to buy switches from Vendor Y and Vendor Z and be able
> > to plug them into my network at various places and have them
> > interoperate.
> >
> >             jak
> >
> >
> > ----- Original Message ----- 
> > From: "Shehzad Merchant" <smerchant [at] extremenetworks.com>
> > To: <capwap [at] frascone.com>
> > Cc: <bwijnen [at] lucent.com>; <mmani [at] avaya.com>;
> > <david.kessens [at] nokia.com>;
> > <Dorothy.Gellert [at] nokia.com>; "Inderpreet Singh"
> > <isingh [at] chantrynetworks.com>
> > Sent: Wednesday, August 04, 2004 3:19 PM
> > Subject: RE: [Capwap] So many architectures, so little
> > time... - take 2
> >
> >
> > > I think the implementation variations even with the split MAC may
> > > cover a broad spectrum. As such its important to clearly articulate
> > > what aspects
> > of
> > > interoperability we are targetting. Is it truly just
> > > control/management or is it interoperability between disparate
> > > implementations of the split MAC, i.e. mix and match
> > operation of WTP
> > > and ACs of all variants within this category.
> > >
> > > I suspect for the latter we may have to arrive at some consensus on
> > > what particular implementations we are targeting
> > interoperability for.
> >
> > > If so, ultimately this problem statement could become part of the
> > > charter.
> > >
> > > -Shehzad
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: capwap-admin [at] frascone.com
> > [mailto:capwap-admin [at] frascone.com] On
> > Behalf
> > > Of Dorothy.Gellert [at] nokia.com
> > > Sent: Wednesday, August 04, 2004 11:53 AM
> > > To: isingh [at] chantrynetworks.com; capwap [at] frascone.com
> > > Cc: bwijnen [at] lucent.com; mmani [at] avaya.com; david.kessens [at] 
> > > nokia.com
> > > Subject: RE: [Capwap] So many architectures, so little
> > time... - take
> > > 2
> > >
> > > I believe this is the consensus, to scope the charter to
> > Centralized
> > > Architecture and LocalMAC and Split MAC.
> > >
> > > I'll update the charter with this change after the CAPWAP
> > WG Mtg. If
> > > there is resistance to this idea, please post to the list.
> > >
> > > Regards
> > > Dorothy
> > >
> > >
> > > > -----Original Message-----
> > > > From: capwap-admin [at] frascone.com
> > [mailto:capwap-admin [at] frascone.com]On
> > > > Behalf Of ext Inderpreet Singh
> > > > Sent: Tuesday, August 03, 2004 9:40 PM
> > > > To: capwap [at] frascone.com
> > > > Cc: bwijnen [at] lucent.com; mmani [at] avaya.com; Kessens David
> > > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView)
> > > > Subject: RE: [Capwap] So many architectures, so little time... -
> > > > take 2
> > > >
> > > >
> > > > The issue(s) at hand and my opinions are:
> > > >
> > > > 1. Do we explicitly state in the re-charter which
> > architecture the
> > > > WG should consider? I think yes.  I propose Centralized
> > architecture
> >
> > > > only. Autonomous and Distributed should be out of scope
> > based on the
> >
> > > > same reasons as per prior postings.
> > > >
> > > > 2. Within Centralized do we focus on all three sub
> > architectures or
> > > > a subset? Remote MAC should be excluded because if I am not
> > > > mistaken, the connectivity constraint between the WTP and
> > the AC is
> > > > "direct connect".
> > > > That being the case and that no IP layer is involved, it doesn't
> > seem
> > > > clear what kind of protocol would help with interoperability.
> > > > I am concerned about the impact, dependencies and interaction with
> > > > the recently constituted IEEE Study group on AP
> > functionality on the
> > > > Split MAC architectures.  Furthermore, there are some
> > pretty drastic
> > > > differences on how the vendors have chosen to split the
> > mac.  Those
> > > > differences will need to be worked out before designing a
> > protocol.
> > > > So, if the low hanging fruit strategy (as James suggested) for
> > > > protocol development and progress is the way to go, then I think
> > > > prioritizing on a protocol for Local MAC is a no brainer.
> >  So as far
> > > > as focus, I feel we should do Local and Split and in that order.
> > > >
> > > > 3. This is not a re-chartering issue but is a response to Pat's
> > > > suggestion that a protocol that just sends the 802.11 MAC frames
> > > > from the AP to the AC would work.  I think possibly, yes.
> >  But again
> >
> > > > the complications of splitting the MAC in an
> > interoperable way will
> > > > be an issue.  Also, you may note in the draft to which
> > you refer, we
> >
> > > > included a capabilities exchange phase.  I had thought of
> > including
> > > > in the capability exchange such things as "AP supports Local MAC"
> > > > and "AP supports Split MAC", but didn't put it in because the
> > > > Taxonomy work was still in progress.  Now that it is pretty much
> > > > done we could surely include that.  But again...let's recharter
> > > > first.
> > > >
> > > > Thanks.  Do people agree with 1 & 2?
> > > >
> > > > ---
> > > > Inderpreet Singh
> > > > Chantry Networks
> > > > isingh [at] chantrynetworks.com
> > > > Cell: 416-831-3705
> > > >
> > > > -----Original Message-----
> > > > From: capwap-admin [at] frascone.com
> > [mailto:capwap-admin [at] frascone.com]
> > > > On Behalf Of Pat R. Calhoun
> > > > Sent: Tuesday, August 03, 2004 6:04 PM
> > > > To: Yang, Lily L; James Kempf; Dorothy.Gellert [at] nokia.com;
> > > > capwap [at] frascone.com
> > > > Cc: bwijnen [at] lucent.com; mmani [at] avaya.com; david.kessens [at] 
> > > > nokia.com
> > > > Subject: [Capwap] So many architectures, so little
> > time... - take 2
> > > >
> > > > After reading Lily's response to Jim, I realize that I
> > fell down the
> >
> > > > same trap. Local MAC is also a centralized approach, and so my
> > > > previous response was not complete. I believe the real
> > question, in
> > > > my mind, is whether we need to address either the Local
> > or the Split
> >
> > > > MAC architecture.
> > > >
> > > > Just looking at the Architecture Consideration tables (7 and
> > > > 10) in the
> > > > specification, the
> > > > main difference (at a high level) between both approaches
> > is where
> > > > the 802.11 management terminates. For Local MAC, it's in the WTP,
> > > > while for SPlit MAC, it's in the AC.
> > > >
> > > > However, looking at table 8, most Local MAC approaches share STA
> > > > state between both the WTP and the AC. So clearly there is some
> > > > signalling protocol between both the WTP and the AC.
> > > >
> > > > Looking at one example of a Local MAC protocol (see
> > > >
> http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt),
> > > there is a protocol message
> > > that corresponds for every 802.11 MAC management event. So when a
> > > STA associates, the AP breaks the message apart and creates an new
> > > protocol PDU, which contains components found in the association
> > > request. I suspect that most Local MAC approaches do something very
> > > similar.
> > >
> > > So if a protocol simply tunnels the 802.11 MAC management frames
> > > from the WTP to the AC, it allows supports both approaches. For
> > > Local MAC, they get what they want via the 802.11 frame, and this
> > > also works fine for Split MAC, which needs access to the MAC
> > > management frame. What would be required in such a protocol is a way
> > > for the AP to communicate whether it will be providing very specific
> > > functions - basically a capabilities negotiation approach.
> > >
> > > So I do believe that there is a way to address both architectures
> > > using a single protocol.
> > >
> > > Thoughts?
> > >
> > > PatC
> > >
> > > _______________________________________________
> > > Capwap mailing list
> > > Capwap [at] frascone.com http://mail.frascone.com/mailman/listinfo/capwap
> > >
> > _______________________________________________
> > Capwap mailing list
> > Capwap [at] frascone.com http://mail.frascone.com/mailman/listinfo/capwap
> > _______________________________________________
> > Capwap mailing list
> > Capwap [at] frascone.com
> > http://mail.frascone.com/mailman/listinfo/capwap
>
>
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com http://mail.frascone.com/mailman/listinfo/capwap
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap
>