Layer Two VPN Service Model (L2SM) Working Group Charter: https://datatracker.ietf.org/wg/l2sm/charter/ Mailing List: https://www.ietf.org/mailman/listinfo/l2sm/ Jabber: l2sm@jabber.ietf.org Chairs: Qin Wu Adrian Farrel IETF-97 Meeting Thursday 17th November : 09.30-11.00 : Studio 2 1. Welcome and Administrivia Chairs [5 minutes : 5/90] Adrian: This is the first meeting of this working group. Please start to use the mailing list. We are instructed by our charter to coordinate with others: - inside IETF is BESS, PALS, NETMOD, NETCONF - outside IETF is MEF and anyone else doing similar or related work 2. Review of Charter Chairs [10 minutes : 15/90] Dean Bogdanovich: You're mainly focusing on L2VPN as a metro technology? Or are you also thinking about use cases inside data centers? Adrian: Any use of L2VPN where that L2VPN is being sold by an operator to a user. Dean B: So what about where they are using it by themselves internally? Adrian: That is, where the customer is the provider. Can you bring your customers into this discussion? Lucy Yong: Customers talk to "service providers" not to "network operators" Adrian: Mahesh is going to bring up this terminology point later. We need to get our language clear, but should not get hung up on it. We are concerned with the organisation that uses the service and the organisation that sells the service. Lucy Y: When you say the base model to cover multiple popular L2VPN types, is this saying that model can be implemented by these technologies, or is it saying that the customer needs to know? Adrian: I think mainly the former. That is, we want an abstract service model that is capable of being realised in these different ways and if one of these ways of realising the sevice demands additional information from the customer then that has to be in the model. Reza Rokui: What about optical L2 services mainly based on MPLS-TP? I want to make sure this model covers that as well. Adrian: This is not an exclusive list. Reza R: And do we cover PW and non-PW based services? Adrian: Generally hope that the customer can't tell the difference. Iftekhar: Does the charter intentionally exclude P2MP sevices such as E-Tree? Adrian: Nothing is intentionally left out with the intent of excluding. If you want to do a type of service, then it is in scope. But be careful about services that no-one is selling yet. Lucy Y: E-Tree is different from a multicast service. There are different communication rules between the root and the leafs. I think we should include E-Tree. Himanshu Shah: In the draft I found a lot of information that was device-specific. For example, up-MEP, down-MEP, layer 2 control protocol. Need to decide is this service model specific or is it specific to the device? Adrian: Two points: 1. It's work in progress. We just need to get it right. 2. Things like CE-PE connectivity do need to be specified. Dean B: I have a draft with Benoit in NETMOD that classifies YANG models into service models and device models. E.g., BESS works on device models to support what is done here. We cannot discuss business service model here and must limit to technical service models. Adrian: This is a cue to the next presentation. Lucy Y: I want to disagree with Dean. You are not rquiring the customer to understand what your device looks like. Dean B: They don't have to understand the device, they just have to decide which device technology they want to use. Adrian: Poll of the room... Who considers themselves a hardware vendor: c.50% Who considers themselves to be a software vendor: c.20% Who is a network operator / service provider: three hands shown 3. What is a Customer Service Model? Qin Wu [10 minutes : 25/90] [Clarification Slides. What a service model is not, and dispells some common misconceptions. Distinguish how the service is delivered from how the service ispresented to the customer.] >>Interrupt at slide 4 Mahesh Jethanandani: It may help to recognise that a "customer" orders a service from a "service provider" not necessarily from a "network operator". An operator can be an SP, but could be a separate entity. Lucy Y: The model is for the customer to use to order the service, not for the customer to order what the network is capable to do. Qin Wu: Covers both aspects. Operator can offer a service to customer. Customer also uses model to talk with operator. Not a single direction model. Dean B: Customer has own equipment and knows what it supports. Provider has equipments and knows what it supports. Have to find overlap. Need to understand what services can be provided for customer equipment and not force customer to have specific equipment. Reza R: I second that. Not intention to cover "normalised" model. It is better to call this "abstract". Iftekhar: This is really at the high level: abstract level. So why are we talking about the signaling protocol? Looks like we are exposing a lot of underlying technology. Adrian: Part of the service specification must include the characteristics of the connectivity (DP and CP) between customer equipment and operator equipment. Dean B: How to model Service Level Agreeement (SLA) I do not how to do that. Only service providers know. Himanshu: Iftekhar made my point. Keep in mind when we go through the model what is network-device specific and what is service specific. Lucy Y: I agree you have to agree wat customer traffic you are carrying (ATM, Ethernet), but you don't have to agree whether you do LDP- based or BGP-based realisation. >> Continues presentation >> Interrupt at slide 5 Dean B: You have your Service Orchestration talking to your Network Orchestration. How does billing / billing authorisation fit in? Adrian: Business models and Billing models are not in scope! I don't believe that could be standardised and each operator does it very differently. Mahesh: Agree, let's not try to model billing etc. We are a technology group so let's focus on the technology. Using technology terms like L2VPN is causing the confusion here when we talk about customer service model because that is technology specific. The service can be of any form. Adrian: Too late! This WG is chartered to do a L2VPN service model. If we want to change our charter to do something different, we have to go to the AD. The chairs have to drive delivery on the charter. Dean B: You cannot have the red arrow [on the slide] without business SLAs. This has to be mapped to technical service requirements and that is one layer down. Mahesh: We should recognize that L2VPN is only one of the services. Not the only one. Plus the customer order may not necessarily consist of a technology or protocol definition as part of the customer order. Benoit Claise: Don't want this WG to do too much. The MEF already working on SLA. This model can point to that. This model tries to be technology agnostic, but if there is some information needed from the customer then it should be in the model. >> Continues presentation >> Interrupt at slide 8 Dhruv Dhody: Can you give me e.g. of service delivery model? Qin Wu: Yes, in BESS there are three WG drafts (L2VPN network service model, L3VPN network service model, EVPN network servce model). Dhruv : Are those service models or service delivery models? Qin Wu: Service delivery models. That is why we clarify the term "Customer service model". Iftekhar: Disgaree. These are device models (speaking as coauthor of one of them). Reza R: One distinction we have to make is the service at the network layer and service at the node level. All these drafts you mentioned are services on a node. Dean B: An example: Customer says "connect A, B, and C with low- latency 10Mbps links in a mesh". That's a service customer wants to get from provider. This is what I call a business service model. Next step is to look at what the network supports in order to deliver that: this is what I call the technical service model. Then I translate it into the lower level device-specific models. Reza R: Exactly. But I think it is better to sort out the name. "Business service" or "abstract model" or "customer model". We're talking about the same thing but confusing ourselves with different names. Let's stick to one name. Dean B: But this is the wrong forum for that model because we don't have the service providers wh can tell us what are the SLAs. Benoit: We have to spend time on terminology, then we can move forward. This key I-D is worked on in OPSAWG. Dean B: Then we lose 1/3 of operators in the room [someone left] Adrian: I am not surprised if we lose operators. Its not our business to tell operators ho to use yang models, we should listen to them. Lucy Y: What is the difference between customer service model and technical service model, what are we working on? Dean B: When we clarify this, then I can make a decision to work on this. Lucy Y: How do we get clarification? Adrian (getting more cross than he should do): The way you clarify is to listen to the Chair as he attempts to present the clarification slides he has been trying to talk about for the last 20 minutes. >> Continues presentation 4. Update from the MEF Mahesh Jethanandani [10 minutes : 35/90] Mahesh: Trying to level-set and avoid firestorms [Slide 3 correction: Next MEF meeting is 23-26 Jan 2017] >> interrupt at slide 5 Dean B: Can you explain where the customer order is decomposed? Mahesh: It is the role of the service orchestrator to decompose the customer order into service provisioning activities Dean B: So in this case it is between the Service Orchestrator and the Infrastructure Control and Management that the L2SM model would be applied? Mahesh: That's where I would envision it to be applied, yes. Dean B: Seems to be different from what Qin said. Adrian: Repeating Benoit, the comparison of the customer service concept and the LSO architecture is sitting in the OPSAWG (not adopted) draft. It would be good to have the discussion in the context of that ad then apply it here. 5. Overview of draft-wen-l2sm-l2vpn-service-model Giuseppe Fioccola [30 minutes : 65/90 Mahesh: SLA definition. MEF has defined SLA model that the customer can request as part of the service. If it meets your requirements you can use it and don't have to repeat that work. Reza R: Wrt usecase #2. When customer orders the mutli-provider service what do they ask for? What is inside the provider should be more or less a black box. When they order this service they don't know whether there is ENNI or not. Your figure is not the abstract model: it is the so-called vendor-agnostic or normlised model. Giuseppe: It depends. It depends on the businsess model we are talking about. Reza R: You are saying that in some cases customers should know about that ENNI and when they put the order they specify that ENNI. Giuseppe: In some cases the customer may know about ENNI Reza R: About the service ID that you put in the YANG model: why is there a service ID? We order only one service. Why list of mutliple services? Giuseppe: One customer could have more services. Reza R: Don't you think the YANG model should have only one service, but there are different instances of that service or that model instead of putting the service ID inside the YANG model. For example, customer orders VLL and VPLS at the same time: I prefer to have [seperate instances of] the YANG model for VLL and one for VPLS although the customer is the same and there is no correlation between those two services. When I saw the YANG model I thought these two services are related which is not the case. And last point: Mahesh mentioned using MEF as much as possible. I agree with that. For example, UNI definition in this model should be what is already defined in MEF. Just reference it Giuseppe: Yes, of course. Mahesh: If you break this down between what is a service provider and what is an operator: a service provider can traverse operator boundaries to offer a service end-to-end so the customer does not need to specify ENNIs or multiple service IDs. It is the service provider's job to divide that service out to multiple operators and say "You will provide this part of the service from this point to this ENNI" and the other operator is going to pick this up from that point and deliver it to the end. unless you make that disctinction you will ave this confusion. Himanshu: When you go through this draft, mae sure what is device- specific and what is service specific. I see a lot of device- specific in this. Of course, this first draft and that is OK. Adrian: So thanks for volunteering to write an email to the list pointing out those objects. 6. Discussion of next steps Everyone [25 minutes : 90/90] Adrian: The WG needs a document to work on. Is this draft one that we feel could be picked up and worked on and made how we want it to be? If you think we should adopt this document and work on it hum now: moderate hum. If you think it is not ready or would be a bad idea, please hum now: silence.