[09:01:40] --- shep has become available
[09:02:36] --- shep has left: Disconnected
[09:04:29] --- shep has become available
[09:17:23] --- bert has become available
[09:17:51] <bert> I am remote, shep are you in the meeting?
[09:20:12] <shep> yes, but I'm not fully up to speed on this BOF.
[09:20:22] <shep> ... and not fully paying attention.
[09:24:00] <bert> can you ask if anyone in the room is willing to report in the chatroom. Can ask it at the Mike.
[09:30:43] <shep> The chair asked someone to take notes, and mentioned someone else was also taking notes already, so there are two. But they apparently aren't doing jabber. Most of the jabber-using folk seem to be in the xmpp meeting next door.
[09:39:10] <shep> hi bert, this is dorothy gellert, one of the chars... I'll get pat calhooun or james kempt to get on chat to fill you in... I don't have jabber installed.
[09:41:18] <shep> bert--- I just showed my screen to dorothy, and she's going to make an announcement after this talk is over to try to get someone to take notes into here. Sorry I cannot do it.
[09:42:15] --- gih has become available
[09:42:19] <shep> She made an announcement.. we'll see if that gets anyone in.
[09:42:39] --- ekr has become available
[09:43:05] <gih> Dave Perkins: "discovery" in your context is configuration, not existence? yes?
[09:43:10] <gih> yes!
[09:43:49] <gih> Authentication and discovery: discovery prior to authentication may involve identifying one or a set of possible acs
[09:44:00] <gih> in arch2 this may be trivial
[09:44:23] <gih> mixed mode environments may select and associate with available acs by exchanging architecture types
[09:44:53] <bert> thanks Geoff for reporting
[09:44:55] <gih> discovery in this context also involves an AP <->AC cpability exchange
[09:45:06] <gih> non-real time service functions deferred to the AC
[09:45:31] <gih> manamget control traffic to be encapped over ethernet lan between AP and AC
[09:45:47] <gih> They may be MAC frames that are L3-encapsulated
[09:46:05] <gih> exustiong secure encap protocols that may use derived keys are candidates here
[09:46:21] <gih> provisioning: ACs to secure boot/runtime config to APs
[09:46:39] <gih> ACs to retrieve MAC/PHY layer status from APs
[09:47:02] <gih> config APs to send low level alarms to AC (as triggers)
[09:47:17] <gih> AC may control AP to AP forwarding
[09:47:31] <bert> who is presenting?
[09:47:46] <gih> indian name - didn't catch it
[09:47:55] <bert> ok thanks
[09:48:00] <gih> Distributed control - scaleability is a concern
[09:48:27] <gih> IAPP - a distributed control primitive with known security issues, but is best current practice
[09:48:46] <shep> I think the person presenting is Mahalingam Mani (one of the chairs of this BOF), but I'm not completely sure.
[09:48:47] <gih> James Kempf: is it a case that IEEE does not stdize protocols that involve IP? anyone know?
[09:49:15] <gih> Charles Perkins - they dont do IP level protocols, but they don;t shy away from using IP
[09:49:37] <gih> Jk: do they / would they consider / include IP protocols in a std vs a best current practice spec
[09:50:06] <gih> Dorothy Stanley: speaking for 802.11 a decision was that scope MAC and PHY
[09:50:16] <gih> DS: recommended practice is not MAC and PHY
[09:50:28] <gih> DS: definition of IP protocols is here in the IETF
[09:50:47] <gih> Charles Perkins: what are the shortcommings of distributed control / context transfers
[09:51:12] <gih> MM: shortcomings are related to timing constraints as part of a distributed control system
[09:51:18] <gih> CP: this seems to be debateable
[09:51:38] <gih> ?: IAPP is bcp becuase of a lack of agreement, not any other factor
[09:51:49] <gih> ?: dont know if 802.11 would shy away
[09:52:31] <gih> ? there were dioscoveries at the L2 and layer 7 with DHCP and what not - will this be part of the CAPWAP charter to clarification this issue of the layer of doscovery
[09:52:59] <gih> chair: we trying to focus on arhciteucre - we';ll list reqts and pick the protocol based on the arch spec and its requirements. we'll go into charter proposal now
[09:53:17] <gih> based on iesg concerns and the issues raised and contravery we'll look at arch and try to list reqts
[09:53:47] <gih> ?: repeat L2 / L3 question with "why is it here?" comment added
[09:53:51] --- Bob.Hinden has become available
[09:54:15] <gih> MM: l2 discovery may have to end up proceeding with L3 perhaps adding additional capability exchange
[09:54:42] <gih> MM; the process of seeking an AC needs only L2. If it is beyond this then you need L3 to do this
[09:55:31] <gih> ?: scaleability - there is a scaleability problem at the AC. All the APs within a domain are all controlled by one AC, and handoffs are in the domain of the AC - which means hat the AC is a point of scaleability
[09:55:49] <gih> ?: do we need to expand the scope to include AC to AC to address larger scaleability?
[09:55:58] --- Bill has become available
[09:56:01] <gih> ekr: do you intnend to do all of these architecture or pick one?
[09:56:16] <gih> MM: the goal is to get these architecture to interoperate to the extent that they can
[09:56:32] <gih> MM: there is a capability exchange to allow specific interactions
[09:56:41] <gih> ekr: group to design protocols to all this agenda?
[09:56:43] <gih> mm: yes
[09:56:50] <gih> ekr: thats a job!
[09:57:06] <gih> ?: are there 4 different alternatives or what?
[09:57:31] <gih> MM: thats a conclusion we'll get to when we finalize the arch work - no presuppositions of the protocol as yet.
[09:57:47] <ekr> In my view, just doing one of these protocols would be a pretty substantial job.
[09:57:53] <gih> MM: be able to negotiate the initial discovery phase to understand the other side's capabilities
[09:57:57] <ekr> just one of these architectures, rather...
[09:58:43] <gih> Chris Ritell: what you are doing here is odentifying services that can move and where - which services must remain togehter and where thewy can move to may be a lever here
[09:58:53] <gih> jk:not 'services' but 'functional entities'
[09:59:13] <gih> jk: derfine entities as ac / AP and functions distribution and integration
[09:59:38] <gih> jk: does not think the point is protocol and architecture and interoperability
[09:59:55] <gih> jk: thinks that there is a defn of functions and how they are mapped to different architectures
[10:00:29] <gih> ekr: on slide 3 of your presentation when you refer to arch2 - then you expect APs will be pushing the data to ACs using 802.11i security
[10:01:53] <gih> ekr: these scemnarios have 3 services: distributed management, distributed network / route config, data network and VPN services. They are distinct and they span 3 orders of magnitude of real time reqs. Theses are big tasks with multi-year IETF activity. This is a larger job than you may have anticpated - you need to scope this task in capwap down
[10:02:26] <gih> jk: yes you are right - this would take a while. The current plan is to define an architecture
[10:02:37] <gih> ekr: the current plan is to produce somne diagrams and a bunch of text?
[10:03:13] <gih> ?: we have refs to 802.11 and 802.11 mac splitting - is this central control target. Need to draw up 802.11 references. This may help with scoping
[10:03:46] <gih> Pat Calhon: arch-2 has been solved by IEEE 802 - this is not a lot of work - its already been fixed
[10:04:03] <gih> Gregopry l(?):" the companies have already built this and fixed it
[10:04:12] <gih> gl: this is a bit like ssl
[10:04:20] <gih> ekr: ssl took years
[10:04:32] <gih> gl: but its already out there and we just need to pick it up
[10:05:06] <gih> ekr: for me to design a protocol to do these things in a generic manner is not a specific implementation task - theres a lot of flap with many people in the game
[10:05:27] <gih> mm: is there a history of any ietf protocol that has had a good time?
[10:05:53] <gih> ?: there is quite a bit of interoperable vendor out there becuase AC and AP vendors have recognised need to interoperate in the market
[10:06:29] <gih> ?: interoperability has already been done - security and design may have been trade-offs in current activity
[10:07:02] <gih> jk: quickest ietf wg was 15 minutes. Nothing wroing with folk presenting complete / almost work to the IETF and asking ietf for review and stdization
[10:07:34] <gih> jk: the particular capwap charter is not to protocol design - its to enumerate some architecture and related requirements
[10:08:10] <gih> Hinden: I like when vendors do similar things they come to the IETF for a std - is that what is happening here - do vendors want a common protocol?
[10:08:51] <gih> chair: we've heard that message on the list - we hear ekr that its a big problem to do protoo design. Limit scope to tlook a tthe arhcitectrure and identify parts of the arch that we can do
[10:09:09] <gih> chair: shop around particular issues in IETF / or / ieee
[10:09:48] <gih> Bob Hinden: useful to understand if implementors really want this to happen. If the world is divided or resistant then we are a mess
[10:10:00] <gih> chair: poll for interest in this work? some hands (8 - 10) raised
[10:10:45] <gih> Liam Casey: as this has morphed to a charter discuss, as a vendor constraining the arch at this stage is important. I can say what my soln is and what other solns are and talk about it in common terms
[10:11:16] <gih> lc: argue in favour of arch work to have a framework to discuss multiple competing soluntions - hard to talk about these without a std architecture
[10:11:31] <gih> ?: should try to involve vendors - but not the only factor.
[10:12:37] <gih> ?: seeing a lot of 802.11 discussion - if you start fromt he functional areas, provisioning, discovery, management, then this is similar to other IETF work in place, like DHCP
[10:13:14] <gih> DIrac: Songwu Lu
[10:13:58] <gih> sl: share some experiencve from system and service experience
[10:14:20] <gih> sl: access router at the edge of the network between access controll and access point
[10:14:41] <gih> [see presentation]
[10:15:11] <gih> bert: do you want the presentation commentary logged?
[10:15:44] <bert> Since I may have to handle this BOF after today, the more info I can get the better
[10:16:04] <gih> new services: more link layer support -
[10:16:14] <gih> 1 - triggers for micro-mobility mgmt
[10:16:27] <gih> 2 - channel quality
[10:16:38] <gih> 3 - physical disconenction of clients (access control, firewals)
[10:17:04] <gih> sl: problem: difficult to implement wireless services and protocols on 'wired' routers
[10:17:31] --- ekr has left
[10:17:32] <gih> sl: insufficient - access points are a simple bridge and an access router is unaware of all wireless activity
[10:18:05] <gih> sl: wireless router goals: improve perf, expose link layer info and mechanics
[10:19:11] <gih> sl: design spectrum: one end - integrated approach to converty every AP ro an Ar AND COLLAPSE l@ AND l# -> INCREASED COST AND COMPLEXITY
[10:19:23] <gih> SL: EVERY AP BECOMG AN ACCESS ROUTER IS OVERLY COMPLEX
[10:19:32] <gih> sorry cxaps lockl
[10:19:57] <gih> sl: propose distributed router archicture with a router 'core" and multiple router 'agents" at each ap
[10:20:17] <gih> sl: agents expose ap L2 mechanisms and report l2 info
[10:20:26] <gih> sl: to the router core
[10:20:58] <gih> sl: define the core and agent interactions: 1) events - such as roaming hosts entering into an AP
[10:21:44] <gih> sl: 2) actions: accept / reject host association, authenticate, set retxmit count, etc
[10:22:37] <gih> 3) statistics reporting ; frame loss, SNR, latency etc
[10:23:13] <gih> sl: block model core design
[10:23:40] <gih> sl: internal modules in core implemented as exchange with APs
[10:23:55] <gih> sl: implemented as software on a PC
[10:24:09] <gih> sl: runs ipv6 proto
[10:24:43] <gih> sl: have defined a core / agent protocol, and an API, and a prototype wireless services
[10:25:06] <gih> sl: agent implemented on open AP platform with linux extentions, etc
[10:26:37] <gih> sl: systems overhead points to efficient stats report function, while event handling has high overhead
[10:26:50] <gih> sl: one pc router can support 50 - 100 APs acting as agents
[10:27:19] <gih> sl: services: handover, channel adaptive data forwaring, link-layer assisted policing
[10:27:38] <gih> sl: micro-mobility - adapted from v6 fast handover
[10:27:57] <gih> sl: handover in 400ms
[10:28:39] <gih> sl: head of line blocking problem in AP
[10:29:03] <gih> sl: implement channel aware forwarding
[10:29:30] <gih> sl: agent tells core of problem - core switches off retransmisison in agent
[10:30:31] <gih> sl: related work - click, scout, router plugins, XORP
[10:30:38] <gih> sl: mobiware toolkit
[10:30:45] <gih> sl: commercail solutions
[10:32:16] <gih> ?: have you considered route to route control (core to core)?
[10:32:25] <gih> sl: this is std internet router to router
[10:32:55] <gih> cp: I heard my name with fast handover - the draft is authored by Rajiv Kubley (sp?)
[10:33:13] <gih> cp: please compare your architecture with Mani's
[10:33:28] <gih> sl: a lot of similarities with manis
[10:33:38] <gih> sl: missing on my approach is security
[10:34:00] <gih> jk: I believe you did not define the data plane forwarding between agent and core
[10:34:25] <gih> sL: use a simple one
[10:34:42] <gih> jk: the mac or the router?
[10:34:47] <gih> jk: the router?
[10:34:52] --- Bill has left: Replaced by new connection
[10:34:56] <gih> sl: yes - the mac layer is terminated at the router
[10:35:12] <gih> jk: frames are tunnelled to the access router
[10:35:15] <gih> sl: y
[10:35:50] <gih> mm: the draft has (speakoing faster than ekr and not intelligle for me)
[10:36:22] <gih> tj knifeton: handover delays: can you explain the terms used int he table?
[10:36:26] --- Bill has become available
[10:36:55] <gih> tj: this is after the l2 handover is complete?
[10:36:57] <gih> sl: yes
[10:37:26] <gih> chair: Issues pack
[10:37:55] <gih> a) belong in the ietf?
[10:38:22] <gih> does not change ieee mac or phy - must be closely reviewed by the ieee, but this is ietf work
[10:38:30] <gih> dorothy is liaison fvrom ieee tot he ietf
[10:39:21] <gih> cp: ieee 802.11 spec is not just one spec. to say that capwap cannot require changes to mac or phy then does this extend to any sort of mandate to use a ieee tool?
[10:39:32] <gih> chair: no
[10:40:03] <gih> c: this has been discussd, and iesg suggested focus on 802.11 to get an architecture and direction for proto work and after that the consider extension to other protocols
[10:40:08] <gih> cp: qos?
[10:40:13] <gih> c: we have problems with this one
[10:40:22] <gih> dorothy sTANLEY:
[10:40:32] <gih> ds: fropm 802.11 there is a single doc - 802.11i
[10:40:41] <gih> ds: trhere are also amendments to that base spectr
[10:40:59] <gih> ds: these amendments are rolled back tot he base ewvery 3 years - a, b are beinbg roled in
[10:41:12] <gih> ds: alkl the other amendments will eventually be roleld into a single dodument
[10:41:24] <gih> ds: the work on security and qos are (currently) amendments to the base std
[10:41:37] <gih> c: issue 2 -are secure downloads in scope?
[10:41:50] <gih> c: we've agreed to take this out of the charter and use existing protocols as appropriate
[10:42:01] <gih> c: why re-invent discovery protocol
[10:42:13] <gih> c: recommend using exisitng discovery mechanisms at this stage
[10:42:33] <gih> c: is IP in capwap the reason to get it into the IETF?
[10:43:08] <gih> c: no we are tryting to scale the problem wioth smaller subnets and managing multiple AP management in an optimal way points to IP. L3 is seens as necessary for multi-ap mgmt
[10:43:11] --- shep has left
[10:43:19] <gih> c: why discuss protocol work int he charter?
[10:43:42] <gih> c: consensus to architecure and work now and recharter afteward
[10:43:51] <gih> c: get agreewment on functionality split
[10:44:04] <gih> c: teh archite document will address this iesg issue
[10:44:14] <gih> c: what about propietaryt 802.11 extensions
[10:44:26] <gih> c: not to include such extentions - ietf to work with the cmmon base
[10:44:52] <gih> c: this is about interoperability - we want to provide the oeprator with a way to manage multiple aps with this wg
[10:45:02] <gih> why is it an access router
[10:45:21] <gih> terminology - we could call is an 'access controller' instead - we'll do that
[10:45:34] <gih> c: is management a MIB issue - why use another mgmt protocol
[10:45:53] <gih> c: appreach is to work in the arch and the functionality split and decide after if SNMP is enough
[10:45:58] <gih> c: thats it. Other issues?
[10:46:07] <gih> mike q empty
[10:46:27] <gih> Dorothy to talk about ieee / ietf
[10:47:24] <gih> ds: slides
[10:47:45] <gih> ds: ieee 802.11 and ietf have an established set of processes for stds development
[10:48:00] <gih> ds: success of 802.11 wlan motivating capwap development
[10:48:19] <gih> ds: need for capwap and 802.11 to communicate
[10:48:57] <gih> ds: process to date - bob o'hara is 802.11's technical advisor to capwap
[10:49:18] <gih> ds: 802.11 to have a review process to review capwap documents
[10:49:25] <gih> ds: chair of 802.11 is supportive
[10:49:45] <gih> ds: call for volunteers - and will set up an 802.11 grou in place by 802.11 jan meeting
[10:50:01] <gih> ds: when capwap is ready for document review, 802.11 will be ready for doc review
[10:50:22] <gih> ds: 802.11 chair very supportive of working with ietf and other orgs on this work
[10:50:45] <gih> ds: request for a liaison fropm capwap to 802.11
[10:50:57] <gih> geoff; THIS IS AN IAB matter - berty can you tag this?
[10:51:15] <gih> GEOFF: sorry - fat finmger
[10:51:26] <gih> ds: 802.11 highlights
[10:51:32] <bert> yes I know that it is IAB matter.
[10:51:38] <bert> Maybe someone should say so at the mike
[10:51:58] <gih> geoff: can't do that and jabber - - BILL?
[10:52:09] <gih> 802.11i (security) tosponsor ballet
[10:52:17] <gih> 802.11we (qos) - recirculation
[10:52:28] <gih> 802.11k 0 radio resource measurements - continuing work
[10:52:37] <gih> ds: new potential study groups:
[10:52:55] <gih> mesh networks, wireless performance and prediction, public access issues, fast roaming
[10:53:18] <bert> checking with bill in other chatroom
[10:53:27] <gih> Geoff: thanks
[10:54:09] <gih> ds: mesh - stations ot stations to stations (ad hoc?) - likely to proceed
[10:55:06] <gih> ds: public access issue discussion NOT happeneing in 802.11 aT THE MOMENT
[10:55:13] <gih> DS: 802.11 MEETS EVERY 2 MONTHS
[10:56:34] <gih> mm: review procvess and liaison with 802.1
[10:56:53] <gih> CAPWAP charter discussion
[10:57:10] <gih> mm: summary of charter on the screen
[10:57:21] --- Bill has left: Logged out
[10:57:43] <gih> goals: clear prob stmt draft, security reqts and split AP architecture
[10:58:30] <gih> mm: any questions on these goals?
[10:58:35] <gih> mike q empty
[10:59:16] <gih> mm: non goals: general inter-subnet mobility, changes to mac layer, inter-AP commns (802.11f), joint dev of protocols with 802.11
[10:59:29] --- Bill has become available
[10:59:47] <gih> mike q empty
[11:00:08] <gih> mm: charter timeline - complete arch doc by Jul 04 and recharter by Spe 04
[11:00:50] <gih> ?: non goals - "general inter-subnet microbility" accepted - what about _specific_
[11:00:58] <gih> Pat: Not going to try and solve this problem here
[11:01:28] <gih> mm: charter questions: interest to work on this?
[11:01:52] <gih> 15 hands up out of 50 or so in the room
[11:02:47] <gih> suffcient user/ vendor interest?
[11:02:48] <bert> is the arch00 doc going to be the base to work from
[11:02:58] <gih> 12 hands
[11:03:08] <bert> user == operators?
[11:03:09] <Bill> bert: is "yes" a good or bad answer?
[11:03:10] <gih> sufficient info to justify prob statement work
[11:03:24] <gih> yes is good
[11:03:39] <bert> you mean to accept the work?
[11:04:03] <bert> or if arch00 is base doc to start from
[11:04:08] <gih> ?: difficulty to answer this - I feel that there is a need to work opn problem statement
[11:04:26] <gih> the question is: do we accept the draft problem statement, or work more on it?
[11:04:27] <bert> I have not read that draft yet... just wanted to know
[11:04:35] <gih> understood
[11:04:42] <gih> Pat: the problem statement needs a lot of work
[11:04:47] <bert> so we can ask to get a problem statement documented in an ID as well before we create WG
[11:04:59] <Bill> bert: ok, didn't know if you wanted us to push or just ask
[11:05:01] <gih> looks like thats what the room wants
[11:05:28] <gih> should the wg be formed with this charter?
[11:05:34] <bert> Ok so tell them to get a problem statement done that comes along with the charter proposal to the AD
[11:05:40] <gih> 25 hanrds out of 50
[11:05:46] <gih> whould we NOT form thewg?
[11:05:48] <gih> no hands
[11:05:54] <gih> Bill to mike
[11:06:12] <gih> bill channelling bert's message on jabber
[11:06:28] <bert> thanks. I need to drop out in a minute
[11:06:31] <gih> ok
[11:06:47] <bert> I will leave my jabber window open so I can see any more stuff later
[11:07:03] <gih> mm: implies the need to work on the prob statm and take it to the mailing list
[11:07:10] <gih> close
[11:07:15] <bert> yes!
[11:07:25] <bert> Thanks a bunch Geoff. This was really helpfull
[11:07:43] <Bob.Hinden> Yes, the jabber has been very useful here.
[11:07:54] --- Bob.Hinden has left
[11:08:49] <bert> I am away from my laptop now
[11:11:11] --- Bill has left: Disconnected
[11:16:30] --- gih has left
[15:31:16] --- bert has left