16:01:22 #startmeeting LSOAPI 16:01:22 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:01:22 The meeting name has been set to 'lsoapi' 16:01:29 #chair KLuehrs 16:01:29 Current chairs: KLuehrs 16:01:40 #Topic Welcome 16:03:38 #info Randy Levensalor 16:03:58 #Topic Extension of project scope: MEF Class of Service and Bandwidth Profile requirements 16:07:38 #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 #info The core model needs to provide sufficient functionality while not over-scoping, in order to make rapid progress. 16:09:18 #info Mehmet reinforced the importance of maintaining consistency with MEF specifications. 16:11:33 #info LSOAPIs should be consistent with APIs developed by Metro Ethernet Forum Service Activation and Configuration (SCA) project 16:13:29 #info Steve S shared presentation 'LSOAPI Phase 2 - Scoping Considerations (Sept 23 2015) 16:14:24 #info Proposed: include MEF ELine/EVPL single operator and E-LAN single operator service in scope 16:15:04 #info Proposed: Out of scope service for now: E-Tree and Multi operator services 16:16:04 #info Mehmet agrees limiting scope to single operator service. Focus on ELine initially for this phase. 16:18:58 #info Mehmet does not have a strong preference on which ELine service (EPL or EVPL) to focus on first 16:23:39 #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 #info Proposed: Include in scope VLAN tagging support 16:25:30 #info Proposed: LAN packet priority tagging (PCP, DSCP) out of scope 16:25:58 #info Proposed: CoS and Bandwidth profile per PCP / DSCP out of scope 16:26:40 #info John C responded to say it's important to preserve priority tagging 16:27:01 #info Mehmet asked if this means we will not be able to provide Class of Service 16:29:18 #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 #info Steve S said if we don't support Priority Codes we can still support CoS per EVC. 16:31:47 #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 #info Mehmet: Agree CoS per EVC to start with 16:35:28 #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 #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 #info Steve S reviewed CoS requirements in MEF 10.3 specification: nine Class of Service attributes 16:38:58 #info For any of the CoS metrics, e.g., one-way frame delay, a set of performance parameters is defined. 16:42:49 #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 #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 #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 #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 #info Mehmet - Referring here to MEF certification. Certification test cases will validate adherence to the MEF specification 16:50:46 #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 #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 #info Steve S - next MEF parameter group is Bandwidth Profiles 16:55:05 #info Bandwidth Profiles define how to handle traffic entering and exiting the service provider's network 16:55:50 #info MEF specifications address Ingress Bandwidth Profiles in significant detail and spend less time on Egress Bandwidth Profiles 16:56:31 #info In MEF specifications Egress BP are optional. Should they be in scope? 16:57:51 #info John C - We should include Egress BP into scope if multiple profiles are to be supported. 16:58:36 #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 #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 #info Proposed: Token Sharing out of scope for now 17:00:55 #info Bill A - this does not become an issue until we go to multiple CoS (per EVC) 17:02:01 #info Does this apply to multiple UNIs per EVC? Refers to borrowing bandwidth between EVCs. 17:02:30 #info This is a complex problem to solve so can be deferred. 17:03:24 #info Continue EIR discussion next week 17:03:27 #endmeeting