Re: [L3sm] New Liaison Statement, "Liaison from MEF on IP Service Attributes"

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 26 February 2016 20:02 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191AD1B2F64 for <l3sm@ietfa.amsl.com>; Fri, 26 Feb 2016 12:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level:
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
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 sCM4N2swShmG for <l3sm@ietfa.amsl.com>; Fri, 26 Feb 2016 12:02:20 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4491B2F69 for <l3sm@ietf.org>; Fri, 26 Feb 2016 12:02:10 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u1QK28nx004871 for <l3sm@ietf.org>; Fri, 26 Feb 2016 20:02:08 GMT
Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u1QK27Pj004844 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <l3sm@ietf.org>; Fri, 26 Feb 2016 20:02:08 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: l3sm@ietf.org
References: <20160226180541.18278.30437.idtracker@ietfa.amsl.com>
In-Reply-To: <20160226180541.18278.30437.idtracker@ietfa.amsl.com>
Date: Fri, 26 Feb 2016 20:02:07 -0000
Message-ID: <01e301d170d0$929a0190$b7ce04b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDut+wpCEdv+aFuSgD94NBIxfmeU6EELnpQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22158.001
X-TM-AS-Result: No--27.583-10.0-31-10
X-imss-scan-details: No--27.583-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtHvkBiM1eNiXlu4M/xm4KZe9mnDjfUPq55kljqvtoNIdjzW aLWbt415dCQVIAR6sWaTz9wa1hxOtEdvGfWAnllX6/xAZojbl7e+8YVU8r+aqC6PLFEfB74c7nP 5+9Z3Og1rrAT5G0XZxPFPDHhQkgxydJXLWwFEzTr7PZziWKg+SFNDrIPosXvFAIZpxx3hp71Btb hSKQOLQiJ6Ql5Qk9DPsfJ5vKZeu+glr4UAbUFME/45MImNrSZy+KgiyLtJrSBUvRK1+R1DYi9TC OyVuKCIL1NpBYi6UhlJHUy0oWekE2hfZ0C50I/bwVaayvK71l/uHZGuwo6K7bl+jVyLzmC7+iVH ADTizbhd8IoL9cNaFlFUtaktOihG3AFJ0Abr1OSjrlYm3WTU74ab/1O/b86B2By6TaLG/FYtUJB 9LGI9xmAO738Oe6NfLNL3mIdAIX42vQUyPTk8IUAvdL4TzpZNoprEeoZHCQIUWf/cATIRrMXRJN gWv23SDD5+MJQYitKoKK25aAKEtf5ZosiHqQrNylAqNTt8FdWNmdPCKLAdu+Q3Q44he/NIT5jNh KqBMgatEJTJS+OyYMgYKUeOkNfS4X8HWMSNX7ozSlmIs9AhOkbbuL7Y47c078UjS8LVUAf2DFj4 3cvg+I0TMEcVjHNwfKcyGJZ2UplL7Dhhh55txth3b7/zBhN1rxZQ031Z6Fpw3ACKo+6ZwlaesTr cFv5b5rWiG+FMYPGdJZY9iykFVOHQff/Y9Ps7bQ9aoPSmWJHNUTeBBPKQKp3BT+pdjEe8kyGMOJ yKxBEVGnmdEWOrGXIsYORvUxxe+zoAW8R15l+eAiCmPx4NwFkMvWAuahr8trNGq+WQEvSrusVRy 4an8bxAi7jPoeEQftwZ3X11IV0=
Archived-At: <http://mailarchive.ietf.org/arch/msg/l3sm/wwdq-9A6ESVsLlT3kqRF-u18STA>
Subject: Re: [L3sm] New Liaison Statement, "Liaison from MEF on IP Service Attributes"
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2016 20:02:23 -0000

All,

This liaison seems to notify us of work that "is different" from what we are doing, but where the authors of this communication believe "there is some synergy between the L3SM work and this MEF project."

Following the link supplied and using the username "mef" fails for me as a password is required. Let me know if you have any success.

In the man time, I suggest we wait to see whether anyone makes any comments on the mailing list with a view to ensuring that the "specifications are aligned."

Adrian

> -----Original Message-----
> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]
> Sent: 26 February 2016 18:06
> To: ietf@wjcerveny.com; joelja@bogus.com; bclaise@cisco.com;
> adrian@olddog.co.uk; rcallon@juniper.net; ietf@trammell.ch;
> swallow.ietf@gmail.com; bill.wu@huawei.com; loa@pi.nu
> Cc: rraghu@ciena.com; IP Performance Metrics Discussion List; Multiprotocol
> Label Switching Discussion List; Brian Trammell; Nan Chen; Ross Callon; L3VPN
> Service Model Discussion List; Spencer Dawkins; George Swallow; Martin
> Stiemerling; Bill Bjorkman; Alia Atlas; The IETF Chair; Joel Jaeggli; Adrian Farrel; Qin
> Wu; Bill Cerveny; Deborah Brungard; Raghu Ranganathan; Loa Andersson; Benoit
> Claise; Alvaro Retana
> Subject: New Liaison Statement, "Liaison from MEF on IP Service Attributes"
> 
> Title: Liaison from MEF on IP Service Attributes
> Submission Date: 2016-02-26
> URL of the IETF Web page: https://datatracker.ietf.org/liaison/1458/
> 
> From: "Raghu Ranganathan" <rraghu@ciena.com>
> To: bclaise@cisco.com, joelja@bogus.com, ietf@trammell.ch>,
> ietf@wjcerveny.com, loa@pi.nu, swallow.ietf@gmail.com, rcallon@juniper.net,
> adrian@olddog.co.uk, bill.wu@huawei.com
> Cc: Alvaro Retana <aretana@cisco.com>,Joel Jaeggli
> <joelja@bogus.com>,Deborah Brungard <db3546@att.com>,IP Performance
> Metrics Discussion List <ippm@ietf.org>,Multiprotocol Label Switching Discussion
> List <mpls@ietf.org>,Adrian Farrel <adrian@olddog.co.uk>,Qin Wu
> <bill.wu@huawei.com>,Bill Cerveny <ietf@wjcerveny.com>,Brian Trammell
> <ietf@trammell.ch>,Spencer Dawkins
> <spencerdawkins.ietf@gmail.com>,George Swallow
> <swallow.ietf@gmail.com>,Alia Atlas <akatlas@gmail.com>,The IETF Chair
> <chair@ietf.org>,Nan Chen <nan@metroethernetforum.org>,Ross Callon
> <rcallon@juniper.net>,Loa Andersson <loa@pi.nu>,Benoit Claise
> <bclaise@cisco.com>,L3VPN Service Model  Discussion List <l3sm@ietf.org>,Bill
> Bjorkman <bill@metroethernetforum.net>,Martin Stiemerling
> <mls.ietf@gmail.com>,Raghu Ranganathan <rraghu@ciena.com>,
> Response Contacts: rraghu@ciena.com
> Technical Contacts:
> Purpose: For information
> 
> Body: We would like to inform you that during our 1Q2016 meeting, MEF has
> approved a new project on IP Service Attributes. We have set out some
> background and further details below.
> 
> MEF is well known for the definition of Carrier Ethernet (CE) services (in MEF 6.2,
> MEF 33 and MEF 51) based on service attributes (defined in MEF 10.3 and MEF
> 26.1). In MEF terms, a "service" refers to the set of attributes and their values
> that are agreed between the provider of a serviceand the customer of that
> service. These attributes are independent of how the service is implemented; for
> example a CE service could be
> implemented using Provider Backbone Bridging (802.1Q) or using VPLS (RFC
> 4761/4762) to provide the connectivity across the service provider's network.
> MEF defines both end-to-end services agreed between a subscriber and a
> service provider, where the end points are all User-Network Interfaces (UNIs),
> and inter-provider services supplied by one service provider or operator to
> another, where the end points may be UNIs or External Network-Network
> Interfaces (ENNIs).
> 
> Note that this differs from how the word "service" is sometimes used in IETF, e.g.
> to describe a particular technology (as in "Virtual Private LAN Service").
> 
> Although IP Services are widely deployed, there is currently no standard
> definition of the attributes and values used to describe them. Each Service
> Provider has their own way of describing IP services (including in some cases their
> own terminology); this makes it hard for customers to compare service offerings
> from different providers, and in particular makes it hard for providers to
> interconnect with each other – each Service Provider must form a specific
> bilateral agreement with each other Service Provider they wish to connect with.
> 
> Furthermore, there is a desire among service providers to improve service
> delivery times by automating the service ordering and configuration process. This
> is a key aspect of MEF Lifecycle Services Orchestration (LSO). The aim of MEF LSO
> is to deliver the MEF Third Network vision, to provide Assured, Agile and
> Orchestrated services. MEF LSO enables automation and orchestration of service
> ordering and management between service providers ("East/West interfaces")
> through the creation of standard data models and APIs. However, a pre-requisite
> for defining those is to have a standard definition of the service that is to be
> managed.
> 
> The new project is intended to address these issues by providing a standard
> definition of IP Services, including both end-to-end services and inter-provider
> services, through the definition of a standard set of Service Attributes that can be
> used in each case. The scope is limited to IP-VPN and Internet Access services  (IP
> peering/transit for internet traffic is precluded). It is intended that this project is
> the first step in enabling multi-operator service orchestration of IP Services using
> MEF LSO, and that later projects will use the Service Attributes to create standard
> data models and APIs. The intent of LSO is to provide a common framework
> across different service technologies; MEF is working with TMF and ONF to create
> common models for services, and the standard data models and APIs for IP
> Services will tie into this framework.
> 
> We have noted that IETF is working on a Yang model for Layer 3 Services in the
> L3SM working group. Although the scope of that project in IETF is different, it is
> clear there is some synergy between the L3SM work and this MEF project. We
> believe that both projects can benefit from input from each other and we hope
> to work closely with the L3SM working group to ensure our specifications are
> aligned.
> 
> The scope of the initial phase of the IP Service Attributes project includes:
> -Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections,
> and for IP Service End Points at UNIs and ENNIs
> -IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs
> -OAM across the external interface (by reference to IETF protocols and
> mechanisms)
> -Service Level Specification (SLS) definitions including performance
> monitoring/constraints (by reference to IETF protocols and metric definitions)
> -Redundant links at an external interface (Subscriber/Service provider or
> between Service Providers), including options for different routing protocols.
> -Multi-CoS services (i.e. QoS classification) and classification of Green/Yellow
> packets including diffserv, Bandwidth profiles, etc.
> -IPv4, IPv6 and dual stack services
> -Inter-operator IP-VPN services using options A, B or C from RFC4364
> -Unicast only (multicast is defered to a future phase).
> -Other topics may be added as the project progresses.
> 
> It is important to note that we intend to make extensive reference to existing
> IETF RFCs where applicable; it is not our intent to specify new protocols or
> mechanisms where there are existing solutions.
> 
> Note: further information about MEF LSO can be found in the LSO Reference
> Architecture. The final verison is expected to be published in March; in the
> meantime, the latest approved draft is available as below:
> https://mef.net/liaison-login
> Username: mef
> Attachments:
> 
>     Liaison
>     https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-02-26-mef-
> ippm-mpls-l3sm-ops-liaison-from-mef-on-ip-service-attributes-attachment-1.pdf