Liaison statement
Response to Liaison Statement on IP Service Attributes 2016-02-26

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/