Draft: draft-ietf-opsawg-sap

Commentary: Check if we need to expose SAPs per servcie - type and if so , how we can easily add support for it OLD : NEW :
Paragraph (version A):
This document defines a YANG data model for representing an abstract
view of the provider network topology containing the points from
which its services can be attached (e.g., basic connectivity, VPN,
network slices).  The data model augments the 'ietf-network' data
model by adding the concept of service attachment points (SAPs).  The
service attachment points are the points to which network services
(such as L3VPN or L2VPN) can be attached.  The customer endpoint of
an attachment circuits are not covered in the SAP network topology.
Paragraph (version A):
The service attachment point (SAP) is an important architectural
concept in many implementations and deployments of services such as
VPNs, SDWAN, or managed VoIP services.  It has already been used to
decide where to attach and, thus, deliver the service in the L3SM
RFC8299 and the L2SM RFC8466.
Paragraph (version A):
This document defines a YANG network model for representing,
managing, and controlling the service attachment points (SAPs).  The
data model augments the 'ietf-network' module RFC8345 by adding the
concept of service attachment points.  The service attachment points
are abstraction of the points where network services such as L3VPNs
or L2VPNs can be attached.
Paragraph (version A):
This document does not make any assumption about the service provided
by the network to the users.  VPN services are used for illustration
purposes.  This concept can also be used to decide network slice SAPs
I-D.ietf-teas-ietf-network-slices.
Paragraph (version B):
This document defines a YANG data model for representing an abstract
view of the provider network topology containing the points from
which its services can be attached (e.g., basic connectivity, VPN,
network slices).  The data model augments the 'ietf-network' data
model by adding the concept of Service Attachment Points (SAPs).  The
Service Attachment Points are the points to which network services
(such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual
Private Network (L2VPN)) can be attached.
Paragraph (version B):
The customer endpoints of an attachment circuit (Customer Edges
(CEs), topically) are not covered in the SAP network topology.
Paragraph (version B):
The Service Attachment Point (SAP) is an important architectural
concept in many implementations and deployments of services such as
Virtual Private Networks (VPNs), Software-Defined Wide Area Network
(SDWAN), or managed Voice over IP (VoIP) services.  It is used to
decide where to attach and, thus, deliver the service in the Layer 3
VPN Service Model (L3SM) RFC8299 and the Layer 2 VPN Service Model
(L2SM) RFC8466.  It can also be used to retrieve where services, such
as the Layer 3 VPN Network Model (L3NM) I-D.ietf-opsawg-l3sm-l3nm,
and the Layer 2 VPN Network Model (L2NM) I-D.ietf-opsawg-l2nm, are
delivered.
Paragraph (version B):
This document defines a YANG network model for representing,
managing, and controlling the Service Attachment Points.  The data
model augments the 'ietf-network' module RFC8345 by adding the
concept of Service Attachment Points.  The Service Attachment Points
are abstraction of the points where network services can be attached.
Paragraph (version B):
This document does not make any assumption about the service(s)
provided by the network to the users.  VPN services (such as Layer 3
Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network
(L2VPN)) are used for illustration purposes.  The SAP concept can be
used to decide network slice SAPs I-D.ietf-teas-ietf-network-slices.
Paragraph (version A):
In the context of Software-Defined Networking (SDN) RFC7426, the
defined YANG data model in this document can be used to exchange
information between control elements, so as to support VPN service
provision and resource management discussed in I-D.ietf-opsawg-l2nm.
Through this data model, the service orchestration layer can learn
the available endpoints (i.e., SAPs) of interconnection resource of
the underlying network.
Paragraph (version A):
The service orchestration layer can determine which endpoint of
interconnection to add to L2VPN or L3VPN service.  With the help of
other data models (e.g., L3SM RFC8299 or L2SM RFC8466), hierarchical
control elements could determine the feasibility of an end-to-end IP
connectivity or L2VPN connectivity and therefore derive the sequence
of domains and the points of interconnection to use.
Paragraph (version A):
This document explains the scope and purpose of a SAP network model
and its relation with the service models and describes how it can be
used by a network operator.  The document also shows how the topology
and service models fit together.
Paragraph (version B):
In the context of Software-Defined Networking (SDN) RFC7426, the
defined YANG data model in this document can be used to exchange
information between control elements, so as to support VPN service
provision and resource management discussed in I-D.ietf-opsawg-l2nm.
Through this data model, the service orchestration layer can learn
the available endpoints (i.e., SAPs) of interconnection resource of
the underlying network.  The service orchestration layer can
determine which interconnection endpoints to add to an L2VPN or L3VPN
service.  With the help of other data models (e.g., L3SM RFC8299 or
L2SM RFC8466), hierarchical control elements can also assess the
feasibility of an end-to-end IP connectivity or L2VPN connectivity
and, therefore, derive the sequence of domains and the points of
interconnection to use.
Paragraph (version B):
This document explains the scope and purpose of a SAP network model
and its relation with the service models.
Paragraph (version A):
Tree diagrams used in this document follow the notation defined in
[RFC8340].
Paragraph (version B):
The meanings of the symbols in tree diagrams are defined in RFC8340.
Paragraph (version A):
An equipment owned and managed by the SP that can support multiple
services (e.g., VPNs) for different customers.  A PE is directly
connected to one or more CEs via attachment circuits.  A PE is
usually located at an SP point of presence (PoP).
Paragraph (version A):
Describes a service's end point characteristics and its reference
to a Termination Point (TP) of the PE; used as service access
point for service.
Paragraph (version B):
An equipment owned and managed by the SP that can support multiple
services (e.g., VPNs) for different customers.  A PE is directly
connected to one or more CEs via attachment circuits.
Paragraph (version B):
Describes a service's endpoint characteristics and its reference
to a Termination Point (TP) of the PE; used as service access
point for service.
Paragraph (version A):
A single SAP network topology can be used for one of multiple service
types (e.g., L3VPN, EVPN).  The network controller can then expose
the service type(s) and associated interfaces via the SAPs.
Paragraph (version A):
As shown in fi3a, the Service Orchestration layer will have also
access to a set of Customer Service Model, e.g., an L3SM or L2SM data
model in the customer-facing interface and a set of network models,
e.g., L3NM and Network topology data models in the resource-facing
interface.  In this use case, it is assumed that the network
controller is unaware of what happens beyond the PEs towards the CEs;
it is only responsible for the management and control of the network
between PEs.
Paragraph (version B):
A single SAP network topology can be used for one of multiple service
types (e.g., L3VPN, Ethernet VPN (EVPN)).  The network controller can
then expose the service type(s) and associated interfaces via the
SAPs.
Paragraph (version B):
As shown in fi3a, the Service Orchestration layer will have also
access to a set of Customer Service Model, e.g., an L3SM or L2SM data
model in the customer-facing interface and a set of network models,
e.g., the L3NM and Network topology data models in the resource-
facing interface.  In this use case, it is assumed that the network
controller is unaware of what happens beyond the PEs towards the CEs;
it is only responsible for the management and control of the network
between PEs.
Paragraph (version A):
A service attachment point is identified by an interface name
("attachment-id"), an interface type ("type"), a status ("admin-
status", and "oper-status"), an encapsulation type ("encapsulation-
type"), one or a list of service types ("sap-type") such as L3VPN or
network slice, a description of the service(s) ("service-
description").
Paragraph (version A):
The SAP network model can be seen as an inventory data associated
with service attachment points.  The model maintains an inventory of
nodes contained in a network based on [RFC8345].
Paragraph (version B):
A Service Attachment Point is identified by an interface name
("attachment-id"), an interface type ("type"), a status ("admin-
status" and "oper-status"), an encapsulation type ("encapsulation-
type"), one or a list of service types ("sap-type"), a description of
the service(s) ("service-description").
Paragraph (version B):
"attachment-id" may include a reference to a physical or a logical
interface.  For example, an "attachment-id" may be the interface
identifier of a VPN network access used in Section 7.6 of I-D.ietf-
opsawg-l3sm-l3nm.
Paragraph (version B):
The SAP network model can be seen as an inventory data associated
with SAPs.  The model maintains an inventory of nodes contained in a
network based on RFC8345.