Lwapp Mailing List: RE: Another Way to Think about CAPWAP

[Dorothy.Gellert (Dorothy.Gellert]

Great discussion thread on SNMP.  keep in mind that we propose to initially 
limit the
charter to architecture development that will flush out requirements to help us 
decide the
protocol question.  

The Friday CAPWAP BOF is intended to gain consensus that there is a problem to 
fix and decide
if we can form a WG to solve it.

If you haven't looked at the updated charter, its at:  
http://www.frascone.com/capwap

Dorothy

> -----Original Message-----
> From: lwapp-admin [at] frascone.com [mailto:lwapp-admin [at] frascone.com]On
> Behalf Of ext James Kempf
> Sent: Thursday, November 13, 2003 12:22 PM
> To: Branislav Meandzija; LWAPP
> Subject: Re: [Lwapp] Another Way to Think about CAPWAP
> 
> 
> > > But it also shifts hosts from one access point to another to
> > > achieve load
> > > balancing. That's a routing-type function.
> > >
> >
> > Not really, as it is just a single hop (AP/Manager) transaction. The
> 
> That's why I said "routing-type" and not "routing". See Pat's 
> comments about
> L2TP in this regard.
> 
> > only distinguishing factor to typical monitoring and control is the
> > pseudo real-time nature of this particular AP management aspect.
> > I've seen SNMP used in pseudo real-time applications like switching
> > on failover.
> >
> 
> Sure. Protocols can be used for whatever people want. I've 
> seen people in
> 3GPP advocate using SIP for setting up HTTP sessions. The 
> point is, some
> protocols are specifically engineered for specific purposes. 
> And SNMP was
> not engineered for routing-type control functions, IMHO.
> 
> > So, considering that this function is tractable with traditional
> > monitoring and control and that all other functions are traditional
> > monitoring and control, I don't see any reason for a new 
> architecture
> > and protocol.
> >
> > That being said, given that SNMP is now on life-support 
> mode and that
> > NETCONF is in the making as a new configuration protocol, I 
> would suggest
> > separating the protocol aspect and the application aspect 
> of this, and
> > handling the protocol in the traditional IETF management 
> area, and the
> > application (i.e. the MIB or the equivalent) in LWAPP.
> >
> 
> Guess we just don't agree here.
> 
>             jak
> 
> _______________________________________________
> Lwapp mailing list
> Lwapp [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
>