Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 20 Jan 2006 11:19:38 -0800

> >>> d) Page 37 -- Section 5.2.4  WTP manager control IPV4 
> address -- do 
> >>> not understand the text --  is there only one ip address ?
> >> if so --
> >>> then the ip address is used to return the interface of 
> the AC.  If 
> >>> only one address -- how is load balancing done ?
> >>>
> >>> Suj> If the AC has more than one Interfaces open for the WTP to
> >>> join, it
> >>> specifies each of these ip address's with Individual TLV's,
> >>> - right, for single ip interface load balancing cannot be
> >> done ,(given
> >>> only one AC) the AC should return its own interface Ip address.
> >>
> >> So the problem is the ip address CAN repeat but this is 
> not reflected 
> >> in the definition of the length?
> > An AC would include one such message element per interface 
> it has. So 
> > the length is correct.
> 
> 
> Could you add a note that message element is repeated per 
> interface being sent to the WTP.
Issue tracker 12: Text modified to add:
    In the event that multiple such message elements are
    returned, the WTP is expected to perform load balancing across
    the multiple interfaces.

> 
> >
> >>>
> >>>
> >>> h) Page 65 -- Blacklist Entry's  -- This whole area is not good
> >>> from my
> >>> point of view.  When I configure a firewall I say what is allowed
> >>> (explicitly) and forbid everything else -- there is no way I can
> >>> give a
> >>> list of trusted stations and forbid everything else.  This
> >> makes live
> >>> very difficult.  There is room for a blacklist -- but an allowed
> >>> list is
> >>> also needed.
> >>>
> >>>
> >>> Suj> In my opinion blacklisting is to prevent any .11 mgt
> >> frames from
> >>> passing upto the AC for the current WTP-AC session.
> >>> - to blacklist one MAC address and allow others is more exact and
> >>> specific rather than knowing ALL those which are
> >>> Allowed, either way the one which is allowed will is kept
> >> the Radius,
> >>> you could put your 'allowed' list there !
> >>
> >> I think there is a use for BOTH cases.  in a secure 
> environment I do
> >> not want control frames from rogue AP's.
> >
> > Looks like we are still not in complete agreement on this 
> one. Typical
> > 802.11
> > Devices include an approved list (known as MAC Filter). It 
> is assumed
> > that this
> > function is provided w/o CAPWAP involvement, while a blacklist is
> > provided
> > by CAPWAP. If I understsand correct, you would like a replicated  
> > set of
> > messages
> > to serve as the permit list? Do others agree?
> 
> Yes -- My Point.  In a secure environment I want to say what is  
> allowed and forbid other things.
Need others to chime in. A MAC Filter, while typical for APs, is not
what I would consider secure.

> 
> >
> >>>
> >>>
> >>> i) Page 70 -- Image Data -- do not understand how this can work --
> >>> only
> >>> 2 fragments allowed -- no count of what is being sent etc
> >> -- no way to
> >>> detect packet loss ---  why not use data xfer mechanism of
> >> tftp ?  --
> >>> the blocks are numbered == etc BUT define a md5 hash of the whole
> >>> image
> >>> and give its length in the initial request.
> >>>
> >>> Suj> LWAPP has the in-band Image transfer mechanism, some
> >> protocols
> >>> use
> >>> what you have specified.
> >>>
> >>
> >> I do not understand how this can work as defined in the text.  I
> >> understand I could overlay it but it needs a definition.
> >
> > Could you help identify what needs a definition?
> 
> 
> I did not understand (and now do) how this mechanism works.  
> But I do  
> not understand how one knows the transfer is finished?
> 
> Is there also another end-case to know if the xfer is beginning ?
Philip and I have talked, and I believe that a small change to text
has resolved his comment. Issue tracker 31 has been created for this.
I have resolved this by adding the following text to the description of
the Image Data information element:
      If the last block was 1024 in length, an Image
      Data with a zero length payload is sent.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Philip Rakity <[email-masked]>
Date: Fri, 20 Jan 2006 11:36:31 -0800

I understand the LWAPP will no longer layer 2 transport.  Is there  
any reason why we should just not require MTU discovery and remove  
the option from the spec.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap