Draft: draft-ietf-opsawg-l3sm-l3nm

Commentary: Additional attributes on static routes . 
 Missing : 1 ) BFD - enable / disable 2 ) metric -uint32 3 ) preference - uint32 4 ) special NH such as blackhole all needed for IPv4 and IPv6 as well . 
 BFD Part : Now it is only at interface level . It could be at static route level . Include the container in the routing protocols . 
 We have metic at IS - IS and Opsf level , but not at static route level . Can be . 
 preference is at OSPF level . Can be also 
  , please provide more information of the blackhole . Provide reference 
 Can you please check the to see if that fit the requirement ?
Paragraph (version A):
This document defines a L3VPN Network YANG Model (L3NM) that can be
used to manage the provisioning of Layer 3 Virtual Private Network
(VPN) services within a Service Provider's network.  The model
provides a network-centric view of L3VPN services.
Paragraph (version B):
This document defines a L3VPN Network YANG Model (L3NM) that can be
used for the provisioning of Layer 3 Virtual Private Network (VPN)
services within a service provider's network.  The model provides a
network-centric view of L3VPN services.
Paragraph (version A):
RFC8299 defines a L3VPN Service YANG data Model (L3SM) that can be
used for communication between customers and network operators.  Such
model is focused on describing the customer view of the Virtual
Private Network (VPN) services, and provides an abstracted view of
the customer's requested services.  That approach limits the usage of
the L3SM module to the role of a Customer Service Model, according to
the terminology defined in RFC8309.
Paragraph (version A):
This document defined a YANG module called L3VPN Network Model
(L3NM).  The L3NM is aimed at providing a network-centric view of
Layer 3 (L3) VPN Services.  This data model can be used to facilitate
communication between the service orchestrator (or a network
operator) and the network controller/orchestrator by allowing for
more network-centric information to be included.  It enables further
capabilities, such as resource management or to serve as a multi-
domain orchestration interface, where logical resources (such as
route targets or route distinguishers) must be synchronized.
Paragraph (version A):
This document does not obsolete, but uses, the definitions in
RFC8299.  These two modules are used for similar objectives but with
different scopes and views.
Paragraph (version A):
The L3NM YANG module is initially built with a prune and extend
approach, taking as a starting points the YANG module described in
RFC8299.  Nevertheless, this module is not defined as an augment to
L3SM because a specific structure is required to meet network-
oriented L3 needs.
Paragraph (version A):
Some of the information captured in the L3SM can be passed by the
Orchestrator in the L3NM (e.g., customer) or be used to fed some of
the L3NM attributes (e.g., actual forwarding policies).  Some of the
information captured in L3SM may be maintained locally within the
Orchestrator; which is in charge of maintaining the correspondence
between a Customer view and its network instantiation.  Likewise,
some of the information captured and exposed using L3NM can fed the
service layer (e.g., capabilities) to derive L3SM and drive VPN
service order handling.
Paragraph (version A):
The L3NM does not attempt to address all deployment cases especially
those where the L3VPN connectivity is supported through the
coordination of different VPNs in different underlying networks.
More complex deployment scenarios involving the coordination of
different VPN instances and different technologies to provide end-to-
end VPN connectivity are addressed by a complementary YANG model
defined in I-D.evenwu-opsawg-yang-composed-vpn.
Paragraph (version A):
L3NM focuses on BGP PE-based Layer 3 VPNs as described in RFC4364 and
Multicast VPNs as described in RFC7988.
Paragraph (version B):
RFC8299 defines a Layer 3 Virtual Private Network Service YANG data
Model (L3SM) that can be used for communication between customers and
network operators.  Such model is focused on describing the customer
view of the Virtual Private Network (VPN) 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
(as per RFC8309).
Paragraph (version B):
This document defined a YANG module called L3VPN Network Model
(L3NM).  The L3NM is aimed at providing a network-centric view of
Layer 3 (L3) VPN services.  This data model can be used to facilitate
communication between the service orchestrator (or a network
operator) and the network controller/orchestrator by allowing for
more network-centric information to be included.  It enables further
capabilities, such as resource management or to serve as a multi-
domain orchestration interface, where logical resources (such as
route targets or route distinguishers) must be coordinated.
Paragraph (version B):
This document does not obsolete RFC8299.  These two modules are used
for similar objectives but with different scopes and views.
Paragraph (version B):
The L3NM YANG module is initially built with a prune and extend
approach, taking as a starting points the YANG module described in
RFC8299.  Nevertheless,the L3NM is not defined as an augment to L3SM
because a specific structure is required to meet network-oriented L3
needs.
Paragraph (version B):
Some of the information captured in the L3SM can be passed by the
Orchestrator in the L3NM (e.g., customer) or be used to fed some of
the L3NM attributes (e.g., actual forwarding policies).  Some of the
information captured in L3SM may be maintained locally within the
Orchestrator; which is in charge of maintaining the correspondence
between a customer view and its network instantiation.  Likewise,
some of the information captured and exposed using the L3NM can feed
the service layer (e.g., capabilities) to drive VPN service order
handling, and thus the L3SM.
Paragraph (version B):
The L3NM does not attempt to address all deployment cases especially
those where the L3VPN connectivity is supported through the
coordination of different VPNs in different underlying networks.
More complex deployment scenarios involving the coordination of
different VPN instances and different technologies to provide an end-
to-end VPN connectivity are addressed by complementary YANG modules,
e.g., I-D.evenwu-opsawg-yang-composed-vpn.
Paragraph (version B):
L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as
described in RFC4364 and Multicast VPNs as described in RFC7988.
Paragraph (version A):
The meaning of the symbols in tree diagrams is defined in RFC8340.
Paragraph (version B):
The meaning of the symbols in the tree diagrams is defined in
RFC8340.
Paragraph (version A):
Layer 3 VPN Customer Service Model (L3SM): A YANG module that
describes the requirements of a L3VPN that interconnects a set of
sites from the point of view of the customer.  The customer
service model does not provide details on the service provider
network.  The L3VPN Customer Service model is defined in RFC8299.
Paragraph (version A):
Service Orchestrator: A functional entity that interacts with the
customer of a L3VPN.  The Service Orchestrator interacts with the
customer using L3SM.  The Service Orchestrator is responsible of
the Customer Edge (CE) - the Provider Edge (PE) attachment
circuits, the PE selection, and requesting the VPN service to the
network controller.
Paragraph (version A):
Network Orchestrator: A functional entity that is hierarchically
intermediate between Service Orchestrator and Network Controllers.
A network orchestrator can manage one or several Network
Controllers.
Paragraph (version B):
Layer 3 VPN Customer Service Model (L3SM): A YANG module that
describes the service requirements of a L3VPN that interconnects a
set of sites from the point of view of the customer.  The customer
service model does not provide details on the service provider
network.  The L3VPN Customer Service model is defined in RFC8299.
Paragraph (version B):
Service Orchestrator: A functional entity that interacts with the
customer of a L3VPN.  The service orchestrator interacts with the
customer using the L3SM.  The service orchestrator is responsible
of the Customer Edge (CE) - Provider Edge (PE) attachment
circuits, the PE selection, and requesting the VPN service to the
Network Controller.
Paragraph (version B):
Network Orchestrator: A functional entity that is hierarchically
intermediate between a service orchestrator and network
nontrollers.  A network orchestrator can manage one or several
network nontrollers.
Paragraph (version A):
VPN Service Provider (SP): A Service Provider that offers VPN-
related services RFC4176.
Paragraph (version A):
Service Provider (SP) Network: A network that is able to provide
VPN-related services.
Paragraph (version A):
xml_happy depicts the reference architecture for L3NM.  The figure is
an expansion of the architecture presented in Section 5 of RFC8299
and decomposes the box marked "orchestration" in that figure into
three separate functional components called "Service Orchestration",
"Network Orchestration", and "Domain Orchestration".
Paragraph (version A):
Although some deployments may choose to construct a monolithic
orchestration component (covering both service and network matters),
this document advocates for a clear separation between service and
network orchestration components for the sake of better flexibility.
Such design adheres to the L3VPN reference architecture defined in
Section 1.3 of RFC4176.  The above separation relies upon a dedicated
communication interface between these components and appropriate YANG
module that reflect network-related information (that is hidden to
customers).
Paragraph (version B):
VPN Service Provider: A service provider that offers VPN-related
services RFC4176.
Paragraph (version B):
Service Provider Network: A network that is able to provide VPN-
related services.
Paragraph (version B):
xml_happy depicts the reference architecture for the L3NM.  The
figure is an expansion of the architecture presented in Section 5 of
RFC8299; it decomposes the box marked "orchestration" in that section
into three separate functional components: Service Orchestration,
Network Orchestration, and Domain Orchestration.
Paragraph (version B):
Although some deployments may choose to construct a monolithic
orchestration component (covering both service and network matters),
this document advocates for a clear separation between service and
network orchestration components for the sake of better flexibility.
Such design adheres to the L3VPN reference architecture defined in
Section 1.3 of RFC4176.  This separation relies upon a dedicated
communication interface between these components and appropriate YANG
module that reflect network-related information (that is hidden to
customers).
Paragraph (version A):
The terminology from RFC8309 is introduced to show the distinction
between the "Customer Service Model", the "Service Delivery Model",
the "Network Configuration Model", and the "Device Configuration
Model".  In that context, the "Domain Orchestration" and "Config
Manager" roles may be performed by "Controllers".
Paragraph (version A):
The L3SM and the L3NM may also be used in the context of the ACTN
architecture RFC8453. l3sm_actn shows the Customer Network Controller
(CNC), the Multi-Domain Service Coordinator (MDSC), and the
Provisioning Network Controller (PNC).  It also shows the interfaces
between these functional blocks: the CNC-MDSC Interface (CMI), the
MDSC-PNC Interface (MPI), and the Southbound Interface (SBI).
Paragraph (version A):
The "ietf-vpn-common" module I-D.ietf-opsawg-vpn-common includes a
set of identities, types, and groupings that are meant to be reused
by VPN-related YANG modules independently of the layer (e.g., Layer
2, Layer 3) and the type of the module (e.g., network model, service
model) including future revisions of existing models (e.g., RFC8299
or RFC8466).  The L3NM reuses these common types and grouping.
Paragraph (version A):
In order to avoid data duplication and to ease passing data between
layers when required (service layer to network layer and vice versa),
early versions of the L3NM reused many of the data nodes that are
defined in RFC8299.  Nevertheless, that approach was abandoned in
favor of the "ietf-vpn-common" module because that design was
interpreted as if the deployment of L3NM depends on L3SM, while this
is not the case.  For example, a Service Provider may decide to use
the L3NM to build its L3VPN services without exposing the L3SM.
Paragraph (version A):
The internal view of the service (L3NM) may be mapped to an
external view which is visible to Customers : L3VPN Service YANG
data Model (L3SM) RFC8299.
Paragraph (version B):
The terminology from RFC8309 is introduced to show the distinction
between the customer service model, the service delivery model, the
network configuration model, and the device configuration model.  In
that context, the "Domain Orchestration" and "Config Manager" roles
may be performed by "Controllers".
Paragraph (version B):
The L3SM and the L3NM may also be used in the context of the
Abstraction and Control of TE Networks (ACTN) architecture RFC8453.
l3sm_actn shows the Customer Network Controller (CNC), the Multi-
Domain Service Coordinator (MDSC), and the Provisioning Network
Controller (PNC).  It also shows the interfaces between these
functional blocks: the CNC-MDSC Interface (CMI), the MDSC-PNC
Interface (MPI), and the Southbound Interface (SBI).
Paragraph (version B):
The "ietf-vpn-common" module I-D.ietf-opsawg-vpn-common includes a
set of identities, types, and groupings that are meant to be reused
by VPN-related YANG modules independently of the layer (e.g., Layer
2, Layer 3) and the type of the module (e.g., network model, service
model) including future revisions of existing models (e.g., RFC8299
or RFC8466).  The L3NM reuses these common types and groupings.
Paragraph (version B):
In order to avoid data duplication and to ease passing data between
layers when required (service layer to network layer and vice versa),
early versions of the L3NM reused many of the data nodes that are
defined in RFC8299.  Nevertheless, that approach was abandoned in
favor of the "ietf-vpn-common" module because that initial design was
interpreted as if the deployment of L3NM depends on L3SM, while this
is not the case.  For example, a service provider may decide to use
the L3NM to build its L3VPN services without exposing the L3SM.
Paragraph (version B):
The internal view of the service (i.e., L3NM) may be mapped to an
external view which is visible to customers: L3VPN Service YANG
data Model (L3SM) RFC8299.
Paragraph (version A):
A L3VPN involves nodes that are part of a topology managed by the
Service Provider Backbone network.  Such topology can be
represented as using the network topology module in RFC8345.
Paragraph (version B):
A L3VPN involves nodes that are part of a topology managed by the
service provider network.  Such topology can be represented as
using the network topology module in RFC8345.
Paragraph (version A):
Enterprise L3VPNs are one of the most demanded services for carriers,
and therefore, L3NM can be useful to automate the tasks of
provisioning and maintenance of these VPNs.  Templates and batch
processes can be built, and as a result many parameters are needed
for the creation from scratch of a VPN that can be abstracted to the
upper SDN layer and little manual intervention will be still
required.
Paragraph (version A):
Also common addition/removal of sites of an existing customer VPN can
benefit of using L3NM, by creation of workflows that either prune or
add nodes as required from the network data model object.
Paragraph (version B):
This section provides a non-exhaustive list of examples to illustrate
contexts where the L3NM can be used.
Paragraph (version B):
Enterprise L3VPNs are one of the most demanded services for carriers,
and therefore, L3NM can be useful to automate the provisioning and
maintenance of these VPNs.  Templates and batch processes can be
built, and as a result many parameters are needed for the creation
from scratch of a VPN that can be abstracted to the upper Software-
Defined Networking (SDN) RFC7426 layer and little manual intervention
will be still required.
Paragraph (version B):
Also common addition and/or removal of sites of an existing customer
VPN can benefit of using L3NM by creation of workflows that either
prune or add nodes as required from the network data mode.
Paragraph (version A):
For example, RTs shall be synchronized between PEs.  When every PE is
controlled by the same management system, RT allocation can be
performed by the system.  In cases where the service spans across
multiple management systems, this task of allocating RTs has to be
aligned across the domains, therefore, the service model must provide
a way to specify RTs.  In addition, RDs must also be synchronized to
avoid collisions in RD allocation between separate systems.  An
incorrect allocation might lead to the same RD and IP prefixes being
exported by different PE routers.
Paragraph (version A):
Multicast services over L3VPN can be implemented either using dual
PIM MVPNs (also known as, Draft Rosen model) RFC4364 or multiprotocol
BGP (MBGP)-based MVPNsRFC6514.  Both methods are supported and
equally effective, but the main difference is that MBGP-based MVPN
does not require multicast configuration on the service provider
backbone.  MBGP MVPNs employ the intra-autonomous system BGP control
plane and PIM sparse mode as the data plane.  The PIM state
information is maintained between the PE routers using the same
architecture that is used for unicast VPNs.
Paragraph (version B):
For example, route targets (RTs) shall be synchronized between PEs.
When all PEs are controlled by the same management system, RT
allocation can be performed by that management system.  In cases
where the service spans across multiple management systems, the task
of allocating RTs has to be aligned across the domains, therefore,
the service model must provide a way to specify RTs.  In addition,
route distinguishers (RDs) must also be synchronized to avoid
collisions in RD allocation between separate management systems.  An
incorrect allocation might lead to the same RD and IP prefixes being
exported by different PEs.
Paragraph (version B):
Multicast services over L3VPN can be implemented using dual PIM MVPNs
(also known as, Draft Rosen model) RFC4364 or multiprotocol BGP
(MBGP)-based MVPNsRFC6514.  Both methods are supported and equally
effective, but the main difference is that MBGP-based MVPN does not
require multicast configuration on the service provider network.
MBGP MVPNs employ the intra-autonomous system BGP control plane and
PIM sparse mode as the data plane.  The PIM state information is
maintained between PEs using the same architecture that is used for
unicast VPNs.
Paragraph (version A):
'cloud-identifier': This identifier refers to a cloud service.
Paragraph (version A):
'encryption-profile-identifier': An encryption profile refers to a
set of policies related to the encryption scheme(s) and setup that
can be applied when building and offering a VPN service.
Paragraph (version A):
'qos-profile-identifier': A QoS profile refers to as set of
policies such as classification, marking, and actions (e.g.,
RFC3644).
Paragraph (version A):
'bfd-profile-identifier': A Bidirectional Forwarding Detection
(BFD) profile refers to a set of BFD RFC5880 policies that can be
invoked when building a VPN service.
Paragraph (version A):
'forwarding-profile-identifier': A forwarding profile refers to
the policies that apply to the forwarding of packets conveyed
within a VPN.  Such policies may consist at applying Access
Control Lists (ACLs).
Paragraph (version A):
'routing-profile-identifier': A routing profile refers to a set of
routing policies that will be invoked (e.g., BGP policies).
Paragraph (version A):
In order to facilitate the identification of the service, 'customer-
name' and 'description' attributes may be provided.
Paragraph (version A):
'status': Allows the control of the operative and administrative
status of the service as a whole.
Paragraph (version A):
'vpn-id': Is an identifier that is used to uniquely identify the
L3VPN Service within L3NM scope.
Paragraph (version A):
'l3sm-vpn-id': Refers to an identifier of L3SM service.  This
identifier allows to easily correlate the (network) service as
built in the network with a service order.
Paragraph (version A):
'vpn-type': Indicate the VPN service signaling type.
Paragraph (version A):
'ie-profiles': Defines reusable import/export policies for the
same 'vpn-service'.  More details are provided in ie_profiles.
Paragraph (version A):
'underlay-transport': Describes the preference for the transport
technology to carry the traffic of the VPN service
(underlay_transport).
Paragraph (version A):
The 'vpn-node' is an abstraction that represents a set of policies
applied to a network node and that belong to a single 'vpn-service'.
A VPN service is typically built by adding instances of 'vpn-node' to
the 'vpn-nodes' container.
Paragraph (version A):
A 'vpn-node' contains 'vpn-network-accesses', which are the
interfaces attached to the VPN by which the customer traffic is
received.  Therefore, the customer sites are connected to the 'vpn-
network-accesses'.
Paragraph (version A):
The L3NM allows to track service status ('status') of a given VPN
service (service-status).  Both operational and administrative status
are maintained together with a timestamp.  For example, a service can
be created but not put into effect.
Paragraph (version A):
'admin' and 'ops' status can be used as trigger to detect service
anomalies.  For example, a service that is declared at the service
layer as active but still inactive at the network layer is an
indication that network provision actions are needed to align the
observed service with the expected service status.
Paragraph (version A):
The import and export profiles construct contains a list with
information related with route target and distinguishers (RTs and
RDs), grouped and identified by 'ie-profile-id'.  The identifier is
then referenced in one or multiple 'vpn-nodes' so the controller can
identify RTs and RDs to be configured for a given VRF.  The subtree
is shown in ie.
Paragraph (version A):
The model allows to indicate a preference for the underlay transport
technology when activating a L3VPN service (transport).  This
preference is especially useful in networks with multiple domains and
NNI types.  This version of the YANG module supports these options:
BGP, LDP, GRE, SR, SR-TE, and RSVP-TE as underlay transport
mechanisms.  Other profiles can be defined in the future.
Paragraph (version B):
This identifier refers to a profile that defines external
connectivity provided to a VPN service (or a subset of VPN sites).
An external connectivity may be access to Internet or restricted
connectivity such as access to a public/private cloud.
Paragraph (version B):
An encryption profile refers to a set of policies related to the
encryption scheme(s) and setup that can be applied when building
and offering a VPN service.
Paragraph (version B):
A Quality of Service (QoS) profile refers to as set of policies
such as classification, marking, and actions (e.g., RFC3644).
Paragraph (version B):
A Bidirectional Forwarding Detection (BFD) profile refers to a set
of BFD RFC5880 policies that can be invoked when building a VPN
service.
Paragraph (version B):
A forwarding profile refers to the policies that apply to the
forwarding of packets conveyed within a VPN.  Such policies may
consist, for example, at applying Access Control Lists (ACLs).
Paragraph (version B):
A routing profile refers to a set of routing policies that will be
invoked (e.g., BGP policies) when delivering the VPN service.
Paragraph (version B):
Is an identifier that is used to uniquely identify the L3VPN
service within L3NM scope.
Paragraph (version B):
Are used to associate a name and a description with the service in
order to facilitate the identification of the service.
Paragraph (version B):
Indicates the name of the customer who ordered the service.
Paragraph (version B):
Refers to an identifier of the L3SM service.  This identifier
allows to easily correlate the (network) service as built in the
network with a service order.
Paragraph (version B):
Indicates the VPN type (L3VPN).
Paragraph (version B):
Indicates the network topology for the service: hub-spoke, any-to-
any, and custom.  The network implementation of this attribute is
defined by the correct usage of import and export profiles.
Paragraph (version B):
Allows the control of the operative and administrative status of
the service as a whole.  The L3NM allows to track service status
('status') of a given VPN service.  Both operational and
administrative status are maintained together with a timestamp.
For example, a service can be created, but not put into effect.
Paragraph (version B):
Administrative and operational status can be used as trigger to
detect service anomalies.  For example, a service that is declared
at the service layer as active but still inactive at the network
layer is an indication that network provision actions are needed
to align the observed service with the expected service status.
Paragraph (version B):
Defines reusable import/export policies for the same 'vpn-
service'.
Paragraph (version B):
More details are provided in ie_profiles.
Paragraph (version B):
Describes the preference for the transport technology to carry the
traffic of the VPN service.  This preference is especially useful
in networks with multiple domains and Network-to-Network Interface
(NNI) types.  This version of the YANG module supports these
options: BGP, LDP, GRE, SR, SR-TE, and RSVP-TE as underlay
transport mechanisms.  Other profiles can be defined in the
future.
Paragraph (version B):
Indicates whether/how external connectivity is provided to the VPN
service.  Only a pointer to a local profile is supported in this
version.
Paragraph (version B):
Is an abstraction that represents a set of policies applied to a
network node and that belong to a single 'vpn-service'.  A VPN
service is typically built by adding instances of 'vpn-node' to
the 'vpn-nodes' container.
Paragraph (version B):
A 'vpn-node' contains 'vpn-network-accesses', which are the
interfaces attached to the VPN by which the customer traffic is
received.  Therefore, the customer sites are connected to the
'vpn-network-accesses'.
Paragraph (version B):
More details are provided in vpn_node.
Paragraph (version B):
The import and export profiles construct contains a list with
information related with route targets and distinguishers (RTs and
RDs), grouped and identified by 'ie-profile-id'.  The identifier is
then referenced in one or multiple 'vpn-nodes' (vpn_node) so the
controller can identify RTs and RDs to be configured for a given VRF.
The subtree is shown in ie.
Paragraph (version B):
Note that RDs can be explicitly configured or automatically assigned.
RD auto-assignment can also constrained by indicating an 'rd-pool-
name'.
Paragraph (version A):
local-autonomous-system: Refers to the autonomous system number
that is locally configured in the instance.  It can be overwritten
for specific purposes in the CE-PE BGP session.
Paragraph (version A):
maximum-routes: Set the maximum number of prefixes allowed in the
'vpn-node' instance.  This value is typically set in the service
request.
Paragraph (version A):
'rd' and 'vpn-targets': For the cases the logical resources are
managed outside the network controller, the model allows to
explicitely indicate the logical resources such as Route targets
(RTs) and Route Distinguishers (RDs) (RT,RD).
Paragraph (version A):
Multicast: Enable multicast traffic inside the VPN.  Refer to mc.
Paragraph (version B):
Refers to the autonomous system number that is locally configured
in the instance.  It can be overwritten for specific purposes in
the CE-PE BGP session.
Paragraph (version B):
Sets the maximum number of prefixes allowed in the 'vpn-node'
instance.  This value is typically set in the service request.
Paragraph (version B):
For the cases the logical resources are managed outside the
network controller, the model allows to explicitely indicate the
logical resources such as Route targets (RTs) and Route
Distinguishers (RDs) (RT,RD).
Paragraph (version B):
Enables multicast traffic inside the VPN.  Refer to mc.
Paragraph (version A):
Likewise, early versions of the L2NM reused many of the data nodes
that are defined in both L2SM and L3NM.  An example of L3NM groupings
reused in L3NM is shown in ex2.  This data nodes reuse was
interpreted as if the deployment of L2NM requires both L3NM; which is
not required.
Paragraph (version A):
I-D.ietf-opsawg-l3sm-l3nm and Layer 2 VPN Network Model (L2NM) I-
D.ietf-opsawg-l2nm: "ietf-vpn-common" (module).
Paragraph (version A):
The "ietf-vpn-common" module includes a set of identities, types, and
groupings that are meant to be reused by other VPN-related YANG
modules independently of their layer (e.g., Layer 2, Layer 3) and the
type of the module (e.g., network model, service model) including
future revisions (if any) of existing models (e.g., Layer 3 VPN
Service Model (L3SM) RFC8299 or Layer 2 VPN Service Model (L2SM)
RFC8466).
Paragraph (version B):
Likewise, early versions of the L2NM reused many of the data nodes
that are defined in both L2SM and L3NM.  An example of L3NM groupings
reused in L3NM is shown in ex2.  Such data nodes reuse was
interpreted as if the deployment of the L2NM requires the support of
the L3NM; which is not required.
Paragraph (version B):
I-D.ietf-opsawg-l3sm-l3nm and L2NM I-D.ietf-opsawg-l2nm: "ietf-vpn-
common" (module).
Paragraph (version B):
The "ietf-vpn-common" module includes a set of identities, types, and
groupings that are meant to be reused by other VPN-related YANG
modules independently of their layer (e.g., Layer 2, Layer 3) and the
type of the module (e.g., network model, service model) including
future revisions (if any) of existing models (e.g., L3SM RFC8299 or
L2SM RFC8466).
Paragraph (version A):
A YANG grouping that defines a set of QoS classification
policies based on various match Layer 3/4 criteria.
Paragraph (version B):
The "ietf-vpn-common" module defines a set of common VPN-related
features (e.g., encapsulation features such as RFC7348, multicast
RFC6513, or routing features such as OSPF RFC4577 or Bidirectional
Forwarding Detection (BFD) RFC5880) and identities (e.g., service
types RFC8365, VPN signaling types RFC5036 RFC3931, protocol types
RFC8277).
Paragraph (version A):
A YANG grouping that defines a set of profiles (encryption,
routing, forwarding) valid for any Layer 2/3 VPN.
Paragraph (version B):
A YANG grouping that defines a set of profiles (encryption,
routing, forwarding, etc.) valid for any Layer 2/3 VPN.  This
document does not make any assumption about the structure of
such profiles, but allows to "glue" a VPN service with other
parameters that can be required locally to provide added value
features to requesting customers.
Paragraph (version B):
For example, a service provider may provide an external
connectivity to a VPN customer (e.g., to a private or public
cloud, Internet).  Such service may involve tweaking filtering
and NAT rules (e.g., bind a Virtual Routing and Forwarding
(VRF) interface with a NAT instance as discussed in
Section 2.10 of RFC8512).  These added value features may be
bound to all or a subset of network accesses.  Some of these
added value features may be implemented in other nodes than PEs
(e.g., P node or event a dedicated node that hosts the NAT
function).
Paragraph (version B):
It is out of the scope of this document to elaborate the
structure of these profiles.
Paragraph (version A):
A YANG grouping that is used to group VPN nodes, VPN network
accesses, or sites.
Paragraph (version B):
A YANG grouping that A defines RT import-export rules used in a
BGP-enabled VPN (e.g., RFC4664).
Paragraph (version B):
A YANG grouping that is used to group VPN nodes, VPN network
accesses, or sites.  For example, diversity or redundancy
constraints can be applied on a per group basis.
Paragraph (version B):
A YANG grouping that defines a set of Quality of Service (QoS)
classification policies based on various match Layer 3/4
criteria.
Paragraph (version A):
Editor's Note: Check that RFCs cited in the reference statements
are included in the References Section and called out in the core
text.