Subject: [L3sm] Liaison from MEF on IP Service Attributes and L3SM coverage

From: Benoit Claise <[email-masked]>
Date: Fri, 11 Mar 2016 12:30:31 +0100

Dear all,

While thinking on how to reply to the "Liaison from MEF on IP Service 
Attributes <https://datatracker.ietf.org/liaison/1458/>", let check a 
few points with the WG
 From the liaison, we can read:

    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.

Let's check how much we support with the L3VPN service YANG data model:
- Definition of attributes for IP-capable UNIs and NNIs, for IP Service 
connections, and for IP Service End Points at UNIs and ENNIs
     UNI is clearly supported
     For NNI, see below (*)
- IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs
     Supported.
- OAM across the external interface (by reference to IETF protocols and 
mechanisms)
     The OAM specifics should not be part of a service definition
     On that topic, see Adrian's email earlier today on the L3SM mailing 
list.
- Service Level Specification (SLS) definitions including performance 
monitoring/constraints (by reference to IETF protocols and metric 
definitions)
     This is not covered by our model
- Redundant links at an external interface (Subscriber/Service provider 
or between Service Providers), including options for different routing 
protocols.
     Supported
- Multi-CoS services (i.e. QoS classification) and classification of 
Green/Yellow packets including diffserv, Bandwidth profiles, etc.
     Supported
- IPv4, IPv6 and dual stack services
     Supported
- Inter-operator IP-VPN services using options A, B or C from RFC4364
     (*) The model supports the configuration of the option A, but would 
require some sort of applicability statement on how to apply for NNI
      Option B and C are not supported. Is there any willingness to 
document B? What about C?
- Unicast only (multicast is defered to a future phase).
     Supported. Not only unicast, but multicast also

Is this assessment correct?

Regards, Benoit

---

From: <[email-masked]>
Date: Fri, 11 Mar 2016 13:11:15 +0000

Hi Benoit,

Your statements are true. For option A, we may need to add some text to explain how we can use the current model for option A.

Best Regards,

Stephane

From: L3sm [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, March 11, 2016 12:31
To: [email-masked]
Subject: [L3sm] Liaison from MEF on IP Service Attributes and L3SM coverage

Dear all,

While thinking on how to reply to the "Liaison from MEF on IP Service Attributes<https://datatracker.ietf.org/liaison/1458/>", let check a few points with the WG
From the liaison, we can read:

mechanisms)

definitions)

protocols.

-Other topics may be added as the project progresses.
Let's check how much we support with the L3VPN service YANG data model:
- Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections, and for IP Service End Points at UNIs and ENNIs
    UNI is clearly supported
    For NNI, see below (*)
- IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs
    Supported.
- OAM across the external interface (by reference to IETF protocols and mechanisms)
    The OAM specifics should not be part of a service definition
    On that topic, see Adrian's email earlier today on the L3SM mailing list.
- Service Level Specification (SLS) definitions including performance monitoring/constraints (by reference to IETF protocols and metric definitions)
    This is not covered by our model
- Redundant links at an external interface (Subscriber/Service provider or between Service Providers), including options for different routing protocols.
    Supported
- Multi-CoS services (i.e. QoS classification) and classification of Green/Yellow packets including diffserv, Bandwidth profiles, etc.
    Supported
- IPv4, IPv6 and dual stack services
    Supported
- Inter-operator IP-VPN services using options A, B or C from RFC4364
    (*) The model supports the configuration of the option A, but would require some sort of applicability statement on how to apply for NNI
     Option B and C are not supported. Is there any willingness to document B? What about C?
- Unicast only (multicast is defered to a future phase).
    Supported. Not only unicast, but multicast also

Regards, Benoit

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.