Liaison statement
Liaison from MEF on IP Service Attributes
Additional information about IETF liaison relationships is available on theIETF webpage and theInternet Architecture Board liaison webpage.
| State | Posted |
|---|---|
| Submitted Date | 2016-02-26 |
| From Group | MEF |
| From Contact | Raghu Ranganathan <rraghu@ciena.com> |
| To Groups | ippm, l3sm, mpls, OPS |
| To Contacts | 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 Contact | rraghu@ciena.com |
| Purpose | For information |
| Attachments | Liaison |
| Liaisons referring to this one | Response to Liaison Statement on IP Service Attributes 2016-02-26 |
| Body | We would like to inform you that during our 1Q2016 meeting, MEF has approved anew project on IP Service Attributes. We have set out some background andfurther details below.MEF is well known for the definition of Carrier Ethernet (CE) services (in MEF6.2, MEF 33 and MEF 51) based on service attributes (defined in MEF 10.3 andMEF 26.1). In MEF terms, a "service" refers to the set of attributes and theirvalues that are agreed between the provider of a serviceand the customer ofthat service. These attributes are independent of how the service isimplemented; for example a CE service could be implemented using ProviderBackbone Bridging (802.1Q) or using VPLS (RFC 4761/4762) to provide theconnectivity across the service provider's network. MEF defines both end-to-endservices agreed between a subscriber and a service provider, where the endpoints are all User-Network Interfaces (UNIs), and inter-provider servicessupplied by one service provider or operator to another, where the end pointsmay 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 standarddefinition of the attributes and values used to describe them. Each ServiceProvider has their own way of describing IP services (including in some casestheir own terminology); this makes it hard for customers to compare serviceofferings from different providers, and in particular makes it hard forproviders to interconnect with each other – each Service Provider must form aspecific bilateral agreement with each other Service Provider they wish toconnect with.Furthermore, there is a desire among service providers to improve servicedelivery times by automating the service ordering and configuration process.This is a key aspect of MEF Lifecycle Services Orchestration (LSO). The aim ofMEF LSO is to deliver the MEF Third Network vision, to provide Assured, Agileand Orchestrated services. MEF LSO enables automation and orchestration ofservice ordering and management between service providers ("East/Westinterfaces") through the creation of standard data models and APIs. However, apre-requisite for defining those is to have a standard definition of theservice that is to be managed.The new project is intended to address these issues by providing a standarddefinition of IP Services, including both end-to-end services andinter-provider services, through the definition of a standard set of ServiceAttributes that can be used in each case. The scope is limited to IP-VPN andInternet Access services (IP peering/transit for internet traffic isprecluded). It is intended that this project is the first step in enablingmulti-operator service orchestration of IP Services using MEF LSO, and thatlater projects will use the Service Attributes to create standard data modelsand APIs. The intent of LSO is to provide a common framework across differentservice technologies; MEF is working with TMF and ONF to create common modelsfor services, and the standard data models and APIs for IP Services will tieinto this framework.We have noted that IETF is working on a Yang model for Layer 3 Services in theL3SM working group. Although the scope of that project in IETF is different, itis clear there is some synergy between the L3SM work and this MEF project. Webelieve that both projects can benefit from input from each other and we hopeto work closely with the L3SM working group to ensure our specifications arealigned.The scope of the initial phase of the IP Service Attributes project includes:-Definition of attributes for IP-capable UNIs and NNIs, for IP Serviceconnections, and for IP Service End Points at UNIs and ENNIs -IP addressallocations and IP control protocols (e.g. DHCP) etc at UNIs -OAM across theexternal interface (by reference to IETF protocols and mechanisms) -ServiceLevel Specification (SLS) definitions including performancemonitoring/constraints (by reference to IETF protocols and metric definitions)-Redundant links at an external interface (Subscriber/Service provider orbetween Service Providers), including options for different routing protocols.-Multi-CoS services (i.e. QoS classification) and classification ofGreen/Yellow packets including diffserv, Bandwidth profiles, etc. -IPv4, IPv6and dual stack services -Inter-operator IP-VPN services using options A, B or CfromRFC4364 -Unicast only (multicast is defered to a future phase). -Othertopics may be added as the project progresses.It is important to note that we intend to make extensive reference to existingIETF RFCs where applicable; it is not our intent to specify new protocols ormechanisms where there are existing solutions.Note: further information about MEF LSO can be found in the LSO ReferenceArchitecture. The final verison is expected to be published in March; in themeantime, the latest approved draft is available as below:https://mef.net/liaison-login Username: mef |