Internet DRAFT - draft-lee-teas-actn-vpn-poi
draft-lee-teas-actn-vpn-poi
TEAS Working Group Y. Lee
Internet Draft Q. Wu
Intended status: Informational I. Busi
Expires: April 20, 2019 Huawei
D. Cecarreli
Ericsson
J. Tantsura
Apstra
October 19, 2018
Applicability of Abstraction and Control of Traffic Engineered Networks
(ACTN) to VPN with the Integration of Packet and Optical Networks
draft-lee-teas-actn-vpn-poi-00
Abstract
This document outlines the applicability of Abstraction and
Control of Traffic Engineered Networks (ACTN) to VPN with the
integration of Packet and Optical Networks (POI). It also
identifies a number of scenarios where the integration of packet
and optical networks is necessary to support VPN service
requirements. The role of optical underlay tunnels in the POI is
to support certain applications that require a hard isolation with
strict deterministic latency and guaranteed constant bandwidth.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
Lee, et al. Expires April 2019 [Page 1]
Internet-Draft ACTN Applicability to VPN with POI October 2018
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2019.
Copyright Notice
Copyright (c) 2018 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
(http://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 Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction.................................................3
1.1. Requirements Language.....................................3
2. Background and Scope.........................................4
3. POI with L2/L3VPN Service Under Single Network Operator Control
................................................................5
3.1. POI with single packet and single optical domain..........5
3.2. POI with multiple packet domains and single optical domain8
3.3. POI with multiple packet domains and multiple optical
domains.......................................................10
3.4. Transport of Tunnel and VPN information..................12
3.5. Virtual Switching Instance (VSI) Provisioning for L2VPN..13
3.6. Inter-domain Links Update................................13
3.7. End-to-end Tunnel Management.............................13
4. POI with VN Recursion Under Multiple Network Operators Control
...............................................................14
4.1. Service Request Process between Multiple Operators.......15
4.2. Service/Network Orchestration of Operator 2..............16
5. Security Considerations.....................................16
6. IANA Considerations.........................................17
7. References..................................................17
Lee, et al. Expires April 2019 [Page 2]
Internet-Draft ACTN Applicability to VPN with POI October 2018
7.1. Normative References.....................................17
7.2. Informative References...................................17
8. Contributors................................................18
Authors' Addresses.............................................18
1. Introduction
Abstraction and Control of Traffic Engineered Networks (ACTN)
describes a set of management and control functions used to
operate one or more TE networks to construct virtual networks that
can be represented to customers and that are built from
abstractions of the underlying TE networks so that, for example, a
link in the customer's network is constructed from a path or
collection of paths in the underlying networks [RFC8453].
This document outlines the applicability of ACTN to VPN with the
integration of packet and optical networks which is known as the
Packet and Optical Integration (POI).
It also identifies a number of scenarios where the integration of
packet and optical networks is necessary to support VPN service
requirements. The role of optical underlay tunnels in the POI is
to support certain applications that require a hard isolation with
strict deterministic latency and guaranteed constant bandwidth.
Note that there may be other transport technologies that can
support the aforementioned service requirements such as TSN or
Detnet to name a few. In this particular document, we are focusing
on the currently available network settings where packet networks
are a client layer to optical transport networks as a server
layer. The principle discussed in this document can be applied to
other transport technologies when they are available.
As ACTN [RFC8453] introduces the role of controllers that
facilitate network operations, the scope of this document is how
controllers can facilitate L2/3VPN service provisioning in the
packet and optical transport networks.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
Lee, et al. Expires April 2019 [Page 3]
Internet-Draft ACTN Applicability to VPN with POI October 2018
2. Background and Scope
One of the important functions the MDSC performs is to identify
which TE Tunnels should carry the L3VPN traffic and to relay this
information to the domain-level controllers to ensure proper
Virtual routing and forwarding (VRF) table be populated according
to the TE binding requirement for the L3VPN. This function is
referred to as TE & service mapping function. The YANG model to
provide TE & service mapping function is provided in [TSM]. The
role of the TE-service Mapping model [TSM] is to expose the
mapping relationship between service models and TE models so that
VN/VPN service instantiations provided by the underlying TE
networks can be viewed outside of the MDSC.
The TE-Service Mapping model also provides service-TE binding
information for each service instance so that proper TE tunnel
should be created.
The TE binding requirement types defined in [TSM] are:
a) New VN/Tunnel Binding - A customer could request a VPN
service based on VN/Tunnels that are not shared with other
existing or future services. This might be to meet VPN
isolation requirements.
Under this mode, the following sub-categories can be
supported:
i. Hard Isolation with deterministic characteristics: A
customer could request a VPN service using a set of TE
Tunnels with deterministic characteristics requirements
(e.g., no latency variation) and where that set of TE
Tunnels must not be shared with other VPN services and
must not compete for bandwidth or other network
resources with other TE Tunnels.
ii. Hard Isolation: This is similar to the above case but
without the deterministic characteristics requirements.
iii. Soft Isolation: The customer requests a VPN service
using a set of TE tunnels which can be shared with other
VPN services.
b) VN/Tunnel Sharing - A customer could request a VPN service
where new tunnels (or a VN) do not need to be created for
each VPN and can be shared across multiple VPNs.
Lee, et al. Expires April 2019 [Page 4]
Internet-Draft ACTN Applicability to VPN with POI October 2018
c) VN/Tunnel Modify - This mode allows the modification of the
properties of the existing VN/tunnel (e.g., bandwidth).
This document addresses cases a)-i (hard isolation with
deterministic latency) and a)-ii (hard isolation with non-
deterministic latency). Both cases warrant consideration of
optical undelay bypass tunnels to meet the service requirement.
The optical bypass tunnel could be setup via RSVP-TE signaling and
thus tunnel label allocation could be done during signaling. It is
also possible that PNC and MDSC coordinates to exchange the TE
tunnel label information to setup this optical bypass tunnel. This
document focuses on the latter case.
The multi-hop e-BGP session between ingress and egress for multi-
domain case would be setup to exchange VPN routes. The rest of the
forwarding action is as per the usual BGP L3VPN handling including
the use of TE tunnel.
3. POI with L2/L3VPN Service Under Single Network Operator Control
This section provides a set of specific deployment scenarios for
POI under single network operator control. Specifically, the
following deployment scenarios are discussed in this section:
- One optical transport domain overarched by one packet domain
(see Section 3.1);
- One optical transport domain overarched by multiple packet
domains (see Section 3.2);
- multiple optical transport domains overarched by multiple packet
domains (see Section 3.3).
All scenarios are taking place in the context of an upper layer
service configuration (e.g., L3VPN) in the packet and optical
transport network.
Since this document only addresses the procedure for creating
optical underlay bypass tunnels, it does not affect MP-BGP MPLS
operations for inter-AS scenarios as specified in [RFC4364].
3.1. POI with single packet and single optical domain
This section provides a specific deployment scenario for POI.
Specifically, it provides a deployment scenario in which
hierarchical controllers (an MDSC and two PNCs, one for packet and
Lee, et al. Expires April 2019 [Page 5]
Internet-Draft ACTN Applicability to VPN with POI October 2018
one for optical) facilitate optical bypass tunnel across the
packet domain and the optical domain.
Figure 1 shows this scenario.
+----------+
| MDSC |
+----------+
|
---------
| |
+--------+ +--------+
| P-PNC | | O-PNC |
+--------+ +--------+
| |
| |
+----------------------+
CE / PE PE \ CE
o--/---o o---\---o
\ : : /
\ : AS Domain : /
+-:------------------:-+
: | :
: | :
+-:------------------:-+
/ : : \
/ o..................o \
\ Optical Domain /
\ /
+----------------------+
Figure 1. One Packet Domain and One Optical Domain
The following control sequence describes the scenario depicted in
Figure 1.
a) The MDSC translates the service instance and its requirement
(hard isolation with deterministic latency).
b) The MDSC computes the path if there is any feasible path to
meet the requirement based on the abstracted topology at
hand. Note that there would not be any tunnel in the packet
domain to meet this requirement (hard isolation with
deterministic latency).
c) The MDSC finds a feasible path in the optical domain.
d) The MDSC asks the optical PNC to create a tunnel for this VPN
instance whose endpoints are the ingress PE and the egress PE
Lee, et al. Expires April 2019 [Page 6]
Internet-Draft ACTN Applicability to VPN with POI October 2018
of the packet domain, respectively. The MDSC and Optical PNC
need to maintain an instance ID for this VPN instance.
e) The MDSC asks the Packet PNC to bind a TE-tunnel label (to be
allocated by the egress PE to identify the underlay optical
tunnel) with the VPN ID and the Ingress and Egress interfaces
of the underlay optical tunnel.
f) The PNC in turn asks the Egress PE to allocate a TE-tunnel
label. The Egress PE allocates a TE-tunnel label, populates
the VRF for this VPN instance, and updates the Packet PNC
with the allocated TE-tunnel label. Please refer to the note
below on the details of this procedure in regard to VPN
binding.
Note: There are two cases for binding network instance with
the TE tunnel label:
1. VRF instance does not exist.
2. VRF instance has already been created.
For case 1, the Egress PE needs to bind the TE-tunnel label
and the VPN information (e.g., VPN instance name, VPN label,
RD, RT, Destination IP address, etc.) and inform this binding
information to the packet PNC.
g) The packet PNC informs the MDSC the allocated TE-tunnel label
for the VPN instance.
h) The MDSC informs the optical PNC to bind the TE-tunnel label
with the VPN instance, which has been created previously in
step d).
i) The optical PNC informs this binding information (i.e.,
ingress/egress interfaces from packet domain and the TE-
tunnel label) to the optical ingress switch.
j) The packet PNC informs the ingress PE to use the TE-label for
this VPN instance. The Ingress PE populates the VRF for the
VPN with the TE-label. (Note that the TE-label would need to
be PUSHed over the VPN traffic).
k) When the packet arrives at the ingress PE, it recognizes the
VPN instance and PUSHes the VPN label and the TE-tunnel label
and forward the traffic to optical ingress switch.
l) The optical ingress switch recognizes the TE-tunnel label and
encapsulate the whole data packet including TE-tunnel label
into the OTN payload.
m) The optical egress switch POPs the ODU label and forwards the
data packet to the packet egress PE.
n) The packet egress PE POPs the TE-tunnel label and forwards
the VPN packets to the destination CE.
Lee, et al. Expires April 2019 [Page 7]
Internet-Draft ACTN Applicability to VPN with POI October 2018
Note: in steps k) - l), the assumption made was that the packet
ingress PE is not OTN-capable router. If the packet ingress PE
support channelized OTN interfaces, the data plane behavior in
steps k) and l) would change as the following:
k') When the packets arrives at the ingress PE, it recognizes
the VPN instance and PUSHes the VPN label and the TE-tunnel
label and the ODU label and forward the traffic to optical
ingress switch.
l') The optical ingress switch recognizes the incoming ODU
label and swap it to outgoing ODU label.
3.2. POI with multiple packet domains and single optical domain
This section provides a specific deployment scenario for POI.
Specifically, it provides a deployment scenario in which
hierarchical controllers (an MDSC and two packet PNCs and one
optical PNC) facilitate optical bypass tunnel across the two
packet domains and the optical domain.
Figure 2 shows this scenario.
+----------+
| MDSC |
+----------+
|
-------------------|-------------------
| | |
+--------+ +--------+ +--------+
| P-PNC 1| | O-PNC | | P-PNC 2|
+--------+ +--------+ +--------+
| | |
| | |
+----------------------+ | +----------------------+
CE / PE ASBR \ | / ASBR PE \ CE
o--/---o o---\-----|-----/---o o----\--o
\ : / | \ : /
\ : AS Domain 1 / | \ AS Domain 2 : /
+-:--------------------+ | +-------------------:--+
: | :
: | :
+-:--------------------------------------------------------:--+
/ : : \
/ o........................................................o \
\ Optical Domain /
\ /
+-------------------------------------------------------------+
Lee, et al. Expires April 2019 [Page 8]
Internet-Draft ACTN Applicability to VPN with POI October 2018
Figure 2. Two Packet Domains and One Optical Domain
The control sequence depicted in Figure 2 is same as the control
sequence a)-d) in Section 3.1 with the following differences:
e) The MDSC asks the Packet PNC 2 to bind a TE-tunnel label (to
be allocated by the egress PE to identify the underlay
optical tunnel) with the VPN ID and the Ingress and Egress
interfaces of the underlay optical tunnel.
f) The packet PNC 2 in turn asks the Egress PE to allocate a TE-
tunnel label. The Egress PE allocates a TE-tunnel label,
populates the VRF for this VPN instance, and updates the
packet PNC 2 with the allocated TE-tunnel label. Please refer
to the note below on the details of this procedure in regard
to VPN binding.
Note: There are two cases for binding network instance with
the TE tunnel label:
1. VRF instance does not exist.
2. VRF instance has already been created.
For case 1, the Egress PE needs to bind the TE-tunnel label
and the VPN information (e.g., VPN instance name, VPN label,
RD, RT, Destination IP address, etc.) and inform this binding
information to the packet PNC 2.
g) The packet PNC 2 informs the MDSC the allocated TE-tunnel
label for the VPN instance.
h) The MDSC informs the packet PNC 1 the allocated TE-tunnel
label for the VPN instance.
i) The MDSC informs the optical PNC to bind the TE-tunnel label
with the VPN instance, which has been created previously in
step d).
j) The optical PNC informs this binding information (i.e.,
ingress/egress interfaces from packet domain and the TE-
tunnel label) to the optical ingress switch.
k) The packet PNC 1 informs the ingress PE in Domain 1 to use
the TE-tunnel label for this VPN instance. The Ingress PE in
Domain 2 populates the VRF for the VPN and bind with the TE-
tunnel label. (Note that the TE-tunnel label would need to be
PUSHed over the VPN traffic).
l) When the packets arrives at the ingress PE in Domain 1, it
recognizes the VPN instance and PUSHes the VPN label and the
TE-tunnel label and forward the traffic to optical ingress
switch.
Lee, et al. Expires April 2019 [Page 9]
Internet-Draft ACTN Applicability to VPN with POI October 2018
m) The optical ingress switch recognizes the TE-tunnel label and
encapsulate the whole data packet including TE-tunnel label
into the OTN payload.
n) The optical egress switch POPs the ODU label and forwards the
data packet to the packet egress PE.
o) The packet egress PE in Domain 2 POPs the TE-tunnel label and
forwards the VPN packets to the destination CE.
Note: in steps l) - m), the assumption made was that the packet
ingress PE is not OTN-capable router. If the packet ingress PE
supports channelized OTN interfaces, the data plane behavior in
steps l) and m) would change as the following:
l') When the packets arrives at the ingress PE, it recognizes
the VPN instance and PUSHes the VPN label and the TE-tunnel
label and the ODU label and forward the traffic to optical
ingress switch.
m') The optical ingress switch recognizes the incoming ODU
label and swap it to outgoing ODU label.
3.3. POI with multiple packet domains and multiple optical domains
This section provides a specific deployment scenario for POI.
Specifically, it provides a deployment scenario in which
hierarchical controllers (an MDSC and two packet PNCs and two
optical PNCs) facilitate optical bypass tunnel across two packet
domains and two optical domains.
Figure 3 shows this scenario.
+----------+
| MDSC |
+----------+
|
-------------------|-------------------
| +--------+ |
+--------+ +--------+ 2| +--------+
| P-PNC 1| | O-PNC 1|--+ | P-PNC 2|
+--------+ +--------+| +--------+
| | | |
| | | |
+---------------------- | | +---------------------+
CE / PE ASBR \ | | / ASBR PE \ CE
o--/---o o---\-|-------|--/---o o----\--o
\ : / | | \ : /
Lee, et al. Expires April 2019 [Page 10]
Internet-Draft ACTN Applicability to VPN with POI October 2018
\ : AS Domain 1 / | | \ AS Domain 2 : /
+-:--------------------+ | | +------------------:--+
: | | :
: | | :
+-:-------------------------+ +------------------------:--+
/ : \ / : \
/ o.......................o...\./...o......................o \
\ Optical Domain 1 / \ Optical Domain 2 /
\ / \ /
+---------------------------+ +---------------------------+
Figure 3. Two Packet Domains and One Optical Domain
The control sequence depicted in Figure 3 is same as the control
sequence a)-c) in Section 3.1 with the following differences:
d) The MDSC asks the optical PNC 1 to create a tunnel for this
VPN instance whose endpoints are the ingress PE of the packet
domain 1 and the optical inter-domain interface toward
optical domain 2; and the optical PNC 2 to create a tunnel
for this VPN instance whose endpoints are the optical inter-
domain interface from optical domain 1 and the egress PE of
the packet domain 2. The MDSC and Optical PNC 1 and PNC 2
need to maintain an instance ID for this VPN instance.
e) The MDSC asks the Packet PNC 2 to bind a TE-tunnel label with
the VPN ID and the Ingress and Egress interfaces of the
underlay optical tunnel.
f) The packet PNC 2 in turn asks the Egress PE to allocate a TE-
tunnel label. The Egress PE allocates a TE-tunnel label,
populates the VRF for this VPN instance, and updates the
packet PNC 2 with the allocated TE-tunnel label. Please refer
to the note below on the details of this procedure in regard
to VPN binding.
Note: There are two cases for binding network instance with
the TE tunnel label:
1. VRF instance does not exist.
2. VRF instance has already been created.
For case 1, the Egress PE needs to bind the TE-tunnel label
and the VPN information (e.g., VPN instance name, VPN label,
RD, RT, Destination IP address, etc.) and inform this binding
information to the packet PNC 2.
g) The packet PNC 2 informs the MDSC the allocated TE-tunnel
label for the VPN instance.
Lee, et al. Expires April 2019 [Page 11]
Internet-Draft ACTN Applicability to VPN with POI October 2018
h) The MDSC informs the packet PNC 1 the allocated TE-tunnel
label for the VPN instance.
i) The MDSC informs the optical PNC 1 and PNC 2 to bind the TE-
tunnel label with the instance, which has been created
previously in step d).
j) The optical PNC 1 informs this binding information (i.e.,
ingress/egress interfaces from packet domain and the TE-
tunnel label) to the optical ingress switch in Domain 1.
Likewise, the optical PNC 2 to the optical egress switch in
Domain 2. (Note we assume that the optical border switches in
Domains 1 and 2 would do the normal OTN switching).
k) The packet PNC 1 informs the ingress PE in Domain 1 to use
the TE-tunnel label for this VPN instance. The Ingress PE in
Domain 2 populates the VRF for the VPN with the TE-label.
(Note that the TE-tunnel label would need to be PUSHed over
the VPN traffic).
l) When the VPN packet arrives at the ingress PE in Domain 1, it
recognizes the VPN label and PUSHes the TE-tunnel label and
forward the traffic to optical ingress switch in optical
domain 1.
m) The optical ingress switch in optical domain 1 recognizes the
TE-tunnel label and encapsulate the whole data packets
including TE-tunnel label into the OTN payload.
n) The optical egress switch in optical domain 2 POPs the OTN
label and forwards the data packet to the packet egress PE.
o) The packet egress PE in Domain 2 POPs the TE-tunnel label and
forwards the VPN packet to the destination CE.
Note: in steps l) - m), the assumption made was that the packet
ingress PE is not OTN-capable router. If the packet ingress PE
supports channelized OTN interfaces, the data plane behavior in
steps l) and m) would change as the following:
l') When the packets arrives at the ingress PE, it recognizes
the VPN instance and PUSHes the VPN label and the TE-tunnel
label and the ODU label and forward the traffic to optical
ingress switch in Domain 1.
m') The optical ingress switch in Domain 1 recognizes the
incoming ODU label and swap it to outgoing ODU label.
3.4. Transport of Tunnel and VPN information
The discussions in Section 3 as to the transport mechanism of the
TE-tunnel label used for the underlay bypass tunnel with the VPN
instance information has the undertone of making use of the
controllers. Note that other mechanisms may also be possible and
Lee, et al. Expires April 2019 [Page 12]
Internet-Draft ACTN Applicability to VPN with POI October 2018
that such mechanisms are not precluded when solutions are sought
out.
3.5. Virtual Switching Instance (VSI) Provisioning for L2VPN
The VSI provisioning for L2VPN is similar to the VPN/VRF provision
for L3VPN. L2VPN service types include:
. Point-to-point Virtual Private Wire Services (VPWSs) that use
LDP-signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074];
. Multipoint Virtual Private LAN Services (VPLSs) that use LDP-
signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074];
. Multipoint Virtual Private LAN Services (VPLSs) that use a
Border Gateway Protocol (BGP) control plane as described in
[RFC4761] and [RFC6624];
. IP-Only LAN-Like Services (IPLSs) that are a functional subset
of VPLS services [RFC7436];
. BGP MPLS-based Ethernet VPN Services as described in [RFC7432]
and [RFC7209];
. Ethernet VPN VPWS specified in [RFC8214] and [RFC7432].
3.6. Inter-domain Links Update
In order to facilitate inter-domain links for the VPN, we assume
that the service/network orchestrator would know the inter-domain
link status and its resource information (e.g., bandwidth
available, protection/restoration policy, etc.) via some
mechanisms (which are beyond the scope of this document). We also
assume that the inter-domain links are pre-configured prior to
service instantiation.
3.7. End-to-end Tunnel Management
It is foreseen that the MDSC should control and manage end-to-end
tunnels for VPNs per VPN policy.
As discussed in [ACTN-Telemetry], the MDSC is responsible to
collect domain LSP-level performance monitoring data from domain
controllers and to derive and report end-to-end tunnel performance
monitoring information to the customer.
Lee, et al. Expires April 2019 [Page 13]
Internet-Draft ACTN Applicability to VPN with POI October 2018
4. POI with VN Recursion Under Multiple Network Operators Control
[RFC8453] briefly introduces a case for the VN supplied to a
customer may be built using resources from different technology
layers operated by different operators. For example, one operator
may run a packet TE network and use optical connectivity provided
by another operator.
Figure 4, extracted from [RFC8453], shows the case where a
customer asks for end-to-end connectivity between CE A and CE B, a
virtual network. The customer's CNC makes a request to Operator
1's MDSC. The MDSC works out which network resources need to be
configured and sends instructions to the appropriate PNCs.
However, the link between Q and R is a virtual link supplied by
Operator 2: Operator 1 is a customer of Operator 2.
To support this, Operator 1 has a CNC that communicates with
Operator 2's MDSC. Note that Operator 1's CNC in Figure 10 is a
functional component that does not dictate implementation: it may
be embedded in a PNC.
Virtual CE A o===============================o CE B
Network
----- CNC wants to create a VN
Customer | CNC | between CE A and CE B
-----
:
*********************************************** CMI
:
Operator 1 ---------------------------
| MDSC |
---------------------------
: : :
: : :
----- ------------- -----
| PNC | | PNC | | PNC |
----- ------------- -----
: : : : :
Higher v v : v v
Layer CE A o---P-----Q===========R-----S---o CE B
Network | : |
| : |
| ----- |
| | CNC | | CNC wants to create a VN
| ----- | between Q and R
Lee, et al. Expires April 2019 [Page 14]
Internet-Draft ACTN Applicability to VPN with POI October 2018
| : |
*********************************************** CMI
| : |
Operator 2 | ------ |
| | MDSC | |
| ------ |
| : |
| ------- |
| | PNC | |
| ------- |
\ : : : /
Lower \v v v/
Layer X--Y--Z
Network
Where
--- is a link
=== is a virtual link
Figure 4: VN Recursion with Network Layers
The CMI in Figure 4 interfaces Operator 1's CNC with Operator 2's
MDSC. The functions to perform and the information carried over
the inter-operator CMI are identical to those of the Customer's
CNC and Operator 1's MDSC. In other words, the two CMIs depicted
in Figure 4 are recursive in nature.
From a data plane perspective, the interaction between operator 1
and operator 2 is similar to the POI case discussed in section 3.2
(See Figure 2) with an exception that the packet domains belong to
operator 1 while optical domain to operator 2.
The control interface depicted in Figure 4 (i.e., the CNC of
operator 1 and the MDSC of operator 2) should behave similarly to
4.1. Service Request Process between Multiple Operators
As discussed previously, the reclusiveness principle applies
seamlessly over the two CMIs. This implies that Operator 1's MDSC
needs to pass all customer service requirements transparently to
Operator 2's MDSC so that Operator 2 should provision its underlay
network tunnels to meet the service requirements of the original
customer. The MDSC of Operator 1 should translate/map the original
customer's intent and service requirements and pass down to the
corresponding PNC(s) which is(are) responsible for interfacing
another operator (in this example, Operator 2) that provides
Lee, et al. Expires April 2019 [Page 15]
Internet-Draft ACTN Applicability to VPN with POI October 2018
transport services for the segment of the customer's VN. The PNC
in turn performs as a CNC when interfacing its southbound with
Operator 2's MDSC.
It is possible that additional recursive relationships may also
exist between Operator 2 and other operators.
4.2. Service/Network Orchestration of Operator 2
Operator 2 that provides transport service for Operator 1 may also
need to perform service/network orchestration function just as the
case for Operator 1.
From a data plane perspective, the interaction between operator 1
and operator 2 is similar to the POI case discussed in section 3.2
(See Figure 2) with an exception that the packet domains belong to
operator 1 while optical domain to operator 2.
The control interface depicted in Figure 4 (i.e., the CNC of
operator 1 and the MDSC of operator 2) should behave similarly to
that of the MDSC and the PNCs discussed in Section 3.
5. Security Considerations
This document defines key components and interfaces for managed
traffic engineered networks. Securing the request and control of
resources, confidentially of the information, and availability of
function, should all be critical security considerations when
deploying and operating ACTN POI platforms.
Several distributed ACTN functional components are required, and
implementations should consider encrypting data that flows between
components, especially when they are implemented at remote nodes,
regardless these data flows are on external or internal network
interfaces.
From a security and reliability perspective, ACTN POI may
encounter many risks such as malicious attack and rogue elements
attempting to connect to various ACTN POI components.
Furthermore, some ACTN POI components represent a single point of
failure and threat vector, and must also manage policy conflicts,
and eavesdropping of communication between different ACTN POI
components.
The conclusion is that all protocols used to realize the ACTN POI
should have rich security features, and customer, application and
network data should be stored in encrypted data stores. Additional
Lee, et al. Expires April 2019 [Page 16]
Internet-Draft ACTN Applicability to VPN with POI October 2018
security risks may still exist. Therefore, discussion and
applicability of specific security functions and protocols will be
better described in documents that are use case and environment
specific.
6. IANA Considerations
This document has no actions for IANA.
7. References
7.1. Normative References
[RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and
Control of Transport Networks", RFC 8453, August 2018.
7.2. Informative References
[DHODY] D. Dhody, et al., "Packet Optical Integration (POI) Use
Cases for Abstraction and Control of Transport Networks
(ACTN)", draft-dhody-actn-poi-use-case, work in progress.
[bgp-l3vpn] D. Jain, et al. "Yang Data Model for BGP/MPLS L3 VPNs",
draft-ietf-bess-l3vpn-yang, work in progress.
[RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[ACTN-VN] Y. Lee, et al., "A Yang Data Model for ACTN VN Operation",
draft-lee-teas-actn-vn-yang, work in progress.
[TSM] Y. Lee, et al., "Traffic Engineering and Service Mapping Yang
Model", draft-lee-teas-te-service-mapping-yang, work in
progress.
[TE-Topo] X. Liu, et al., "YANG Data Model for Traffic Engineering
(TE) Topologies", draft-ietf-teas-yang-te-topo, work in
progress.
[RFC8309] Q. Wu, W. Liu, and A. Farrel, "Service Models Explained",
RFC 8309, January 2018.
[L3SM] Q. Wu, S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC 8299, January 2018.
[L2SM] G. Fioccola (Ed), "A YANG Data Model for L2VPN Service
Delivery", draft-ietf-l2sm-l2vpn-service-model, work in
progress.
Lee, et al. Expires April 2019 [Page 17]
Internet-Draft ACTN Applicability to VPN with POI October 2018
[ACTN-Telemetry] Y. Lee, et al.," YANG models for ACTN TE
Performance Monitoring Telemetry and Network Autonomics",
draft-lee-teas-actn-pm-telemetry-autonomics, work in
progress.
8. Contributors
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
Dhruv Dhody
Huawei
Email: dhruv.dhody@huawei.com
Haomian Zheng
Huawei
Email: haomianzheng@hauwei.com
Authors' Addresses
Young Lee
Huawei Technologies
Email: leeyoung@huawei.com
Qin Wu
Huawei Technologies
Email: bill.wu@huawei.com
Italo Busi
Huawei Technologies
Email: Italo.Busi@huawei.com
Daniele Ceccarelli
Ericsson
Email: daniele.ceccarelli@ericsson.com
Jeff Tantsura
Nuage
Email: jefftant.ietf@gmail.com
Lee, et al. Expires April 2019 [Page 18]
