CAPWAP
meeting minutes – December 3rd, 2007
-----------
Minutes
taken by Dorothy Stanley
1.05pm Meeting
Called to order
Volunteers
for note taker – Dorothy Stanley volunteers
Volunteer for Jabber scribe – Mohamad Badra volunteers
Chairs report – Milestones
-Milestones
are out of date. Need to update.
Updated
milestones”
Hope to
have WGLC after this meeting
One month
between WGLC and submitting to IESG seems short.
Have had
large changes, need another last call.
WGLC for
Binding MIB – change to April 2008
WGLC for
Base protocol and 802.11 Binding to December 2007
To
IESG - January 2008
MIB to
IESG to June 2008. If we decide not to do the MIB, will remove milestones. Have
in the charter, and have drafts. Need to deal with them.
Discuss
milestones after the extent of changes is known.
Next
steps – move capwap specs to IESG – final WGLC in December 2007
Joint
WGLC with DHCP WG on dhcp draft – Dec 5-19
How to
manage 802.11 changes and updates from IEEE – additional discussion needed.
CAPWAP Editor’s report
Given by
Pat Calhoun
3
categories – issues in resolved state, pending and new
Issue 2 –
Potential Firmware Download Performance Issue – review of issue.
Windowing
of 1 means firmware may take a long time. Add text – agree, but won’t impact
service.
Lars
Egard (Transport AD) agrees with resolution.
Issue 4 –
Potential Middlebox Issues.
Lars –
Asking why working through middleboxes is required.
Pat –
there is a NAT considerations section, separate from transport considerations.
Issue had
to do with keep-alives, added to make sure that middlebox keeps state. We
picked 30
Seconds.
New document says to use 15 seconds, unless know about the deployment.
Option –
could go to 15 seconds, probably too aggressive for CAPWAP applcations.
Margaret
– Does anyone see need to go to 15 seconds? None given.
Issue 5 –
Proposed text for benefits of using UDP-Lite
Desire to
implement data plane handling in hardware. Agreement was made to make UDP-Lite
optional.
Some
folks arguing that should use zero for IPv6. In hallway discussion stage.
Took
minimum of 8 octets. Added new message elements to determine if there is
a middlebox – local IPv4 and local IPv6 addresses.
Issue 18
– CAPWAP and congestion control.
Added
text saying that applications have their own congestion control.
UDP
guidelines document defines cases – UDP as a tunneling protocol.
Is
consistent with solution here.
Puneet –
had modification to the last paragraph – there should be additional text, the
Change is
not included here.
Is sue 20
– Echo protocol
Actually
no need for te Netighbor Dead timer.
Issue 6 –
Handling of multiple priority streams over DTLS datapath was moved to the
drferred state
Issue 15
– Timer was undefined
Issue 16,
17, 21
Issue 3 –
MTU Discovery requirement
Rather
than recreating a mechanism in the protocol, add reference to RFc 1191, 1981.
Also,
there is a new mechanism, see RFC 48xx, reference will be added.
Added
text for dealing with errors. Removed MTU padding message element.
Lars –
agree with resolution. Close with addition of RFC reference.
Issue 19
– Issue with Image Data to Reset
Two
options for fixing were considered. Require the WTP reboot when it completes
the download, and let the AC clean its slate when expiry occurs.
Text
change is in draft 8, would like to close.
Issue 22
– Data Check has no timeout on AC
State
machine changes added – new state transition, timer,
No
objection to closing the issue.
Issue 23
– Entering Image Data has no timeout.
AC needs
a way to timeout if WTP never initiates the firmware download.
Clost the
issue
Issue 24
– CAPWAP Header alignment issue
Changed
length of the field.
Issue 25
– ChangeStatePending Timer clarification
Type –
change from “WTP” to “AC” more of an editorial change.
Only need
a week on the list.
Issue 27
– capwap-07 term
Clarify
the “integration function” is in WTP for one case.
Issue 28
– omissions in draft 08
Elements
30-49 are missing – will be added.
Issue 26
– Bidirectional data transfer.
Current
spec defines Data transfer Request messages to be sent by the WTP
To the
AC, a “push” mechanism. Asked for a “pull” mechanism.
Margaret:
Back in Feb – agreed to not accept new features.
Does
anyone want to advocate adding this new feature?
Pat –
Adding tools to allow troubleshooting is valuable. Is useful.
Margaret
– How much work is this?
Pat –
Don’t know, just came in Friday.
Hassnaa
Moustafa - Issue is really do we want to add new features. Troubleshooting
Is a new
use case. Is CAPWAP intended to be a general purpose protocol for
Scenarios
that use troubleshooting
David
Harrington – being proposed to remote troubleshooting. Already have a MIB.
Pat – MIB
is at the AC, not at the WTP. No way for AC to request the data today.
WTP
doesn’t run SNMP.
Dan R –
No model of management is provided. Why do we think this is needed.
Pat -
Have products that have this today; customers using this for troubleshooting
today.
Dan R– This is beyond the line that we drew last
February. The management
Model
needs to be understood. Not everything needs to be in the standard. Leave to
Vendor
implemementation.
Margaret
– Hold the bar and say “no new features”.
Chairs –
do a show of hands. Had decided “no new features’ in the past, need strong
consensus
to over-rule this. If no overwhelming
support, have chairs respond to the commenter
That at
this point, no new features are being incorporated, will be added to the
feature list.
Who wants
to add the feature: hesitating hum
Not open
the draft – clear hum.
Issue 29
– Vendor specific payloads
New issue
raised. Is this a bug or a feature. None of CAPWAP messages state that the VSP
is a permitted message element.
Add text
to every message saying that can be used in any message.
Dan –
other option is to delete the vendor specific element.
Margaret
– was assuming that it would be there.
Agree to
add the text.
Issue 30
– Inconsistent state tracking on Ac prior to DTLSEstablishment
Transitions
e and f.
Scott –
the purpose of the client cookie is to prevent this kind of DOS attack.
Provides
a measurable mechanism.
Charles:
When is the cookie sent?
Scott: in
the DTLS exchange, returned in order for state to be established.
No memory is allocated before this exchange.
Charles:
If the DOS against the DTLS handshake is minimal.
Say
“should not maintain state” – Charles and Scott agree. Add text to the security
considerations
Section
about this. No objection.
There are
2 different threads – listen thread looking at discovery requests, then
The state
machine for each WTP. Text makes this explicit, but doesn’t make the first
discovery
Piece
clear. Add text for this. Agreement.
Issue 31
– Peer Authorization is optional.
Pat –
suggestion is to make peer authorization mandatory.
Scott –
don’t want to give hints on how to “dumb-down” security.
Discussion:
various forms of ACL, Could have large ACL list, accept all, look at Cert,
Charles
and Scott to propose text to the list.
Send the
text to the list, then get the draft out, and then send out to last call (3
weeks).
Dorothy
S: Send both the binding and base specification documents to last call
together.
Margaret:
Agree.
Security
Threats draft - can send out at same time, or different.
Do we
need a full security review of the draft? There will be a section/lst call
review of the document by Joe Salowey, as part of IETF last call. Scott and
Charles will do a review in WGLC also.
Published
an updated versio in October, many editorial in nature, incorporated most
suggested changes.
Should
this draft be 802.11 specific – added the rationale for the reason that the
document
is focused on 802.11.
Many
clarification son AAA and 802.11 link security are out of scope.
Eliminated
duplicate scenarios.
Added
more language about trust relationships.
Changed
“channel bindings” to “cryptographic bindings” to eliminate conflicting terms
with other groups.
CAPWAP MIB – Shi Yang, David Perkins,
presentation by Shi Yang
Review of
MIB design general information, and review of the CAPWAP MIB.
Goal –
require a way to avoid reinventing the wheel for centralized architectures.
Re-use
current MOB standards and future extensions for the wireless binding.
Use
RFC1213 to bridge the MIBs from various SDOs.
Dan –
Very good, provides operational model. Note that if the MIB view
Is from
the AC, then need some description of the CAPWAP data.
How to
build the if table.
Dave
Harrington. Issue 26 was around adding a pull capability, in addition to the
existing push model.
Pat –
Agree with the structure. Have a difference between what CAPWAP supports and
What the
IEEE 802.11 MIB supports.
The
CAPWAP MIB function is independent of any specific wireless binding technology.
Provide
counters for WTP, radio reboot, etc.
Have to
prepare configuration at the AC side before WTPs connect to the AC.
Maintain
the mapping relationship between WTP+radio ID and ifIndex.
Define a
WTP Virtual Radio Interface
CAPWAP-DOT11-MIB
– reuse 802.11 defined MIB.
Radio and
Wireless ID dynamically create Wireless BSS interface.
Description
of MIB usage example (see slides).
Puneet:
Example of MIB usage ½ - Virtual RadioifIndex is part of the CAPWAP MIB space.
Sline 1/5
– is from the 802.11 MIB space. Can be any kind of wireless binding. Not
tightly coupled.
Virtual
Radio Index is in CAPWAP space. Wireless binding indicates the radio MIB to be
used.
Status:
(00) versio of CAPWAP MIB and 802.11 MOB were published in July 07.
Requesting
that these become formal working group documents. Chairs will ask the list
After the
new documents are posted.
Dan –
Documents look good.
Dave
Harrington – Is a MIB doctor. Worked with Richard to made sure that the
variables
Correctly
represented, follow RFC recommendations. From a MIB doctor perspective is very
good. Impression is that re-use of 802.11 MIB is excellent approach. Needs
review by CAPWAP WG.
Margaret:
Concern that the -01 version hasn’t been posted yet, seems premature to ask for
adoption
as a WG document.
Pat: Do
we even want the MIB?
Margaret
– Asked this at the last 2 meetings, agreement that a MIB was needed.
Dan –
Feel free to reconsider, but explain to me how you manage CAPWAP without a MIB.
Margaret
– Is anyone willing to review the MIB and send comments to the list – 3 people
say yes.
Dave –
How does the group want to manage CAPWAP. Don’t need to wait for the -01 to
wait for the decision on whether or not to decide on the approach. 6-7 people.
Margaret
– concern that enough people are interested in this as a working group item.
Chris –
Extensively use MIB to be able to manage networks. Need a MIB for CAPWAP.
Margaret
– 5-6 people think we should take the MIB on as a work item, zero people said
no.
Dan – as
an AD – add to your query on the list – ask for other approaches, other than
what is being proposed here.
Margaret
– get the draft -01 posted. Tell the list that we had this discussion, give
folks a month to
propose new approached for a MIB. Then make the decision on whether to adopt
this as a working group work item.
Dave
Harrington: David Perkins is a co-author has been unavailable to help Richard.
Richard
Needs
some help from a co-author. Needs better responsiveness from the WG members.
Believe
that this is a good solution/approach. Concern that it is taking forever to get
this done. Too slow, need to step up and get this done, and off the charter by
finishing the work.
Margaret
– ideally need someone with experience with writing the document, familiar with
the publication process. Volunteers –
please see the chairs. Also put the call on the list for this.
Talk to
David Perkins to see if he is available to help.
Dorothy
G; See no other comments, meeting is adjourned.