Presentation #1) Jamal went through the intro/agenda slides Presentation #2) WG Status - Jamal Documents published! - Jamal wondered if we should celebrate by taking a moment of silence or applaud. Joel initiated applauds for Jamal. Loud cheering. - There are already minor typo errata detected * will be updating errata for the rfc - docs about to be completed - Applicability: Jamal to shepard the doc after the meeting - Implementation report: Joel to shepard - docs need to be completed: LFB library Whither Forces? - feedback is welcome - new AD coming in is Adrian Farrel - not much left to do for ForCES, LFB lib pending, CECE hopefully shutting down in 1 year. - any influencing work in Forces; if someone else wants to use Forces; might need to charter update with milestone (Ross); simply use it in other WG (Joel); work could be done elsewhere (Jamal) Presentation #3) Forces LFB Library Weiming Wang just updated the forces lib, new version, many updates based on feedback. Please refer to the slides. - changes: *added Overview - see slides *router functions - ip forwarding, address rersolution icmp; network mgmt, running routing protocol * Base types definition changes * Separated XML defs from Based LFB lib * question: is base type lib in this doc or separate doc (same doc) * LFB classes description * re-categorization of LFB groups * where core LFB will be performed in the XML lib so it can be defined discussion: Weiming thinks that the Core LFBs should be part of the LFBlib. There was disagreement from Joel and Jamal * port LFB: need to discuss if necessary to include POS or ATM port LFBs; Jamal: shouldn't need to define other media ports Joel: We should zone on at most one - Ethernet seems reasonable. Discussion: Jamal: if classifying v4 and v6, where it is needed for basic ipv4/6 forwarding?not clear Joel: include an example of a classifier so the implementers can build it, and to know how the tool works Jamal: QoS Control LFB: we need maybe a FIFO only; Joel: how much we trying to build; depending it could be a mess Joel: redirect could be visualized as a port attached to the protocol channel; a conceptual issue not an implementation issue - version 00 (4) * IPv4 unicast forwarding - processing path shown Discussion: Jamal - first attempt; there are varying implementations; some updating FIB, path will include next hop; others with separate FIB and NH tables. Joel: majority of implementations have a separate FIB/NH - so it is reasonable to go with that assumption to simplify things. Extra book keeping involved in FE logic in the first model - which seems a fair optimization (so that the majority dont get affected). - ARP Processing * if LFB need to use link layer; for metadata from Ether Encap Discussion: Joel: local delivery comes in - Jamal: it is missing; Joel: LPM may have to decide Weiming Q: ARP and IP Forwarding Processing, where the classifier should be; Ether Decap or Encap? - ICMP Processing Discussion: Jamal: Would it be both ICMPgeneration and consumption? Joel: Redirects will not be considered here; send it to CE and let it deal with it - Running Routing Protocol * packets are redirected from CE question: looking at the routing protocol process, if we need to define multicast processing? - Supporting Network Management - Need to discuss next work refinement - maybe we can decide LFB classes, what kind of classes we should define and put components in LFBs - should cut LFBs to make it efficient - should state what people collapse and need to do Discussion: - Martin Johnson - Are LFBs normative or informative? Weiming - they are normative - Joel- issue complicated - CE to work with FE; LFBs should be shared; need to standardize; but some can be informational; key goal is interoperability which cant be acheived if we dont standardize. --------------------- Presentation #4) Kentaro Ogawa CE CE Strawman discussion - new topic; feedback is needed * please look at the slides and comment * plan to publish an initial draft * desire is to have very minimal changes to ForCES protocol/architecture - Possibility of having a CE object LFB Discussion: Joel FE protocol already contain CE objects Joel: The problem statement is not clear Joel: thinks kentaro is trying to define Hot standby - yes we need direction in that area Jamal: CE Object LFB sounds reasonable if you use ForCES if a path is available - CE set discovery alternatives * discussed the ways a CE can discover other CEs - FE participation * reiterate what RFC 5810 says how an FE should participate with multi CEs - CE master election * tries to keep it simple - Challenges on CECE * Discusses various challenges that need to be resolved to get a working solution - solution: referencing update component * kentaro discusses several approaches (refer to slides) Discussion: Long - Joel didnt seem happy with the approaches. Discussion of possible "wrapper protocol". Kentaro to do some rethinking. - CECE association * backup CEs (slaves) associate to master CE. *ForCES liveliness detection in play via ForCES heartbeats Joel: CE should process whether the connecting one is another CE, not an FE weiming: thinks CECE association is not necessary Jamal: Forces is not complete if there is one CE; so something like this is needed. - CE Master Split Brain Joel: think the condition is real Overall: Kentaro needs to work on the feedback provided and resolve then publish a draft.