TEAS Working Group                                        Haomian Zheng
Internet Draft                                                Young Lee
Intended status: Informational                                   Huawei
                                                     Daniele Ceccarelli
                                                               Ericsson
                                                         Jong Yoon Shin
                                                             SK Telecom
                                                              Yunbin Xu
                                                                  CAICT
                                                               Yunbo Li
                                                           China Mobile
                                                                Yan Shi
                                                           China Unicom
                                                             Boyuan Yan
                                                                   BUPT

Expires: April 30 2017                                October 31, 2016


 Inter-op Test Cases in Multi-vendor Scenario based on ACTN Architecture


               draft-zheng-teas-actn-multivendor-interop-00


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."

   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 30, 2017.





Zheng et al              Expires April 2017                   [Page 1]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


Copyright Notice


   Copyright (c) 2016 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.


Abstract

   ACTN is a practical approach to repurpose existing and well-defined
   technologies, and underpinning them with SDN principle. It provides
   a hierarchal architecture to scale and support multi-vendor multi-
   domain interworking using RESTconf(YANG Model)/PCEP/BGP-LS.

   This document contains a test case proposal focused multi-domain,
   multi-vendor interoperation test cases for the ACTN framework. These
   test cases cover four test scenarios, including topology
   abstraction, E2E service provisioning, DC load balancing and inter-
   domain restoration, to demonstrate the fundamental ideas of the ACTN
   framework and standards.



Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



Table of Contents

   1. Introduction ................................................ 3


Zheng et al              Expires April 2017                   [Page 2]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


   2. Terminology ................................................. 3
   3. Related work: Architecture, Modeling and Protocols........... 4
   4. Test-cases .................................................. 4
      4.1. Topology Abstraction ................................... 4
      4.2. E2E Service Provisioning ............................... 6
      4.3. DC Load Balancing ...................................... 8
      4.4. Inter-domain Recovery .................................. 8
   5. Implementation Details....................................... 8
   6. Future work ................................................. 9
   7. Security Considerations...................................... 9
   8. References .................................................. 9
      8.1. Informative References.................................. 9
   9. Contributors' Addresses..................................... 10
   10. Acknowledgment ............................................ 12



1. Introduction

   The ACTN interoperation test cases are designed to demonstrate the
   on-going work in IETF of the ACTN framework, including:

   - ACTN basic solutions for SDN architecture to support multi-domain,
      multi-vendor supporting.

   - ACTN important interfaces are focused on IETF standards for multi-
      protocol supporting.

   This document is focused on the demonstration of interoperation test
   case procedures to show how ACTN architecture can be implemented.
   The ACTN hierarchical controllers include Customer Network
   Controller (CNC), the Multi-domain Service Coordinator (MDSC), and
   Physical Network Controller (PNC). In this interoperation test, we
   focus on the MDSC, PNC, and the MDSC-PNC Interface (MPI) between
   them. The ACTN MPI can support both RESTCONF/YANG and PCEP-LS and
   gives a deployment choice that meets the need of the operators.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].






Zheng et al              Expires April 2017                   [Page 3]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


3. Related work: Architecture, Modeling and Protocols

   ACTN provides description about future requirements in SDN
   literature in [ACTN-Requirements]. ACTN framework has been proposed
   in [ACTN-Frame] to support all the requirements. The information
   model has been defined in [ACTN-Info].

   From the solution perspective, ACTN work has been associated with
   some other IETF works in various working group including netmod,
   i2rs, rtgwg, ccamp, pce and so on. Yang models, defined in Netconf
   [RFC6241]/Restconf [Restconf], have been considered as an approach
   for network configuration. [ACTN-YANG] has described the
   applicability of YANG models in the ACTN framework, where various
   yang models including TE topology model from [TE-Topology], tunnel
   model from [TE-Tunnel] and service model from [Transport-Service-
   Model] and [ACTN-VN-YANG] have been applied on the ACTN interfaces
   to complete different functions. PCE protocol in the pce working
   group has also been considered to be extended and applied for the
   ACTN interfaces. The applicability draft can be found in [ACTN-PCE].
   PCEP extensions with Link State features can be found in [PCEP-LS]
   for topology discovery, and PCE Initation mechanism defined in [PCE-
   Init] can be used to set up the connections.

4. Test-cases

   This section provides a number of test cases. Currently the test is
   basically conducted between the MDSC and PNC, i.e., on the MPI
   interface in the ACTN architecture. The scenario we are going to
   test includes the topology abstraction, E2E service provisioning, DC
   load balancing and Inter-domain recovery.

   Some fundamental environment has been set up and applied to all the
   test cases. On the network element level, emulators from various
   vendors have been connected with their corresponding PNC. The
   interface between PNC and network elements is known as the
   southbound interface (SBI) in SDN literature. The protocol on SBI
   can be vendor-specific.

   The MDSC can be either from network operators or vendors, to
   coordinate among multiple PNCs. The interaction between the MDSC and
   the PNCs, which is known as MPI in ACTN and considered as a part of
   northbound interface in SDN literature, should be standard.

4.1. Topology Abstraction

   This scenario is used to verify the multi-domain topology collection
   on the MDSC level. Multi-technology network (IP, MPLS, Transport)


Zheng et al              Expires April 2017                   [Page 4]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


   should report their topology and the MDSC should be capable of
   integrating different topologies together.

   MDSC, PNC and network elements are involved in this scenario. The
   PNC needs to collect the information from the network elements and
   maintain its own TE Database. Given the physical topology, the PNC
   may simplify the topology and report an 'abstract' version to the
   MDSC. The interaction on MPI to exchange the topology information
   may be via RESTconf with topology YANG model. The example of
   topology abstraction is shown in Fig. 1, PNC collect the information
   of 6 network elements in every single domain, and abstract the
   topology into a 4-point format. Then the abstracted topology can be
   reported to MDSC. In this example, MDSC will receive the information
   from two PNC domains, and manipulate on an 8-point abstracted
   topology.



                                        +---+   +---+    +---+   +---+
                                        |NE1+---+NE2+----+NE3+---+NE4+
                                        +-+-+   +-+-+    +-+-+   +-+-+
                                          |       |        |       |
                                        +-+-+   +-+-+    +-+-+   +-+-+
                                        |NE5+---+NE6+----+NE7+---+NE8+
                                        +---+   +---+    +---+   +---+
                                +-------+
                                |  MDSC |
                                +--/\---+
      Abstract Domain1           //  \\                Abstract Domain2
       +---+   +---+           //      \\                +---+   +---+
       |NE1+---+NE2+         //          \\              |NE1+---+NE2+
       +-+-+   +-+-+  +--+--*              \+-------+    +-+-+   +-+-+
         |       |    | PNC |               |  PNC  |      |       |
       +-+-+   +-+-+  +--+--+               +---+---+    +-+-+   +-+-+
       |NE3+---+NE4+     |                      |        |NE3+---+NE4+
       +---+   +---+     |                      |        +---+   +---+



Zheng et al              Expires April 2017                   [Page 5]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


          +--------------+---------+   +--------+--------------+
          | +---+   +---+   +---+  |   | +---+   +---+   +---+ |
          | |NE1+---+NE2+---+NE3|  |   | |NE1+---+NE2+---+NE3| |
          | +-+-+   +-+-+   +-+-+  |   | +-+-+   +-+-+   +-+-+ |
          |   |       |       |    |   |   |       |       |   |
          | +-+-+   +-+-+   +-+-+  |   | +-+-+   +-+-+   +-+-+ |
          | |NE4+---+NE5+---+NE6|  |   | |NE4+---+NE5+---+NE6| |
          | +---+   +---+   +---+  |   | +---+   +---+   +---+ |
          |        Domain 1        |   |        Domain 2       |
          +------------------------+   +-----------------------+
                   Fig. 1 Topology Abstraction Scenario

   Dynamical changes in topology should also be considered. For example
   when there is a new node discovered in the network, the incremental
   topology should be correctly detected on PNC, and the abstraction
   may need to be adjusted accordingly and reported to MDSC for update.

4.2. E2E Service Provisioning

   This test case is used to verify the Restconf/YANG functionality on
   service provisioning via interaction between MDSC and PNC. Inter-
   domain connection, shown in Fig. 2, is expected to be established.
   In Fig. 2 the topology on the MDSC is shown, and the network element
   information is hidden.




       +---+   +---+    +---+   +---+    +---+   +---+
       | A1+---+ A2+----+ B1+---+ B2+----+ C1+---+ C2+
       +-+-+   +-+-+    +-+-+   +-+-+    +-+-+   +-+-+
         |       |        |       |        |       |
       +-+-+   +-+-+    +-+-+   +-+-+    +-+-+   +-+-+
       | A3+---+ A4+----+ B3+---+ B4+----+ C3+---+ C4+
       +---+   +---+    +---+   +---+    +---+   +---+

                           +------+


Zheng et al              Expires April 2017                   [Page 6]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


                           | MDSC |
                          -+--+---+--
                      ----    |      ----
                  ----        |          ----
          +------+         +--+---+        +------+
          | PNC A|         |PNC B |        | PNC C|
          +------+         +------+        +------+
                 Fig. 2: E2E Service Provisioning Scenario

   We assume there is request of 100GE service from A1 to C2, following
   steps need to be completed to set up the connection.

   Step 1: MDSC compute an inter-domain path and translate the multi-
   domain request into multiple single domain requests of domain A, B
   and C.
   Step 2: MDSC sends decomposed requests to each PNC, and each PNC
   compute intra-domain path:
      a) Send request to PNC of domain A to set up a service from A1 to
        A2.
      b) Send request to PNC of domain B to set up a service from B1 to
        B2.
      c) Send request to PNC of domain C to set up a service from C1 to
        C2.
      d) These requests may be sent in parallel.
   Step 3: Each PNC responds successfully creation, or failure with
   error message.
   Step 4: MDSC receives responds from all the PNCs, and successfully
   set up a multi-domain service.
   The communication between MDSC and PNC could be completed by
   Restconf protocol associated with tunnel YANG model or service YANG
   model. The communication between PNC and network elements can be
   vendor-specific in this scenario.



Zheng et al              Expires April 2017                   [Page 7]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


4.3. DC Load Balancing

   DC Load balancing is more advanced scenario based on active LSP set
   up in the network. In this scenario, the result of previous 2
   scenarios needs to be reused. We assumed there are two disjoint
   LSPs, one from A1 to C2, and another from A1 to C4. Explicit route
   can be found as following:

   LSP1: A1-A2-B1-B2-C1-C2;

   LSP2: A1-A3-A4-B3-B4-C3-C4;

   The bandwidth of LSP1 and LSP2 are set to 300G and 100G respectively
   before load balancing, with a target on adjusting both of them to
   200G for load balancing. MDSC need to send update message to PNCs to
   adjust their bandwidth on corresponding links.

   The interaction on MPI in this case can be completed by Restconf
   protocol with topology and service YANG model. The interactions
   between PNC and network elements are vendor-specific.



4.4. Inter-domain Recovery

   Another test case about inter-domain recovery is also designed to
   verify the function of cross-domain restoration. In this case a
   cross-domain LSP is set up, such as reusing the LSP1 in section 4.3.
   Then a failure in one domain is emulated in one domain, and the PNC
   of this domain cannot find sufficient resources within the domain so
   that it MUST turn to the MDSC for inter-domain restoration. MDSC
   then need to update the topology and resource usage in every domain
   to compute a path for re-routing. After MDSC got an answer, it will
   deliver another E2E service, which is a repeating of section 4.2.

   The interaction on MPI in this case can be completed by Restconf
   protocol with topology and service YANG model. The interactions
   between PNC and network elements are vendor-specific.





5. Implementation Details

   The implementation and inter-op test is on-going. Once the result is
   available, this section will be updated.


Zheng et al              Expires April 2017                   [Page 8]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


   The progress of future test work will be updated and available at
   the ACTN wiki page: https://sites.google.com/site/openactn/.

6. Future work

   Inter-op test can be done either with emulation environment or
   physical devices in the lab. Some of the test related work in this
   draft will be done on emulations via remote labs of various vendors,
   or during IETF Hackathon activity. This will be a continuing
   activity with follow-up work in coming IETF meetings. More
   participants will be welcomed to join this effort to further promote
   IETF work to expedite SDN deployment.



7. Security Considerations

      This document is an informational draft. When the models
   mentioned in this draft are implemented, detailed security
   consideration will be given in such work.



8. References

8.1. Informative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.



   [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
             and A. Bierman, Ed., "Network Configuration
             Protocol(NETCONF)", RFC 6241.

   [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
             Protocol", draft-ietf-netconf-restconf, work in progress.

   [ACTN-Requirements] Y. Lee, et al., "ACTN Requirements for
             Abstraction and Control of TE Networks", draft-ietf-teas-
             actn-requirements, work in progress.

   [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
             Control of Traffic Engineered Networks", draft-ietf-teas-
             actn-framework, work in progress.



Zheng et al              Expires April 2017                   [Page 9]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


   [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies",
             draft-ietf-teas-yang-te-topo, work in progress.

   [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
             Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
             te, work in progress.

   [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN
             Operation", draft-lee-teas-actn-vn-yang, work in progress.

   [ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction
             and Control of TE Networks (ACTN)", draft-leebelotti-teas-
             actn-info, work in progress.

   [Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model
             for Connection-oriented Transport Networks", draft-zhang-
             teas-transport-service-model, work in progress.

   [ACTN-YANG] Y. Lee, X. Zhang, D. Ceccarelli, B. Yoon, O.Gonzalez de
             Dios, J. Shin,  Applicability of YANG models for
             Abstraction and Control of Traffic Engineered Networks,
             work in progress.

   [ACTN-PCE] D.Dhody, Y. Lee, D. Ceccarelli, Applicability of Path
             Computation Element (PCE) for Abstraction and Control of
             TE Networks (ACTN), work in progress.

   [PCE-LS] D.Dhody, Y. Lee, D. Ceccarelli, PCEP Extension for
             Distribution of Link-State and TE Information, work in
             progress.

   [PCE-Init] E. Crabbe, I. Minei, S. Sivabalan, R. Varga, PCEP
             Extensions for PCE-initiated LSP Setup in a Stateful PCE
             Model, work in progress.



9. Contributors' Addresses



    Kun Xiang
    Huawei Technologies
    Email: xiangkun@huawei.com




Zheng et al              Expires April 2017                  [Page 10]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


    Xian Zhang
    Huawei Technologies
    Email zhang.xian@huawei.com

    Xin Liu
    Huawei Technologies
    Email liuxin12@huawei.com

    Lei Wang
    China Communications Corporation
    Email wangleiyj@chinamobile.com


    Weiqiang Cheng
    China Communications Corporation
    Email chengweiqiang@chinamobile.com

    Liang Geng
    China Communications Corporation
    Email gengliang@chinamobile.com


    Dong Wang
    China Communications Corporation
    Email wangdongyjy@chinamobile.com


    Dhruv Dhody
    Huawei Technologies
    Email: dhruv.ietf@gmail.com

    Satish Karunanithi
    Huawei Technologies
    Email: satishk@huawei.com


    Wei Wang
    Beijing University of Post and Telecommunications
    Email: weiw@bupt.edu.cn



Zheng et al              Expires April 2017                  [Page 11]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


    Yongli Zhao
    Beijing University of Post and Telecommunications
    Email: yonglizhao@bupt.edu.cn

    Jie Zhang
    Beijing University of Post and Telecommunications
    Email: lgr24@bupt.edu.cn






10. Acknowledgment

   TBD



   Authors' Address

   Haomian Zheng
   Huawei Technologies
   Email: Zhenghaomian@huawei.com


   Young Lee
   Huawei Technologies
   5340 Legacy Dr.
   Plano, TX 75023, USA
   Phone: (469)277-5838
   Email: leeyoung@huawei.com

    Daniele Ceccarelli
    Ericsson
    Torshamnsgatan,48
    Stockholm, Sweden
    Email: daniele.ceccarelli@ericsson.com


    Jong Yoon Shin
    SK Telecom



Zheng et al              Expires April 2017                  [Page 12]


draft-zheng-teas-actn-multivendor-interop-00              October 2016


    Email: jongyoon.shin@sk.com


    Yunbin Xu
    China Academy of Information and Communication Technology
    Email: xuyunbin@mail.ritt.com.cn

    Yunbo Li
    China Communications Corporation
    Email liyunbo@chinamobile.com

    Yan Shi
    China Unicom
    Email shiyan49@chinaunicom.cn

    Boyuan Yan
    Beijing University of Post and Telecommunications
    Email: yanboyuan@bupt.edu.cn



























Zheng et al              Expires April 2017                  [Page 13]