Minutes IETF97: l2sm
minutes-97-l2sm-00

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 <bill.wu@huawei.com>
              Adrian Farrel <adrian@olddog.co.uk>

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.