#opnfv-meeting: LSOAPI

Meeting started by KLuehrs at 16:01:22 UTC (full logs).

Meeting summary

  1. Welcome (KLuehrs, 16:01:40)
    1. Randy Levensalor (RandyLevensalor, 16:03:38)

  2. Extension of project scope: MEF Class of Service and Bandwidth Profile requirements (KLuehrs, 16:03:58)
    1. Steve S analyzed MEF Class of Service requirements and Bandwidth Profile requirements and proposed a limited set of attributes to define scope. (KLuehrs, 16:07:38)
    2. The core model needs to provide sufficient functionality while not over-scoping, in order to make rapid progress. (KLuehrs, 16:08:33)
    3. Mehmet reinforced the importance of maintaining consistency with MEF specifications. (KLuehrs, 16:09:18)
    4. LSOAPIs should be consistent with APIs developed by Metro Ethernet Forum Service Activation and Configuration (SCA) project (KLuehrs, 16:11:33)
    5. Steve S shared presentation 'LSOAPI Phase 2 - Scoping Considerations (Sept 23 2015) (KLuehrs, 16:13:29)
    6. Proposed: include MEF ELine/EVPL single operator and E-LAN single operator service in scope (KLuehrs, 16:14:24)
    7. Proposed: Out of scope service for now: E-Tree and Multi operator services (KLuehrs, 16:15:04)
    8. Mehmet agrees limiting scope to single operator service. Focus on ELine initially for this phase. (KLuehrs, 16:16:04)
    9. Mehmet does not have a strong preference on which ELine service (EPL or EVPL) to focus on first (KLuehrs, 16:18:58)
    10. 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. (KLuehrs, 16:23:39)
    11. Proposed: Include in scope VLAN tagging support (KLuehrs, 16:24:02)
    12. Proposed: LAN packet priority tagging (PCP, DSCP) out of scope (KLuehrs, 16:25:30)
    13. Proposed: CoS and Bandwidth profile per PCP / DSCP out of scope (KLuehrs, 16:25:58)
    14. John C responded to say it's important to preserve priority tagging (KLuehrs, 16:26:40)
    15. Mehmet asked if this means we will not be able to provide Class of Service (KLuehrs, 16:27:01)
    16. 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. (KLuehrs, 16:29:18)
    17. Steve S said if we don't support Priority Codes we can still support CoS per EVC. (KLuehrs, 16:29:52)
    18. 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). (KLuehrs, 16:31:47)
    19. Mehmet: Agree CoS per EVC to start with (KLuehrs, 16:33:29)
    20. 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. (KLuehrs, 16:35:28)
    21. 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. (KLuehrs, 16:36:25)
    22. Steve S reviewed CoS requirements in MEF 10.3 specification: nine Class of Service attributes (KLuehrs, 16:38:12)
    23. For any of the CoS metrics, e.g., one-way frame delay, a set of performance parameters is defined. (KLuehrs, 16:38:58)
    24. Do service providers need CoS Performance Parameters included in the API, or is it sufficient to include a simple value for each CoS metric? (KLuehrs, 16:42:49)
    25. 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? (KLuehrs, 16:43:47)
    26. 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, ... (KLuehrs, 16:45:52)
    27. 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. (KLuehrs, 16:48:28)
    28. Mehmet - Referring here to MEF certification. Certification test cases will validate adherence to the MEF specification (KLuehrs, 16:49:37)
    29. 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. (KLuehrs, 16:50:46)
    30. 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. (KLuehrs, 16:53:56)
    31. Steve S - next MEF parameter group is Bandwidth Profiles (KLuehrs, 16:54:26)
    32. Bandwidth Profiles define how to handle traffic entering and exiting the service provider's network (KLuehrs, 16:55:05)
    33. MEF specifications address Ingress Bandwidth Profiles in significant detail and spend less time on Egress Bandwidth Profiles (KLuehrs, 16:55:50)
    34. In MEF specifications Egress BP are optional. Should they be in scope? (KLuehrs, 16:56:31)
    35. John C - We should include Egress BP into scope if multiple profiles are to be supported. (KLuehrs, 16:57:51)
    36. Team participating in today's call agree it makes sense to keep multiple profile per EVC out of scope for Brahmaputra release (KLuehrs, 16:58:36)
    37. 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. (KLuehrs, 17:00:01)
    38. Proposed: Token Sharing out of scope for now (KLuehrs, 17:00:24)
    39. Bill A - this does not become an issue until we go to multiple CoS (per EVC) (KLuehrs, 17:00:55)
    40. Does this apply to multiple UNIs per EVC? Refers to borrowing bandwidth between EVCs. (KLuehrs, 17:02:01)
    41. This is a complex problem to solve so can be deferred. (KLuehrs, 17:02:30)
    42. Continue EIR discussion next week (KLuehrs, 17:03:24)


Meeting ended at 17:03:27 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. KLuehrs (47)
  2. collabot (4)
  3. RandyLevensalor (1)


Generated by MeetBot 0.1.4.