#opnfv-meeting: LSOAPI

Meeting summary

1. Continuation of discussion of scope for LSOAPI Phase 2 (KLuehrs, 16:04:18)
   1. Steve S presented options for MEF class of service and bandwidth profile to be considered whether in or out for LSOAPI phase 2 (KLuehrs, 16:05:58)
   2. Consensus for in-scope and out-of-scope features achieved during Sept. 24 meeting were reviewed. They are also listed on the LSOAPI meetings wiki page: https://wiki.opnfv.org/meetings/lsoapi (KLuehrs, 16:07:36)
   3. In addition to data frames, MEF allows CoS metrics to be applied to L2CP frames and SOAM frames. Choices: (1) map every L2CP frame through an EVC to a particular CoS level, or (2) map CoS on protocol-by-protocol basis. (KLuehrs, 16:11:48)
   4. Kerry - be careful with CoS. Factors e.g., distance which adds latency, impact whether CoS can be met. (KLuehrs, 16:16:57)
   5. Kerry, Jeff: We are applying CoS for L2CP per EVC. (KLuehrs, 16:18:48)
   6. John - for single CoS, we take customer-based L2CP at the level of service they bought for the EVC. (KLuehrs, 16:19:31)
   7. John: Pay attention to the tunnelling aspect of service delivery. Customer's L2CP, spanning tree, etc. - service provider tunnels these protocols through the service. Is it the customer L2CP or the service provider's L2CP? If the customer's then we tunnel through the EVC. (KLuehrs, 16:21:52)
   8. Steve: assume MEF defined the mapping options for customer L2CP. (KLuehrs, 16:22:48)
   9. Agreed: L2CP frames per EVC mapped to CoS name, for the EVC. (KLuehrs, 16:23:40)
   10. SOAM CoS: Per MEF 10.3 SOAM frame CoS ID to CoS name mapping must mirror data from CoS ID to CoS Name (KLuehrs, 16:24:36)
   11. No disagreement with this. Agreed (KLuehrs, 16:24:49)
   12. Question: at what granularity should Bandwidth Profiles be applied? BP refers to how frames are admitted to the network, versus CoS which refers to treatment of frames after they have been admitted. (KLuehrs, 16:25:50)
   13. Steve shared diagram illustrating Ingress Bandwidth Profiles (KLuehrs, 16:26:23)
   14. Choices (1) allow multiple bandwidth profiles per EVC, or (2) apply bandwidth profiles on an EVC basis (KLuehrs, 16:27:23)
   15. Second thing to think about with respect Bandwidth Profiles: Bandwidth Profile Flows per Envelope (KLuehrs, 16:29:41)
   16. Reference: MEF document 'Understanding MEF 6.2 Bandwidth Profiles' (KLuehrs, 16:30:43)
   17. If there are multiple flows within a single Bandwidth Profile, MEF allows tokens to be borrowed between flows, for those flows that are exceeding their Committed Information Rate. (KLuehrs, 16:32:15)
   18. Each Flow Profile defines a particular set of parameters: CIR, CBS, EIR, CF, etc (KLuehrs, 16:33:01)
   19. MEF Token Sharing feature describes how flows can share bandwidth through sharing of tokens. (KLuehrs, 16:35:30)
   20. Supporting multiple flows per envelope complicates information model, APIs, software (KLuehrs, 16:36:37)
   21. Decision: support single bandwidth flow or multiple bandwidth flows (KLuehrs, 16:36:59)
   22. Kerry, Jeff: At this early stage of virtualization there is value in just virtualizing basic service. Recommend staying with single flow for now. More sophisticated features, such as multiple flows per EVC, can be considered at a later phase. (KLuehrs, 16:39:03)
   23. Agree: support only one flow per profile (KLuehrs, 16:39:56)
   24. John: Does this refer to color-awareness? No, that's separate topic. MEF allows you to map frames with different priority codes to different bandwidth profiles. (KLuehrs, 16:40:54)
   25. Kerry: Do not see the need to support coloring, multiple flows per EVC. Stay with fundamental service, connecting two points for the initial phase. (KLuehrs, 16:43:15)
   26. Agreed: single bandwidth profile node per profile == no token sharing for LSOAPI Phase 2 (KLuehrs, 16:44:09)
   27. Decision: Support Frame Coloring? (KLuehrs, 16:44:40)
   28. When a frame makes it onto a service provider's network: Green means frame was admitted with tokens from CIR - no problems. Yellow means token was admitted with tokens from Excess Information Rate (EIR) bucket. Red means there are no CIR or EIR tokens left - traffic is exceeding the EIR. Red frames are never admitted. (KLuehrs, 16:46:51)
   29. Is support for frame coloring important? (KLuehrs, 16:47:08)
   30. John: This is a topic for debate within service providers. One view: can mark frame down if in excess but not above excess. Other view is to mark Discard Eligible bit. Although MEF defines marking down in multiple ways, their preference is to mark frame down to 'low' if it exceeds CIR but bandwidth is available. (KLuehrs, 16:49:27)
   31. Kerry: Sees value in frame coloring but does not see this as a requirement for this phase. Jeff agrees. (KLuehrs, 16:50:37)
   32. Consensus: support for frame coloring is not in scope for LSOAPI Phase 2 (KLuehrs, 16:52:01)
   33. Kerry: Re-iterated concern about how much can be taken on if we want to complete something in 4 - 6 months. Need to keep feature set simple initially. (KLuehrs, 16:56:03)
   34. Thanks to everyone for participation (KLuehrs, 16:56:14)

Action items

1. (none)

People present (lines said)

1. KLuehrs (38)
2. collabot (6)
3. Luehrs (0)
4. Kevin (0)