draft-ietf-teas-actn-poi-applicability-01.txt   draft-ietf-teas-actn-poi-applicability-02.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: May 2021 November 2, 2020 Expires: November 2021 May 14, 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-01 draft-ietf-teas-actn-poi-applicability-02
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 41 skipping to change at page 2, line 36
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 in North Bound of MDSC...........8
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......................................12
2.2.2. Shared Tunnel Selection.............................13 2.2.2. Shared Tunnel Selection.............................12
2.3. IP/MPLS Domain Controller and NE Functions...............13 2.3. IP/MPLS Domain Controller and NE Functions...............13
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.........15
3.1. RESTCONF protocol at the MPIs............................15 3.1. RESTCONF protocol at the MPIs............................15
3.2. YANG data models at the MPIs.............................16 3.2. YANG data models at the MPIs.............................15
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.....................16
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
4. Multi-layer and multi-domain services scenarios...............19 4. Multi-layer and multi-domain services scenarios...............19
4.1. Scenario 1: network and service topology discovery.......19 4.1. Scenario 1: inventory, service and network topology
4.1.1. Inter-domain link discovery.........................20 discovery.....................................................20
4.1.2. IP Link Setup Procedure.............................21 4.1.1. Inter-domain link discovery.........................21
4.2. L2VPN/L3VPN establishment................................22 4.1.2. IP Link Setup Procedure.............................22
5. Security Considerations.......................................22 4.1.3. Inventory discovery.................................22
6. Operational Considerations....................................23 4.2. L2VPN/L3VPN establishment................................23
7. IANA Considerations...........................................23 5. Security Considerations.......................................24
8. References....................................................23 6. Operational Considerations....................................24
8.1. Normative References.....................................23 7. IANA Considerations...........................................24
8.2. Informative References...................................24 8. References....................................................24
Appendix A. Multi-layer and multi-domain resiliency...........27 8.1. Normative References.....................................24
A.1. Maintenance Window......................................27 8.2. Informative References...................................25
A.2. Router port failure.....................................27 Appendix A. Multi-layer and multi-domain resiliency...........28
Acknowledgments..................................................28 A.1. Maintenance Window......................................28
Contributors.....................................................28 A.2. Router port failure.....................................28
Authors' Addresses...............................................29 Acknowledgments..................................................29
Contributors.....................................................29
Authors' Addresses...............................................30
1. Introduction 1. Introduction
The full automation of the management and control of Service The full automation of the management and control of Service
Providers transport networks (IP/MPLS, Optical and also Microwave) Providers transport networks (IP/MPLS, Optical and also Microwave)
is key for achieving the new challenges coming now with 5G as well is key for achieving the new challenges coming now with 5G as well
as with the increased demand in terms of business agility and as with the increased demand in terms of business agility and
mobility in a digital world. ACTN architecture, by abstracting the mobility in a digital world. ACTN architecture, by abstracting the
network complexity from Optical and IP/MPLS networks towards MDSC network complexity from Optical and IP/MPLS networks towards MDSC
and then from MDSC towards OSS/BSS or Orchestration layer through and then from MDSC towards OSS/BSS or Orchestration layer through
skipping to change at page 5, line 17 skipping to change at page 5, line 17
+-----+----+ +-----+----+
| |
+-----------+-----+------+-----------+ +-----------+-----+------+-----------+
| | | | | | | |
+----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+
| P-PNC 1 | | O-PNC 1 | | O-PNC 2 | | P-PNC 2 | | P-PNC 1 | | O-PNC 1 | | O-PNC 2 | | P-PNC 2 |
+----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+
| | | | | | | |
| \ / | | \ / |
+-------------------+ \ / +-------------------+ +-------------------+ \ / +-------------------+
CE / PE BR \ | / / BR PE \ CE CE1 / PE1 BR1 \ | / / BR2 PE2 \ CE2
o--/---o o---\-|-------|--/---o o---\--o o--/---o o---\-|-------|--/---o o---\--o
\ : : / | | \ : : / \ : : / | | \ : : /
\ : PKT Domain 1 : / | | \ : PKT Domain 2 : / \ : PKT Domain 1 : / | | \ : PKT Domain 2 : /
+-:---------------:-+ | | +-:---------------:--+ +-:---------------:-+ | | +-:---------------:--+
: : | | : : : : | | : :
: : | | : : : : | | : :
+-:---------------:------+ +-------:---------------:--+ +-:---------------:------+ +-------:---------------:--+
/ : : \ / : : \ / : : \ / : : \
/ o...............o \ / o...............o \ / o...............o \ / o...............o \
\ Optical Domain 1 / \ Optical Domain 2 / \ Optical Domain 1 / \ Optical Domain 2 /
skipping to change at page 8, line 36 skipping to change at page 8, line 32
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 works, beyond discovery (e.g.
rerouting LSPs with their associated services when putting a rerouting LSPs with their associated services when putting a
resource, like a fibre, in maintenance mode during a maintenance resource, like a fibre, in maintenance mode during a maintenance
window). Different to service fulfillment, the workflows then are window). Different to service fulfillment, the workflows then are
not related at all to a service provisioning request being not related at all to a service provisioning request being
received from the OSS/Orchestration layer. received from the OSS/Orchestration layer.
Above two MDSC workflow cases are in the scope of this draft or in Above two MDSC workflow cases are in the scope of this draft. The
future versions. workflow initiation is transparent at the MPI.
2.1. L2/L3VPN Service Request in North Bound of MDSC 2.1. L2/L3VPN Service Request in 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 of L2/L3VPN services (with or without TE
requirements). requirements).
Although the interface between the OSS/Orchestration layer is Although the interface between the OSS/Orchestration layer is
usually operator-specific, ideally it would be using a RESTCONF/YANG usually operator-specific, ideally it would be using a RESTCONF/YANG
interface with more abstracted version of the MPI YANG data models interface with more abstracted version of the MPI YANG data models
skipping to change at page 11, line 42 skipping to change at page 11, line 30
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]. path computation, as shown in Figure 10 of [RFC8453]. Another
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 19, line 12 skipping to change at page 18, line 47
draft-ietf-opsawg-l3sm-l3nm [L3NM] used for non-ACTN MPI for draft-ietf-opsawg-l3sm-l3nm [L3NM] used for non-ACTN MPI for
L3VPN service provisioning L3VPN service provisioning
o L2VPN network data model defined in "ietf-l2vpn-ntw" module of o L2VPN network data model defined in "ietf-l2vpn-ntw" module of
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
[RFC8637] examines the applicability of a Path Computation Element
(PCE) [RFC5440] and PCE Communication Protocol (PCEP) to the ACTN
framework. It further describes how the PCE architecture is
applicable to ACTN and lists the PCEP extensions that are needed to
use PCEP as an ACTN interface. The stateful PCE [RFC8231], PCE-
Initiation [RFC8281], stateful Hierarchical PCE (H-PCE) [RFC8751],
and PCE as a central controller (PCECC) [RFC8283] are some of the
key extensions that enable the use of PCE/PCEP for ACTN.
Since the PCEP supports path computation in the packet as well as
optical networks, PCEP is well suited for inter-layer path
computation. [RFC5623] describes a framework for applying the PCE-
based architecture to interlayer (G)MPLS traffic engineering.
Further, the section 6.1 of [RFC8751] states the H-PCE applicability
for inter-layer or POI.
[RFC8637] lists various PCEP extensions that are applicable to ACTN.
It also list the PCEP extension for optical network and POI.
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
deployed in a greenfield or browfield, two options are possible:
1. The MDSC uses a single RESTCONF/YANG interface towards each PNC
to discover all the TE information and requests the creation of
TE tunnels. It may either perform full multi-layer path
computation or delegate path computation to the underneath PNCs.
This approach is very attractive for operators from an
multi-vendor integration perspective as it is simple and we need
only one type of interface (RESTCONF) and use the relevant YANG
data models depending on the operator use case considered.
Benefits of having only one protocol for the MPI between MDSC and
PNC have been already highlighted in [PATH-COMPUTE].
2. The MDSC uses the RESTCONF/YANG interface towards each PNC to
discover all the TE information and requests the creation of TE
tunnels but it uses PCEP for hierararchical path computation.
As mentioned in Option 1, from an operator perspective this
option can add integration complexity to have two protocols
instead of one, unless the RESTOCONF/YANG interface is added to
an existing PCEP deployment (brownfield scenario).
Section 4 of this draft analyses the case where a single
RESTCONF/YANG interface is deployed at the MPI (i.e., option 1
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 IP PNCs are also
identified. identified.
4.1. Scenario 1: network and service 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 (NEs) and links, including inter AS domain links as well as nodes and links, including inter AS domain links as well as cross-
cross-layer links but also in terms of tunnels (MPLS or SR paths in layer links but also in terms of tunnels (MPLS or SR paths in IP
IP layer and OCh and optionally ODUk tunnels in optical layer).MDSC layer and OCh and optionally ODUk tunnels in optical layer).
discovers also the IP/MPLS transport services (L2VPN/L3VPN)
deployed, both intra-domain and inter-domain wise. In addition, the MDSC should discover the IP/MPLS transport services
(L2VPN/L3VPN) deployed, both intra-domain and inter-domain wise.
The O-PNC and P-PNC could discover and report the inventory
information of their equipment that is used by the different
management layers. In the context of POI, the inventory information
of IP and WDM equipment can complement the topology views and
facilitate the IP-Optical multi-layer view.
MDSC could also discover also the whole inventory information of
both IP and WDM equipment and be able to correlate this information
with the links 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, and all or some of the NEs and related physical
links are exposed as abstract nodes and logical (virtual) links, links are exposed as abstract nodes and logical (virtual) links,
depending on the level of abstraction the user requires. This depending on the level of abstraction the user requires. This
information is key to understand both the inter-AS domain links information is key to understand both the inter-AS domain links
(seen by each controller as UNI interfaces but as I-NNI interfaces (seen by each controller as UNI interfaces but as I-NNI interfaces
by the MDSC) as well as the cross-layer mapping between IP and WDM by the MDSC) as well as the cross-layer mapping between IP and WDM
layer. layer.
The MDSC also maintains an up-to-date network database of both IP The MDSC should also maintain up-to-date inventory, service and
and WDM layers (and optionally OTN layer) through the use of IETF network topology databases of both IP and WDM layers (and optionally
notifications through MPI with the PNCs when any topology change OTN layer) through the use of IETF notifications through MPI with
occurs. It should be possible also to correlate information coming the PNCs when any inventory/topology/service change occurs.
from IP and WDM layers (e.g.: which port, lambda/OTSi, direction is
used by a specific IP service on the WDM equipment) It should be possible also to correlate information coming from IP
In particular, For the cross-layer links it is key for MDSC to be and WDM layers (e.g.: which port, lambda/OTSi, direction is used by
a specific IP service on the WDM equipment).
In particular, for the cross-layer links it is key for MDSC to be
able to correlate automatically the information from the PNC network able to correlate automatically 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 main to backup
skipping to change at page 22, line 5 skipping to change at page 22, line 46
If LLDP [IEEE 802.1AB] is used between the two routers, the P PNC 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 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 IP LTPs terminating this IP Link are supported by the ETH LTPs
terminating the two access links. terminating the two access links.
Otherwise, the MDSC needs to require the P PNC to configure an IP 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 Link between the two routers: the MDSC also configures the two ETH
LTPs which support the two IP LTPs terminating this IP Link. LTPs which support the two IP LTPs terminating this IP Link.
4.1.3. Inventory discovery
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.
[RFC8345] has foreseen some work for inventory as an augmentation of
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
correlate topology information, e.g., a link termination point
(LTP), with inventory information, e.g., the physical port
supporting an LTP, if any.
Inventory information through MPI and correlation with topology
information is identified as a gap requiring further work, which is
outside of the scope of this draft.
4.2. L2VPN/L3VPN establishment 4.2. L2VPN/L3VPN establishment
To be added To be added
[Editor's Note] What mechanism would convey on the interface to the [Editor's Note] What mechanism would convey on the interface to the
IP/MPLS domain controllers as well as on the SBI (between IP/MPLS IP/MPLS domain controllers as well as on the SBI (between IP/MPLS
domain controllers and IP/MPLS PE routers) the TE binding policy domain controllers and IP/MPLS PE routers) the TE binding policy
dynamically for the L3VPN? Typically, VRF is the function of the dynamically for the L3VPN? Typically, VRF is the function of the
device that participate MP-BGP in MPLS VPN. With current MP-BGP device that participate MP-BGP in MPLS VPN. With current MP-BGP
implementation in MPLS VPN, the VRF's BGP next hop is the implementation in MPLS VPN, the VRF's BGP next hop is the
skipping to change at page 29, line 4 skipping to change at page 29, line 47
Email: ggalimbe@cisco.com Email: ggalimbe@cisco.com
Zheng Yanlei Zheng Yanlei
China Unicom China Unicom
Email: zhengyanlei@chinaunicom.cn Email: zhengyanlei@chinaunicom.cn
Anton Snitser Anton Snitser
Sedona Sedona
Email: antons@sedonasys.com
Email: antons@sedonasys.com
Washington Costa Pereira Correia Washington Costa Pereira Correia
TIM Brasil TIM Brasil
Email: wcorreia@timbrasil.com.br Email: wcorreia@timbrasil.com.br
Michael Scharf Michael Scharf
Hochschule Esslingen - University of Applied Sciences Hochschule Esslingen - University of Applied Sciences
Email: michael.scharf@hs-esslingen.de Email: michael.scharf@hs-esslingen.de
skipping to change at page 30, line 4 skipping to change at page 30, line 38
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
Email: jeff.bouquier@vodafone.com
Email: jeff.bouquier@vodafone.com
Italo Busi Italo Busi
Huawei Huawei
Email: Italo.busi@huawei.com Email: Italo.busi@huawei.com
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
 End of changes. 18 change blocks. 
39 lines changed or deleted 128 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/