Subject: [Teas] Mail regarding draft-ietf-teas-te-service-mapping-yang

From: Stephen Cheng <[email-masked]>
Date: Tue, 5 Nov 2019 03:50:57 +0000

Authors of draft-ietf-teas-te-service-mapping-yang,

RFC 8466 L2SM Figure 3 specifically identify L2SM as a Customer Service Model, although Section 4 does say:
"This way of using the service model is illustrated in Figure 3 and is
described in more detail in [RFC8309] and [RFC8199]. The split of
the orchestration function between a "service orchestrator" and a
"network orchestrator" is clarified in [RFC8309]. The usage of this
service model is not limited to this example: it can be used by any
component of the management system but not directly by network
elements."
In https://tools.ietf.org/pdf/draft-ietf-opsawg-l3sm-l3nm-00.pdf section 1 L3SM is characterized as Customer Service Model:
"[RFC8299] defines a L3VPN Service YANG data Model (L3SM) model that can be used for communication between customers and network operators. Such model is focused on describing the customer view of the services, and provides an abstracted view of the customer's requested services. That approach limits the usage of the L3SM to the role of a Customer Service Model, according to the terminology defined in [RFC8309]."

However draft-ietf-teas-te-service-mapping-yang-02 section 1 characterizes L2SM and L3SM as Service Delivery Models rather than Customer Service Model:
"[RFC8299] provides a L3VPN service delivery YANG model for PE-based VPNs. The scope of that draft is limited to a set of domains under control of the same network operator to deliver services requiring TE tunnels. [RFC8466] provides a L2VPN service delivery YANG model for PE-based VPNs. The scope of that draft is limited to a set of domains under control of the same network operator to deliver services requiring TE tunnels."

Why is draft-ietf-teas-te-service-mapping-yang-02 characterizing L2SM and L3SM as Service Delivery Models rather than Customer Service Model, contrary to other IETF works (and especially RFC 8466)?

Since L2SM and L3SM are Customer Service Models, what additional purpose do the YANG data models in draft-ietf-teas-te-service-mapping-yang serve regarding the purpose as set forth in section 1  "The models presented in this document are also applicable in generic context [RFC8309] as part of Customer Service Model used between Service Orchestrator and Customer."? Are the YANG data models in draft-ietf-teas-te-service-mapping-yang meant to provide optional supplement to L2SM/L3SM in their capacity as Customer Service Models?

Warm regards,
Stephen Cheng

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 5 Nov 2019 10:20:44 +0530

Hi Stephen,

In the context of our draft, the term 'service delivery' came from the
title of RFC 8299 - YANG Data Model for L3VPN Service Delivery and RFC
8466 - A YANG Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery.

> “[RFC8299] provides a L3VPN service delivery YANG model for PE-based VPNs. The scope of that draft is limited to a set of domains under control of the same network operator to deliver services requiring TE tunnels. [RFC8466] provides a L2VPN service delivery YANG model for PE-based VPNs. The scope of that draft is limited to a set of domains under control of the same network operator to deliver services requiring TE tunnels.”
>
>

But, I can see how 'service delivery YANG model' can be confusing. We
will make the necessary changes in the next version.

> Since L2SM and L3SM are Customer Service Models, what additional purpose do the YANG data models in draft-ietf-teas-te-service-mapping-yang serve regarding the purpose as set forth in section 1  “The models presented in this document are also applicable in generic context [RFC8309] as part of Customer Service Model used between Service Orchestrator and Customer.”? Are the YANG data models in draft-ietf-teas-te-service-mapping-yang meant to provide optional supplement to L2SM/L3SM in their capacity as Customer Service Models?
>

Currently the draft augments L3SM/L2SM/L1CSM. We hope this can also
work with L3NM model and would like to discuss this further in 106.

Thanks!
Dhruv