Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)
draft-peru-teas-actn-poi-applicability-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Fabio Peruzzini , Jean-Francois Bouquier , Italo Busi , Daniel King , Daniele Ceccarelli | ||
| Last updated | 2020-06-18 (Latest revision 2020-06-17) | ||
| Replaces | draft-lee-teas-actn-poi-applicability | ||
| Replaced by | draft-ietf-teas-actn-poi-applicability | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-peru-teas-actn-poi-applicability-04
3.3.1. YANG models used at the MPIs This section is for further study 3.4. Provisioning Link Members to an existing LAG When adding a new link member to a LAG between two routers with or without path latency/diversity constraint, the MDSC must be able to force the additional optical connection to use the same physical path in the optical domain where the LAG capacity increase is required. 3.4.1. YANG Models used at the MPIs This is for further study 4. Multi-Layer Recovery Coordination 4.1. Ensuring Network Resiliency during Maintenance Events Before planned maintenance operation on DWDM network takes place, IP traffic should be moved hitless to another link. MDSC must reroute IP traffic before the events takes place. It should be possible to lock IP traffic to the protection route until the maintenance event is finished, unless a fault occurs on such path. 4.2. Router Port Failure The focus is on client-side protection scheme between IP router and reconfigurable ROADM. Scenario here is to define only one port in the routers and in the ROADM muxponder board at both ends as back-up ports to recover any other port failure on client-side of the ROADM (either on router port side or on muxponder side or on the link between them). When client-side port failure occurs, alarms are raised to MDSC by IP-PNC and O-PNC (port status down, LOS etc.). MDSC checks with OP-PNC(s) that there is no optical failure in the optical layer. There can be two cases here: Peruzzini et al. Expires December 17, 2020 [Page 13] Internet-Draft ACTN POI June 2020 a) LAG was defined between the two end routers. MDSC, after checking that optical layer is fine between the two end ROADMs, triggers the ROADM configuration so that the router back-up port with its associated muxponder port can reuse the OCh that was already in use previously by the failed router port and adds the new link to the LAG on the failure side. While the ROADM reconfiguration takes place, IP/MPLS traffic is using the reduced bandwidth of the IP link bundle, discarding lower priority traffic if required. Once backup port has been reconfigured to reuse the existing OCh and new link has been added to the LAG then original Bandwidth is recovered between the end routers. 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 of the link member of the LAG fails. b) If there is no LAG then the scenario is not clear since a router port failure would automatically trigger (through BFD failure) first a sub-50ms protection at MPLS level :FRR (MPLS RSVP-TE case) or TI-LFA (MPLS based SR-TE case) through a protection port. At the same time MDSC, after checking that optical network connection is still fine, would trigger the reconfiguration of 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 port. Once everything has been correctly configured, MDSC Global PCE could suggest to the operator to trigger a possible re- optimisation of the back-up MPLS path to go back to the MPLS primary path through the back-up port of the router and the original OCh if overall cost, latency etc. is improved. However, 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. 5. Service Coordination for Multi-Layer network [Editors' Note] This text has been taken from section 2 of draft- lee-teas-actn-poi-applicability-00 and need to be reconciled with the other sections (the introduction in particular) of this document This section provides a number of deployment scenarios for packet and optical integration (POI). Specifically, this section provides a deployment scenario in which ACTN hierarchy is deployed to control a multi-layer and multi-domain network via two IP/MPLS PNCs and two Optical PNCs with coordination with L-MDSC. This scenario is in the context of an upper layer service configuration (e.g. L3VPN) across Peruzzini et al. Expires December 17, 2020 [Page 14] Internet-Draft ACTN POI June 2020 two AS domains which are transported by two transport underlay domains (e.g. OTN). The provisioning of the L3VPN service is outside ACTN scope but it is worth showing how the L3VPN service provisioning is integrated for the end-to-end service fulfilment in ACTN context. An example of service configuration function in the Service/Network Orchestrator is discussed in [BGP-L3VPN]. Figure 2 shows an ACTN POI Reference Architecture where it shows ACTN components as well as non-ACTN components that are necessary for the end-to-end service fulfilment. Both IP/MPLS and Optical Networks are multi-domain. Each IP/MPLS domain network is controlled by its' domain controller and all the optical domains are controlled by a hierarchy of optical domain controllers. The L-MDSC function of the optical domain controllers provides an abstract view of the whole optical network to the Service/Network Orchestrator. It is assumed that all these components of the network belong to one single network operator domain under the control of the service/network orchestrator. Peruzzini et al. Expires December 17, 2020 [Page 15] Internet-Draft ACTN POI June 2020 Customer +-------------------------------+ | +-----+ +------------+ | | | CNC |----| Service Op.| | | +-----+ +------------+ | +-------|------------------|----+ | ACTN interface | Non-ACTN interface | CMI | (Customer Service model) Service/Network| +-----------------+ Orchestrator | | +-----|------------------------------------|-----------+ | +----------------------------------+ | | | |MDSC TE & Service Mapping Function| | | | +----------------------------------+ | | | | | | | | +------------------+ +---------------------+ | | | MDSC NP Function |-------|Service Config. Func.| | | +------------------+ +---------------------+ | +------|---------------------------|-------------------+ MPI | +---------------------+--+ | / Non-ACTN interface \ +-------+---/-------+------------+ \ IP/MPLS | / |Optical | \ IP/MPLS Domain 1 | / |Domain | \ Domain 2 Controller| / |Controller | \ Controller +------|-------/--+ +---|-----+ +--|-----------\----+ | +-----+ +-----+| | +-----+ | |+------+ +------+| | |PNC1 | |Serv.|| | |PNC | | || PNC2 | | Serv.|| | +-----+ +----- | | +-----+ | |+------+ +------+| +-----------------+ +---------+ +-------------------+ SBI | | | SBI v | V +------------------+ | +------------------+ / IP/MPLS Network \ | / IP/MPLS Network \ +----------------------+ | SBI +----------------------+ v +-------------------------------+ / Optical Network \ +-----------------------------------+ Figure 2 ACTN POI Reference Architecture Figure 2 shows ACTN POI Reference Architecture where it depicts: Peruzzini et al. Expires December 17, 2020 [Page 16] Internet-Draft ACTN POI June 2020 o CMI (CNC-MDSC Interface) interfacing CNC with MDSC function in the Service/Network Orchestrator. This is where TE & Service Mapping [TSM] and either ACTN VN [ACTN-VN] or TE-topology [TE- TOPO] model is exchanged over CMI. o Customer Service Model Interface: Non-ACTN interface in the Customer Portal interfacing Service/Network Orchestrator's Service Configuration Function. This is the interface where L3SM information is exchanged. o MPI (MDSC-PNC Interface) interfacing IP/MPLS Domain Controllers and Optical Domain Controllers. o Service Configuration Interface: Non-ACTN interface in Service/Network Orchestrator interfacing with the IP/MPLS Domain Controllers to coordinate L2/L3VPN multi-domain service configuration. This is where service specific information such as VPN, VPN binding policy (e.g., new underlay tunnel creation for isolation), etc. are conveyed. o SBI (South Bound Interface): Non-ACTN interface in the domain controller interfacing network elements in the domain. Please note that MPI and Service Configuration Interface can be implemented as the same interface with the two different capabilities. The split is just functional but doesn't have to be also logical. The following sections are provided to describe key functions that are necessary for the vertical as well as horizontal end-to-end service fulfilment of POI. 5.1. L2/L3VPN/VN Service Request by the Customer A customer can request L3VPN services with TE requirements using ACTN CMI models (i.e., ACTN VN YANG, TE & Service Mapping YANG) and non-ACTN customer service models such as L2SM/L3SM YANG together. Figure 3 shows detailed control flow between customer and service/network orchestrator to instantiate L2/L3VPN/VN service request. Peruzzini et al. Expires December 17, 2020 [Page 17] Internet-Draft ACTN POI June 2020 Customer +-------------------------------------------+ | +-----+ +------------+ | | | CNC |--------------| Service Op.| | | +-----+ +------------+ | +-------|------------------------|----------+ 2. VN & TE/Svc | | 1.L2/3SM Mapping | | | | | ^ | | | | | | | v | | 3. Update VN | v | & TE/Svc | Service/Network | mapping | Orchestrator | | +------------------|------------------------|-----------+ | +----------------------------------+ | | | |MDSC TE & Service Mapping Function| | | | +----------------------------------+ | | | | | | | | +------------------+ +---------------------+ | | | MDSC NP Function |-------|Service Config. Func.| | | +------------------+ +---------------------+ | +-------|-----------------------------------|-----------+ NP: Network Provisioning Figure 3 Service Request Process o ACTN VN YANG provides VN Service configuration, as specified in [ACTN-VN]. o It provides the profile of VN in terms of VN members, each of which corresponds to an edge-to-edge link between customer end-points (VNAPs). It also provides the mappings between the VNAPs with the LTPs and between the connectivity matrix with the VN member from which the associated traffic matrix (e.g., bandwidth, latency, protection level, etc.) of VN member is expressed (i.e., via the TE-topology's connectivity matrix). o The model also provides VN-level preference information (e.g., VN member diversity) and VN-level admin-status and operational-status. Peruzzini et al. Expires December 17, 2020 [Page 18] Internet-Draft ACTN POI June 2020 o L2SM YANG [RFC8466] provides all L2VPN service configuration and site information from a customer/service point of view. o L3SM YANG [RFC8299] provides all L3VPN service configuration and site information from a customer/service point of view. o The TE & Service Mapping YANG model [TSM] provides TE-service mapping as well as site mapping. o TE-service mapping provides the mapping of L3VPN instance from [RFC8299] with the corresponding ACTN VN instance. o The TE-service mapping also provides the service mapping requirement type as to how each L2/L3VPN/VN instance is created with respect to the underlay TE tunnels (e.g., whether the L3VPN requires a new and isolated set of TE underlay tunnels or not, etc.). See Section 5.2 for detailed discussion on the mapping requirement types. o Site mapping provides the site reference information across L2/L3VPN Site ID, ACTN VN Access Point ID, and the LTP of the access link. 5.2. Service and Network Orchestration The Service/Network orchestrator shown in Figure 2 interfaces the customer and decouples the ACTN MDSC functions from the customer service configuration functions. An implementation can choose to split the Service/Network orchestration functions, as described in [RFC8309] and in section 4.2 of [RFC8453], between a top-level Service Orchestrator interfacing the customer and two low-level Network Orchestrators, one controlling a multi-domain IP/MPLS network and the other controlling the Optical networks. Another implementation can choose to combine the L-MDSC functions of the Optical hierarchical controller, providing multi-domain coordination of the Optical network together with the MDSC functions in the Service/Network orchestrator. Without loss of generality, this assumes that the service/network orchestrator as depicted in Figure 2 would include all the required functionalities as in a hierarchical orchestration case. Peruzzini et al. Expires December 17, 2020 [Page 19] Internet-Draft ACTN POI June 2020 One of the important service functions the Service/Network orchestrator performs is to identify which TE Tunnels should carry the L3VPN traffic (from TE & Service Mapping Model) and to relay this information to the IP/MPLS domain controllers, via non-ACTN interface, to ensure proper IP/VRF forwarding table be populated according to the TE binding requirement for the L3VPN. [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 domain controllers and IP/MPLS PE routers) the TE binding policy dynamically for the L3VPN? Typically, VRF is the function of the 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. Figure 4 shows service/network orchestrator interactions with various domain controllers to instantiate tunnel provisioning as well as service configuration. Peruzzini et al. Expires December 17, 2020 [Page 20] Internet-Draft ACTN POI June 2020 +-------|----------------------------------|-----------+ | +----------------------------------+ | | | |MDSC TE & Service Mapping Function| | | | +----------------------------------+ | | | | | | | | +------------------+ +---------------------+ | | | MDSC NP Function |-------|Service Config. Func.| | | +------------------+ +---------------------+ | +-------|------------------------------|---------------+ | | | +-------------------+------+ 3. 2. Inter-layer | / \ VPN Serv. tunnel +-----+--------/-------+-----------------+ \provision binding| / | 1. Optical | \ | / | tunnel creation | \ +----|-----------/-+ +---|------+ +-----|-------\---+ | +-----+ +-----+ | | +------+ | | +-----+ +-----+| | |PNC1 | |Serv.| | | | PNC | | | |PNC2 | |Serv.|| | +-----+ +-----+ | | +------+ | | +-----+ +-----+| +------------------+ +----------+ +-----------------+ Figure 4 Service and Network Orchestration Process TE binding requirement types [TSM] are: 1. Hard Isolation with deterministic latency: Customer would request an L3VPN service [RFC8299] using a set of TE Tunnels with a deterministic latency requirement and that cannot be not shared with other L3VPN services nor compete for bandwidth with other Tunnels. 2. Hard Isolation: This is similar to the above case without deterministic latency requirements. 3. Soft Isolation: Customer would request an L3VPN service using a set of MPLS-TE tunnel which cannot be shared with other L3VPN services. 4. Sharing: Customer would accept sharing the MPLS-TE Tunnels supporting its L3VPN service with other services. For the first three types, there could be additional TE binding requirements with respect to different VN members of the same VN Peruzzini et al. Expires December 17, 2020 [Page 21] Internet-Draft ACTN POI June 2020 associated with an L3VPN service. For the first two cases, VN members can be hard-isolated, soft-isolated, or shared. For the third case, VN members can be soft-isolated or shared. o When "Hard Isolation with or w/o deterministic latency" (i.e., the first and the second type) TE binding requirement is applied for a L3VPN, a new optical layer tunnel has to be created (Step 1 in Figure 4). This operation requires the following control level mechanisms as follows: o The MDSC function of the Service/Network Orchestrator identifies only the domains in the IP/MPLS layer in which the VPN needs to be forwarded. o Once the IP/MPLS layer domains are determined, the MDSC function of the Service/Network Orchestrator needs to identify the set of optical ingress and egress points of the underlay optical tunnels providing connectivity between the IP/MPLS layer domains. o Once both IP/MPLS layers and optical layer are determined, the MDSC needs to identify the inter-layer peering points in both IP/MPLS domains as well as the optical domain(s). This implies that the L3VPN traffic will be forwarded to an MPLS- TE tunnel that starts at the ingress PE (in one IP/MPLS domain) and terminates at the egress PE (in another IP/MPLS domain) via a dedicated underlay optical tunnel. o The MDSC function of the Service/Network Orchestrator needs to first request the optical L-MDSC to instantiate an optical tunnel for the optical ingress and egress. This is referred to as optical tunnel creation (Step 1 in Figure 4). Note that it is L- MDSC responsibility to perform multi-domain optical coordination with its underlying optical PNCs, for setting up a multi-domain optical tunnel. o Once the optical tunnel is established, then the MDSC function of the Service/Network Orchestrator needs to coordinate with the PNC functions of the IP/MPLS Domain Controllers (under which the ingress and egress PEs belong) the setup of a multi-domain MPLS- TE Tunnel, between the ingress and egress PEs. This setup is carried by the created underlay optical tunnel (Step 2 in Figure 4). Peruzzini et al. Expires December 17, 2020 [Page 22] Internet-Draft ACTN POI June 2020 o It is the responsibility of the Service Configuration Function of the Service/Network Orchestrator to identify interfaces/labels on both ingress and egress PEs and to convey this information to both the IP/MPLS Domain Controllers (under which the ingress and egress PEs belong) for proper configuration of the L3VPN (BGP and VRF function of the PEs) in their domain networks (Step 3 in Figure 4). 5.3. IP/MPLS Domain Controller and NE Functions IP/MPLS networks are assumed to have multiple domains and each domain is controlled by IP/MPLS domain controller in which the ACTN PNC functions and non-ACTN service functions are performed by the IP/MPLS domain controller. Among the functions of the IP/MPLS domain controller are VPN service aspect provisioning such as VRF control and management for VPN services, etc. It is assumed that BGP is running in the inter-domain IP/MPLS networks for L2/L3VPN and that the IP/MPLS domain controller is also responsible for configuring the BGP speakers within its control domain if necessary. Depending on the TE binding requirement types discussed in Section 5.2, there are two possible deployment scenarios. 5.3.1. Scenario A: Shared Tunnel Selection When the L2/L3VPN does not require isolation (either hard or soft), it can select an existing MPLS-TE and Optical tunnel between ingress and egress PE, without creating any new TE tunnels. Figure 5 shows this scenario. Peruzzini et al. Expires December 17, 2020 [Page 23] Internet-Draft ACTN POI June 2020 IP/MPLS Domain 1 IP/MPLS Domain 2 Controller Controller +------------------+ +------------------+ | +-----+ +-----+ | | +-----+ +-----+ | | |PNC1 | |Serv.| | | |PNC2 | |Serv.| | | +-----+ +-----+ | | +-----+ +-----+ | +--|-----------|---+ +--|-----------|---+ | 1.Tunnel | 2.VPN/VRF | 1.Tunnel | 2.VPN/VRF | Selection | Provisioning | Selection | Provisioning V V V V +---------------------+ +---------------------+ CE / PE tunnel 1 ASBR\ /ASBR tunnel 2 PE \ CE o--/---o..................o--\--------/--o..................o--- \--o \ / \ / \ AS Domain 1 / \ AS Domain 2 / +---------------------+ +---------------------+ End-to-end tunnel <-----------------------------------------------------> Figure 5 IP/MPLS Domain Controller & NE Functions How VPN is disseminated across the network is out of the scope of this document. We assume that MP-BGP is running in IP/MPLS networks and VPN is made known to ABSRs and PEs by each IP/MPLS domain controllers. See [RFC4364] for detailed descriptions on how MP-BGP works. There are several functions IP/MPLS domain controllers need to provide in order to facilitate tunnel selection for the VPN in both domain level and end-to-end level. 5.3.1.1. Domain Tunnel Selection Each domain IP/MPLS controller is responsible for selecting its domain level tunnel for the L3VPN. First it needs to determine which existing tunnels would fit for the L2/L3VPN requirements allotted to the domain by the Service/Network Orchestrator (e.g., tunnel binding, bandwidth, latency, etc.). If there are existing tunnels that are feasible to satisfy the L3VPN requirements, the IP/MPLS domain controller selects the optimal tunnel from the candidate Peruzzini et al. Expires December 17, 2020 [Page 24] Internet-Draft ACTN POI June 2020 pool. Otherwise, an MPLS tunnel with modified bandwidth or a new MPLS Tunnel needs to be setup. Note that with no isolation requirement for the L3VPN, existing MPLS tunnel can be selected. With soft isolation requirement for the L3VPN, an optical tunnel can be shared with other L2/L3VPN services while with hard isolation requirement for the L2/L3VPN, a dedicated MPLS-TE and a dedicated optical tunnel MUST be provisioned for the L2/L3VPN. 5.3.1.2. VPN/VRF Provisioning for L3VPN Once the domain level tunnel is selected for a domain, the Service Function of the IP/MPLS domain controller maps the L3VPN to the selected MPLS-TE tunnel and assigns a label (e.g., MPLS label) with the PE. Then the PE creates a new entry for the VPN in the VRF forwarding table so that when the VPN packet arrives to the PE, it will be able to direct to the right interface and PUSH the label assigned for the VPN. When the PE forwards a VPN packet, it will push the VPN label signaled by BGP and, in case of option A and B [RFC4364], it will also push the LSP label assigned to the configured MPLS-TE Tunnel to reach the ASBR next hop and forwards the packet to the MPLS next-hop of this MPLS-TE Tunnel. In case of option C [RFC4364], the PE will push one MPLS LSP label signaled by BGP to reach the destination PE and a second MPLS LSP label assigned to the configured MPLS-TE Tunnel to reach the ASBR next-hop and forward the packet to the MPLS next-hop of this MPLS-TE Tunnel. With Option C, the ASBR of the first domain interfacing the next domain should keep the VPN label intact to the ASBR of the next domain so that the ASBR in the next domain sees the VPN packets as if they are coming from a CE. With Option B, the VPN label is swapped. With option A, the VPN label is removed. With Option A and B, the ASBR of the second domain does the same procedure that includes VPN/VRF tunnel mapping and interface/label assignment with the IP/MPLS domain controller. With option A, the ASBR operations are the same as of the PEs. With option B, the ASBR operates with VPN labels so it can see the VPN the traffic belongs to. With option C, the ASBR operates with the end-to-end tunnel labels so it may be not aware of the VPN the traffic belongs to. This process is repeated in each domain. The PE of the last domain interfacing the destination CE should recognize the VPN label when Peruzzini et al. Expires December 17, 2020 [Page 25] Internet-Draft ACTN POI June 2020 the VPN packets arrive and thus POP the VPN label and forward the packets to the CE. 5.3.1.3. VSI Provisioning for L2VPN The VSI provisioning for L2VPN is similar to the VPN/VRF provision for L3VPN. L2VPN service types include: o Point-to-point Virtual Private Wire Services (VPWSs) that use LDP-signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; o Multipoint Virtual Private LAN Services (VPLSs) that use LDP- signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; o Multipoint Virtual Private LAN Services (VPLSs) that use a Border Gateway Protocol (BGP) control plane as described in [RFC4761]and [RFC6624]; o IP-Only LAN-Like Services (IPLSs) that are a functional subset of VPLS services [RFC7436]; o BGP MPLS-based Ethernet VPN Services as described in [RFC7432] and [RFC7209]; o Ethernet VPN VPWS specified in [RFC8214] and [RFC7432]. 5.3.1.4. 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. 5.3.1.5. End-to-end Tunnel Management It is foreseen that the Service/Network orchestrator should control and manage end-to-end tunnels for VPNs per VPN policy. As discussed in [ACTN-PM], the Orchestrator 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. Peruzzini et al. Expires December 17, 2020 [Page 26] Internet-Draft ACTN POI June 2020 5.3.2. Scenario B: Isolated VN/Tunnel Establishment When the L3VPN requires hard-isolated Tunnel establishment, optical layer tunnel binding with IP/MPLS layer is necessary. As such, the following functions are necessary. o The IP/MPLS Domain Controller of Domain 1 needs to send the VRF instruction to the PE: o To the Ingress PE of AS Domain 1: Configuration for each L3VPN destination IP address (in this case the remote CE's IP address for the VPN or any customer's IP addresses reachable through a remote CE) of the associated VPN label assigned by the Egress PE and of the MPLS-TE Tunnel to be used to reach the Egress PE: so that the proper VRF table is populated to forward the VPN traffic to the inter-layer optical interface with the VPN label. o The Egress PE, upon the discovery of a new IP address, needs to send the mapping information (i.e., VPN to IP address) to its' IP/MPLS Domain Controller of Domain 2 which sends, in turn, to the service orchestrator. The service orchestrator would then propagate this mapping information to the IP/MPLS Domain Controller of Domain 1 which sends it, in turn, to the ingress PE so that it may override the VPN/VRF forwarding or VSI forwarding, respectively for L3VPN and L2VPN. As a result, when packets arriving at the ingress PE with that IP destination address, the ingress PE would then forward this packet to the inter-layer optical interface. [Editor's Note] in case of hard isolated tunnel required for the VPN, we need to create a separate MPLS TE tunnel and encapsulate the MPLS packets of the MPLS Tunnel into the ODU so that the optical NE would route this MPLS Tunnel to a separate optical tunnel from other tunnels.] 5.4. Optical Domain Controller and NE Functions Optical network provides the underlay connectivity services to IP/MPLS networks. The multi-domain optical network coordination is performed by the L-MDSC function shown in Figure 2 so that the whole multi-domain optical network appears to the service/network orchestrator as one optical network. The coordination of Packet/Optical multi-layer and IP/MPLS multi-domain is done by the service/network orchestrator where it interfaces two IP/MPLS domain controllers and one optical L-MDSC. Peruzzini et al. Expires December 17, 2020 [Page 27] Internet-Draft ACTN POI June 2020 Figure 6 shows how the Optical Domain Controllers create a new optical tunnel and the related interaction with IP/MPLS domain controllers and the NEs to bind the optical tunnel with proper forwarding instruction so that the VPN requiring hard isolation can be fulfilled. IP/MPLS Domain 1 Optical Domain IP/MPLS Domain 2 Controller Controller Controller +------------------+ +---------+ +------------------+ | +-----+ +-----+ | | +-----+ | | +-----+ +-----+ | | |PNC1 | |Serv.| | | |PNC | | | |PNC2 | |Serv.| | | +-----+ +-----+ | | +-----+ | | +-----+ +-----+ | +--|-----------|---+ +----|----+ +--|----------|----+ | 2.Tunnel | 3.VPN/VRF | |2.Tunnel | 3.VPN/VRF | Binding | Provisioning| |Binding | Provisioning V V | V V +-------------------+ | +-------------------+ CE / PE ASBR\ | /ASBR PE \ CE o--/---o o--\----|--/--o o---\--o \ : / | \ : / \ : AS Domain 1 / | \ AS Domain 2 : / +-:-----------------+ | +-----------------:-+ : | : : | 1. Optical : : | Tunnel Creation : : v : +-:--------------------------------------------------:-+ / : : \ / o..................................................o \ | Optical Tunnel | \ / \ Optical Domain / +------------------------------------------------------+ Figure 6 Domain Controller & NE Functions (Isolated Optical Tunnel) As discussed in 5.2, in case that VPN has requirement for hard- isolated tunnel establishment, the service/network orchestrator will coordinate across IP/MPLS domain controllers and Optical L-MDSC to ensure the creation of a new optical tunnel for the VPN in proper sequence. Figure 6 shows this scenario. Peruzzini et al. Expires December 17, 2020 [Page 28] Internet-Draft ACTN POI June 2020 o The MDSC of the service/network orchestrator requests the L-MDSC to setup and Optical tunnel providing connectivity between the inter-layer interfaces at the ingress and egress PEs and requests the two IP/MPLS domain controllers to setup an inter-domain IP link between these interfaces o The MDSC of the service/network orchestrator then should provide the ingress IP/MPLS domain controller with the routing instruction for the VPN so that the ingress IP/MPLS domain controller would help its ingress PE to populate forwarding table. The packet with the VPN label should be forwarded to the optical interface the MDSC provided. o The Ingress Optical Domain PE needs to recognize MPLS-TE label on its ingress interface from IP/MPLS domain PE and encapsulate the MPLS packets of this MPLS-TE Tunnel into the ODU. [Editor's Note] We assumed that the Optical PE is LSR.] o The Egress Optical Domain PE needs to POP the ODU label before sending the packet (with MPLS-TE label kept intact at the top level) to the Egress PE in the IP/MPLS Domain to which the packet is destined. [Editor's Note] If there are two VPNs having the same destination CE requiring non-shared optical tunnels from each other, we need to explain this case with a need for additional Label to differentiate the VPNs] 5.5. Orchestrator-Controllers-NEs Communication Protocol Flows This section provides generic communication protocol flows across orchestrator, controllers and NEs in order to facilitate the POI scenarios discussed in Section 5.3.2 for dynamic optical Tunnel establishment. Figure 7 shows the communication flows. Peruzzini et al. Expires December 17, 2020 [Page 29] Internet-Draft ACTN POI June 2020 +---------+ +-------+ +------+ +------+ +------+ +------+ |Orchestr.| |Optical| |Packet| |Packet| |Ing.PE| |Egr.PE| | | | Ctr. | |Ctr-D1| |Ctr-D2| | D1 | | D2 | +---------+ +-------+ +------+ +------+ +------+ +------+ | | | | | | | | | | |<--BGP--->| | | | |VPN Update | | | | | VPN Update|<---------------------| |<--------------------------------------|(Dest, VPN)| | | | |(Dest, VPN)| | | | Tunnel Create | | | | | |---------------->| | | | | |(VPN,Ingr/Egr if)| | | | | | | | | | | | Tunnel Confirm | | | | | |<----------------| | | | | | (Tunnel ID) | | | | | | | | | | | | Tunnel Bind | | | | | |-------------------------->| | | | | (Tunnel ID, VPN, Ingr if) | Forward. Mapping | | | | |---------------------->| (1) | | Tunnel Bind Confirm | (Dest, VPN, Ingr if | | |<--------------------------| | | | | | | | | | | Tunnel Bind | | | | | |-------------------------------------->| | | | (Tunnel ID, VPN, Egr if) | | | | | | | | Forward. Mapping | | | | |--------------------- >|(2) | | | | (Dest, VPN , Egr if) | | | Tunnel Bind Confirm | | | |<--------------------------------------| | | | | | | | | Figure 7 Communication Flows for Optical Tunnel Establishment and binding. When Domain Packet Controller 1 sends the forwarding mapping information as indicated in (1) in Figure 7, the Ingress PE in Domain 1 will need to provision the VRF forwarding table based on the information it receives. Please see the detailed procedure in section 5.3.1.2. A similar procedure is to be done at the Egress PE in Domain 2. Peruzzini et al. Expires December 17, 2020 [Page 30] Internet-Draft ACTN POI June 2020 6. Security Considerations Several security considerations have been identified and will be discussed in future versions of this document. 7. Operational Considerations Telemetry data, such as the collection of lower-layer networking health and consideration of network and service performance from POI domain controllers, may be required. These requirements and capabilities will be discussed in future versions of this document. 8. IANA Considerations This document requires no IANA actions. 9. References 9.1. Normative References [RFC7950] Bjorklund, M. et al., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016. [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, August 2016. [RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January 2017. [RFC8345] Clemm, A., Medved, J. et al., "A Yang Data Model for Network Topologies", RFC8345, March 2018. [RFC8346] Clemm, A. et al., "A YANG Data Model for Layer 3 Topologies", RFC8346, March 2018. [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC8453, August 2018. [RFC8525] Bierman, A. et al., "YANG Library", RFC 8525, March 2019. [IEEE 802.1AB] IEEE 802.1AB-2016, "IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery", March 2016. [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", draft-ietf-teas-yang-te-topo, work in progress. Peruzzini et al. Expires December 17, 2020 [Page 31] Internet-Draft ACTN POI June 2020 [WSON-TOPO] Lee, Y. et al., " A YANG Data Model for WSON (Wavelength Switched Optical Networks)", draft-ietf-ccamp-wson-yang, work in progress. [Flexi-TOPO] Lopez de Vergara, J. E. et al., "YANG data model for Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid- yang, work in progress. [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer Topology", draft-zheng-ccamp-client-topo-yang, work in progress. [L3-TE-TOPO] Liu, X. et al., "YANG Data Model for Layer 3 TE Topologies", draft-ietf-teas-yang-l3-te-topo, work in progress. [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang- te, work in progress. [WSON-TUNNEL] Lee, Y. et al., "A Yang Data Model for WSON Tunnel", draft-ietf-ccamp-wson-tunnel-model, work in progress. [Flexi-MC] Lopez de Vergara, J. E. et al., "YANG data model for Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid- media-channel-yang, work in progress. [CLIENT-SIGNAL] Zheng, H. et al., "A YANG Data Model for Transport Network Client Signals", draft-ietf-ccamp-client-signal- yang, work in progress. 9.2. Informative References [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4761] K. Kompella, Ed., Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC6074] E. Rosen, B. Davie, V. Radoaca, and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. Peruzzini et al. Expires December 17, 2020 [Page 32] Internet-Draft ACTN POI June 2020 [RFC6624] K. Kompella, B. Kothari, and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, May 2012. [RFC7209] A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. Henderickx, and A. Isaac, "Requirements for Ethernet VPN (EVPN)", RFC 7209, May 2014. [RFC7432] A. Sajassi, Ed., et al., "BGP MPLS-Based Ethernet VPN", RFC 7432, February 2015. [RFC7436] H. Shah, E. Rosen, F. Le Faucheur, and G. Heron, "IP-Only LAN Service (IPLS)", RFC 7436, January 2015. [RFC8214] S. Boutros, A. Sajassi, S. Salam, J. Drake, and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, August 2017. [RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, January 2018. [RFC8309] Q. Wu, W. Liu, and A. Farrel, "Service Model Explained", RFC 8309, January 2018. [RFC8466] G. Fioccola, ed., "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC8466, October 2018. [TNBI] Busi, I., Daniel, K. et al., "Transport Northbound Interface Applicability Statement", draft-ietf-ccamp- transport-nbi-app-statement, work in progress. [ACTN-VN] Y. Lee, et al., "A Yang Data Model for ACTN VN Operation", draft-ietf-teas-actn-vn-yang, 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 Monitoring Telemetry and Scaling Intent Autonomics", draft-lee-teas-actn-pm-telemetry-autonomics, 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. Peruzzini et al. Expires December 17, 2020 [Page 33] Internet-Draft ACTN POI June 2020 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Some of this analysis work was supported in part by the European Commission funded H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). 11. Authors' Addresses Fabio Peruzzini TIM Email: fabio.peruzzini@telecomitalia.it Jean-Francois Bouquier Vodafone Email: jeff.bouquier@vodafone.com Italo Busi Huawei Email: Italo.busi@huawei.com Daniel King Old Dog Consulting Email: daniel@olddog.co.uk Daniele Ceccarelli Ericsson Email: daniele.ceccarelli@ericsson.com Peruzzini et al. Expires December 17, 2020 [Page 34] Internet-Draft ACTN POI June 2020 Sergio Belotti Nokia Email: sergio.belotti@nokia.com Gabriele Galimberti Cisco Email: ggalimbe@cisco.com Zheng Yanlei China Unicom Email: zhengyanlei@chinaunicom.cn Anton Snitser Sedona Email: antons@sedonasys.com Washington Costa Pereira Correia TIM Brasil Email: wcorreia@timbrasil.com.br Michael Scharf Hochschule Esslingen - University of Applied Sciences Email: michael.scharf@hs-esslingen.de Young Lee Sung Kyun Kwan University Email: younglee.tx@gmail.com Peruzzini et al. Expires December 17, 2020 [Page 35] Internet-Draft ACTN POI June 2020 Jeff Tantsura Apstra Email: jefftant.ietf@gmail.com Peruzzini et al. Expires December 17, 2020 [Page 36]