draft-ietf-teas-actn-poi-applicability-02.txt   draft-ietf-teas-actn-poi-applicability-03.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet Draft TIM Internet Draft TIM
Intended status: Informational Jean-Francois Bouquier Intended status: Informational Jean-Francois Bouquier
Vodafone Vodafone
Italo Busi Italo Busi
Huawei Huawei
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Expires: November 2021 May 14, 2021 Expires: January 2022 July 12, 2021
Applicability of Abstraction and Control of Traffic Engineered Applicability of Abstraction and Control of Traffic Engineered
Networks (ACTN) to Packet Optical Integration (POI) Networks (ACTN) to Packet Optical Integration (POI)
draft-ietf-teas-actn-poi-applicability-02 draft-ietf-teas-actn-poi-applicability-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
This document considers the applicability of Abstraction and Control This document considers the applicability of Abstraction and Control
of TE Networks (ACTN) architecture to Packet Optical Integration of TE Networks (ACTN) architecture to Packet Optical Integration
(POI)in the context of IP/MPLS and Optical internetworking, (POI)in the context of IP/MPLS and Optical internetworking. It
identifying the YANG data models being defined by the IETF to identifies the YANG data models being defined by the IETF to support
support this deployment architecture as well as specific scenarios this deployment architecture and specific scenarios relevant for
relevant for Service Providers. Service Providers.
Existing IETF protocols and data models are identified for each Existing IETF protocols and data models are identified for each
multi-layer (packet over optical) scenario with particular focus on multi-layer (packet over optical) scenario with a specific focus on
the MPI (Multi-Domain Service Coordinator to Provisioning Network the MPI (Multi-Domain Service Coordinator to Provisioning Network
Controllers Interface)in the ACTN architecture. Controllers Interface)in the ACTN architecture.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Reference architecture and network scenario....................4 2. Reference architecture and network scenario....................4
2.1. L2/L3VPN Service Request in North Bound of MDSC...........8 2.1. L2/L3VPN Service Request North Bound of MDSC..............9
2.2. Service and Network Orchestration........................10 2.2. Service and Network Orchestration........................10
2.2.1. Hard Isolation......................................12 2.2.1. Hard Isolation......................................13
2.2.2. Shared Tunnel Selection.............................12 2.2.2. Shared Tunnel Selection.............................13
2.3. IP/MPLS Domain Controller and NE Functions...............13 2.3. IP/MPLS Domain Controller and NE Functions...............14
2.4. Optical Domain Controller and NE Functions...............15 2.4. Optical Domain Controller and NE Functions...............15
3. Interface protocols and YANG data models for the MPIs.........15 3. Interface protocols and YANG data models for the MPIs.........16
3.1. RESTCONF protocol at the MPIs............................15 3.1. RESTCONF protocol at the MPIs............................16
3.2. YANG data models at the MPIs.............................15 3.2. YANG data models at the MPIs.............................16
3.2.1. Common YANG data models at the MPIs.................16 3.2.1. Common YANG data models at the MPIs.................16
3.2.2. YANG models at the Optical MPIs.....................16 3.2.2. YANG models at the Optical MPIs.....................17
3.2.3. YANG data models at the Packet MPIs.................18 3.2.3. YANG data models at the Packet MPIs.................18
3.3. PCEP.....................................................18 3.3. PCEP.....................................................19
4. Multi-layer and multi-domain services scenarios...............19 4. Multi-layer and multi-domain services scenarios...............20
4.1. Scenario 1: inventory, service and network topology 4.1. Scenario 1: inventory, service and network topology
discovery.....................................................20 discovery.....................................................21
4.1.1. Inter-domain link discovery.........................21 4.1.1. Inter-domain link discovery.........................22
4.1.2. IP Link Setup Procedure.............................22 4.1.2. Multi-layer IP Link discovery.......................23
4.1.3. Inventory discovery.................................22 4.1.3. Inventory discovery.................................23
4.2. L2VPN/L3VPN establishment................................23 4.1.4. SR-TE paths discovery...............................24
5. Security Considerations.......................................24 4.2. Establishment of L2VPN/L3VPN with TE requirements........24
6. Operational Considerations....................................24 4.2.1. Optical Path Computation............................29
7. IANA Considerations...........................................24 4.2.2. Multi-layer IP Link Setup and Update................29
8. References....................................................24 4.2.3. SR-TE Path Setup and Update.........................30
8.1. Normative References.....................................24 5. Security Considerations.......................................30
8.2. Informative References...................................25 6. Operational Considerations....................................31
Appendix A. Multi-layer and multi-domain resiliency...........28 7. IANA Considerations...........................................31
A.1. Maintenance Window......................................28 8. References....................................................31
A.2. Router port failure.....................................28 8.1. Normative References.....................................31
Acknowledgments..................................................29 8.2. Informative References...................................33
Contributors.....................................................29 Appendix A. Multi-layer and multi-domain resiliency...........35
Authors' Addresses...............................................30 A.1. Maintenance Window......................................35
A.2. Router port failure.....................................35
Acknowledgments..................................................36
Contributors.....................................................36
Authors' Addresses...............................................38
1. Introduction 1. Introduction
The full automation of the management and control of Service The complete automation of the management and control of Service
Providers transport networks (IP/MPLS, Optical and also Microwave) Providers transport networks (IP/MPLS, optical, and microwave
is key for achieving the new challenges coming now with 5G as well transport networks) is vital for meeting emerging demand for high-
as with the increased demand in terms of business agility and bandwidth use cases, including 5G and fiber connectivity services.
mobility in a digital world. ACTN architecture, by abstracting the The Abstraction and Control of TE Networks (ACTN) architecture and
network complexity from Optical and IP/MPLS networks towards MDSC interfaces facilitate the automation and operation of complex
and then from MDSC towards OSS/BSS or Orchestration layer through Optical and IP/MPLS networks through standard interfaces and data
the use of standard interfaces and data models, is allowing a wide models. Thus allowing a wide range of transport connectivity
range of transport connectivity services that can be requested by services that can be requested by the upper layers fulfilling almost
the upper layers fulfilling almost any kind of service level any kind of service level requirements from a network perspective
requirements from a network perspective (e.g. physical diversity, (e.g. physical diversity, latency, bandwidth, topology, etc.)
latency, bandwidth, topology etc.)
Packet Optical Integration (POI) is an advanced use case of traffic Packet Optical Integration (POI) is an advanced use case of traffic
engineering. In wide area networks, a packet network based on the engineering. In wide-area networks, a packet network based on the
Internet Protocol (IP) and possibly Multiprotocol Label Switching Internet Protocol (IP), and often Multiprotocol Label Switching
(MPLS) is typically realized on top of an optical transport network (MPLS), is typically realized on top of an optical transport network
that uses Dense Wavelength Division Multiplexing (DWDM)(and that uses Dense Wavelength Division Multiplexing (DWDM)(and
optionally an Optical Transport Network (OTN)layer). In many optionally an Optical Transport Network (OTN)layer).
existing network deployments, the packet and the optical networks
are engineered and operated independently of each other. There are
technical differences between the technologies (e.g., routers vs.
optical switches) and the corresponding network engineering and
planning methods (e.g., inter-domain peering optimization in IP vs.
dealing with physical impairments in DWDM, or very different time
scales). In addition, customers needs can be different between a
packet and an optical network, and it is not uncommon to use
different vendors in both domains. Last but not least, state-of-the-
art packet and optical networks use sophisticated but complex
technologies, and for a network engineer it may not be trivial to be
a full expert in both areas. As a result, packet and optical
networks are often operated in technical and organizational silos.
This separation is inefficient for many reasons. Both capital In many existing network deployments, the packet and the optical
expenditure (CAPEX) and operational expenditure (OPEX) could be networks are engineered and operated independently. As a result,
significantly reduced by better integrating the packet and the there are technical differences between the technologies (e.g.,
optical network. Multi-layer online topology insight can speed up routers compared to optical switches) and the corresponding network
troubleshooting (e.g., alarm correlation) and network operation engineering and planning methods (e.g., inter-domain peering
(e.g., coordination of maintenance events), multi-layer offline optimization in IP, versus dealing with physical impairments in
topology inventory can improve service quality (e.g., detection of DWDM, or very different time scales). In addition, customers needs
diversity constraint violations) and multi-layer traffic engineering can be different between a packet and an optical network, and it is
can use the available network capacity more efficiently (e.g., not uncommon to use different vendors in both domains. The operation
coordination of restoration). In addition, provisioning workflows of these complex packet and optical networks is often siloed, as
can be simplified or automated as needed across layers (e.g, to these technology domains require specific skills sets.
achieve bandwidth on demand, or to perform maintenance events).
The packet/optical network deployment and operation separation are
inefficient for many reasons. Both capital expenditure (CAPEX) and
operational expenditure (OPEX) could be significantly reduced by
integrating the packet and the optical network. Multi-layer online
topology insight can speed up troubleshooting (e.g., alarm
correlation) and network operation (e.g., coordination of
maintenance events), multi-layer offline topology inventory can
improve service quality (e.g., detection of diversity constraint
violations) and multi-layer traffic engineering can use the
available network capacity more efficiently (e.g., coordination of
restoration). In addition, provisioning workflows can be simplified
or automated as needed across layers (e.g., to achieve bandwidth-on-
demand or to perform maintenance events).
ACTN framework enables this complete multi-layer and multi-vendor ACTN framework enables this complete multi-layer and multi-vendor
integration of packet and optical networks through MDSC and packet integration of packet and optical networks through MDSC and packet
and optical PNCs. and optical PNCs.
In this document, key scenarios for Packet Optical Integration (POI) In this document, critical scenarios for POI are described from the
are described from the packet service layer perspective. The packet service layer perspective and identify the required
objective is to explain the benefit and the impact for both the coordination between packet and optical layers to improve POI
packet and the optical layer, and to identify the required deployment and operation. Precise definitions of scenarios can help
coordination between both layers. Precise definitions of scenarios with achieving a common understanding across different disciplines.
can help with achieving a common understanding across different The focus of the scenarios are IP/MPLS networks operated as a client
disciplines. The focus of the scenarios are IP/MPLS networks of optical DWDM networks. The scenarios are ordered by increasing
operated as client of optical DWDM networks. The scenarios are the level of integration and complexity. For each multi-layer
ordered by increasing level of integration and complexity. For each scenario, the document analyzes how to use the interfaces and data
multi-layer scenario, the document analyzes how to use the models of the ACTN architecture.
interfaces and data models of the ACTN architecture.
Understanding the level of standardization and the possible gaps Understanding the level of standardization and the possible gaps
will help to better assess the feasibility of integration between IP will help assess the feasibility of integration between IP and
and Optical DWDM domain (and optionally OTN layer), in an end-to-end Optical DWDM domain (and optionally OTN layer) in an end-to-end
multi-vendor service provisioning perspective. multi-vendor service provisioning perspective.
2. Reference architecture and network scenario 2. Reference architecture and network scenario
This document analyses a number of deployment scenarios for Packet This document analyses several deployment scenarios for Packet and
and Optical Integration (POI) in which ACTN hierarchy is deployed to Optical Integration (POI) in which ACTN hierarchy is deployed to
control a multi-layer and multi-domain network, with two Optical control a multi-layer and multi-domain network, with two Optical
domains and two Packet domains, as shown in Figure 1: domains and two Packet domains, as shown in Figure 1:
+----------+ +----------+
| MDSC | | MDSC |
+-----+----+ +-----+----+
| |
+-----------+-----+------+-----------+ +-----------+-----+------+-----------+
| | | | | | | |
+----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+
skipping to change at page 5, line 37 skipping to change at page 5, line 37
\ Optical Domain 1 / \ Optical Domain 2 / \ Optical Domain 1 / \ Optical Domain 2 /
\ / \ / \ / \ /
+------------------------+ +--------------------------+ +------------------------+ +--------------------------+
Figure 1 - Reference Scenario Figure 1 - Reference Scenario
The ACTN architecture, defined in [RFC8453], is used to control this The ACTN architecture, defined in [RFC8453], is used to control this
multi-domain network where each Packet PNC (P-PNC) is responsible multi-domain network where each Packet PNC (P-PNC) is responsible
for controlling its IP domain, which can be either an Autonomous for controlling its IP domain, which can be either an Autonomous
System (AS), [RFC1930], or an IGP area within the same operator System (AS), [RFC1930], or an IGP area within the same operator
network, and each Optical PNC (O-PNC) is responsible for controlling network. Each Optical PNC (O-PNC) in the above topology is
its Optical Domain. responsible for controlling its Optical Domain.
The routers between IP domains can be either AS Boundary Routers The routers between IP domains can be either AS Boundary Routers
(ASBR) or Area Border Router (ABR): in this document the generic (ASBR) or Area Border Router (ABR): in this document, the generic
term Border Router (BR) is used to represent either an ASBR or a term Border Router (BR) is used to represent either an ASBR or a
ABR. ABR.
The MDSC is responsible for coordinating the whole multi-domain The MDSC is responsible for coordinating the whole multi-domain
multi-layer (Packet and Optical) network. A specific standard multi-layer (Packet and Optical) network. A specific standard
interface (MPI) permits MDSC to interact with the different interface (MPI) permits MDSC to interact with the different
Provisioning Network Controller (O/P-PNCs). Provisioning Network Controller (O/P-PNCs).
The MPI interface presents an abstracted topology to MDSC hiding The MPI interface presents an abstracted topology to MDSC hiding
technology-specific aspects of the network and hiding topology technology-specific aspects of the network and hiding topology
skipping to change at page 6, line 31 skipping to change at page 6, line 38
o The interfaces between the Border Routers (BRs) are "Ethernet" o The interfaces between the Border Routers (BRs) are "Ethernet"
physical interfaces. physical interfaces.
This version of the document assumes that the IP Link supported by This version of the document assumes that the IP Link supported by
the Optical network are always intra-AS (PE-BR, intra-domain BR-BR, the Optical network are always intra-AS (PE-BR, intra-domain BR-BR,
PE-P, BR-P, or P-P) and that the BRs are co-located and connected by PE-P, BR-P, or P-P) and that the BRs are co-located and connected by
an IP Link supported by an Ethernet physical link. an IP Link supported by an Ethernet physical link.
The possibility to setup inter-AS/inter-area IP Links (e.g., The possibility to setup inter-AS/inter-area IP Links (e.g.,
inter-domain BR-BR or PE-PE), supported by Optical network, is for inter-domain BR-BR or PE-PE), supported by optical network, is for
further study. further study.
Therefore, if inter-domain links between the Optical domains exist, Therefore, if inter-domain links between the Optical domains exist,
they would be used to support multi-domain Optical services, which they would be used to support multi-domain Optical services, which
are outside the scope of this document. are outside the scope of this document.
The Optical NEs within the optical domains can be ROADMs or OTN The Optical NEs within the optical domains can be ROADMs or OTN
switches, with or without a ROADM. switches, with or without a ROADM.
The MDSC in Figure 1 is responsible for multi-domain and multi-layer The MDSC in Figure 1 is responsible for multi-domain and multi-layer
coordination across multiple Packet and Optical domains, as well as coordination across multiple Packet and Optical domains, as well as
to provide L2/L3VPN services. to provide L2/L3VPN services.
Although the new technologies (e.g. QSFP-DD ZR 400G) are making Although the new optical technologies (e.g. QSFP-DD ZR 400G)
convenient to fit the DWDM pluggable interfaces on the Routers, the providing DWDM pluggable interfaces on the Routers, the deployment
deployment of those pluggable is not yet widely adopted by the of those pluggable optics is not yet widely adopted by the
operators. The reason is that most of operators are not yet ready to operators. The reason is that most operators are not yet ready to
manage Packet and Transport networks in a unified single domain. As manage Packet and Transport networks in a single unified domain. As
a consequence, this draft is not addressing the unified scenario. a consequence, this draft is not addressing the unified scenario.
This matter will be described in a different draft. Instead, the unified use case will be described in a different
draft.
From an implementation perspective, the functions associated with From an implementation perspective, the functions associated with
MDSC and described in [RFC8453] may be grouped in different ways. MDSC and described in [RFC8453] may be grouped in different ways.
1. Both the service- and network-related functions are collapsed into 1. Both the service- and network-related functions are collapsed into
a single, monolithic implementation, dealing with the end customer a single, monolithic implementation, dealing with the end customer
service requests, received from the CMI (Customer MDSC Interface), service requests received from the CMI (Customer MDSC Interface)
and the adaptation to the relevant network models. Such case is and adapting the relevant network models. An example is
represented in Figure 2 of [RFC8453] represented in Figure 2 of [RFC8453]
2. An implementation can choose to split the service-related and the 2. An implementation can choose to split the service-related and the
network-related functions in different functional entities, as network-related functions into different functional entities, as
described in [RFC8309] and in section 4.2 of [RFC8453]. In this described in [RFC8309] and in section 4.2 of [RFC8453]. In this
case, MDSC is decomposed into a top-level Service Orchestrator, case, MDSC is decomposed into a top-level Service Orchestrator,
interfacing the customer via the CMI, and into a Network interfacing the customer via the CMI, and into a Network
Orchestrator interfacing at the southbound with the PNCs. The Orchestrator interfacing at the southbound with the PNCs. The
interface between the Service Orchestrator and the Network interface between the Service Orchestrator and the Network
Orchestrator is not specified in [RFC8453]. Orchestrator is not specified in [RFC8453].
3. Another implementation can choose to split the MDSC functions 3. Another implementation can choose to split the MDSC functions
between an H-MDSC responsible for packet-optical multi-layer between an H-MDSC responsible for packet-optical multi-layer
coordination, interfacing with one Optical L-MDSC, providing coordination, interfacing with one Optical L-MDSC, providing
multi-domain coordination between the O-PNCs and one Packet multi-domain coordination between the O-PNCs and one Packet
L-MDSC, providing multi-domain coordination betweeh the P-PNCs L-MDSC, providing multi-domain coordination betweeh the P-PNCs
(see for example Figure 9 of [RFC8453]). (see for example Figure 9 of [RFC8453]).
4. Another implementation can also choose to combine the MDSC and the 4. Another implementation can also choose to combine the MDSC and the
P-PNC functions together. P-PNC functions together.
Please note that in current service provider's network deployments, Please note that in the current service provider's network
at the North Bound of the MDSC, instead of a CNC, typically there is deployments, at the North Bound of the MDSC, instead of a CNC,
an OSS/Orchestration layer. In this case, the MDSC would implement typically there is an OSS/Orchestration layer. In this case, the
only the Network Orchestration functions, as in [RFC8309] and MDSC would implement only the Network Orchestration functions, as in
described in point 2 above. In this case, the MDSC is dealing with [RFC8309] and described in point 2 above. In this case, the MDSC is
the network services requests received from the OSS/Orchestration dealing with the network services requests received from the
layer. OSS/Orchestration layer.
[Editors'note:] Check for a better term to define the network [Editors'note:] Check for a better term to define the network
services. It may be worthwhile defining what are the customer and services. It may be worthwhile defining what are the customer and
network services. network services.
The OSS/Orchestration layer is a key part of the architecture The OSS/Orchestration layer is a vital part of the architecture
framework for a service provider: framework for a service provider:
o to abstract (through MDSC and PNCs) the underlying transport o to abstract (through MDSC and PNCs) the underlying transport
network complexity to the Business Systems Support layer network complexity to the Business Systems Support layer;
o to coordinate NFV, Transport (e.g. IP, Optical and Microwave o to coordinate NFV, Transport (e.g. IP, Optical and Microwave
networks), Fixed Acess, Core and Radio domains enabling full networks), Fixed Acess, Core and Radio domains enabling full
automation of end-to-end services to the end customers. automation of end-to-end services to the end customers;
o to enable catalogue-driven service provisioning from external o to enable catalogue-driven service provisioning from external
applications (e.g. Customer Portal for Enterprise Business applications (e.g. Customer Portal for Enterprise Business
services) orchestrating the design and lifecycle management of services), orchestrating the design and lifecycle management of
these end-to-end transport connectivity services, consuming IP these end-to-end transport connectivity services, consuming IP
and/or Optical transport connectivity services upon request. and/or Optical transport connectivity services upon request.
The functionality of the OSS/Orchestration layer as well as the The functionality of the OSS/Orchestration layer and the interface
interface toward the MDSC are usually operator-specific and outside toward the MDSC are usually operator-specific and outside the scope
the scope of this draft. This document assumes that the of this draft. For example, this document assumes that the
OSS/Orchestrator requests MDSC to setup L2VPN/L3VPN services through OSS/Orchestrator requests MDSC to set up L2VPN/L3VPN services
mechanisms which are outside the scope of the draft. through mechanisms that are outside the scope of this document.
There are two main cases when MDSC coordination of underlying PNCs There are two prominent cases when MDSC coordination of underlying
in POI context is initiated: PNCs for POI networking is initiated:
o Initiated by a request from the OSS/Orchestration layer to setup o Initiated by a request from the OSS/Orchestration layer to setup
L2VPN/L3VPN services that requires multi-layer/multi-domain L2VPN/L3VPN services that requires multi-layer/multi-domain
coordination. coordination;
o Initiated by the MDSC itself to perform multi-layer/multi-domain o Initiated by the MDSC itself to perform multi-layer/multi-domain
optimizations and/or maintenance works, beyond discovery (e.g. optimizations and/or maintenance activities (e.g. rerouting LSPs
rerouting LSPs with their associated services when putting a with their associated services when putting a resource, like a
resource, like a fibre, in maintenance mode during a maintenance fibre, in maintenance mode during a maintenance window).
window). Different to service fulfillment, the workflows then are Unlike service fulfillment, these workflows are not related to a
not related at all to a service provisioning request being service provisioning request being received from
received from the OSS/Orchestration layer. the OSS/Orchestration layer.
Above two MDSC workflow cases are in the scope of this draft. The The two aforemetioned MDSC workflow cases are in the scope of this
workflow initiation is transparent at the MPI. draft. The workflow initiation is transparent at the MPI.
2.1. L2/L3VPN Service Request in North Bound of MDSC 2.1. L2/L3VPN Service Request North Bound of MDSC
As explained in section 2, the OSS/Orchestration layer can request As explained in section 2, the OSS/Orchestration layer can request
the MDSC to setup of L2/L3VPN services (with or without TE the MDSC to setup L2/L3VPN services (with or without TE
requirements). requirements).
Although the interface between the OSS/Orchestration layer is Although the OSS/Orchestration layer interface is usually operator-
usually operator-specific, ideally it would be using a RESTCONF/YANG specific, typically it would be using a RESTCONF/YANG interface with
interface with more abstracted version of the MPI YANG data models a more abstracted version of the MPI YANG data models used for
used for network configuration (e.g. L3NM, L2NM). network configuration (e.g. L3NM, L2NM).
Figure 2 shows an example of a possible control flow between the Figure 2 shows an example of possible control flow between the
OSS/Orchestration layer and the MDSC to instantiate L2/L3VPN OSS/Orchestration layer and the MDSC to instantiate L2/L3VPN
services, using the YANG models under definition in [VN], [L2NM], services, using the YANG models under the definition in [VN],
[L3NM] and [TSM]. [L2NM], [L3NM] and [TSM].
+-------------------------------------------+ +-------------------------------------------+
| | | |
| OSS/Orchestration layer | | OSS/Orchestration layer |
| | | |
+-----------------------+-------------------+ +-----------------------+-------------------+
| |
1.VN 2. L2/L3NM & | ^ 1.VN 2. L2/L3NM & | ^
| TSM | | | TSM | |
| | | | | | | |
skipping to change at page 9, line 26 skipping to change at page 9, line 42
| |
+-----------------------+-------------------+ +-----------------------+-------------------+
| | | |
| MDSC | | MDSC |
| | | |
+-------------------------------------------+ +-------------------------------------------+
Figure 2 Service Request Process Figure 2 Service Request Process
o The VN YANG model [VN], whose primary focus is the CMI, can also o The VN YANG model [VN], whose primary focus is the CMI, can also
be used to provide VN Service configuration from a orchestrated provide VN Service configuration from an orchestrated
connectivity service point of view, when the L2/L3VPN service has connectivity service point of view when the L2/L3VPN service has
TE requirements. This model is not used to setup L2/L3VPN service TE requirements. However, this model is not used to setup
with no TE requirements. L2/L3VPN service with no TE requirements.
o It provides the profile of VN in terms of VN members, each of o It provides the profile of VN in terms of VN members, each of
which corresponds to an edge-to-edge link between customer which corresponds to an edge-to-edge link between customer
end-points (VNAPs). It also provides the mappings between the end-points (VNAPs). It also provides the mappings between the
VNAPs with the LTPs and between the connectivity matrix with VNAPs with the LTPs and the connectivity matrix with the VN
the VN member from which the associated traffic matrix (e.g., member. The associated traffic matrix (e.g., bandwidth,
bandwidth, latency, protection level, etc.) of VN member is latency, protection level, etc.) of VN member is expressed
expressed (i.e., via the TE-topology's connectivity matrix). (i.e., via the TE-topology's connectivity matrix).
o The model also provides VN-level preference information o The model also provides VN-level preference information
(e.g., VN member diversity) and VN-level admin-status and (e.g., VN member diversity) and VN-level admin-status and
operational-status. operational-status.
o The L2NM YANG model [L2NM], whose primary focus is the MPI, can o The L2NM YANG model [L2NM], whose primary focus is the MPI, can
also be used to provide L2VPN service configuration and site also be used to provide L2VPN service configuration and site
information, from a orchestrated connectivity service point of information, from a orchestrated connectivity service point of
view. view.
skipping to change at page 10, line 10 skipping to change at page 10, line 35
view. view.
o The TE & Service Mapping YANG model [TSM] provides TE-service o The TE & Service Mapping YANG model [TSM] provides TE-service
mapping as well as site mapping. mapping as well as site mapping.
o TE-service mapping provides the mapping between a L2/L3VPN o TE-service mapping provides the mapping between a L2/L3VPN
instance and the corresponding VN instances. instance and the corresponding VN instances.
o The TE-service mapping also provides the service mapping o The TE-service mapping also provides the service mapping
requirement type as to how each L2/L3VPN/VN instance is requirement type as to how each L2/L3VPN/VN instance is
created with respect to the underlay TE tunnels (e.g., created concerning the underlay TE tunnels (e.g., whether
whether they require a new and isolated set of TE underlay they require a new and isolated set of TE underlay tunnels or
tunnels or not). See Section 2.2 for detailed discussion on not). See Section 2.2 for a detailed discussion on the
the mapping requirement types. mapping requirement types.
o Site mapping provides the site reference information across o Site mapping provides the site reference information across
L2/L3VPN Site ID, VN Access Point ID, and the LTP of the L2/L3VPN Site ID, VN Access Point ID, and the LTP of the
access link. access link.
2.2. Service and Network Orchestration 2.2. Service and Network Orchestration
From a functional standpoint, MDSC represented in Figure 2 From a functional standpoint, MDSC represented in Figure 2
interfaces with the OSS/Orchestration layer and decouples L2/L3VPN interfaces with the OSS/Orchestration layer and decoupled L2/L3VPN
service configuration functions from network configuration service configuration functions from network configuration
functions. Therefore in this document the MDSC performs the functions. Therefore in this document, the MDSC performs the
functions of the Network Orchestrator, as defined in [RFC 8309]. functions of the Network Orchestrator, as defined in [RFC 8309].
One of the important MDSC functions is to identify which TE Tunnels One of the important MDSC functions is to identify which TE Tunnels
should carry the L2/L3VPN traffic (e.g., from TE & Service Mapping should carry the L2/L3VPN traffic (e.g., from TE & Service Mapping
configuration) and to relay this information to the P-PNCs, to configuration) and to relay this information to the P-PNCs, to
ensure the PEs' forwarding tables (e.g., VRF) are properly ensure the PEs' forwarding tables (e.g., VRF) are properly
populated, according to the TE binding requirement for the L2/L3VPN. populated, according to the TE binding requirement for the L2/L3VPN.
TE binding requirement types [TSM] are: TE binding requirement types [TSM] are:
1. Hard Isolation with deterministic latency: The L2/L3VPN service 1. Hard Isolation with deterministic latency: The L2/L3VPN service
requires a set of dedicated TE Tunnels providing deterministic requires a set of dedicated TE Tunnels providing deterministic
latency performances and that cannot be not shared with other latency performances and that cannot be not shared with other
services, nor compete for bandwidth with other Tunnels. services, nor compete for bandwidth with other Tunnels.
2. Hard Isolation: This is similar to the above case without 2. Hard Isolation: This is similar to the above case without
deterministic latency requirements. deterministic latency requirements.
3. Soft Isolation: The L2/L3VPN service requires a set of dedicated 3. Soft Isolation: The L2/L3VPN service requires a set of dedicated
MPLS-TE tunnels which cannot be shared with other services, but MPLS-TE tunnels that cannot be shared with other services, but
which could compete for bandwidth with other Tunnels. which could compete for bandwidth with other Tunnels.
4. Sharing: The L2/L3VPN service allows sharing the MPLS-TE Tunnels 4. Sharing: The L2/L3VPN service allows sharing the MPLS-TE Tunnels
supporting it with other services. supporting it with other services.
For the first three types, there could be additional TE binding There could be additional TE binding requirements for the first
requirements with respect to different VN members of the same VN (on three types with respect to different VN members of the same VN (on
how different VN members, belonging to the same VN, can share or not how different VN members, belonging to the same VN, can share or not
network resources). For the first two cases, VN members can be network resources). For the first two cases, VN members can be
hard-isolated, soft-isolated, or shared. For the third case, VN hard-isolated, soft-isolated, or shared. For the third case, VN
members can be soft-isolated or shared. members can be soft-isolated or shared.
In order to fulfill the the L2/L3VPN end-to-end TE requirements, In order to fulfil the L2/L3VPN end-to-end TE requirements,
including the TE binding requirements, the MDSC needs to perform including the TE binding requirements, the MDSC needs to perform
multi-layer/multi-domain path computation to select the BRs, the multi-layer/multi-domain path computation to select the BRs, the
intra-domain MPLS-TE Tunnels and the intra-domain Optical Tunnels. intra-domain MPLS-TE Tunnels and the intra-domain Optical Tunnels.
Depending on the knowledge that MDSC has of the topology and Depending on the knowledge that MDSC has of the topology and
configuration of the underlying network domains, three models for configuration of the underlying network domains, three models for
performing path computation are possible: performing path computation are possible:
1. Summarization: MDSC has an abstracted TE topology view of all of 1. Summarization: MDSC has an abstracted TE topology view of all of
the underlying domains, both packet and optical. MDSC does not the underlying domains, both packet and optical. MDSC does not
skipping to change at page 11, line 30 skipping to change at page 12, line 19
delegates the P-PNCs and O-PNCs to perform a local path delegates the P-PNCs and O-PNCs to perform a local path
computation within their controlled domains and it uses the computation within their controlled domains and it uses the
information returned by the P-PNCs and O-PNCs to compute the information returned by the P-PNCs and O-PNCs to compute the
optimal multi-domain/multi-layer path. optimal multi-domain/multi-layer path.
This model presents an issue to P-PNC, which does not have the This model presents an issue to P-PNC, which does not have the
capability of performing a single-domain/multi-layer path capability of performing a single-domain/multi-layer path
computation (that is, P-PNC does not have any possibility to computation (that is, P-PNC does not have any possibility to
retrieve the topology/configuration information from the Optical retrieve the topology/configuration information from the Optical
controller). A possible solution could be to include a CNC controller). A possible solution could be to include a CNC
function in the P-PNC to request the MDSC multi-domain Optical function in the P-PNC to request the MDSC multi-domain Optical
path computation, as shown in Figure 10 of [RFC8453]. Another path computation, as shown in Figure 10 of [RFC8453].
possible solution could be to rely on the MDSC recursive
hierarchy, as defined in section 4.1 of [RFC8453], where, for
each domain, a "lower-level MDSC" (L-MDSC) provides the essential
multi-layer correlation and the "higher-level MDSC" (H-MDSC)
provides the multi-domain coordination.
2. Partial summarization: MDSC has full visibility of the TE 2. Partial summarization: MDSC has full visibility of the TE
topology of the packet network domains and an abstracted view of topology of the packet network domains and an abstracted view of
the TE topology of the optical network domains. the TE topology of the optical network domains.
MDSC then has only the capability of performing multi- MDSC then has only the capability of performing multi-
domain/single-layer path computation for the packet layer (the domain/single-layer path computation for the packet layer (the
path can be computed optimally for the two packet domains). path can be computed optimally for the two packet domains).
Therefore MDSC still needs to delegate the O-PNCs to perform Therefore MDSC still needs to delegate the O-PNCs to perform
local path computation within their respective domains and it local path computation within their respective domains and it
uses the information received by the O-PNCs, together with its TE uses the information received by the O-PNCs, together with its TE
skipping to change at page 12, line 24 skipping to change at page 13, line 7
vendor-specific optical attributes (which may be different in the vendor-specific optical attributes (which may be different in the
two domains if they are provided by different vendors). two domains if they are provided by different vendors).
The current version of this draft assumes that MDSC supports at The current version of this draft assumes that MDSC supports at
least model #2 (Partial summarization). least model #2 (Partial summarization).
[Note: check with opeerators for some references on real deployment] [Note: check with opeerators for some references on real deployment]
2.2.1. Hard Isolation 2.2.1. Hard Isolation
For example, when "Hard Isolation with or w/o deterministic latency" For example, when "Hard Isolation with, or without, deterministic
TE binding requirement is applied for a L2/L3VPN, new Optical latency" TE binding requirement is applied for a L2/L3VPN, new
Tunnels need to be setup to support dedicated IP Links between PEs Optical Tunnels need to be setup to support dedicated IP Links
and BRs. between PEs and BRs.
The MDSC needs to identify the set of IP/MPLS domains and their BRs. The MDSC needs to identify the set of IP/MPLS domains and their BRs.
This requires the MDSC to request each O-PNC to compute the This requires the MDSC to request each O-PNC to compute the
intra-domain optical paths between each PEs/BRs pairs. intra-domain optical paths between each PEs/BRs pairs.
When requesting optical path computation to the O-PNC, the MDSC When requesting optical path computation to the O-PNC, the MDSC
needs to take into account the inter-layer peering points, such as needs to take into account the inter-layer peering points, such as
the interconnections between the PE/BR nodes and the edge Optical the interconnections between the PE/BR nodes and the edge Optical
nodes (e.g., using the inter-layer lock or the transitional link nodes (e.g., using the inter-layer lock or the transitional link
information, defined in [RFC8795]). information, defined in [RFC8795]).
skipping to change at page 12, line 49 skipping to change at page 13, line 32
When the optimal multi-layer/multi-domain path has been computed, When the optimal multi-layer/multi-domain path has been computed,
the MDSC requests each O-PNC to setup the selected Optical Tunnels the MDSC requests each O-PNC to setup the selected Optical Tunnels
and P-PNC to setup the intra-domain MPLS-TE Tunnels, over the and P-PNC to setup the intra-domain MPLS-TE Tunnels, over the
selected Optical Tunnels. MDSC also properly configures its BGP selected Optical Tunnels. MDSC also properly configures its BGP
speakers and PE/BR forwarding tables to ensure that the VPN traffic speakers and PE/BR forwarding tables to ensure that the VPN traffic
is properly forwarded. is properly forwarded.
2.2.2. Shared Tunnel Selection 2.2.2. Shared Tunnel Selection
In case of shared tunnel selection, the MDSC needs to check if there In case of shared tunnel selection, the MDSC needs to check if there
is multi-domain path which can support the L2/L3VPN end-to-end TE is a multi-domain path which can support the L2/L3VPN end-to-end TE
service requirements (e.g., bandwidth, latency, etc.) using existing service requirements (e.g., bandwidth, latency, etc.) using existing
intra-domain MPLS-TE tunnels. intra-domain MPLS-TE tunnels.
If such a path is found, the MDSC selects the optimal path from the If such a path is found, the MDSC selects the optimal path from the
candidate pool and request each P-PNC to setup the L2/L3VPN service candidate pool and request each P-PNC to setup the L2/L3VPN service
using the selected intra-domain MPLS-TE tunnel, between PE/BR nodes. using the selected intra-domain MPLS-TE tunnel, between PE/BR nodes.
Otherwise, the MDSC should detect if the multi-domain path can be Otherwise, the MDSC should detect if the multi-domain path can be
setup using existing intra-domain MPLS-TE tunnels with modifications setup using existing intra-domain MPLS-TE tunnels with modifications
(e.g., increasing the tunnel bandwidth) or setting up new intra- (e.g., increasing the tunnel bandwidth) or setting up new intra-
domain MPLS-TE tunnel(s). domain MPLS-TE tunnel(s).
The modification of an existing MPLS-TE Tunnel as well as the setup The modification of an existing MPLS-TE Tunnel and the setup of a
of a new MPLS-TE Tunnel may also require multi-layer coordination new MPLS-TE Tunnel may also require multi-layer coordination e.g.,
e.g., in case the available bandwidth of underlying Optical Tunnels in case the available bandwidth of underlying Optical Tunnels is not
is not sufficient. Based on multi-domain/multi-layer path sufficient. Based on multi-domain/multi-layer path computation, the
computation, the MDSC can decide for example to modify the bandwidth MDSC can decide for example to modify the bandwidth of an existing
of an existing Optical Tunnel (e.g., ODUflex bandwidth increase) or Optical Tunnel (e.g., ODUflex bandwidth increase) or to setup new
to setup new Optical Tunnels to be used as additional LAG members of Optical Tunnels to be used as additional LAG members of an existing
an existing IP Link or as new IP Links to re-route the MPLS-TE IP Link or as new IP Links to re-route the MPLS-TE Tunnel.
Tunnel.
In all the cases, the labels used by the end-to-end tunnel are In all the cases, the labels used by the end-to-end tunnel are
distributed in the PE and BR nodes by BGP. The MDSC is responsible distributed in the PE and BR nodes by BGP. The MDSC is responsible
to configure the BGP speakeers in each P-PNC, if needed. to configure the BGP speakers in each P-PNC, if needed.
2.3. IP/MPLS Domain Controller and NE Functions 2.3. IP/MPLS Domain Controller and NE Functions
IP/MPLS networks are assumed to have multiple domains, where each IP/MPLS networks are assumed to have multiple domains. Each domain,
domain, corresponding to either an IGP area or an Autonomous System corresponding to either an IGP area or an Autonomous System (AS)
(AS) within the same operator network, is controlled by an IP/MPLS within the same operator network, is controlled by an IP/MPLS domain
domain controller (P-PNC). controller (P-PNC).
Among the functions of the P-PNC, there are the setup or Among the functions of the P-PNC, there are the setup or
modification of the intra-domain MPLS-TE Tunnels, between PEs and modification of the intra-domain MPLS-TE Tunnels, between PEs and
BRs, and the configuration of the VPN services, such as the VRF in BRs, and the configuration of the VPN services, such as the VRF in
the PE nodes, as shown in Figure 3: the PE nodes, as shown in Figure 3:
+------------------+ +------------------+ +------------------+ +------------------+
| | | | | | | |
| P-PNC1 | | P-PNC2 | | P-PNC1 | | P-PNC2 |
| | | | | | | |
skipping to change at page 14, line 26 skipping to change at page 14, line 44
\ / \ / \ / \ /
\ Domain 1 / \ Domain 2 / \ Domain 1 / \ Domain 2 /
+---------------------+ +---------------------+ +---------------------+ +---------------------+
End-to-end tunnel End-to-end tunnel
<-------------------------------------------------> <------------------------------------------------->
Figure 3 IP/MPLS Domain Controller & NE Functions Figure 3 IP/MPLS Domain Controller & NE Functions
It is assumed that BGP is running in the inter-domain IP/MPLS It is assumed that BGP is running in the inter-domain IP/MPLS
networks for L2/L3VPN and that the P-PNC controller is also networks for L2/L3VPN. The P-PNC controller is also responsible for
responsible for configuring the BGP speakers within its control configuring the BGP speakers within its control domain, if
domain, if necessary. necessary.
The BGP would be responsible for the label distribution of the The BGP would be responsible for the end-to-end tunnel label
end-to-end tunnel on PE and BR nodes. The MDSC is responsible for distribution on PE and BR nodes. The MDSC is responsible for
the selection of the BRs and of the intra-domain MPLS-TE Tunnels selecting the BRs and the intra-domain MPLS-TE Tunnels between PE/BR
between PE/BR nodes. nodes.
If new MPLS-TE Tunnels are needed or mofications (e.g., bandwidth If new MPLS-TE Tunnels are needed or modifications (e.g., bandwidth
ingrease) to existing MPLS_TE Tunnels are needed, as outlined in increase) to existing MPLS_TE Tunnels are needed, as outlined in
section 2.2, the MDSC would request their setup or modifications to section 2.2, the MDSC would request their setup or modifications to
the P-PNCs (step 1 in Figure 3). Then the MDSC would request the the P-PNCs (step 1 in Figure 3). Then the MDSC would request the
P-PNC to configure the VPN, including the selection of the P-PNC to configure the VPN, including selecting the intra-domain TE
intra-domain TE Tunnel (step 2 in Figure 3). Tunnel (step 2 in Figure 3).
The P-PNC should configure, using mechanisms outside the scope of The P-PNC should configure, using mechanisms outside the scope of
this document, the ingress PE forwarding table, e.g., the VRF, to this document, the ingress PE forwarding table, e.g., the VRF, to
forward the VPN traffic, received from the CE, with the following forward the VPN traffic, received from the CE, with the following
three labels: three labels:
o VPN label: assigned by the egress PE and distributed by BGP; o VPN label: assigned by the egress PE and distributed by BGP;
o end-to-end LSP label: assigned by the egress BR, selected by the o end-to-end LSP label: assigned by the egress BR, selected by the
MDSC, and distributed by BGP; MDSC, and distributed by BGP;
o MPLS-TE tunnel label, assigned by the next hop P node of the o MPLS-TE tunnel label, assigned by the next hop P node of the
tunnel selected by the MDSC and distributed by mechanism internal tunnel selected by the MDSC and distributed by mechanism internal
to the IP/MPLS domain (e.g., RSVP-TE). to the IP/MPLS domain (e.g., RSVP-TE).
2.4. Optical Domain Controller and NE Functions 2.4. Optical Domain Controller and NE Functions
Optical network provides the underlay connectivity services to The optical network provides the underlay connectivity services to
IP/MPLS networks. The coordination of Packet/Optical multi-layer is IP/MPLS networks. The coordination of Packet/Optical multi-layer is
done by the MDSC, as shown in Figure 1. done by the MDSC, as shown in Figure 1.
The O-PNC is responsible to: The O-PNC is responsible to:
o provide to the MDSC an abstract TE topology view of its o provide to the MDSC an abstract TE topology view of its
underlying optical network resources; underlying optical network resources;
o perform single-domain local path computation, when requested by o perform single-domain local path computation, when requested by
the MDSC; the MDSC;
o perform Optical Tunnel setup, when requested by the MDSC. o perform Optical Tunnel setup, when requested by the MDSC.
The mechanisms used by O-PNC to perform intra-domain topology The mechanisms used by O-PNC to perform intra-domain topology
discovery and path setup are usually vendor-speicific and outside discovery and path setup are usually vendor-specific and outside the
the scope of this document. scope of this document.
Depending on the type of optical network, TE topology abstraction, Depending on the type of optical network, TE topology abstraction,
path compution and path setup can be single-layer (either OTN or path computation and path setup can be single-layer (either OTN or
WDM) or multi-layer OTN/WDM. In the latter case, the multi-layer WDM) or multi-layer OTN/WDM. In the latter case, the multi-layer
coordination between the OTN and WDM layers is performed by the coordination between the OTN and WDM layers is performed by the
O-PNC. O-PNC.
3. Interface protocols and YANG data models for the MPIs 3. Interface protocols and YANG data models for the MPIs
This section describes general assumptions which are applicable at This section describes general assumptions applicable at all the MPI
all the MPI interfaces, between each PNC (Optical or Packet) and the interfaces, between each PNC (Optical or Packet) and the MDSC, and
MDSC, and also to all the scenarios discussed in this document. all the scenarios discussed in this document.
3.1. RESTCONF protocol at the MPIs 3.1. RESTCONF protocol at the MPIs
The RESTCONF protocol, as defined in [RFC8040], using the JSON The RESTCONF protocol, as defined in [RFC8040], using the JSON
representation, defined in [RFC7951], is assumed to be used at these representation defined in [RFC7951], is assumed to be used at these
interfaces. Extensions to RESTCONF, as defined in [RFC8527], to be interfaces. In addition, extensions to RESTCONF, as defined in
compliant with Network Management Datastore Architecture (NMDA) [RFC8527], to be compliant with Network Management Datastore
defined in [RFC8342], are assumed to be used as well at these MPI Architecture (NMDA) defined in [RFC8342], are assumed to be used as
interfaces and also at CMI interfaces. well at these MPI interfaces and also at CMI interfaces.
3.2. YANG data models at the MPIs 3.2. YANG data models at the MPIs
The data models used on these interfaces are assumed to use the YANG The data models used on these interfaces are assumed to use the YANG
1.1 Data Modeling Language, as defined in [RFC7950]. 1.1 Data Modeling Language, as defined in [RFC7950].
3.2.1. Common YANG data models at the MPIs 3.2.1. Common YANG data models at the MPIs
As required in [RFC8040], the "ietf-yang-library" YANG module As required in [RFC8040], the "ietf-yang-library" YANG module
defined in [RFC8525] is used to allow the MDSC to discover the set defined in [RFC8525] is used to allow the MDSC to discover the set
of YANG modules supported by each PNC at its MPI. of YANG modules supported by each PNC at its MPI.
Both Optical and Packet PNCs use the following common topology YANG Both Optical and Packet PNCs use the following common topology YANG
models at the MPI to report their abstract topologies: models at the MPI to report their abstract topologies:
o The Base Network Model, defined in the "ietf-network" YANG module o The Base Network Model, defined in the "ietf-network" YANG module
of [RFC8345] of [RFC8345];
o The Base Network Topology Model, defined in the "ietf-network- o The Base Network Topology Model, defined in the "ietf-network-
topology" YANG module of [RFC8345], which augments the Base topology" YANG module of [RFC8345], which augments the Base
Network Model Network Model;
o The TE Topology Model, defined in the "ietf-te-topology" YANG o The TE Topology Model, defined in the "ietf-te-topology" YANG
module of [RFC8795], which augments the Base Network Topology module of [RFC8795], which augments the Base Network Topology
Model with TE specific information. Model with TE specific information.
These common YANG models are generic and augmented by technology- These common YANG models are generic and augmented by technology-
specific YANG modules as described in the following sections. specific YANG modules as described in the following sections.
Both Optical and Packet PNCs must use the following common Both Optical and Packet PNCs must use the following common
notifications YANG models at the MPI so that any network changes can notifications YANG models at the MPI so that any network changes can
be reported almost in real-time to MDSC by the PNCs: be reported almost in real-time to MDSC by the PNCs:
o Dynamic Subscription to YANG Events and Datastores over RESTCONF o Dynamic Subscription to YANG Events and Datastores over RESTCONF
as defined in [RFC8650] as defined in [RFC8650];
o Subscription to YANG Notifications for Datastores updates as o Subscription to YANG Notifications for Datastores updates as
defined in [RFC8641] defined in [RFC8641].
PNCs and MDSCs must be compliant with subscription requirements as PNCs and MDSCs must be compliant with subscription requirements as
stated in [RFC7923]. stated in [RFC7923].
3.2.2. YANG models at the Optical MPIs 3.2.2. YANG models at the Optical MPIs
The Optical PNC also uses at least the following technology-specific The Optical PNC also uses at least the following technology-specific
topology YANG models, providing WDM and Ethernet technology-specific topology YANG models, providing WDM and Ethernet technology-specific
augmentations of the generic TE Topology Model: augmentations of the generic TE Topology Model:
o The WSON Topology Model, defined in the "ietf-wson-topology" YANG o The WSON Topology Model, defined in the "ietf-wson-topology" YANG
modules of [WSON-TOPO], or the Flexi-grid Topology Model, defined modules of [WSON-TOPO], or the Flexi-grid Topology Model, defined
in the "ietf-flexi-grid-topology" YANG module of [Flexi-TOPO]. in the "ietf-flexi-grid-topology" YANG module of [Flexi-TOPO];
o Optionally, when the OTN layer is used, the OTN Topology Model, o Optionally, when the OTN layer is used, the OTN Topology Model,
as defined in the "ietf-otn-topology" YANG module of [OTN-TOPO]. as defined in the "ietf-otn-topology" YANG module of [OTN-TOPO];
o The Ethernet Topology Model, defined in the "ietf-eth-te- o The Ethernet Topology Model, defined in the "ietf-eth-te-
topology" YANG module of [CLIENT-TOPO]. topology" YANG module of [CLIENT-TOPO];
o Optionally, when the OTN layer is used, the network data model o Optionally, when the OTN layer is used, the network data model
for L1 OTN services (e.g. an Ethernet transparent service) as for L1 OTN services (e.g. an Ethernet transparent service) as
defined in "ietf-trans-client-service" YANG module of draft-ietf- defined in "ietf-trans-client-service" YANG module of draft-ietf-
ccamp-client-signal-yang [CLIENT-SIGNAL]. ccamp-client-signal-yang [CLIENT-SIGNAL];
o The WSON Topology Model or, alternatively, the Flexi-grid o The WSON Topology Model or, alternatively, the Flexi-grid
Topology model is used to report the DWDM network topology (e.g., Topology model is used to report the DWDM network topology (e.g.,
ROADMs and links) depending on whether the DWDM optical network ROADMs and links) depending on whether the DWDM optical network
is based on fixed grid or flexible-grid. is based on fixed grid or flexible-grid.
The Ethernet Topology is used to report the access links between the The Ethernet Topology is used to report the access links between the
IP routers and the edge ROADMs. IP routers and the edge ROADMs.
The optical PNC uses at least the following YANG models: The optical PNC uses at least the following YANG models:
o The TE Tunnel Model, defined in the "ietf-te" YANG module of o The TE Tunnel Model, defined in the "ietf-te" YANG module of
[TE-TUNNEL] [TE-TUNNEL];
o The WSON Tunnel Model, defined in the "ietf-wson-tunnel" YANG o The WSON Tunnel Model, defined in the "ietf-wson-tunnel" YANG
modules of [WSON-TUNNEL], or the Flexi-grid Media Channel Model, modules of [WSON-TUNNEL], or the Flexi-grid Media Channel Model,
defined in the "ietf-flexi-grid-media-channel" YANG module of defined in the "ietf-flexi-grid-media-channel" YANG module of
[Flexi-MC] [Flexi-MC];
o Optionally, when the OTN layer is used, the OTN Tunnel Model, o Optionally, when the OTN layer is used, the OTN Tunnel Model,
defined in the "ietf-otn-tunnel" YANG module of [OTN-TUNNEL]. defined in the "ietf-otn-tunnel" YANG module of [OTN-TUNNEL];
o The Ethernet Client Signal Model, defined in the "ietf-eth-tran- o The Ethernet Client Signal Model, defined in the "ietf-eth-tran-
service" YANG module of [CLIENT-SIGNAL]. service" YANG module of [CLIENT-SIGNAL].
The TE Tunnel model is generic and augmented by technology-specific The TE Tunnel model is generic and augmented by technology-specific
models such as the WSON Tunnel Model and the Flexi-grid Media models such as the WSON Tunnel Model and the Flexi-grid Media
Channel Model. Channel Model.
The WSON Tunnel Model or, alternatively, the Flexi-grid Media The WSON Tunnel Model, or the Flexi-grid Media Channel Model, may be
Channel Model are used to setup connectivity within the DWDM network used to setup connectivity within the DWDM network depending on
depending on whether the DWDM optical network is based on fixed grid whether the DWDM optical network is based on fixed grid or flexible-
or flexible-grid. grid.
The Ethernet Client Signal Model is used to configure the steering The Ethernet Client Signal Model is used to configure the steering
of the Ethernet client traffic between Ethernet access links and TE of the Ethernet client traffic between Ethernet access links and TE
Tunnels, which in this case could be either WSON Tunnels or Tunnels, which in this case could be either WSON Tunnels or
Flexi-Grid Media Channels. This model is generic and applies to any Flexi-Grid Media Channels. This model is generic and applies to any
technology-specific TE Tunnel: technology-specific attributes are technology-specific TE Tunnel: technology-specific attributes are
provided by the technology-specific models which augment the generic provided by the technology-specific models which augment the generic
TE-Tunnel Model. TE-Tunnel Model.
3.2.3. YANG data models at the Packet MPIs 3.2.3. YANG data models at the Packet MPIs
The Packet PNC also uses at least the following technology-specific The Packet PNC also uses at least the following technology-specific
topology YANG models, providing IP and Ethernet technology-specific topology YANG models, providing IP and Ethernet technology-specific
augmentations of the generic Topology Models described in section augmentations of the generic Topology Models described in section
3.2.1: 3.2.1:
o The L3 Topology Model, defined in the "ietf-l3-unicast-topology" o The L3 Topology Model, defined in the "ietf-l3-unicast-topology"
YANG modules of [RFC8346], which augments the Base Network YANG module of [RFC8346], which augments the Base Network
Topology Model Topology Model;
o The L3 specific data model including extended TE attributes (e.g. o The L3 specific data model including extended TE attributes (e.g.
performance derived metrics like latency), defined in "ietf-l3- performance derived metrics like latency), defined in "ietf-l3-
te-topology" and in "ietf-te-topology-packet" in draft-ietf-teas- te-topology" and in "ietf-te-topology-packet" YANG modules of
l3-te-topo [L3-TE-TOPO] [L3-TE-TOPO];
o When SR-TE is used, the SR Topology Model, defined in the "ietf-
sr-mpls-topology" YANG module of [SR-TE-TOPO]: this YANG module
is used together with other YANG modules to provide the SR-TE
topology view as described in figure 2 of [SR-TE-TOPO];
o The Ethernet Topology Model, defined in the "ietf-eth-te- o The Ethernet Topology Model, defined in the "ietf-eth-te-
topology" YANG module of [CLIENT-TOPO], which augments the TE topology" YANG module of [CLIENT-TOPO], which augments the TE
Topology Model Topology Model.
The Ethernet Topology Model is used to report the access links The Ethernet Topology Model is used to report the access links
between the IP routers and the edge ROADMs as well as the between the IP routers and the edge ROADMs as well as the
inter-domain links between ASBRs, while the L3 Topology Model is inter-domain links between ASBRs, while the L3 Topology Model is
used to report the IP network topology (e.g., IP routers and links). used to report the IP network topology (e.g., IP routers and links).
o The User Network Interface (UNI) Topology Model, being defined in o The User Network Interface (UNI) Topology Model, being defined in
the "ietf-uni-topology" module of the draft-ogondio-opsawg-uni- the "ietf-uni-topology" module of the draft-ogondio-opsawg-uni-
topology [UNI-TOPO] which augment "ietf-network" module defined topology [UNI-TOPO] which augment "ietf-network" module defined
in [RFC8345] adding service attachment points to the nodes to in [RFC8345] adding service attachment points to the nodes to
skipping to change at page 18, line 51 skipping to change at page 19, line 40
draft-ietf-barguil-opsawg-l2sm-l2nm [L2NM] used for non-ACTN MPI draft-ietf-barguil-opsawg-l2sm-l2nm [L2NM] used for non-ACTN MPI
for L2VPN service provisioning for L2VPN service provisioning
[Editor's note:] Add YANG models used for tunnel and service [Editor's note:] Add YANG models used for tunnel and service
configuration. configuration.
3.3. PCEP 3.3. PCEP
[RFC8637] examines the applicability of a Path Computation Element [RFC8637] examines the applicability of a Path Computation Element
(PCE) [RFC5440] and PCE Communication Protocol (PCEP) to the ACTN (PCE) [RFC5440] and PCE Communication Protocol (PCEP) to the ACTN
framework. It further describes how the PCE architecture is framework. It further describes how the PCE architecture applies to
applicable to ACTN and lists the PCEP extensions that are needed to ACTN and lists the PCEP extensions that are needed to use PCEP as an
use PCEP as an ACTN interface. The stateful PCE [RFC8231], PCE- ACTN interface. The stateful PCE [RFC8231], PCE-Initiation
Initiation [RFC8281], stateful Hierarchical PCE (H-PCE) [RFC8751], [RFC8281], stateful Hierarchical PCE (H-PCE) [RFC8751], and PCE as a
and PCE as a central controller (PCECC) [RFC8283] are some of the central controller (PCECC) [RFC8283] are some of the key extensions
key extensions that enable the use of PCE/PCEP for ACTN. that enable the use of PCE/PCEP for ACTN.
Since the PCEP supports path computation in the packet as well as Since the PCEP supports path computation in the packet and optical
optical networks, PCEP is well suited for inter-layer path networks, PCEP is well suited for inter-layer path computation.
computation. [RFC5623] describes a framework for applying the PCE- [RFC5623] describes a framework for applying the PCE-based
based architecture to interlayer (G)MPLS traffic engineering. architecture to interlayer (G)MPLS traffic engineering. Furthermore,
Further, the section 6.1 of [RFC8751] states the H-PCE applicability the section 6.1 of [RFC8751] states the H-PCE applicability for
for inter-layer or POI. inter-layer or POI.
[RFC8637] lists various PCEP extensions that are applicable to ACTN. [RFC8637] lists various PCEP extensions that apply to ACTN. It also
It also list the PCEP extension for optical network and POI. list the PCEP extension for optical network and POI.
Note that the PCEP can be used in conjunction with the YANG models Note that the PCEP can be used in conjunction with the YANG models
described in the rest of this document. Depending on whether ACTN is described in the rest of this document. Depending on whether ACTN is
deployed in a greenfield or browfield, two options are possible: deployed in a greenfield or brownfield, two options are possible:
1. The MDSC uses a single RESTCONF/YANG interface towards each PNC 1. The MDSC uses a single RESTCONF/YANG interface towards each PNC
to discover all the TE information and requests the creation of to discover all the TE information and request TE tunnels. It may
TE tunnels. It may either perform full multi-layer path either perform full multi-layer path computation or delegate path
computation or delegate path computation to the underneath PNCs. computation to the underneath PNCs.
This approach is very attractive for operators from an This approach is desirable for operators from an multi-vendor
multi-vendor integration perspective as it is simple and we need integration perspective as it is simple, and we need only one
only one type of interface (RESTCONF) and use the relevant YANG type of interface (RESTCONF) and use the relevant YANG data
data models depending on the operator use case considered. models depending on the operator use case considered. Benefits of
Benefits of having only one protocol for the MPI between MDSC and having only one protocol for the MPI between MDSC and PNC have
PNC have been already highlighted in [PATH-COMPUTE]. been already highlighted in [PATH-COMPUTE].
2. The MDSC uses the RESTCONF/YANG interface towards each PNC to 2. The MDSC uses the RESTCONF/YANG interface towards each PNC to
discover all the TE information and requests the creation of TE discover all the TE information and requests the creation of TE
tunnels but it uses PCEP for hierararchical path computation. tunnels. However, it uses PCEP for hierarchical path computation.
As mentioned in Option 1, from an operator perspective this As mentioned in Option 1, from an operator perspective, this
option can add integration complexity to have two protocols option can add integration complexity to have two protocols
instead of one, unless the RESTOCONF/YANG interface is added to instead of one, unless the RESTOCONF/YANG interface is added to
an existing PCEP deployment (brownfield scenario). an existing PCEP deployment (brownfield scenario).
Section 4 of this draft analyses the case where a single Section 4 of this draft analyses the case where a single
RESTCONF/YANG interface is deployed at the MPI (i.e., option 1 RESTCONF/YANG interface is deployed at the MPI (i.e., option 1
above). above).
4. Multi-layer and multi-domain services scenarios 4. Multi-layer and multi-domain services scenarios
Multi-layer and multi-domain scenarios, based on reference network Multi-layer and multi-domain scenarios, based on reference network
described in section 2, and very relevant for Service Providers, are described in section 2, and very relevant for Service Providers, are
described in the next sections. For each scenario existing IETF described in the next sections. For each scenario, existing IETF
protocols and data models are identified with particular focus on protocols and data models are identified with particular focus on
the MPI in the ACTN architecture. Non ACTN IETF data models required the MPI in the ACTN architecture. Non-ACTN IETF data models required
for L2/L3VPN service provisioning between MDSC and IP PNCs are also for L2/L3VPN service provisioning between MDSC and packet PNCs are
identified. also identified.
4.1. Scenario 1: inventory, service and network topology discovery 4.1. Scenario 1: inventory, service and network topology discovery
In this scenario, the MSDC needs to discover through the underlying In this scenario, the MSDC needs to discover through the underlying
PNCs, the network topology, at both WDM and IP layers, in terms of PNCs, the network topology, at both WDM and IP layers, in terms of
nodes and links, including inter AS domain links as well as cross- nodes and links, including inter-AS domain links as well as cross-
layer links but also in terms of tunnels (MPLS or SR paths in IP layer links but also in terms of tunnels (MPLS or SR paths in IP
layer and OCh and optionally ODUk tunnels in optical layer). layer and OCh and optionally ODUk tunnels in optical layer).
In addition, the MDSC should discover the IP/MPLS transport services In addition, the MDSC should discover the IP/MPLS transport services
(L2VPN/L3VPN) deployed, both intra-domain and inter-domain wise. (L2VPN/L3VPN) deployed, both intra-domain and inter-domain wise.
The O-PNC and P-PNC could discover and report the inventory The O-PNC and P-PNC could discover and report the inventory
information of their equipment that is used by the different information of their equipment that is used by the different
management layers. In the context of POI, the inventory information management layers. In the context of POI, the inventory information
of IP and WDM equipment can complement the topology views and of IP and WDM equipment can complement the topology views and
facilitate the IP-Optical multi-layer view. facilitate the IP-Optical multi-layer view.
MDSC could also discover also the whole inventory information of The MDSC could also discover the whole inventory information of both
both IP and WDM equipment and be able to correlate this information IP and WDM equipment and correlate this information with the links
with the links reported in the network topology. reported in the network topology.
Each PNC provides to the MDSC an abstracted or full topology view of Each PNC provides to the MDSC an abstracted or full topology view of
the WDM or the IP topology of the domain it controls. This topology the WDM or the IP topology of the domain it controls. This topology
can be abstracted in the sense that some detailed NE information is can be abstracted in the sense that some detailed NE information is
hidden at the MPI, and all or some of the NEs and related physical hidden at the MPI. All or some of the NEs and related physical links
links are exposed as abstract nodes and logical (virtual) links, are exposed as abstract nodes and logical (virtual) links, depending
depending on the level of abstraction the user requires. This on the level of abstraction the user requires. This information is
information is key to understand both the inter-AS domain links key to understanding both the inter-AS domain links (seen by each
(seen by each controller as UNI interfaces but as I-NNI interfaces controller as UNI interfaces but as I-NNI interfaces by the MDSC)
by the MDSC) as well as the cross-layer mapping between IP and WDM and the cross-layer mapping between IP and WDM layer.
layer.
The MDSC should also maintain up-to-date inventory, service and The MDSC should also maintain up-to-date inventory, service and
network topology databases of both IP and WDM layers (and optionally network topology databases of both IP and WDM layers (and optionally
OTN layer) through the use of IETF notifications through MPI with OTN layer) through the use of IETF notifications through MPI with
the PNCs when any inventory/topology/service change occurs. the PNCs when any inventory/topology/service change occurs.
It should be possible also to correlate information coming from IP It should be possible also to correlate information coming from IP
and WDM layers (e.g.: which port, lambda/OTSi, direction is used by and WDM layers (e.g., which port, lambda/OTSi, and direction, is
a specific IP service on the WDM equipment). used by a specific IP service on the WDM equipment).
In particular, for the cross-layer links it is key for MDSC to be In particular, for the cross-layer links, it is key for MDSC to
able to correlate automatically the information from the PNC network automatically correlate the information from the PNC network
databases about the physical ports from the routers (single link or databases about the physical ports from the routers (single link or
bundle links for LAG) to client ports in the ROADM. bundle links for LAG) to client ports in the ROADM.
It should be possible at MDSC level to easily correlate WDM and IP It should be possible at MDSC level to easily correlate WDM and IP
layers alarms to speed-up troubleshooting layers alarms to speed-up troubleshooting
Alarms and event notifications are required between MDSC and PNCs so Alarms and event notifications are required between MDSC and PNCs so
that any network changes are reported almost in real-time to the MDSC that any network changes are reported almost in real-time to the MDSC
(e.g. NE or link failure, MPLS tunnel switched from main to backup (e.g. NE or link failure, MPLS tunnel switched from primary to back-
path etc.). As specified in [RFC7923] MDSC must be able to subscribe up path etc.). As specified in [RFC7923], MDSC must subscribe to
to specific objects from PNC YANG datastores for notifications. specific objects from PNC YANG datastores for notifications.
4.1.1. Inter-domain link discovery 4.1.1. Inter-domain link discovery
In the reference network of Figure 1, there are two types of In the reference network of Figure 1, there are two types of
inter-domain links: inter-domain links:
o Links between two IP domains (ASes) o Links between two IP domains (ASes)
o Links between an IP router and a ROADM o Links between an IP router and a ROADM
Both types of links are Ethernet physical links. Both types of links are Ethernet physical links.
The inter-domain link information is reported to the MDSC by the two The inter-domain link information is reported to the MDSC by the two
adjacent PNCs, controlling the two ends of the inter-domain link. adjacent PNCs, controlling the two ends of the inter-domain link.
The MDSC needs to understa how to merge the these inter-domain The MDSC needs to understand how to merge these inter-domain
Ethernet links together. Ethernet links together.
This document considers the following two options for discovering This document considers the following two options for discovering
inter-domain links: inter-domain links:
1. Static configuration 1. Static configuration
2. LLDP [IEEE 802.1AB] automatic discovery 2. LLDP [IEEE 802.1AB] automatic discovery
Other options are possible but not described in this document. Other options are possible but not described in this document.
The MDSC can understand how to merge these inter-domain links The MDSC can understand how to merge these inter-domain links using
together using the plug-id attribute defined in the TE Topology the plug-id attribute defined in the TE Topology Model [RFC8795], as
Model [RFC8795], as described in as described in section 4.3 of described in section 4.3 of [RFC8795].
[RFC8795].
A more detailed description of how the plug-id can be used to A more detailed description of how the plug-id can be used to
discover inter-domain link is also provided in section 5.1.4 of discover inter-domain links is also provided in section 5.1.4 of
[TNBI]. [TNBI].
Both types of inter-domain links are discovered using the plug-id Both types of inter-domain links are discovered using the plug-id
attributes reported in the Ethernet Topologies exposed by the two attributes reported in the Ethernet Topologies exposed by the two
adjacent PNCs. The MDSC can also discover an inter-domain IP adjacent PNCs. In addition, the MDSC can also discover an
link/adjacency between the two IP LTPs, reported in the IP inter-domain IP link/adjacency between the two IP LTPs, reported in
Topologies exposed by the two adjacent P-PNCs, supported by the two the IP Topologies exposed by the two adjacent P-PNCs, supported by
ETH LTPs of an Ethernet Link discovered between these two P-PNCs. the two ETH LTPs of an Ethernet Link discovered between these two
P-PNCs.
The static configuration requires an administrative burden to The static configuration requires an administrative burden to
configure network-wide unique identifiers: it is therefore more configure network-wide unique identifiers: it is therefore more
viable for inter-AS links. For the links between the IP routers and viable for inter-AS links. For the links between the IP routers and
the Optical NEs, the automatic discovery solution based on LLDP the Optical NEs, the automatic discovery solution based on LLDP
snooping is preferable when LLDP snooping is supported by the snooping is preferable when LLDP snooping is supported by the
Optical NEs. Optical NEs.
As outlined in [TNBI], the encoding of the plug-id namespace as well As outlined in [TNBI], the encoding of the plug-id namespace and the
as of the LLDP information within the plug-id value is LLDP information within the plug-id value is implementation specific
implementation specific and needs to be consistent across all the and needs to be consistent across all the PNCs.
PNCs.
4.1.2. IP Link Setup Procedure
The MDSC requires the O-PNC to setup a WDM Tunnel (either a WSON 4.1.2. Multi-layer IP Link discovery
Tunnel or a Flexi grid Tunnel) within the DWDM network between the
two Optical Transponders (OTs) associated with the two access links.
The Optical Transponders are reported by the O-PNC as Trail All the intra-domain IP links are discovered by P-PNC, using LLDP
Termination Points (TTPs), defined in [TE TOPO], within the WDM [IEEE 802.1AB] or any other mechanisms which are outside the scope
Topology. The association between the Ethernet access link and the of this document, and reported at the MPI within the L3 Topology.
WDM TTP is reported by the Inter Layer Lock (ILL) identifiers,
defined in [TE TOPO], reported by the O PNC within the Ethernet
Topology and WDM Topology.
The MDSC also requires the O-PNC to steer the Ethernet client In case of a multi-layer IP link, the P-PNC also reports the two
traffic between the two access Ethernet Links over the WDM Tunnel. inter-domain ETH LTPs that supports the two IP LTPs terminating the
multi-layer IP link.
After the WDM Tunnel has been setup and the client traffic steering The MDSC can therefore discover which Ethernet access link supports
configured, the two IP routers can exchange Ethernet packets between the multi-layer IP link as described in section 4.1.1.
themselves, including LLDP messages.
If LLDP [IEEE 802.1AB] is used between the two routers, the P PNC The Optical Transponders, or the OTN access cards, are reported by
can automatically discover the IP Link being set up by the MDSC. The the O-PNC as Trail Termination Points (TTPs), defined in [TE-TOPO],
IP LTPs terminating this IP Link are supported by the ETH LTPs within the Optical Topology. The association between the Ethernet
terminating the two access links. access link and the Optical TTP is reported using the Inter Layer
Lock (ILL) identifiers, defined in [TE-TOPO], within the Ethernet
Topology and Optical Topology, exposed by the O-PNC.
Otherwise, the MDSC needs to require the P PNC to configure an IP The MDSC can discover throught the MPI the Optical Tunnels being
Link between the two routers: the MDSC also configures the two ETH setup by each O-PNC and in particular which Optical Tunnel has been
LTPs which support the two IP LTPs terminating this IP Link. setup between the two TTPs associated with the two Ethernet access
links supporting an inter-domain IP Link.
4.1.3. Inventory discovery 4.1.3. Inventory discovery
The are no YANG data models in IETF that could be used to report at The are no YANG data models in IETF that could be used to report at
the MPI the whole inventory information discovered by a PNC. the MPI the whole inventory information discovered by a PNC.
[RFC8345] has foreseen some work for inventory as an augmentation of [RFC8345] has foreseen some work for inventory as an augmentation of
the network model, but no YANG data model has been developed so far. the network model, but no YANG data model has been developed so far.
There are also no YANG data models in IETF that could be used to There are also no YANG data models in IETF that could be used to
correlate topology information, e.g., a link termination point correlate topology information, e.g., a link termination point
(LTP), with inventory information, e.g., the physical port (LTP), with inventory information, e.g., the physical port
supporting an LTP, if any. supporting an LTP, if any.
Inventory information through MPI and correlation with topology Inventory information through MPI and correlation with topology
information is identified as a gap requiring further work, which is information is identified as a gap requiring further work and
outside of the scope of this draft. outside of the scope of this draft.
4.2. L2VPN/L3VPN establishment 4.1.4. SR-TE paths discovery
To be added This version of the draft assumes that discovery of existing SR-TE
paths, including their bandwidth, at the MPI is done using the
generic TE tunnel YANG data model, defined in [TE-TUNNEL], with
SR-TE specific augmentations, as also outlined in section 1 of
[TE-TUNNEL].
[Editor's Note] What mechanism would convey on the interface to the To enable MDSC to discover the full end-to-end SR-TE path
IP/MPLS domain controllers as well as on the SBI (between IP/MPLS configuration, the SR-TE specific augmentation of the [TE-TUNNEL]
domain controllers and IP/MPLS PE routers) the TE binding policy should allow the P-PNC to report the SID list assigned to an SR-TE
dynamically for the L3VPN? Typically, VRF is the function of the path within its domain.
device that participate MP-BGP in MPLS VPN. With current MP-BGP
implementation in MPLS VPN, the VRF's BGP next hop is the
destination PE and the mapping to a tunnel (either an LDP or a BGP
tunnel) toward the destination PE is done by automatically without
any configuration. It is to be determined the impact on the PE VRF
operation when the tunnel is an optical bypass tunnel which does not
participate either LDP or BGP.
New text to answer the yellow part: [Editors' note:] Need to check if SR-TE specific augmentation is
required for SR-TE path discovery
The MDSC Network-related function will then coordinate with the PNCs For example, considering the L3VPN in Figure 4, the PE13-P16-PE14
involved in the process to provide the provisioning information SR-TE path and the SR-TE path in the reverse direction (between PE14
through ACTN MDSC to PNC (MPI) interface. The relevant data models and PE13) could be reported by the P-PNC1 to the MDSC as TE paths of
used at the MPI may be in the form of L3NM, L2NM or others and are the same TE tunnel instance. The bandwidth of these TE paths
exchanged through MPI API calls. Through this process MDSC Network- represents the bandwidth allocated by P-PNC1 to the two SR-TE
related functions provide the configuration information to realize a paths,which can be symmetric or asymmetric in the two directions.
VPN service to PNCs. For example, this process will inform PNCs on
what PE routers compose a L3VPN, the topology requested, the VPN
attributes, etc.
At the end of the process PNCs will deliver the actual configuration 4.2. Establishment of L2VPN/L3VPN with TE requirements
to the devices (either physical or virtual), through the ACTN
Southbound Interface (SBI). In this case the configuration policies
may be exchanged using a Netconf session delivering configuration
commands associated to device-specific data models (e.g. BGP[], QOS
[], etc.).
Having the topology information of the network domains under their In this scenario the MDSC needs to setup a multi-domain L2VPN or a
control, PNCs will deliver all the information necessary to create, L3VPN with some SLA requirements.
update, optimize or delete the tunnels connecting the PE nodes as
requested by the VPN instantiation. Figure 4 provides an example of an hub&spoke L3VPN with three PEs
where the hub PE (PE13) and one spoke PE (PE14) are within the same
packet domain and the other spoke PE (PE23) is within a different
packet domain.
------
| CE13 |___________________
------ ) __________________
( | ) ( )
( | PE13 P15 BR11 ) ( BR21 P24 )
( ____ ___ ____ ) ( ____ ___ )
( / H \ _ _ _ / \ _ _ / \ _)_ _ _(_ / \ _ _ _ / \ )
( \____/... \___/ \____/ ) ( \____/ \___/ )
( :..... ) ( | )
( ____ :__ ____ ) ( ____ _|__ )
( / S \...../ \._._./ \__________/ \._._._._./ S \ )
( \____/ \___/ \____/ ) ( \____/ \____/ )
( | ) ( | )
( | PE14 P16 BR12 ) ( BR22 PE23 | )
( | ) ( | )
------ ) ( ------
| CE14 | ___________________) (_____________| CE23 |
------ ------
_____________________________ ___________________
( ) ( )
( ____ ____ ) ( ____ )
( / \ __ _ _ _ _ / \ ) ( / \ _ _ )
( \____/.. \____/ ) ( \____/ \ )
( | :..... ...: \ ) ( / \ )
( _|__ :__: \____ ) ( ___/ __\_ )
( / \_ _ / \ _ _ _ / \ ) ( / \ _ _ _ / \ )
( \____/ \____/ \____/ ) ( \____/ \____/ )
( ) ( )
(_____________________________) (___________________)
Optical Domain 1 Optical Domain 2
H / S = Hub VRF / Spoke VRF
____ = Inter-domain interconnections
..... = SR policy Path 1
_ _ _ = SR policy Path 2
Figure 4 Multi-domain L3VPN example
[Editors' note:] Update the SR policy paths to show the intra-domain
PE13-P16-P14 and inter-domain PE13-BR11-BR12-P24-PE23 paths. No need
to show the TI-LFA in this figure. Remove also the intra-domain TI-
LFA.
There are many options to implement multi-domain L3VPN, including:
1. BGP-LU (seamless MPLS)
2. Inter-domain RSVP-TE
3. Inter-domain SR-TE
This version of the draft provides an analysis of the inter-domain
SR-TE option. A future update of this draft will provide a high-
level analysis of the BGP-LU option.
It is assumed that each packet domain in Figure 4 is implementing
SR-TE and the stitching between two domains is done using end-to-
end/multi-domain SR-TE. It is assumed that the bandwidth of each
intra-domain SR-TE path is managed by its respective P-PNC and that
binding SID is used for the end-to-end SR-TE path stitching. It is
assumed that each packet domain in Figure 4 is using TI-LFA, with
SRLG awareness, for local protection within each domain.
[Editor's note:] Analyze how TI-LFA can take into account multi-
layer SRLG disjointness, providing that SRLG information is provided
by the O-PNCs to the P-PNC throught the MDSC.
It is assumed that the MDSC adopts the partial summarization model,
described in section 2.2, having full visibility of the packet layer
TE topology and an abstract view of the underlay optical layer TE
topology.
The MDSC needs to translate the L3VPN SLA requirements to TE
requirements (e.g., bandwidth, TE metric bounds, SRLG disjointness,
nodes/links/domains inclusion/exclusion) and find the SR-TE paths
between PE13 (hub PE) and, respectively, PE23 and PE14 (spoke PEs)
that meet these TE requirements.
For each SR-TE path required to support the L3VPN, it is possible
that:
1. A SR-TE path that meets the TE requirements already exist in the
network.
2. An existing SR-TE path could be modified (e.g., through bandwidth
increase) to meet the TE requirements:
a. The SR-TE path characteristics can be modified only in the
packet layer.
b. One or more new underlay Optical tunnels need to be setup to
support the requested changes of the overlay SR-TE paths
(multi-layer coordination is required).
3. A new SR-TE path needs to be setup:
a. The new SR-TE path reuses existing underlay optical tunnels;
b. One or more new underlay Optical tunnels need to be setup to
support the setup of the new SR-TE path (multi-layer
coordination is required).
For example, considering the L3VPN in Figure 4, the MDSC discovers
that:
o a PE13-P16-PE14 SR-TE path already exists but have not enough
bandwidth to support the new L3VPN, as described in section
4.1.4;
o the IP link(s) between P16 and PE14 has not enough bandwidth to
support increasing the bandwidth of that SR-TE path, as described
in section 4.1;
o a new underlay optical tunnel could be setup to increase the
bandwidth IP link(s) between P16 and PE14 to support increasing
the bandwidth of that overlay SR-TE path, as described in section
4.2.1. The dimensioning of the underlay optical tunnel is decided
by the MDSC based on the bandwidth requested by the SR-TE path
and on its multi-layer optimization policy, which is an internal
MDSC implementation issue.
The MDSC would therefore request:
o the O-PNC1 to setup a new optical tunnel between the ROADMs
connected to P16 and PE14, as described in section 4.2.2;
o the P-PNC1 to update the configuration of the existing IP link,
in case of LAG, or configure a new IP link, in case of ECMP,
between P16 and PE14, as described in section 4.2.2;
o the P-PNC1 to update the bandwidth of the selected SR-TE path
between PE13 and PE14, as described in section 4.2.3.
For example, considering the L3VPN in Figure 4, the MDSC can also
decide that a new multi-domain SR-TE path needs to be setup between
PE13 and PE23.
As described in section 2.2, with partial summarization, the MDSC
will use the TE topology information provided by the P-PNCs and the
results of the path computation requests sent to the O-PNCs, as
described in section 4.2.1, to compute the multi-layer/multi-domain
path between PE13 and PE23.
For example, the multi-layer/multi-domain performed by the MDSC
could require the setup of:
o a new underlay optical tunnel between PE13 and BR11, supporting a
new IP link, as described in section 4.2.2;
o a new underlay optical tunnel between BR21 and P24 to increase
the bandwidth of the IP link(s) between BR21 and P24, as
described in section 4.2.2.
After that, the MDSC requests P-PNC2 to setup an SR-TE path between
BR21 and PE23, with an explicit path (BR21, P24, PE23) as described
in section 4.2.3. The P-PNC2, knowing the node and the adjacency
SIDs assigned within its domain, can install the proper SR policy,
or hierarchical policies, within BR21 and returns to the MDSC the
assigned binding SID.
[Editor's Note] Further investigation is needed for the SR specific
extensions to the TE tunnel model.
MDSC request P-PNC1 to setup an SR-TE path between PE13 and BR11,
with an explicit path (PE13, BR11), specifying the inter-domain link
toward BR21 and the binding SID to be used for the end-to-end SR-TE
path stitching, as described in section 4.2.3. The P-PNC1, knowing
also the node and the adjacency SIDs assigned within its domain and
the EPE SID assigned by BR11 to the inter-domain link toward BR21,
installs the proper policy, or policies, within PE13.
Once the SR-TE paths have been selected and, if needed,
setup/modified, the MDSC can request to both P-PNCs to configure the
L3VPN and its binding with the selected SR-TE paths using the
[L3NM] and [TSM] YANG models.
[Editor's Note] Further investigation is needed to understand how
the binding between a L3VPN and this new end-to-end SR-TE path can
be configured.
4.2.1. Optical Path Computation
As described in section 2.2, the optical path computation is usually
performed by the Optical PNC.
When performing multi-layer/multi-domain path computation, the MDSC
can delegate the Optical PNCs for single-domain optical path
computation.
As discussed in [PATH-COMPUTE], there are two options to request an
Optical PNC to perform optical path computation: either via a
"compute-only" TE tunnel path, using the generic TE tunnel YANG data
model defined in [TE-TUNNEL] or via the path computation RPC defined
in [PATH-COMPUTE].
This draft assumes that the path computation RPC is used.
The are no YANG data models in IETF that could be used to augment
the generic path computation RPC with technology-specific
attributes.
Optical technology-specific augmentation for the path computation
RPC is identified as a gap requiring further work outside of this
draft's scope.
4.2.2. Multi-layer IP Link Setup and Update
The MDSC requires the O-PNC to setup an Optical Tunnel (either a
WSON Tunnel or a Flexi-grid Tunnel or an OTN Tunnel) within the
Optical network between the two Optical Transponders (OTs), in case
of DWDM network, or the two OTN access cards, in case of OTN
networks, associated with the two access links.
The MDSC also requires the O-PNC to steer the Ethernet client
traffic between the two access Ethernet Links over the Optical
Tunnel.
After the Optical Tunnel has been setup and the client traffic
steering configured, the two IP routers can exchange Ethernet
packets between themselves, including LLDP messages.
If LLDP [IEEE 802.1AB] is used between the two routers, the P- PNC
can automatically discover the IP Link being set up by the MDSC. The
IP LTPs terminating this IP Link are supported by the ETH LTPs
terminating the two access links.
Otherwise, the MDSC needs to require the P-PNC to configure an IP
Link between the two routers: the MDSC also configures the two ETH
LTPs which support the two IP LTPs terminating this IP Link.
[Editor's Note] Add text for IP link update and clarify that the IP
link bandwidth increase can be done either by LAG or by ECMP. Both
options are valid and widely deployed and more or less the same from
POI perspective.
4.2.3. SR-TE Path Setup and Update
This version of the draft assumes that SR-TE path setup and update
at the MPI could be done using the generic TE tunnel YANG data
model, defined in [TE TUNNEL], with SR TE specific augmentations, as
also outlined in section 1 of [TE TUNNEL].
The MDSC can use the [TE-TUNNEL] model to request the P-PNC to setup
TE paths specifying the explicit path to force the P-PNC to setup
the actual path being computed by MDSC.
The [TE-TUNNEL] model supports requesting the setup of both end-
to-end as well as segment TE paths (within one domain).
In the latter case, SR-TE specific augmentations of the [TE-TUNNEL]
model should be defined to allow the MDSC to configure the binding
SIDs to be used for the end to-end SR-TE path stitching and to allow
the P-PNC to report the binding SID assigned to the segment TE
paths.
The assigned binding SID should be persistent in case router or P-
PNC rebooting.
The MDSC can also use the [TE-TUNNEL] model to request the P-PNC to
increase the bandwidth allocated to an existing TE path, and, if
needed, also on its reverse TE path. The [TE-TUNNEL] model supports
both symmetric and asymmetric bandwidth configuration in the two
directions.
SR-TE path setup and update (e.g., bandwidth increase) through MPI
is identified as a gap requiring further work, which is outside of
the scope of this draft.
5. Security Considerations 5. Security Considerations
Several security considerations have been identified and will be Several security considerations have been identified and will be
discussed in future versions of this document. discussed in future versions of this document.
6. Operational Considerations 6. Operational Considerations
Telemetry data, such as the collection of lower-layer networking Telemetry data, such as collecting lower-layer networking health and
health and consideration of network and service performance from POI consideration of network and service performance from POI domain
domain controllers, may be required. These requirements and controllers, may be required. These requirements and capabilities
capabilities will be discussed in future versions of this document. will be discussed in future versions of this document.
7. IANA Considerations 7. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC7950] Bjorklund, M. et al., "The YANG 1.1 Data Modeling [RFC7950] Bjorklund, M. et al., "The YANG 1.1 Data Modeling
skipping to change at page 25, line 21 skipping to change at page 32, line 21
yang, work in progress. yang, work in progress.
[CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer
Topology", draft-zheng-ccamp-client-topo-yang, work in Topology", draft-zheng-ccamp-client-topo-yang, work in
progress. progress.
[L3-TE-TOPO] Liu, X. et al., "YANG Data Model for Layer 3 TE [L3-TE-TOPO] Liu, X. et al., "YANG Data Model for Layer 3 TE
Topologies", draft-ietf-teas-yang-l3-te-topo, work in Topologies", draft-ietf-teas-yang-l3-te-topo, work in
progress. progress.
[SR-TE-TOPO] Liu, X. et al., "YANG Data Model for SR and SR TE
Topologies on MPLS Data Plane", draft-ietf-teas-yang-sr-
te-topo, work in progress.
[TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress. te, work in progress.
[WSON-TUNNEL] Lee, Y. et al., "A Yang Data Model for WSON Tunnel", [WSON-TUNNEL] Lee, Y. et al., "A Yang Data Model for WSON Tunnel",
draft-ietf-ccamp-wson-tunnel-model, work in progress. draft-ietf-ccamp-wson-tunnel-model, work in progress.
[Flexi-MC] Lopez de Vergara, J. E. et al., "YANG data model for [Flexi-MC] Lopez de Vergara, J. E. et al., "YANG data model for
Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid- Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid-
media-channel-yang, work in progress. media-channel-yang, work in progress.
[OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft- [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft-
ietf-ccamp-otn-tunnel-model, work in progress. ietf-ccamp-otn-tunnel-model, work in progress.
[PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for
requesting Path Computation", draft-ietf-teas-yang-path-
computation, work in progress.
[CLIENT-SIGNAL] Zheng, H. et al., "A YANG Data Model for Transport [CLIENT-SIGNAL] Zheng, H. et al., "A YANG Data Model for Transport
Network Client Signals", draft-ietf-ccamp-client-signal- Network Client Signals", draft-ietf-ccamp-client-signal-
yang, work in progress. yang, work in progress.
[L2NM] S. Barguil, et al., "A Layer 2 VPN Network YANG Model",
draft-ietf-opsawg-l2nm, work in progress.
[L3NM] S. Barguil, et al., "A Layer 3 VPN Network YANG Model",
draft-ietf-opsawg-l3sm-l3nm, work in progress.
[TSM] Y. Lee, et al., "Traffic Engineering and Service Mapping
Yang Model", draft-ietf-teas-te-service-mapping-yang, work
in progress.
8.2. Informative References 8.2. Informative References
[RFC1930] J. Hawkinson, T. Bates, "Guideline for creation, [RFC1930] J. Hawkinson, T. Bates, "Guideline for creation,
selection, and registration of an Autonomous System (AS)", selection, and registration of an Autonomous System (AS)",
RFC 1930, March 1996. RFC 1930, March 1996.
[RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4761] K. Kompella, Ed., Y. Rekhter, Ed., "Virtual Private LAN [RFC4761] K. Kompella, Ed., Y. Rekhter, Ed., "Virtual Private LAN
skipping to change at page 26, line 40 skipping to change at page 34, line 19
Private Network (L2VPN) Service Delivery", RFC8466, Private Network (L2VPN) Service Delivery", RFC8466,
October 2018. October 2018.
[TNBI] Busi, I., Daniel, K. et al., "Transport Northbound [TNBI] Busi, I., Daniel, K. et al., "Transport Northbound
Interface Applicability Statement", draft-ietf-ccamp- Interface Applicability Statement", draft-ietf-ccamp-
transport-nbi-app-statement, work in progress. transport-nbi-app-statement, work in progress.
[VN] Y. Lee, et al., "A Yang Data Model for ACTN VN Operation", [VN] Y. Lee, et al., "A Yang Data Model for ACTN VN Operation",
draft-ietf-teas-actn-vn-yang, work in progress. draft-ietf-teas-actn-vn-yang, work in progress.
[L2NM] S. Barguil, et al., "A Layer 2 VPN Network YANG Model",
draft-ietf-opsawg-l2nm, work in progress.
[L3NM] S. Barguil, et al., "A Layer 3 VPN Network YANG Model",
draft-ietf-opsawg-l3sm-l3nm, work in progress.
[TSM] Y. Lee, et al., "Traffic Engineering and Service Mapping
Yang Model", draft-ietf-teas-te-service-mapping-yang, work
in progress.
[ACTN-PM] Y. Lee, et al., "YANG models for VN & TE Performance [ACTN-PM] Y. Lee, et al., "YANG models for VN & TE Performance
Monitoring Telemetry and Scaling Intent Autonomics", Monitoring Telemetry and Scaling Intent Autonomics",
draft-lee-teas-actn-pm-telemetry-autonomics, work in draft-lee-teas-actn-pm-telemetry-autonomics, work in
progress. progress.
[BGP-L3VPN] D. Jain, et al. "Yang Data Model for BGP/MPLS L3 VPNs", [BGP-L3VPN] D. Jain, et al. "Yang Data Model for BGP/MPLS L3 VPNs",
draft-ietf-bess-l3vpn-yang, work in progress. draft-ietf-bess-l3vpn-yang, work in progress.
Appendix A. Multi-layer and multi-domain resiliency Appendix A. Multi-layer and multi-domain resiliency
skipping to change at page 28, line 40 skipping to change at page 35, line 40
a) LAG was defined between the two end routers. MDSC, after checking a) LAG was defined between the two end routers. MDSC, after checking
that optical layer is fine between the two end ROADMs, triggers that optical layer is fine between the two end ROADMs, triggers
the ROADM configuration so that the router back-up port with its the ROADM configuration so that the router back-up port with its
associated muxponder port can reuse the OCh that was already in associated muxponder port can reuse the OCh that was already in
use previously by the failed router port and adds the new link to use previously by the failed router port and adds the new link to
the LAG on the failure side. the LAG on the failure side.
While the ROADM reconfiguration takes place, IP/MPLS traffic is While the ROADM reconfiguration takes place, IP/MPLS traffic is
using the reduced bandwidth of the IP link bundle, discarding using the reduced bandwidth of the IP link bundle, discarding
lower priority traffic if required. Once backup port has been lower priority traffic if required. Once back-up port has been
reconfigured to reuse the existing OCh and new link has been reconfigured to reuse the existing OCh and new link has been
added to the LAG then original Bandwidth is recovered between the added to the LAG then original Bandwidth is recovered between the
end routers. end routers.
Note: in this LAG scenario let assume that BFD is running at LAG Note: in this LAG scenario let assume that BFD is running at LAG
level so that there is nothing triggered at MPLS level when one level so that there is nothing triggered at MPLS level when one
of the link member of the LAG fails. of the link member of the LAG fails.
b) If there is no LAG then the scenario is not clear since a router b) If there is no LAG then the scenario is not clear since a router
port failure would automatically trigger (through BFD failure) port failure would automatically trigger (through BFD failure)
first a sub-50ms protection at MPLS level :FRR (MPLS RSVP-TE first a sub-50ms protection at MPLS level :FRR (MPLS RSVP-TE
case) or TI-LFA (MPLS based SR-TE case) through a protection case) or TI-LFA (MPLS based SR-TE case) through a protection
port. At the same time MDSC, after checking that optical network port. At the same time MDSC, after checking that optical network
connection is still fine, would trigger the reconfiguration of connection is still fine, would trigger the reconfiguration of
the back-up port of the router and of the ROADM muxponder to re- the back-up port of the router and of the ROADM muxponder to re-
use the same OCh as the one used originally for the failed router use the same OCh as the one used originally for the failed router
port. Once everything has been correctly configured, MDSC Global port. Once everything has been correctly configured, MDSC Global
PCE could suggest to the operator to trigger a possible re- PCE could suggest to the operator to trigger a possible re-
optimisation of the back-up MPLS path to go back to the MPLS optimization of the back-up MPLS path to go back to the MPLS
primary path through the back-up port of the router and the primary path through the back-up port of the router and the
original OCh if overall cost, latency etc. is improved. However, original OCh if overall cost, latency etc. is improved. However,
in this scenario, there is a need for protection port PLUS back- in this scenario, there is a need for protection port PLUS back-
up port in the router which does not lead to clear port savings. up port in the router which does not lead to clear port savings.
Acknowledgments Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Some of this analysis work was supported in part by the European Some of this analysis work was supported in part by the European
skipping to change at page 30, line 29 skipping to change at page 37, line 34
Jeff Tantsura Jeff Tantsura
Apstra Apstra
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Paolo Volpato Paolo Volpato
Huawei Huawei
Email: paolo.volpato@huawei.com Email: paolo.volpato@huawei.com
Brent Foster
Cisco
Email: brfoster@cisco.com
Authors' Addresses Authors' Addresses
Fabio Peruzzini Fabio Peruzzini
TIM TIM
Email: fabio.peruzzini@telecomitalia.it Email: fabio.peruzzini@telecomitalia.it
Jean-Francois Bouquier Jean-Francois Bouquier
Vodafone Vodafone
 End of changes. 121 change blocks. 
361 lines changed or deleted 631 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/