16:00:19 <KLuehrs> #startmeeting LSOAPI
16:00:19 <collabot> Meeting started Thu Oct  1 16:00:19 2015 UTC.  The chair is KLuehrs. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:19 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:19 <collabot> The meeting name has been set to 'lsoapi'
16:00:26 <KLuehrs> #chair Kevin Luehrs
16:00:26 <collabot> Warning: Nick not in channel: Kevin
16:00:26 <collabot> Warning: Nick not in channel: Luehrs
16:00:26 <collabot> Current chairs: KLuehrs Kevin Luehrs
16:04:18 <KLuehrs> #topic Continuation of discussion of scope for LSOAPI Phase 2
16:05:58 <KLuehrs> #info Steve S presented options for MEF class of service and bandwidth profile to be considered whether in or out for LSOAPI phase 2
16:07:36 <KLuehrs> #info 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
16:11:48 <KLuehrs> #info 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.
16:16:57 <KLuehrs> #info Kerry - be careful with CoS. Factors e.g., distance which adds latency, impact whether CoS can be met.
16:18:48 <KLuehrs> #info Kerry, Jeff: We are applying CoS for L2CP per EVC.
16:19:31 <KLuehrs> #info John - for single CoS, we take customer-based L2CP at the level of service they bought for the EVC.
16:21:52 <KLuehrs> #info 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.
16:22:48 <KLuehrs> #info Steve: assume MEF defined the mapping options for customer L2CP.
16:23:40 <KLuehrs> #info Agreed: L2CP frames per EVC mapped to CoS name, for the EVC.
16:24:36 <KLuehrs> #info SOAM CoS: Per MEF 10.3 SOAM frame CoS ID to CoS name mapping must mirror data from CoS ID to CoS Name
16:24:49 <KLuehrs> #info No disagreement with this. Agreed
16:25:50 <KLuehrs> #info 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.
16:26:23 <KLuehrs> #info Steve shared diagram illustrating Ingress Bandwidth Profiles
16:27:23 <KLuehrs> #info Choices (1) allow multiple bandwidth profiles per EVC, or  (2) apply bandwidth profiles on an EVC basis
16:29:41 <KLuehrs> #info Second thing to think about with respect Bandwidth Profiles: Bandwidth Profile Flows per Envelope
16:30:43 <KLuehrs> #info Reference: MEF document 'Understanding MEF 6.2 Bandwidth Profiles'
16:32:15 <KLuehrs> #info 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.
16:33:01 <KLuehrs> #info Each Flow Profile defines a particular set of parameters: CIR, CBS, EIR, CF, etc
16:35:30 <KLuehrs> #info MEF Token Sharing feature describes how flows can share bandwidth through sharing of tokens.
16:36:37 <KLuehrs> #info Supporting multiple flows per envelope complicates information model, APIs, software
16:36:59 <KLuehrs> #info Decision: support single bandwidth flow or multiple bandwidth flows
16:39:03 <KLuehrs> #info 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.
16:39:56 <KLuehrs> #info Agree: support only one flow per profile
16:40:54 <KLuehrs> #info 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.
16:43:15 <KLuehrs> #info Kerry: Do not see the need to support coloring, multiple flows per EVC. Stay with fundamental service, connecting two points for the initial phase.
16:44:09 <KLuehrs> #info Agreed: single bandwidth profile node per profile == no token sharing for LSOAPI Phase 2
16:44:40 <KLuehrs> #info Decision: Support Frame Coloring?
16:46:51 <KLuehrs> #info 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.
16:47:08 <KLuehrs> #info Is support for frame coloring important?
16:49:27 <KLuehrs> #info 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.
16:50:37 <KLuehrs> #info Kerry: Sees value in frame coloring but does not see this as a requirement for this phase. Jeff agrees.
16:52:01 <KLuehrs> #info Consensus: support for frame coloring is not in scope for LSOAPI Phase 2
16:56:03 <KLuehrs> #info 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.
16:56:14 <KLuehrs> #info Thanks to everyone for participation
16:56:18 <KLuehrs> #endmeeting