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

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 26 December 2016 19:59 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8331294AD; Mon, 26 Dec 2016 11:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhV5srx7jMxk; Mon, 26 Dec 2016 11:59:25 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A5E1296EF; Mon, 26 Dec 2016 11:59:24 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uBQJxItR005541; Mon, 26 Dec 2016 19:59:18 GMT
Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uBQJxDbo005507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 26 Dec 2016 19:59:14 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Benoit Claise' <bclaise@cisco.com>, l2sm@ietf.org
References: <0d4501d24132$62ceb590$286c20b0$@olddog.co.uk> <5b6dbba2-d283-8c81-7aaa-152d05ebdb8c@cisco.com>
In-Reply-To: <5b6dbba2-d283-8c81-7aaa-152d05ebdb8c@cisco.com>
Date: Mon, 26 Dec 2016 19:59:15 -0000
Message-ID: <003001d25fb2$8a84ebb0$9f8ec310$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01D25FB2.8A88BC40"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKr5J3krbFM/YS1TonUwzHGXgh46QGU20fQn1r0KRA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22786.002
X-TM-AS-Result: No--23.828-10.0-31-10
X-imss-scan-details: No--23.828-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wpmug812qIbzdsM3mpA5g7JXPwnnY5XL5LQ/ qGZnrEeUYiQZDj0xMK0LAm2pIsyKt0d2G5hiQttMW7gz/Gbgpl4g0L4Xy2OHlbTrab10uqrnvL4 BuAuBsSnzYbug6chYNpbrFFwxb/fFehHR0rDYUtlgP1dNF1ow7R3vBjCQ8n+aRfmFzyKgHb7Akt gDJtZ0Ahuxq0/oHJphycSs9fVCfPRiqZR3e04StWgws6g0ewz2xBgaBynd2vm7qpOHKudqcwAit k7O303Nw4fpofXJzEm66rswlFLG/hBvv3WDz+O1qVdeuk7LerSdtHUoZpvleVfXgfL55invWXOj 3NIpqIr9I7SBHKlogDYA74Rvb6PfxxsF7SoDQIrcWo5Vvs8MQjTbofuc5kuvFJfW7wEu1kAGvzV mOA+OnSmYSq0UBiOoXPhLslnt+0sTY/HRCFabdKfXIl6Cf6Vr1fb4QERdWcDn0eNPmPPe5GmKT/ 2E8HDdZ953sefdXw3Y2grEqMmU0BJkI6WLdk0QsyNb+yeIRArSde/CNbaZJVIEge/2lT8Ar5cH6 L5+Gu/a5HpFN+Z3QaqXbbImsVMS7K35r0y1/56sDodw9yUkxq+LpFmmk3oAs/G/Xv+uK7907+2Q NMSDJFLEWNgJk5q7uOwi+0htYJFd/pNkIrEbEQArNgt5xpQYQrO4XR6BRQMVhrI1wflQjNkKUuy Iqarg+QeHvtsdEokcGy6+e6SNEsAQ0nRNv2K2FyqkfsPWu1ATbU1KYGoQp0iO8DX9hL7R6Tbrq1 sb9rbOwIq0vD8WyFQjKY/I2E1dVcszrzmwgFmeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMlezI0tDTMokcsQPR+jpDgPpY5twODUF6GOWcfOgA+pp+3BndfXUhXQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/EAunAuZ8DZ2AizxfaxI3Y3aI3nA>
Cc: l2sm-chairs@ietf.org
Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt
X-BeenThere: l2sm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <l2sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm>, <mailto:l2sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2sm/>
List-Post: <mailto:l2sm@ietf.org>
List-Help: <mailto:l2sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2sm>, <mailto:l2sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Dec 2016 19:59:28 -0000

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:bclaise@cisco.com] 
Sent: 22 December 2016 13:44
To: adrian@olddog.co.uk; l2sm@ietf.org; 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:
<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 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
L2sm@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm
.