Internet DRAFT - draft-poidt-teas-actn-poi-assurance
draft-poidt-teas-actn-poi-assurance
TEAS WG I. Busi
Internet-Draft Huawei Technologies
Intended status: Informational J.-F. Bouquier
Expires: 14 September 2023 Vodafone
F. Peruzzini
TIM
P. Volpato
Huawei Technologies
P. Manna
Cisco
13 March 2023
Applicability of Abstraction and Control of Traffic Engineered Networks
(ACTN) for Packet Optical Integration (POI) service assurance
draft-poidt-teas-actn-poi-assurance-00
Abstract
This document extends the analysis of the applicability of
Abstraction and Control of TE Networks (ACTN) architecture to Packet
Optical Integration (POI), provided in RFC YYYY, to cover multi-layer
service assurance scenarios, for end-to-end customer L2VPN or L3VPN
connectivity services setup over underlying transport optical paths,
with specific Service Level Agreement (SLA) requirements.
EDITORS NOTE: Replace RFC YYYY with the RFC number of draft-ietf-
teas-actn-poi-applicability once it has been published.
Existing IETF protocols and data models are identified for each
multi-layer (packet over optical) service assurance scenario with a
specific focus on the MPI (Multi-Domain Service Coordinator to
Provisioning Network Controllers Interface) in the ACTN architecture.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Busi, et al. Expires 14 September 2023 [Page 1]
Internet-Draft ACTN POI Assurance March 2023
This Internet-Draft will expire on 14 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Reference Network Architecture . . . . . . . . . . . . . . . 3
4. YANG Data Models for the MPIs . . . . . . . . . . . . . . . . 6
5. Optical Network Failure and Performance Degradation . . . . . 7
5.1. Fault Detection . . . . . . . . . . . . . . . . . . . . . 7
5.2. Performance Monitoring . . . . . . . . . . . . . . . . . 7
5.3. Protection Switching . . . . . . . . . . . . . . . . . . 7
5.4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 7
6. Failures between the IP and Optical edges . . . . . . . . . . 7
6.1. Fault Detection . . . . . . . . . . . . . . . . . . . . . 8
6.2. Protection Switching . . . . . . . . . . . . . . . . . . 8
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
TODO Complete the Introduction
Multi-layer and multi-domain service assurance scenarios, based on
the reference network described in section 2 of
[I-D.ietf-teas-actn-poi-applicability] and very relevant for Service
Providers, are described in sections Section 5 and Section 6.
Busi, et al. Expires 14 September 2023 [Page 2]
Internet-Draft ACTN POI Assurance March 2023
This document is focusing on service assurance for end-to-end L2VPN
or L3VPN connectivity services setup over underlying transport
optical paths that requires multi-layer coordination
For each scenario, existing IETF YANG data models, identified in
section Section 4, are analyzed with a particular focus on the MPI in
the ACTN architecture.
For each multi-layer scenario, the document analyzes how to use the
interfaces and data models of the ACTN architecture.
A summary of the gaps identified in this analysis is provided in
Section 7.
Understanding the level of standardization and the possible gaps will
help assess the feasibility of integration between packet and optical
DWDM domains (and optionally OTN layer) from an end-to-end multi-
vendor service assurance perspective.
2. Conventions and Definitions
2.1. Terminology
TODO Terminology
3. Reference Network Architecture
This document analyses several scenarios for service assurance in
Packet and Optical Integration (POI) in which ACTN hierarchy is
deployed to control a multi-layer and multi-domain network with two
optical domains and two packet domains, as shown in Figure 1 of
[I-D.ietf-teas-actn-poi-applicability], which is copied in Figure 1
below.
Busi, et al. Expires 14 September 2023 [Page 3]
Internet-Draft ACTN POI Assurance March 2023
+----------+
| MDSC |
+-----+----+
|
+-----------+-----+------+-----------+
| | | |
+----+----+ +----+----+ +----+----+ +----+----+
| P-PNC 1 | | O-PNC 1 | | O-PNC 2 | | P-PNC 2 |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
| \ / |
+-------------------+ \ / +-------------------+
CE1 / PE1 BR1 \ | / / BR2 PE2 \ CE2
o--/---o o---\-|-------|--/---o o---\--o
\ : : / | | \ : : /
\ : PKT domain 1 : / | | \ : PKT domain 2 : /
+-:---------------:-+ | | +-:---------------:--+
: : | | : :
: : | | : :
+-:---------------:------+ +-------:---------------:--+
/ : : \ / : : \
/ o...............o \ / o...............o \
\ optical domain 1 / \ optical domain 2 /
\ / \ /
+------------------------+ +--------------------------+
Figure 1: Reference Network (copy of Figure 1 of RFC YYYY)
EDITORS NOTE: Replace RFC YYYY with the RFC number of
[I-D.ietf-teas-actn-poi-applicability] once it has been published.
In general, service assurance involves fault detection and
localization; performance monitoring as well as re-routing
(protection).
Two cases will be considered:
1. using grey interfaces on routers' ports, as outlined in
[I-D.ietf-teas-actn-poi-applicability]
2. using colored optical interfaces on routers' ports, as outlined
in [I-D.mix-teas-actn-poi-extension]
NOTE: It is not fully clear how much commonalities there are in
service assurance for these two cases. This draft will start
addressing both cases. At a later stage it will be assessed whether
it is worthwhile keeping everything in a single draft or to split
into two drafts.
Busi, et al. Expires 14 September 2023 [Page 4]
Internet-Draft ACTN POI Assurance March 2023
The MDSC is responsible for coordinating the whole multi-domain,
multi-layer (packet and optical) network. MDSC interacts with
different Provisioning Network Controllers (O/P-PNCs) through the MPI
interface. The MPI interface presents an abstracted topology to
MDSC, hiding the technology-specific aspects of the network and the
topology details (depending on the policy chosen regarding the level
of abstraction supported).
Following the assumptions of section 2.1.2 of
[I-D.ietf-teas-actn-poi-applicability], this document analyses
scenarios where the MDSC uses the partial summarization approach to
coordinate multi-domain/multi-layer path computation.
In this approach, the MDSC has complete visibility of the TE topology
of the packet network domains and an abstracted view of the TE
topology of the optical network domains. That means the MDSC has the
capability of performing multi-domain/single-layer path computation
for the packet layer. The MDSC needs to delegate the O-PNCs to
perform local path computation within their respective domains. It
uses the information received by the O-PNCs and its TE topology view
of the multi-domain packet layer to perform multi-layer/multi-domain
path computation.
P-PNCs are responsible for setting up the TE paths between any two
PEs or BRs in their respective controlled domains, as requested by
MDSC, and providing topology information to the MDSC.
O-PNCs are responsible to provide to the MDSC an abstract TE topology
view of their underlying optical network resources. They perform
single-domain local path computation, when requested by the MDSC.
They also perform optical tunnel setup, when requested by the MDSC.
No GMPLS-UNI interaction between IP and Optical equipment is
considered. This is also the assumption followed in this document:
the MDSC performs the function of multi-layer/multi-domain path
computation through the same mechanisms described in
[I-D.ietf-teas-actn-poi-applicability].
TO DO - Complete the description of the pre-requisites of MDSC in the
cases discussed.
The following list summarizes the main assumptions about how MDSC can
handle the service assurance cases described in this document. Most
of them have been already described in
[I-D.ietf-teas-actn-poi-applicability]
1. MDSC has acquired all the topology and status information of both
the IP and optical layers.
Busi, et al. Expires 14 September 2023 [Page 5]
Internet-Draft ACTN POI Assurance March 2023
2. MDSC is fully aware of any multi-layer connections between the IP
and the optical layers. It is also aware of the multi-domain
interconnection links between different IP domains.
3. MDSC is aware of any topology or resource utilization change
obtained in real time through coordination with the O/P-PNCs.
This applies in the case of a fault or a maintenance activity
involving either the IP or the DWDM layer.
4. MDSC coordinates the IP and DWDM protections and, as a result,
the re-routing of traffic at both the IP and DWDM layer.
5. Before planned maintenance operation at the DWDM layer, MDSC
instructs the P-PNC to move the affected IP traffic to an other
link in an hitless way. This is done before the event takes
place. MDSC also coordinates with P-PNC to revert back the
traffic on the original path when the maintenance event is
concluded.
6. When the O-PNC detects a degradation of optical performance (e.g.
BER PRE-FEC values threshold crossing over a certain period of
time), it alerts the MDSC so that the MDSC relates the warning to
an IP link.
7. MDSC distinguishes between IP and Optical failures. For example,
in the case of the failure of an IP port of a router, the IP
traffic may be switched to a stand-by port, reusing the same
ROADM optical resources (lambda, optical path) and keeping the
end-to-end IP connection. If a remote IP node fails, then a re-
route of optical resources takes place together with a switch of
the local IP port in order to establish a new connection with a
different IP node used for protection.
4. YANG Data Models for the MPIs
TODO YANG Data Models
Initial set of YANG models that are potentially in the scope of this
analysis:
* ietf-alarms defined in [RFC8632]
* ietf-performance-monitoring defined in
[I-D.yu-performance-monitoring-yang]
Busi, et al. Expires 14 September 2023 [Page 6]
Internet-Draft ACTN POI Assurance March 2023
5. Optical Network Failure and Performance Degradation
5.1. Fault Detection
TODO Describe fault detection performed by the O-PNC and how this
information is reported to the MDSC: see for example the failure
scenario in https://github.com/italobusi/draft-poidt-teas-actn-poi-
assurance/files/10885907/2023.03.draft-poidt-teas-poi-assurance.pptx
(slide 3)
5.2. Performance Monitoring
TODO Describe performance monitoring and performance degradation
detection performed by the O-PNC and how this information is reported
to the MDSC: see for example the degradation scenario in
https://github.com/italobusi/draft-poidt-teas-actn-poi-assurance/
files/10885907/2023.03.draft-poidt-teas-poi-assurance.pptx (slide 7)
5.3. Protection Switching
Failures in the optical domain can be recovered by packet-based
protection mechanisms as described in
[I-D.ietf-teas-actn-poi-applicability].
TODO Describe how the MDSC coordinates the protection switching
mechanisms at the IP layer (e.g., FRR) and at optical layer,
including the reversion when the failure is repaired: see for example
the protection switching scenario in https://github.com/italobusi/
draft-poidt-teas-actn-poi-assurance/files/10885907/2023.03.draft-
poidt-teas-poi-assurance.pptx (slide 3)
5.4. Maintenance
TODO Describe how the MDSC initiates protection switching at the IP
layer (e.g., FRR) and at optical layer at the beginning of a
maintenance window, including the reversion after the maintenance
operations are completed: see for example the maintenance scenario in
https://github.com/italobusi/draft-poidt-teas-actn-poi-assurance/
files/10885907/2023.03.draft-poidt-teas-poi-assurance.pptx (slide 4)
6. Failures between the IP and Optical edges
Busi, et al. Expires 14 September 2023 [Page 7]
Internet-Draft ACTN POI Assurance March 2023
6.1. Fault Detection
TODO Describe the mechanisms to detect when the failure occurs on a
router port or on the router node connected with the optical domain:
see for example the fault scenarios in https://github.com/italobusi/
draft-poidt-teas-actn-poi-assurance/files/10885907/2023.03.draft-
poidt-teas-poi-assurance.pptx (slide 5 and slide 6)
6.2. Protection Switching
TODO Describe the mechanisms to protect the traffic when the failure
occurs on a router port or on the router node connected with the
optical domain: see for example the protection scenarios in
https://github.com/italobusi/draft-poidt-teas-actn-poi-assurance/
files/10885907/2023.03.draft-poidt-teas-poi-assurance.pptx (slide 5
and slide 6)
7. Conclusions
This section will provide a summary of the analysis and of the gaps
identified in this draft once the analysis is mature.
8. Security Considerations
TODO Security
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[I-D.ietf-teas-actn-poi-applicability]
Peruzzini, F., Bouquier, J., Busi, I., King, D., and D.
Ceccarelli, "Applicability of Abstraction and Control of
Traffic Engineered Networks (ACTN) to Packet Optical
Integration (POI)", Work in Progress, Internet-Draft,
draft-ietf-teas-actn-poi-applicability-08, 11 January
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-actn-poi-applicability-08>.
Busi, et al. Expires 14 September 2023 [Page 8]
Internet-Draft ACTN POI Assurance March 2023
[I-D.yu-performance-monitoring-yang]
Yu, C., "A YANG Data Model for Optical Performance
Monitoring", Work in Progress, Internet-Draft, draft-yu-
performance-monitoring-yang-00, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-yu-
performance-monitoring-yang-00>.
[RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm
Management", RFC 8632, DOI 10.17487/RFC8632, September
2019, <https://www.rfc-editor.org/info/rfc8632>.
10.2. Informative References
[I-D.mix-teas-actn-poi-extension]
Galimberti, G., Bouquier, J., Gerstel, O., Foster, B., and
D. Ceccarelli, "Applicability of Abstraction and Control
of Traffic Engineered Networks (ACTN) to Packet Optical
Integration (POI) extensions to support Router Optical
interfaces.", Work in Progress, Internet-Draft, draft-mix-
teas-actn-poi-extension-00, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-mix-teas-
actn-poi-extension-00>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Italo Busi
Huawei Technologies
Email: italo.busi@huawei.com
Jean-Francois Bouquier
Vodafone
Email: jeff.bouquier@vodafone.com
Fabio Peruzzini
TIM
Email: fabio.peruzzini@telecomitalia.it
Paolo Volpato
Huawei Technologies
Email: paolo.volpato@huawei.com
Busi, et al. Expires 14 September 2023 [Page 9]
Internet-Draft ACTN POI Assurance March 2023
Prasenjit Manna
Cisco
Email: prmanna@cisco.com
Busi, et al. Expires 14 September 2023 [Page 10]
