16:01:22 <KLuehrs> #startmeeting LSOAPI
16:01:22 <collabot> Meeting started Thu Sep 24 16:01:22 2015 UTC.  The chair is KLuehrs. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:22 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:22 <collabot> The meeting name has been set to 'lsoapi'
16:01:29 <KLuehrs> #chair KLuehrs
16:01:29 <collabot> Current chairs: KLuehrs
16:01:40 <KLuehrs> #Topic Welcome
16:03:38 <RandyLevensalor> #info Randy Levensalor
16:03:58 <KLuehrs> #Topic Extension of project scope: MEF Class of Service and Bandwidth Profile requirements
16:07:38 <KLuehrs> #info Steve S analyzed MEF Class of Service requirements and Bandwidth Profile requirements and proposed a limited set of attributes to define scope.
16:08:33 <KLuehrs> #info The core model needs to provide sufficient functionality while not over-scoping, in order to make rapid progress.
16:09:18 <KLuehrs> #info Mehmet reinforced the importance of maintaining consistency with MEF specifications.
16:11:33 <KLuehrs> #info LSOAPIs should be consistent with APIs developed by Metro Ethernet Forum Service Activation and Configuration (SCA) project
16:13:29 <KLuehrs> #info Steve S shared presentation 'LSOAPI Phase 2 - Scoping Considerations (Sept 23 2015)
16:14:24 <KLuehrs> #info Proposed: include MEF ELine/EVPL single operator and E-LAN single operator service in scope
16:15:04 <KLuehrs> #info Proposed: Out of scope service for now: E-Tree and Multi operator services
16:16:04 <KLuehrs> #info Mehmet agrees limiting scope to single operator service. Focus on ELine initially for this phase.
16:18:58 <KLuehrs> #info Mehmet does not have a strong preference on which ELine service (EPL or EVPL) to focus on first
16:23:39 <KLuehrs> #info Recommendation for scope of LSOAPI, for the Brahmaputra release timeframe, is limit to ELine service. Additionally some research is needed to understand how to merge/incorporate/interface with work done to define APIs defined by MEF SCA project to configure network elements between UNIs.
16:24:02 <KLuehrs> #info Proposed: Include in scope VLAN tagging support
16:25:30 <KLuehrs> #info Proposed: LAN packet priority tagging (PCP, DSCP) out of scope
16:25:58 <KLuehrs> #info Proposed: CoS and Bandwidth profile per PCP / DSCP out of scope
16:26:40 <KLuehrs> #info John C responded to say it's important to preserve priority tagging
16:27:01 <KLuehrs> #info Mehmet asked if this means we will not be able to provide Class of Service
16:29:18 <KLuehrs> #info Steve S responded it gets down to how much detail we include to provide CoS. MEF supports providing CoS to EVC as a whole (all traffic in EVC subjected to same CoS). Another option defined by MEF is application of different CoS within EVC based on Priority Tag. Scoping question for APIs is how granular we need to support priorities.
16:29:52 <KLuehrs> #info Steve S said if we don't support Priority Codes we can still support CoS per EVC.
16:31:47 <KLuehrs> #info John C - Charter Cable - Moving from single CoS per EVC to multiple CoS per EVC. Working toward CE 2.0 compliance. Want to be sure we do not preclude including in the information model and APIs multiple CoS per EVC (priority tag).
16:33:29 <KLuehrs> #info Mehmet: Agree CoS per EVC to start with
16:35:28 <KLuehrs> #info Bill Armstrong - Charter : couldn't we include all the priority codes in the API and model and simply map them to EVC, and use them as we need to later.
16:36:25 <KLuehrs> #info Steve S - It's not difficult to include the priority tags in the model. It sounds like there is interest among operators to include the priority tags.
16:38:12 <KLuehrs> #info Steve S reviewed CoS requirements in MEF 10.3 specification: nine Class of Service attributes
16:38:58 <KLuehrs> #info For any of the CoS metrics, e.g., one-way frame delay, a set of performance parameters is defined.
16:42:49 <KLuehrs> #info Do service providers need CoS Performance Parameters included in the API, or is it sufficient to include a simple value for each CoS metric?
16:43:47 <KLuehrs> #info Is it possible to define each CoS metric as a container, so that we can include a single 'aggregate' value for now, but potentially extend the table later?
16:45:52 <KLuehrs> #info Steve S: Choices include (1) create first container with single metric only for now, (2) create container for each metric and include all the performance parameters, ...
16:48:28 <KLuehrs> #info Ioakem S - How will the CoS attributes be validated? How will we know if API is implemented correctly? We will need a test bed with particular devices.
16:49:37 <KLuehrs> #info Mehmet - Referring here to MEF certification. Certification test cases will validate adherence to the MEF specification
16:50:46 <KLuehrs> #info LSOAPI project's job is to provide the means for the correct parameters to be passed. It will be the job of the application implementers to ensure the parameters are used appropriately.
16:53:56 <KLuehrs> #info Bill A - Don't see any reason why we can't model the CoS metrics and performance parameters. As long as they parameters are just pluggable values and not dependencies it should be reasonable to model them.
16:54:26 <KLuehrs> #info Steve S - next MEF parameter group is Bandwidth Profiles
16:55:05 <KLuehrs> #info Bandwidth Profiles define how to handle traffic entering and exiting the service provider's network
16:55:50 <KLuehrs> #info MEF specifications address Ingress Bandwidth Profiles in significant detail and spend less time on Egress Bandwidth Profiles
16:56:31 <KLuehrs> #info In MEF specifications Egress BP are optional. Should they be in scope?
16:57:51 <KLuehrs> #info John C - We should include Egress BP into scope if multiple profiles are to be supported.
16:58:36 <KLuehrs> #info Team participating in today's call agree it makes sense to keep multiple profile per EVC out of scope for Brahmaputra release
17:00:01 <KLuehrs> #info Steve S - Next MEF specification topic is Token Sharing. Steve provided brief explanation of token sharing. Single-flow processing is defined in MEF as a way to not need token sharing.
17:00:24 <KLuehrs> #info Proposed: Token Sharing out of scope for now
17:00:55 <KLuehrs> #info Bill A - this does not become an issue until we go to multiple CoS (per EVC)
17:02:01 <KLuehrs> #info Does this apply to multiple UNIs per EVC? Refers to borrowing bandwidth between EVCs.
17:02:30 <KLuehrs> #info This is a complex problem to solve so can be deferred.
17:03:24 <KLuehrs> #info Continue EIR discussion next week
17:03:27 <KLuehrs> #endmeeting