Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt

From: "[email-masked]" <[email-masked]>
Date: Tue, 3 Jan 2017 22:34:04 +0800

Hi, Adrian,

Firstly, thank you for writing the long mail to illustrate of the status of the l2sm. 
Secondly, I support this draft can be adopted as early as possible. China Telecom is one of the operators who offer L2VPN service, in most cases, in joint with foreign operators. The service model like L2SM will make the service provisioning more flexible and quicker.

Thank you!
Chongfeng  
 
From: Adrian Farrel
Date: 2016-12-27 03:59
To: 'Benoit Claise'; [email-masked]
CC: l2sm-chairs
Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt
Hi all,
 
Thanks Benoit for your email and clarifications. Here is my take on where we are and what needs to happen.
 
[tl;dr -- Adoption poll remains open; please review and comment; authors continue work]
 
I think we didn't get enough momentum or support for adoption of this document.
 
At the moment I can't tell whether this resulted from no one caring or from people refraining from commenting after the very strong opposition expressed by David.
 
Having read and re-read David's email I believe he expresses clearly why he thinks the current draft is not suitable for adoption, and offers two suggestions for alternative approaches, but he neither points at not volunteers for work to support those alternatives.
 
Therefore, it seems to me that we still only have one draft on the table. We can either work with that draft or give up. I think it would be unfortunate to abandon the working group when we have a number of operators who believe it is a good idea and who have put in a lot of effort. So I would like to see us move forward with what we have and adapt it as necessary. To do that, however, I think the chairs need to hear more voices in support.
 
I do, however, want to revisit some of the points made in Seoul and by David:
 
1. This document should not include protocol-specific details.
It is my view that when a PE-mode VPN is being discussed the service offered includes the CE-PE link (access circuit) and the technology details of that link must be represented in the service model.
Clearly when the service is a CE-mode VPN those details don't apply.
In Seoul, we received an offer to go through the current document and flag the protocol parameters that are a concern. I hope that this can be done so that those of us who don't think there is a problem can better understand what the concern is.
 
2. We should not redevelop work already done by the MEF
I could not agree more, and it seems that the authors of the draft in hand have adopted a similar philosophy intending to point at (or provide containers for) at least QoS, SLA, and billing models developed by the MEF.
On the other hand, attempts to map this service modelling approach into the MEF LSO architecture have not been entirely successful (with lots of differing opinions and some suggestions that parts of multiple LSO reference points are captured in this model). That suggests to me that what is going on in L2SM is closer to a parallel with L3SM than a duplication of MEF work. It may be a different approach or a different thing.
 
As Benoit said in Seoul (quoting from the minutes) and applying to both of these points:
>   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.
 
Bottom line:
 
- The authors of draft-wen-l2sm-l2vpn-service-model-03.txt should
   continue their work. 
   - Address specific issues raised in Seoul
   - Revisit all protocol-specific parameters to be sure they are needed
   - Adding examples in Section 7 would be most helpful to aid others to 
     see how the model is used
   - Make clearer and more explicit references to use of existing or in-
      progress MEF work.
 
- The working group should again look at this document and say whether
   it is currently something that we can use for a starting point for our work.
   I would particularly like to hear from network operators (service providers)
   who offer L2VPN services, and from consumers (such as enterprises) who
   purchase such services. As the chairs said in Seoul, this work really needs to
   be led by the operators and not dominated by the vendors.
 
Thanks,
Adrian
 
From: Benoit Claise [mailto:[email-masked]] 
Sent: 22 December 2016 13:44
To: [email-masked]; [email-masked]; Scott Mansfield
Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt
 
Dear all,

A couple of reflections on L2SM, just before the end of year break.

First, I want to quote one chairs slides https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-chairs-slides-01.pdf: 
We really need this to be driven by Operators
    - Of course, vendors can and should participate
    - But be aware of how the data model is use   
I'm always baffled when vendors 'seem to) know better than the operators what they need. I don't believe we have spent enough time listening to the few operators in the room during the WG meeting. 
We have here a group of operators who want to do work in the IETF, and we should respect that.

Second, on the differences between IETF and MEF service management.
MEF wants to go for the full LSO architecture (billing, SLA, order management, etc.). Perfect.
L2SM charter wants to do something similar to L3SM: a self-contained service YANG module.
It would be nice to try to fit the L2SM service models in the MEF LSO architecture, but the L2SM work follows a different architectural model to LSO, and that there is no value in trying to match the functions across model at all costs. This should not invalidate either approach, only observe that they are different.

Third, exactly like the L3SM draft, the L2SM draft includes a number of technology-specific parameters and these have caused people to claim that the I-D must be describing a normalised or configuration model. But (of course?) the parameters are needed to configure the CE-PE access connections. This is a suitable point of differentiation between MEF and L2SM that MEF has worked on CE-based models while L2SM will work on PE-based models. Indeed, the IETF works on the networking aspects. However, when a building is done somewhere else (typical example, SLA management done in MEF), this L2SM YANG module should only contain a place holder or a pointer.

Fourth. Discussing those very topics live with Scott Mansfield (our MEF - IETF liaison manager) during a workshop recently, we agree that both IETF and MEF service models have a place. While we start to see some consolidation in terms of YANG modules for device management, we are only at the beginning of YANG service modules. 

I hope this is useful and that it clarifies the situation.

Regards, Benoit
Hi, Our charter mandates that we consider basing our work ondraft-wen-l2sm-l2vpn-service-model-03.txt As we discussed in the meeting, that draft is not perfect. But when I asked theroom whether we thought that it would provide a good starting point that wecould work with to polish and adapt to become the I-D that we ultimately submitfor publication as an RFC, I believe I heard a good hum in favour and silence inopposition. So this email starts a formal poll for adoption. Please answer: Do you think that the WG should adopt draft-wen-l2sm-l2vpn-service-model-03.txt? If "yes," it would help if you could indicate whether you have read the draftand how happy you are with it.If "no", it is important that you provide reasons. This poll will last for two weeks, ending on Saturday 3rd December. Just to reassure everyone that adoption does not imply that anything is set instone: we expect the WG to continue to develop the content and change whateverneeds to be changed. Thanks,Adrian and Qin _______________________________________________L2sm mailing [email-masked]://www.ietf.org/mailman/listinfo/l2sm.

---

From: Scott Mansfield <[email-masked]>
Date: Tue, 3 Jan 2017 19:19:18 +0000

I agree with Benoit.  There are many dimensions to the modeling space and we can't let the perfect be the enemy of the good.  Constant communication and sharing will help alignment while allowing the people that actually run networks to get what they need.  30+ years of object-oriented software development (should have) taught all designers/architects/programmers that the first iteration of a solution is not the best and most optimized.  Each iteration provides the opportunity to abstract, refine, refactor, and extend.  Proper information hiding and encapsulation is key.  Automation is very important and we need to work together to ensure that whatever models that are created are supported by tools that allow for effective reuse and extensions.

Regards,
-scott.

From: Benoit Claise [mailto:[email-masked]]
Sent: Thursday, December 22, 2016 8:44 AM
To: [email-masked]; [email-masked]; Scott Mansfield <[email-masked]>
Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt

Dear all,

First, I want to quote one chairs slides https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-chairs-slides-01.pdf:<https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-chairs-slides-01.pdf>

Regards, Benoit

Hi,

Our charter mandates that we consider basing our work on

draft-wen-l2sm-l2vpn-service-model-03.txt

As we discussed in the meeting, that draft is not perfect. But when I asked the

room whether we thought that it would provide a good starting point that we

could work with to polish and adapt to become the I-D that we ultimately submit

for publication as an RFC, I believe I heard a good hum in favour and silence in

opposition.

So this email starts a formal poll for adoption. Please answer:

Do you think that the WG should adopt draft-wen-l2sm-l2vpn-service-model-03.txt?

If "yes," it would help if you could indicate whether you have read the draft

and how happy you are with it.

If "no", it is important that you provide reasons.

This poll will last for two weeks, ending on Saturday 3rd December.

Just to reassure everyone that adoption does not imply that anything is set in

stone: we expect the WG to continue to develop the content and change whatever

needs to be changed.

Thanks,

Adrian and Qin

_______________________________________________

L2sm mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/l2sm

.

---

From: David Ball <[email-masked]>
Date: Wed, 4 Jan 2017 10:14:18 +0000

Hi Scott,

I agree; but what is being proposed is not iteration, reuse and 
extension, which you rightly extol.  It is instead ignoring all the work 
that has gone before (not just the MEF yang models, but the 10+ years of 
work MEF has done in defining Carrier Ethernet services).

Benoit, to answer your points:

  * You are correct that MEF has a grand vision for the LSO
    architecture; time will tell whether that is achievable. However,
    the one small part of it that they are furthest progressed with is
    exactly the same area that is covered by L2SM.  I don't understand
    why you think L2SM is following a different architecture; in both
    cases what we are talking about is a model for the set of things
    that need to be agreed between the SP and the customer, right?
  * I can't speak for anyone else, but my criticism regarding the
    inclusion of "technology-specific parameters", as you put it, is not
    in respect of the PE-CE links.  I agree the technology details are
    needed there.  However, the draft also includes a lot of details
    about the technology used within the SP's network (i.e., PE-PE) -
    that is the detail which I think is not relevant and does not belong
    in a service model.
  * I do not understand what you mean when you say the MEF has worked on
    CE-based models.  A service model is not used between the CE and PE,
    it is used between the customer's management systems (as the client)
    and the SP's management systems (as the server).  There are
    differences in terminology for those systems, but fundamentally I
    don't see any difference between MEF and IETF approach here.  Can
    you clarify what you meant?

Benoit, you mentioned that, as vendors, we should listen more to 
operators.  I agree.  I would love to hear from the operators who 
support adoption of this draft what issues they see with the MEF models, 
and why they believe that starting again from scratch in IETF is a 
better option than working with MEF to improve on what they have already 
done, and then augmenting ("extending") it to fill in any gaps.  The MEF 
models are certainly far from perfect (and of course they are still WIP 
in MEF), but what I would like to understand is why you, as operators, 
think they are not a good starting point for solving the problems that 
led to the creation of this WG.

     David

On 03/01/2017 19:19, Scott Mansfield wrote:
>
> I agree with Benoit.  There are many dimensions to the modeling space 
> and we can’t let the perfect be the enemy of the good.  Constant 
> communication and sharing will help alignment while allowing the 
> people that actually run networks to get what they need.  30+ years of 
> object-oriented software development (should have) taught all 
> designers/architects/programmers that the first iteration of a 
> solution is not the best and most optimized. Each iteration provides 
> the opportunity to abstract, refine, refactor, and extend.  Proper 
> information hiding and encapsulation is key.  Automation is very 
> important and we need to work together to ensure that whatever models 
> that are created are supported by tools that allow for effective reuse 
> and extensions.
>
> Regards,
>
> -scott.
>
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* Thursday, December 22, 2016 8:44 AM
> *To:* [email-masked]; [email-masked]; Scott Mansfield 
> <[email-masked]>
> *Subject:* Re: [L2sm] Adoption poll for 
> First, I want to quote one chairs slides 
> https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-chairs-slides-01.pdf: 
> <https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-chairs-slides-01.pdf> 
>
>
> I'm always baffled when vendors 'seem to) know better than the 
> operators what they need. I don't believe we have spent enough time 
> listening to the few operators in the room during the WG meeting.
> It would be nice to try to fit the L2SM service models in the MEF LSO 
> architecture, but the L2SM work follows a different architectural 
> model to LSO, and that there is no value in trying to match the 
> functions across model at all costs. This should not invalidate either 
> approach, only observe that they are different.
>
> Third, exactly like the L3SM draft, the L2SM draft includes a number 
> of technology-specific parameters and these have caused people to 
> claim that the I-D must be describing a normalised or configuration 
> model. But (of course?) the parameters are needed to configure the 
> CE-PE access connections. This is a suitable point of differentiation 
> between MEF and L2SM that MEF has worked on CE-based models while L2SM 
> will work on PE-based models. Indeed, the IETF works on the networking 
> aspects. However, when a building is done somewhere else (typical 
> example, SLA management done in MEF), this L2SM YANG module should 
> only contain a place holder or a pointer.
>
> Fourth. Discussing those very topics live with Scott Mansfield (our 
> MEF - IETF liaison manager) during a workshop recently, we agree that 
> both IETF and MEF service models have a place. While we start to see 
> some consolidation in terms of YANG modules for device management, we 
> are only at the beginning of YANG service modules.
>
>     [email-masked] <mailto:[email-masked]>
>
> [email-masked]

-- 
David Ball
<[email-masked]>

---

From: "Wen, Bin" <[email-masked]>
Date: Fri, 13 Jan 2017 03:58:04 +0000

I support the adoption of this draft. From operator perspective, it¹s
important to decouple customer service model from the actual service
delivery method. 

The current draft needs to be updated. However, it¹s a good

On 11/17/16, 7:26 PM, "L2sm on behalf of Adrian Farrel"
<[email-masked] on behalf of [email-masked]> wrote:

>Do you think that the WG should adopt
>draft-wen-l2sm-l2vpn-service-model-03.txt?
>