Draft: draft-ietf-opsawg-l2nm

Commentary: Adding information in section Global Parameters Profile
Paragraph (version A):
The data model defined in this document is called the L2VPN Network
Model (L2NM), playing the role of Service Delivery Model (Figure 3 of
RFC8466).  The module supports additional capabilities, such as
exposing operational parameters, transport protocols selection and
precedence.  It also serves as a multi-domain orchestration
interface, because this model can transport resources (i.e., VCID)
between domains.  The data model keeps minimum customer-related
information.
Paragraph (version B):
The data model defined in this document is called the L2VPN Network
Model (L2NM), playing the role of Service Delivery Model (Figure 3 of
RFC8466).  The module supports additional capabilities, such as
exposing operational parameters, transport protocols selection and
precedence.  It also serves as a multi-domain orchestration
interface, because this model can use resources (i.e., Virtual
Connection Identifier - VCID) between domains.  The data model keeps
minimum customer-related information.
Paragraph (version A):
Describes the service characterization of an L2VPN that
interconnects a set of sites from the perspective of the customer.
The customer service model does not provide details on the service
provider network.  The L2VPN customer service model is defined in
RFC8466.
Paragraph (version A):
Refers to the YANG module that describes an L2VPN service with a
network-centric view.  It contains information of the service
providers network and might include allocated resources.  It can
be used by network controllers to manage the Layer 2 VPN service
configuration in the service providers network.  The YANG module
can be consumed by a service orchestrator to request a VPN service
to a network controller or to expose the list of active L2VPN
services.
Paragraph (version B):
Describes the service characterization of an L2VPN that
interconnects a set of sites from the customer's perspective.  The
customer service model does not provide details on the service
provider network.  The L2VPN customer service model is defined in
RFC8466.
Paragraph (version B):
Refers to the YANG module that describes an L2VPN service with a
network-centric view.  It contains information of the service
providers network and might include allocated resources.  Network
controllers can use it to manage the Layer 2 VPN service
configuration in the service providers network.  The YANG module
can be consumed by a service orchestrator to request a VPN service
to a network controller or to expose the list of active L2VPN
services.
Paragraph (version A):
The customer may use a variety of means to request a service that may
trigger the instantiation of a L2NM.  The customer may use the L2SM
or may rely upon more abstract models to request a service that
relies upon an L3VPN service.  For example, the customer may supply
an IP Connectivity Provisioning Profile (CPP) RFC7297, an enhanced
VPN (VPN+) service I-D.ietf-teas-enhanced-vpn, or an IETF network
slice I-D.ietf-teas-ietf-network-slices.
Paragraph (version B):
The customer may use various means to request a service that may
trigger the instantiation of a L2NM.  The customer may use the L2SM
or may rely upon more abstract models to request a service that
relies upon an L3VPN service.  For example, the customer may supply
an IP Connectivity Provisioning Profile (CPP) RFC7297, an enhanced
VPN (VPN+) service I-D.ietf-teas-enhanced-vpn, or an IETF network
slice I-D.ietf-teas-ietf-network-slices.
Paragraph (version A):
The L2NM can be fed with inputs that are requested by customers,
typically, relying upon an L2SM template.  Concretely, some parts
of the L2SM module can be directly mapped into L2NM while other
parts are generated as a function of the requested service and
local guidelines.  Some other parts are local to the service
provider and do not map directly to L2SM.
Paragraph (version B):
The L2NM can be fed with inputs that are requested by customers,
typically, relying upon an L2SM template.  Concretely, some parts
of the L2SM module can be directly mapped into L2NM while other
parts are generated as a function of the requested service and
local guidelines.  Finally, there are parts local to the service
provider and do not map directly to L2SM.
Paragraph (version A):
The L2NM module ('ietf-l2vpn-ntw') is meant to manage L2VPNs within a
service provider network.  In particular, the 'ietf-l2vpn-ntw' module
can be used to create, modify, and retrieve L2VPN services in a
network controller.  The module is not aimed at maintaining customer-
related information.
Paragraph (version A):
The 'ietf-l2vpn-ntw' module uses two main containers: 'vpn-services'
and 'vpn-profiles'.  The 'vpn-services' container maintains a set of
L2VPN services managed in the service providers network.  The module
allows to create a new L2VPN service by adding a new instance of
'vpn-service'.  The 'vpn-service' is the data structure that
abstracts the VPN Service.
Paragraph (version B):
The L2NM module ('ietf-l2vpn-ntw') is meant to manage L2VPNs within a
service provider network.  In particular, the 'ietf-l2vpn-ntw' module
can be used to create, modify, and retrieve L2VPN services in a
network controller.  The aim of the module is not to maintain
customer- related information.
Paragraph (version B):
The full tree diagram of the module can be generated using the
"pyang" tool PYANG.  That tree is not included here because it is too
long (Section 3.3 of RFC8340).  Instead, subtrees are provided for
the reader's convenience.
Paragraph (version B):
The 'ietf-l2vpn-ntw' module uses two main containers: 'vpn-services'
and 'vpn-profiles' (see ietf-l2vpn-ntw_tree).
Paragraph (version B):
The 'vpn-profiles' container is used by the provider to maintain a
set of common VPN profiles that apply to one or several VPN services
(vpn_profiles).
Paragraph (version B):
The 'vpn-services' container maintains the set of L2VPN services
managed in the service providers network.  The module allows to
create a new L2VPN service by adding a new instance of 'vpn-service'.
The 'vpn-service' is the data structure that abstracts the VPN
Service.
Paragraph (version B):
The 'global-parameters-profile' defines reusable parameters for the
same 'vpn-service'.  A 'global-parameters-profile' contains 'profile-
ids', which is a list of 'profile-id', which is the identifier of the
global parameters profiles.
Paragraph (version A):
Refers to the BGP control plane as described in RFC4761 and
RFC6624.
Paragraph (version A):
Refers to the BGP control plane as described in RFC7432 and
RFC7209.
Paragraph (version A):
Refers to LDP-signaled pseudowires RFC6074.
Paragraph (version A):
Refers to L2TP-signaled pseudowires RFC6074.
Paragraph (version B):
The service is a Multipoint VPLSs that use a BGP control plane as
described in RFC4761 and RFC6624.  For this L2VPN service, the
model allows configuring the Route Distinguisher, the Route
Targets, the PWE encapsulation type and the MTU configurations to
allow MTU mismatch.
Paragraph (version B):
The service is a Multipoint VPLSs that use also a BGP control
plane but also includes the additional features and related
parameters RFC7432 and RFC7209.  The model allows the
configuration of the EVPN service interface type, the local and
remote VPWS Service Instance (VSI) RFC8214, the EVPN policies for
handling MAC addresses and the Ethernet Segment Identifier (ESI)
information.
Paragraph (version B):
A Multipoint VPLSs that use a mesh of LDP-signaled Pseudowires
RFC6074.  The model allows configuring the T-LDP PWE type, MTU
mismatch and the list of AC and PW bindings.
Paragraph (version B):
The L2 VPN uses L2TP-signaled Pseudowires as described in RFC6074.
The model allows configuring TBC.