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

[Benoit Claise <[e-mail]>]

Dear all,

The L3SM, IPPM, MPLS, and the OPS Area would like to thank the MEF for 
informing us of your effort on IP Service Attributes 
<https://datatracker.ietf.org/liaison/1458/>  [1].

We're pleased that you mentioned the L3VPN service model (L3SM) work in 
your liaison. The L3SM work covers an abstracted view of the Layer 3 
IPVPN service configuration components, with its "YANG Data Model for 
L3VPN service delivery" [2] deliverable.

 From your liaison statement, we read "In MEF terms, a "service" refers 
to the set of attributes and their values that are agreed between the 
provider of a service and the customer of that service." You will be 
glad to hear that we use the same definition in our L3SM work. As such, 
the MEF initiative on IP service attributes clearly relates to L3SM.

The L3SM chairs and working group have examined the proposed scope of 
the initial phase of the MEF IP Service Attributes project:

    -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.


The L3SM work already covers most of the items in this list, including 
multicast.  However, we should observe that:
1.  L3SM has initially focused on the interface between the customer and 
the service provider, not the interface between services providers or 
between service provider domains. The current service model supports the 
configuration of the RFC 4364 option A (as this is a subset of the 
existing site model), and we're considering whether to add option B and C.
2.  The L3SM work does not cover either the Service Level Specification 
definitions or the Lifecycle Service Orchestration as described in the 
MEF Lifecycle Service Orchestration (LSO) Reference Architecture & 
Framework.

The L3SM work started about a year ago and is in the final stage of 
standardization. Therefore, we would encourage anyone who is interested 
to review and provide feedback on the future standard by sending a 
message to the L3SM mailing list as soon as possible (details at [3]). 
Please keep us informed of any gaps you identify that are needed to 
satisfy the requirements in your specifications, without the need for a 
formal liaison.

I hope you will agree that it is important to not duplicate work within 
standardization. Therefore, I hope you will work to produce extensions 
to the L3SM YANG model for additional features such as the Service Level 
Specification, and will not repeat any of the function already provided 
by that model. If you need further information, don't hesitate to 
contact us. We are always available for further discussions or 
conference calls regarding the L3SM specifications content.

Regards, Benoit Claise (OPS Area Director)

[1] https://datatracker.ietf.org/liaison/1458/
[2] https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/
[3] https://datatracker.ietf.org/wg/l3sm/charter/



> 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" <[e-mail]>
> To: [e-mail], [e-mail], [e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
> Cc: Alvaro Retana <[e-mail]>,Joel Jaeggli <[e-mail]>,Deborah Brungard <[e-mail]>,IP Performance Metrics Discussion List <[e-mail]>,Multiprotocol Label Switching Discussion List <[e-mail]>,Adrian Farrel <[e-mail]>,Qin Wu <[e-mail]>,Bill Cerveny <[e-mail]>,Brian Trammell <[e-mail]>,Spencer Dawkins <[e-mail]>,George Swallow <[e-mail]>,Alia Atlas <[e-mail]>,The IETF Chair <[e-mail]>,Nan Chen <[e-mail]>,Ross Callon <[e-mail]>,Loa Andersson <[e-mail]>,Benoit Claise <[e-mail]>,L3VPN Service Model  Discussion List <[e-mail]>,Bill Bjorkman <[e-mail]>,Martin Stiemerling <[e-mail]>,Raghu Ranganathan <[e-mail]>,
> Response Contacts: [e-mail]
> 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
>
> .
>