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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 18 Jan 2006 12:41:21 -0800

Saravanan,

In order to ensure that I am tracking all of the issues properly, could
you please be more specific in your change recommendations below? I do
have the field size one already, as this was in the eval draft.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Wednesday, December 14, 2005 11:08 PM
> To: Philip Rakity; [email-masked]
> Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP
> 
> Hi Philip,
> 
> You have clearly reviewed the draft in detail! I think the 
> points you raise are very important for the protocol. 
> 
> Perhaps some recommendations can be made based on the points 
> raised. I think it would be helpful for the WG to see how the 
> recommendations can fit in to the current LWAPP specifications. 
> 
> On a related note, I think the first WG version of the 
> protocol can also include those issues which were discussed 
> during the last meeting. There seemed to be some agreement in 
> the issues such as information elements field size, firmware 
> operations and local-MAC mode operations. 
> 
> Cheers,
> 
> Saravanan
> 
> 
> 
> 
> -----Original Message-----
> From: Philip Rakity [mailto:[email-masked]]
> Sent: Tuesday, December 13, 2005 5:35 AM
> To: [email-masked]
> Subject: [Capwap] Comments on Draft 3 -- LWAPP
> 
> 
> I am a newbie to the group and this the first time that I have read
> the internet draft.  I have a number of comments on the draft that
> are below.  Most a minor editorial things but some are areas I do not
> understand
> 
> a) Use of "integer" is not consistent in the document --- most of the
> time it means unsigned, sometimes signed (but marked as signed), but
> sometimes the phrase "unsigned integer" is used and this then makes
> me wonder if the fields marked integer are signed or not.
> 
> b) page 32 --  section 5.1 "Discovery requests MUST be sent by an ...
> AND when no echo responses are received and the WTP"    I think it
> should say that "Discovery requests MUST be sent by a WTP when the
> WTP returns to the idle state.   This can occur for example when no
> echo responses are received for NeibhborDeadInteval. "
> 
> c) Page 35 -- Radio Type --  no 802.11b (only) -- no 802.11n -- no
> superG -- no superA
> 
> 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 ?
> 
> e) Page 41 -- Section 6.1  Join Request  -- 3rd paragraph -- Why the
> 1596 MTU limit -- how was this number chosen ? == (RIF routes if
> vlan ?)  if I use 802.3 then I have seen h/w do 1522 (4 byte vlan
> tag) -- some number a little bigger than 1522 and h/w do 16K bytes --
> (intel ixp 4xx series) ---  The 16K number is bigger than the 4k SDU
> for wireless medium...  Would it be better to base the discovery on
> the MTU of the wireless media and work down ?
> 
> f) Page 52 -- Section 6.5 and Section 6.6 -- Change item that says
> see Figure 2 -- to read see section 2.2
> 
> g) Page 60 -- REboot Statistics == this requires the WTP maintain
> state to know if the last Failure Type was LWAPP initiated.   Same
> comment for Crash count.  No value defined for state not maintained
> by WTP.  Add cross reference to section where AC tells WTP to reboot.
> 
> 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.
> 
> 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.
> 
> j) Page 72 -- Section 8.5.1 Decryption Error Report   == add note
> about only useful if split mac.
> 
> k) Page 72 -- Section 8.5.2   Duplicate IP address == what is a
> host ?  Is this a mobile station ?  What about the case of a mobile
> station having the SAME mac address as a already connected mobile
> station to the WTP.  == only useful if NOT split mac
> 
> l) General comment -- there is no command to synchronize  time (set
> the clocks) in the WTP to a common time base
> 
> j) General comment -- why not use the text in the 802.11 MIB
> definitions and the name of the MIB entry where these are used to
> configure the WTP
> 
> k) Page 94 -- Section 11.3.1 -- WLAN's field -- just do NOT
> understand how setting a bit relates to the WLAN ID's used later in
> the document -- can you give an example or two ?  Only 16 WLAN ID's
> allowed ??/
> 
> l) Page 97 -- WLAN ID -- field is 8 bits -- other places in document
> 16 bits
> 
> m) Page 102 -- IEEE 802.11 stats -- Why not pad out Radio ID with 3
> bytes of "reserved field" so all other fields are 32 bit aligned or
> move it to the end of definition (after decryption errors).
> 
> n) Page 105 -- WLAN ID -- picture is 8 bits -- text is 16 bits
> 
> o) Page 109 WLAN Capability -- can you rename this and ALL other
> fields to use the same terms as the 802.11 base standard or the MIB
> (very confusing) -- or cross reference
> 
> p) Page 113 -- Country Code -- reference 802.11d since this is the
> definition
> 
> q) Page 113 -- Rate Set -- is length wrong ?  should be >= 2
> otherwise what is definition for rates NOT used
> 
> r) Page 115 -- RTS Threshold etc -- use wording from the MIB
> definitions for all of these entries and reference mib object
> 
> s) Page 119 -- IEEE Antenna length -- length sound be >= 5
> 
> t) Page 120 -- Supported rates -- length >= 2 and <= 9
> 
> u) Page 122 - WTP Qos -- length is 2 if untagged or 802.1p  -- if
> dscp it is 2 + (10)*dscp entries
> 
> v) Security -- any reason ssl could not be used even for level 2
> encryption?  since the link is PT to PT -- the ip address/header is
> not need -- then almost same code as layer 3 -- and the package is
> public domain so easy to hack
> 
> regards,
> 
> Philip
> 
> Philip Rakity
> [email-masked]
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 19 Jan 2006 09:09:31 +0800

Hi Pat,

I'll send the issues in separate notes. In general, they follow the
issues list from the last meeting.

Saravanan

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, January 19, 2006 4:41 AM
To: Saravanan Govindan; Philip Rakity; [email-masked]
Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP

Saravanan,

Pat Calhoun