[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Internet Engineering Task Force                                  H. Chen
Internet-Draft                                                     R. Li
Intended status: Experimental                               A. Kumar S N
Expires: January 21, 2018                                         Huawei
                                                               A. Retana
                                                     Cisco Systems, Inc.
                                                                   N. So
                                                     Tata Communications
                                                                  V. Liu
                                                            China Mobile
                                                                  M. Toy
                                                                 Verizon
                                                                  L. Liu
                                                                 Fijitsu
                                                           July 20, 2017


                    IS-IS Topology-Transparent Zone
                       draft-chen-isis-ttz-04.txt

Abstract

   This document presents a topology-transparent zone in a domain.  A
   zone comprises a group of routers and a number of circuits connecting
   them.  Any router outside of the zone is not aware of the zone.  The
   information about the circuits and routers inside the zone is not
   distributed to any router outside of the zone.  Any link state change
   such as a circuit down inside the zone is not seen by any router
   outside of the zone.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 21, 2018.

Copyright Notice



Chen, et al.            Expires January 21, 2018                [Page 1]


Internet-Draft          Topology-Transparent Zone              July 2017


   Copyright (c) 2017 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
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Topology-Transparent Zone  . . . . . . . . . . . . . . . . . .  4
     4.1.  Overview of Topology-Transparent Zone  . . . . . . . . . .  4
     4.2.  An Example of TTZ  . . . . . . . . . . . . . . . . . . . .  5
   5.  Extensions to IS-IS Protocols  . . . . . . . . . . . . . . . .  6
     5.1.  TTZ TLV  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Updating LSPs for TTZ  . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Updating LSP for a TTZ Internal Router . . . . . . . . . .  9
     6.2.  Updating LSP for a TTZ Edge Router . . . . . . . . . . . .  9
   7.  Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 10
     7.1.  Discover TTZ Neighbor over Normal Adjacency  . . . . . . . 10
     7.2.  Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 10
     7.3.  Adjacency between TTZ Edge and Router outside  . . . . . . 10
   8.  Distribution of LSPs . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Distribution of LSPs within TTZ  . . . . . . . . . . . . . 11
     8.2.  Distribution of LSPs through TTZ . . . . . . . . . . . . . 11
   9.  Computation of Routing Table . . . . . . . . . . . . . . . . . 12
   10. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Configuring TTZ  . . . . . . . . . . . . . . . . . . . . . 12
     10.2. Smooth Migration to TTZ  . . . . . . . . . . . . . . . . . 13
     10.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 14
   11. Security  Considerations . . . . . . . . . . . . . . . . . . . 14
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
   14. Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 15
   15. Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16






Chen, et al.            Expires January 21, 2018                [Page 2]


Internet-Draft          Topology-Transparent Zone              July 2017


1.  Introduction

   ISO/IEC 10589 describes IS-IS areas or levels in an Autonomous System
   (AS).  Each level 1 area has a number of level 1 and level 2 routers
   connected to the level 2 area.  Each level 1 and level 2 router may
   summarize the topology of its attached level 1 areas to the level 2
   area or vice versa.

   The number of routers in a network becomes larger and larger as the
   Internet traffic keeps growing.  Through splitting the network into
   multiple areas, we can extend the network further.  However, there
   are a number of issues when a network is split further into more
   areas.

   At first, dividing a network from one area into multiple areas or
   from a number of existing areas to even more areas is a very
   challenging and time consuming task since it is involved in
   significant network architecture changes.

   Secondly, the services carried by the network may be interrupted
   while the network is being split from one area into multiple areas or
   from a number of existing areas into even more areas.

   Furthermore, it is complex for a Multi-Protocol Label Switching
   (MPLS) Traffic Engineering (TE) Label Switching Path (LSP) crossing
   multiple areas to be setup.  In one option, a TE path crossing
   multiple areas is computed by using collaborating Path Computation
   Elements (PCEs) [RFC5441] through the PCE Communication Protocol
   (PCEP)[RFC5440], which is not easy to configure by operators since
   the manual configuration of the sequence of domains is required.
   Although this issue can be addressed by using the Hierarchical PCE,
   this solution may further increase the complexity of network design.
   Especially, the current PCE standard method may not guarantee that
   the path found is optimal.

   This document presents a topology-transparent zone in a domain or an
   area and describes extensions to IS-IS for supporting the topology-
   transparent zone, which is scalable and resolves the issues above.

   A topology-transparent zone comprises a group of routers and a number
   of circuits connecting these routers.  Any router outside of the zone
   is not aware of the zone.  The information about the circuits and
   routers inside the zone is not distributed to any router outside of
   the zone.  Any link state change such as a circuit down inside the
   zone is not seen by any router outside of the zone.






Chen, et al.            Expires January 21, 2018                [Page 3]


Internet-Draft          Topology-Transparent Zone              July 2017


2.  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 RFC 2119.


3.  Requirements

   Topology-Transparent Zone (TTZ) may be deployed for resolving some
   critical issues such as scalability in existing networks and future
   networks.  The requirements for TTZ are listed as follows:

   o  TTZ MUST be backward compatible.  When a TTZ is deployed on a set
      of routers in a network, the routers outside of the TTZ in the
      network do not need to know or support TTZ.

   o  TTZ MUST support at least one more levels of network hierarchies,
      in addition to the hierarchies supported by existing routing
      protocols.

   o  Users SHOULD be able to easily set up an end to end service
      crossing TTZs.

   o  The configuration for a TTZ in a network SHOULD be minimum.

   o  The changes on the existing protocols for supporting TTZ SHOULD be
      minimum.


4.  Topology-Transparent Zone

4.1.  Overview of Topology-Transparent Zone

   A Topology-Transparent Zone (TTZ) is identified by an Identifier
   (ID), and it includes a group of routers and a number of circuits
   connecting the routers.  A TTZ is in an IS-IS domain (area).

   The ID of a TTZ or TTZ ID is a number that is unique for identifying
   an entity such as a node in an IS-IS domain (area).  It is not zero
   in general.

   In addition to having the functions of an IS-IS level or area, an
   IS-IS TTZ makes some improvements on an IS-IS level or area, which
   include:

   o  An IS-IS TTZ is virtualized as the TTZ edge routers connected.




Chen, et al.            Expires January 21, 2018                [Page 4]


Internet-Draft          Topology-Transparent Zone              July 2017


   o  An IS-IS TTZ receives the link state information about the
      topology outside of the TTZ, stores the information in the TTZ and
      floods the information through the TTZ to the routers outside of
      TTZ.

4.2.  An Example of TTZ

   The figure below illustrates an example of a routing domain
   containing a TTZ: TTZ 600.

                 TTZ 600
                   \
                    \ ^~^~^~^~^~^~^~^~^~^~^~^~
                     (                        )
    ===[R15]========(==[R61]------------[R63]==)======[R29]===
        ||         (   |    \          /    |   )       ||
        ||         (   |     \        /     |   )       ||
        ||         (   |      \      /      |   )       ||
        ||         (   |    ___\    /       |   )       ||
        ||         (   |   /   [R71]        |   )       ||
        ||         (   | [R73] /    \       |   )       ||
        ||         (   |      /      \      |   )       ||
        ||         (   |     /        \     |   )       ||
        ||         (   |    /          \    |   )       ||
    ===[R17]========(==[R65]------------[R67]==)======[R31]===
         \\          (//                    \\)       //
          ||         //v~v~v~v~v~v~v~v~v~v~v~\\      ||
          ||        //                        \\     ||
          ||       //                          \\    ||
           \\     //                            \\  //
       ======[R23]==============================[R25]=====
             //                                     \\
            //                                       \\


                        Figure 1: An Example of TTZ

   The routing domain comprises routers R15, R17, R23, R25, R29 and R31.
   It also contains TTZ 600, which comprises routers R61, R63, R65, R67,
   R71 and R73, and the circuits connecting them.

   There are two types of routers in a TTZ: TTZ internal routers and TTZ
   edge routers.  A TTZ internal router is a router inside the TTZ and
   its adjacent routers are inside the TTZ.  A TTZ edge router is a
   router inside the TTZ and has at least one adjacent router that is
   outside of the TTZ.

   The TTZ in the figure above comprises four TTZ edge routers R61, R63,



Chen, et al.            Expires January 21, 2018                [Page 5]


Internet-Draft          Topology-Transparent Zone              July 2017


   R65 and R67.  Each TTZ edge router is connected to at least one
   router outside of the TTZ.  For instance, router R61 is a TTZ edge
   router since it is connected to router R15, which is outside of the
   TTZ.

   In addition, the TTZ comprises two TTZ internal routers R71 and R73.
   A TTZ internal router is not connected to any router outside of the
   TTZ.  For instance, router R71 is a TTZ internal router since it is
   not connected to any router outside of the TTZ.  It is just connected
   to routers R61, R63, R65, R67 and R73 inside the TTZ.

   A TTZ MUST hide the information inside the TTZ from the outside.  It
   MUST NOT directly distribute any internal information about the TTZ
   to a router outside of the TTZ.

   For instance, the TTZ in the figure above MUST NOT send the
   information about TTZ internal router R71 to any router outside of
   the TTZ in the routing domain; it MUST NOT send the information about
   the circuit between TTZ router R61 and R65 to any router outside of
   the TTZ.

   In order to create a TTZ, we MUST configure the same TTZ ID on the
   edge routers and identify the TTZ internal circuits on them.  In
   addition, we SHOULD configure the TTZ ID on every TTZ internal router
   which indicates that every circuit of the router is a TTZ internal
   circuit.

   From a router outside of the TTZ, a TTZ is seen as a group of routers
   fully connected.  For instance, router R15 in the figure above, which
   is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers:
   R61, R63, R65 and R67.  These four TTZ edge routers are fully
   connected.

   In addition, a router outside of the TTZ sees TTZ edge routers having
   normal connections to the routers outside of the TTZ.  For example,
   router R15 sees four TTZ edge routers R61, R63, R65 and R67, which
   have the normal connections to R15, R29, R17 and R23, R25 and R31
   respectively.


5.  Extensions to IS-IS Protocols

5.1.  TTZ TLV

   A new TLV, which is called TTZ TLV, may be added into a link state
   PDU(LSP) or a Hello PDU for a TTZ node.  It has the following format.





Chen, et al.            Expires January 21, 2018                [Page 6]


Internet-Draft          Topology-Transparent Zone              July 2017


                         TTZ TLV          Length in Byte
                 +----------------------+
                 |      Type = TBD      |  1
                 +----------------------+
                 |        Length        |  1
                 +----------------------+
                 |         Flags        |  2
                 +----------------------+
                 |        TTZ  ID       |  4
                 +----------------------+
                 |       Sub-TLVs       |  Length of Sub-TLVs
                 +----------------------+


                             Figure 2: TTZ TLV

   A TTZ TLV has 1 byte of Type, 1 byte of Length of the value field of
   the TLV, which is followed by 2 bytes of Flags and 4 bytes of TTZ ID.
   A TTZ TLV in an LSP may contains a number of sub TLVs and have Flags
   defined as follows.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |E|T|M|N|R|    0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      E = 1: Edge router of TTZ
      T = 1: Distributing TTZ Topology Information for Migration
      M = 1: Migrating to TTZ
      N = 1: Distributing Normal Topology Information for Rollback
      R = 1: Rolling back from TTZ


   When a router in a TTZ receives a CLI command triggering TTZ
   information distribution for migration, it updates its LSP by adding
   a TTZ TLV with T set to 1.  When a router in a TTZ receives a CLI
   command activating migration to TTZ, it sets M to 1 in the TTZ TLV in
   its LSP.

   Two new sub-TLVs are defined, which may be added into a TTZ TLV in an
   LSP.  One is TTZ IS Neighbor sub-TLV, or TTZ ISN sub-TLV for short.
   The other is TTZ ES Neighbor sub-TLV, or TTZ ESN sub-TLV for short.
   A TTZ ISN sub-TLV contains the information about a number of TTZ IS
   neighbors connected to a TTZ edge router.  It has the format below.







Chen, et al.            Expires January 21, 2018                [Page 7]


Internet-Draft          Topology-Transparent Zone              July 2017


                     TTZ ISN sub-TLV      Length in Byte
                 +----------------------+
                 |    Sub-Type = 1      |  1
                 +----------------------+
                 |        Length        |  n*(IDLength + 5)
                 +----------------------+
                 |   Default Metric(i)  |  1
                 +----------------------+
                 |   Delay Metric(i)    |  1
                 +----------------------+
                 |   Expense Metric(i)  |  1
                 +----------------------+
                 |   Error Metric(i)    |  1
                 +----------------------+
                 |    Neighbor ID(i)    |  IDLength + 1
                 +----------------------+


                         Figure 3: TTZ ISN sub TLV

   A TTZ ESN sub-TLV contains the information about a number of TTZ ES
   neighbors connected to a TTZ edge router.  It has the format below.

                     TTZ ESN sub-TLV      Length in Byte
                 +----------------------+
                 |    Sub-Type = 2      |  1
                 +----------------------+
                 |        Length        |  4 + n*IDLength
                 +----------------------+
                 |    Default Metric    |  1
                 +----------------------+
                 |    Delay Metric      |  1
                 +----------------------+
                 |    Expense Metric    |  1
                 +----------------------+
                 |    Error Metric      |  1
                 +----------------------+
                 |    Neighbor ID       |  IDLength
                 +----------------------+
                 |    . . . . . .       |
                 +----------------------+
                 |    Neighbor ID       |  IDLength
                 +----------------------+


                         Figure 4: TTZ ESN sub TLV





Chen, et al.            Expires January 21, 2018                [Page 8]


Internet-Draft          Topology-Transparent Zone              July 2017


6.  Updating LSPs for TTZ

6.1.  Updating LSP for a TTZ Internal Router

   A TTZ internal router adds a TTZ TLV into its LSP after it receives
   an LSP containing a TTZ TLV with T = 1 or a CLI command triggering
   TTZ information distribution for migration.  The TLV has a TTZ ID set
   to the ID of the TTZ and E bit in Flags set to 0 indicating TTZ
   internal router.  The router floods its LSP to its neighbors in the
   TTZ.

   When a router inside the TTZ receives a link state packet (LSP)
   containing a TTZ TLV from a neighboring router in the TTZ, it stores
   the link state and floods the link state to the other neighboring
   routers in the TTZ.

6.2.  Updating LSP for a TTZ Edge Router

   For every edge router of a TTZ, it updates its LSP in three steps and
   floods the LSP to all its neighbors.

   At first, a TTZ edge router adds a TTZ TLV into its LSP after it
   receives an LSP containing a TTZ TLV with T = 1 or a CLI command
   triggering TTZ information distribution for migration.  The TLV has a
   TTZ ID set to the ID of the TTZ, E bit in Flags set to 1 indicating
   TTZ edge router and a TTZ ISN sub TLV.  The sub TLV contains the
   information about the TTZ IS neighbors connected to the TTZ edge
   router.  In addition, the TLV may has a TTZ ESN sub TLV comprising
   the information about the TTZ end systems connected to the TTZ edge
   router.

   Secondly, it adds each of the other TTZ edge routers as an IS
   neighbor into the Intermediate System Neighbors TLV in the LSP after
   it receives an LSP containing a TTZ TLV with M = 1 or a CLI command
   activating migration to TTZ.  The metric to the neighbor is the
   metric of the shortest path to the edge router within the TTZ.

   In addition, it adds a Prefix Neighbors TLV into its LSP.  The TLV
   contains a number of address prefixes in the TTZ to be reachable from
   outside of the TTZ.

   And then it removes the IS neighbors corresponding to the IS
   neighbors in the TTZ TLV (i.e., in the TTZ ISN sub TLV) from
   Intermediate System Neighbors TLV in the LSP, and the ES neighbors
   corresponding to the ES neighbors in the TTZ TLV (i.e., in the TTZ
   ESN sub TLV) from End System Neighbors TLV in the LSP.  This SHOULD
   be done after it receives the LSPs for virtualizing TTZ from the
   other TTZ edges for a given time.



Chen, et al.            Expires January 21, 2018                [Page 9]


Internet-Draft          Topology-Transparent Zone              July 2017


7.  Establishing Adjacencies

7.1.  Discover TTZ Neighbor over Normal Adjacency

   For two routers A and B connected by a P2P circuit and having a
   normal adjacency, they discover TTZ each other through including a
   TTZ TLV containing a TTZ ID in their hello packets.  If two ends of
   the circuit have the same TTZ ID, A and B are TTZ neighbors;
   otherwise, they are not TTZ neighbors, but normal neighbors.

   For a number of routers connected through a broadcast circuit and
   having normal adjacencies among them, they also discover TTZ each
   other through including a TTZ TLV containing a TTZ ID in their hello
   packets.  The DIS for the circuit "forms" TTZ adjacency with each of
   the other routers if all the routers attached to the circuit have the
   same TTZ ID configured on the connections to the circuit and included
   in their hello packets; otherwise, they are not TTZ neighbors, but
   still normal neighbors.

7.2.  Establishing TTZ Adjacencies

   When a router (say A) is connected via a P2P circuit to another
   router (say B) and there is not any adjacency between them over the
   circuit, a user configures TTZ on two ends of the circuit to form a
   TTZ adjacency.

   Routers A and B include a TTZ TLV containing a TTZ ID in their hello
   packets.  If two routers have the same TTZ IDs in their hellos, an
   adjacency between these two routers is to be formed; otherwise, no
   adjacency is formed.

   For a number of routers connected through a broadcast circuit and
   having no adjacency among them, they start to form TTZ adjacencies
   after TTZ is configured on the circuit and a TTZ TLV with a TTZ ID is
   included in their hello packets.  The DIS for the circuit forms TTZ
   adjacency with each of the other routers if all the routers attached
   to the circuit have the same TTZ ID configured on the connections to
   the circuit and included in the hello packets; otherwise, the DIS
   does not form any adjacency with any router attached to the circuit.

7.3.  Adjacency between TTZ Edge and Router outside

   For an edge router in a TTZ, in addition to establishing adjacencies
   with other routers in the TTZ that have connections with the edge
   router, it forms an adjacency with any router outside of the TTZ that
   has a connection with the edge router.

   When the edge router synchronizes its link state database with the



Chen, et al.            Expires January 21, 2018               [Page 10]


Internet-Draft          Topology-Transparent Zone              July 2017


   router outside of the TTZ, it sends the router outside of the TTZ the
   information about all the LSPs except for the LSPs belong to the TTZ
   that are hidden from any router outside of the TTZ.

   At the end of the link state database synchronization, the edge
   router originates its own LSP and sends this LSP to the router
   outside of the TTZ.  This LSP contains two groups of circuits.

   The first group of circuits are the circuits connecting to the
   routers outside of the TTZ from this TTZ edge router.  The second
   group of circuits are the "virtual" circuits connecting to the other
   TTZ edge routers from this TTZ edge router.

   From the point of view of the router outside of the TTZ, it sees the
   other end as a normal router and forms the adjacency in the same way
   as a normal router.  It is not aware of anything about its
   neighboring TTZ.  From the LSPs related to the TTZ edge router in the
   other end, it knows that the TTZ edge router is connected to each of
   the other TTZ edge routers and some routers outside of the TTZ.


8.  Distribution of LSPs

   LSPs can be divided into two classes according to their
   distributions.  One class of LSPs is distributed within a TTZ.  The
   other is distributed through a TTZ.

8.1.  Distribution of LSPs within TTZ

   Any LSP generated for a TTZ internal router in a TTZ is distributed
   within the TTZ.  It will not be distributed to any router outside of
   the TTZ.

   Any pseudo node LSP generated for a broadcast network inside a TTZ,
   is distributed within the TTZ.  It will not be distributed to any
   router outside of the TTZ.

8.2.  Distribution of LSPs through TTZ

   Any LSP about a link state outside of a TTZ received by an edge
   router of the TTZ is distributed through the TTZ; and any LSP about a
   link state for the TTZ generated by a TTZ edge router is distributed
   through the TTZ.

   For example, when an edge router of a TTZ receives an LSP for a link
   state outside of the TTZ from a router outside of the TTZ, it floods
   it to its neighboring routers both inside the TTZ and outside of the
   TTZ.  This LSP may be any LSP such as a router LSP that is



Chen, et al.            Expires January 21, 2018               [Page 11]


Internet-Draft          Topology-Transparent Zone              July 2017


   distributed in a domain.

   The routers in the TTZ continue to flood the LSP.  When another edge
   router of the TTZ receives the LSP, it floods the LSP to its
   neighboring routers both outside of the TTZ and inside the TTZ.


9.  Computation of Routing Table

   The computation of the routing table on a router outside of a TTZ is
   the same as that described in ISO/SEC 10589.  On a router in a TTZ,
   the computation of the routing table has the same procedure flow as
   that described in ISO/SEC 10589, with one exception.  A router in a
   TTZ MUST ignore the circuits in the router LSPs generated by the edge
   routers of the TTZ for virtualizing the TTZ.

   The routing table on a router inside the TTZ is computed through
   using the link state database (LSDB) containing the LSPs for the
   topology of the TTZ and the LSPs for the topology outside of the TTZ.
   That is that the shortest path to every destination both inside the
   TTZ and outside of the TTZ is computed over all the circuits
   including the circuits inside the TTZ and the circuits outside of the
   TTZ.


10.  Operations

10.1.  Configuring TTZ

   This section proposes some options for configuring a TTZ.

   1.  Configuring TTZ on Every Circuit in TTZ

   If every circuit in a TTZ is configured with a same TTZ ID as a TTZ
   circuit, the TTZ is determined.  A router with some TTZ circuits and
   some normal circuits is a TTZ edge router.  A router with only TTZ
   circuits is a TTZ internal router.

   2.  Configuring TTZ on Every Router in TTZ

   We may configure a same TTZ ID on every router in the TTZ, and on
   every edge router's circuits connecting to the routers in the TTZ.

   A router configured with the TTZ ID on some of its circuits is a TTZ
   edge router.  A router configured with the TTZ ID only is a TTZ
   internal router.  All the circuits on a TTZ internal router are TTZ
   circuits.  This option is simpler than the above one.




Chen, et al.            Expires January 21, 2018               [Page 12]


Internet-Draft          Topology-Transparent Zone              July 2017


10.2.  Smooth Migration to TTZ

   For a group of routers and a number of circuits connecting the
   routers in an area, making them transfer to work as a TTZ without any
   service interruption may take a few of steps.

   At first, users configure the TTZ feature on every router in the TTZ.
   In this stage, a router does not update its LSPs.  It will discover
   its TTZ neighbors.

   Secondly, after configuring the TTZ, users issue a CLI command on one
   router in the TTZ, which triggers every router in the TTZ to
   distribute TTZ information among the routers in the TTZ.  When the
   router receives the command, it updates its LSP by adding a TTZ TLV,
   and distributes the LSP to its TTZ neighbors.  The LSP has T = 1 in
   Flags in the TTZ TLV (indicating TTZ information generation and
   distribution for migration).  When a router in the TTZ receives the
   LSP with T = 1, it updates its LSP by adding a TTZ TLV.  In this
   stage, every router in the TTZ has dual roles.  One is to function as
   a normal router.  The other is to generate and distribute TTZ
   information.

   Thirdly, users may check whether every router in the TTZ is ready for
   transferring to work as a TTZ router.  A router in the TTZ is ready
   after it has received all the necessary information from all the
   routers in the TTZ.  This information may be displayed on a router
   through a CLI command.

   And then users activate the TTZ through using a CLI command such as
   migrate to TTZ on one router in the TTZ.  The router transfers to
   work as a TTZ router, updates its LSP with M = 1 in the TTZ TLV
   (indicating Migrating to TTZ) after it receives the command.

   After a router in the TTZ receives the LSP with M = 1, it also
   transfers to work as a TTZ router.  Thus, activating the TTZ on one
   TTZ router makes every router in the TTZ transfer to work as a TTZ
   router, which computes routes through using the TTZ topology and the
   topology outside of the TTZ.

   For an edge router of the TTZ, transferring to work as a TTZ router
   comprises updating its LSP to virtualize the TTZ by adding each of
   the other TTZ edge routers as an IS neighbor and flooding this LSP to
   all its direct neighboring routers.  And then, the TTZ edge router
   removes the IS neighbors corresponding to the IS neighbors in the TTZ
   TLV (i.e., in the TTZ ISN sub TLV) from Intermediate System Neighbors
   TLV in the LSP





Chen, et al.            Expires January 21, 2018               [Page 13]


Internet-Draft          Topology-Transparent Zone              July 2017


10.3.  Adding a Router into TTZ

   When a non TTZ router (say R1) is connected via a P2P circuit to a
   TTZ router (say T1) working as TTZ and there is a normal adjacency
   between them over the circuit, a user can configure TTZ on two ends
   of the circuit to add R1 into the TTZ to which T1 belongs.  They
   discover TTZ each other in the same way as described in section 7.1.

   When a number of non TTZ routers are connected via a broadcast
   circuit to a TTZ router (say T1) working as TTZ and there are normal
   adjacencies among them, a user configures TTZ on the connection to
   the circuit on every router to add the non TTZ routers into the TTZ
   to which T1 belongs.  The DIS for the circuit "forms" TTZ adjacency
   with each of the other routers if all the routers have the same TTZ
   ID configured on the connections to the circuit.

   When a router (say R1) is connected via a P2P circuit to a TTZ router
   (say T1) and there is not any adjacency between them over the
   circuit, a user can configure TTZ on two ends of the circuit to add
   R1 into the TTZ to which T1 belongs.  R1 and T1 will form an
   adjacency in the same way as described in section 7.2.

   When a router (say R1) is connected via a broadcast circuit to a
   group of TTZ routers on the circuit and there is not any adjacency
   between R1 and any over the circuit, a user can configure TTZ on the
   connection to the circuit on R1 to add R1 into the TTZ to which the
   TTZ routers belong.  R1 starts to form an adjacency with the DIS for
   the circuit after the configuration.


11.  Security  Considerations

   The mechanism described in this document does not raise any new
   security issues for the IS-IS protocols.


12.  IANA Considerations

   This document requires the allocation for a new TLV and a couple of
   new sub TLVs in the new TLV.  IANA is requested to assign a new Type
   (value 150 is suggested) for new TLV TTZ as follows:

     +========+========+=======+=======+=======+=======+
     |  Type  |  Name  |  IIH  |  LSP  |  SNP  | Purge |
     +========+========+=======+=======+=======+=======+
     |  150   |  TTZ   |   Y   |   Y   |   N   |   N   |
     +========+========+=======+=======+=======+=======+




Chen, et al.            Expires January 21, 2018               [Page 14]


Internet-Draft          Topology-Transparent Zone              July 2017


   This document defines two new Sub-TLVs in TLV 150.  The values below
   are suggested for them subject to assignment by IANA or Expert
   review.

     +========+==================================+
     |  Type  |      Name and Description        |
     +========+==================================+
     |   1    | TTZ ISN, TTZ IS Neighbors        |
     +--------+----------------------------------+
     |   2    | TTZ ESN, TTZ ES Neighbors        |
     +========+==================================+



13.  Contributors


        Veerendranatha Reddy Vallem
        Huawei Technologies
        Bangalore
        India
        Email: veerendranatharv@huawei.com

        William McCall
        cisco Systems, Inc.
        Bellevue, WA
        USA
        wimccall@cisco.com



14.  Acknowledgement

   The author would like to thank Acee Lindem, Abhay Roy, Dean Cheng,
   Wenhu Lu, Russ White, Tony Przygienda, Bingzhang Zhao, and Lin Han
   for their valuable comments.


15.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7142]  Shand, M. and L. Ginsberg, "Reclassification of RFC 1142
              to Historic", RFC 7142, DOI 10.17487/RFC7142,
              February 2014, <http://www.rfc-editor.org/info/rfc7142>.



Chen, et al.            Expires January 21, 2018               [Page 15]


Internet-Draft          Topology-Transparent Zone              July 2017


   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <http://www.rfc-editor.org/info/rfc1195>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305,
              October 2008, <http://www.rfc-editor.org/info/rfc5305>.

   [RFC5029]  Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link
              Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029,
              September 2007, <http://www.rfc-editor.org/info/rfc5029>.


Authors' Addresses

   Huaimo Chen
   Huawei
   Boston, MA
   USA

   Email: huaimo.chen@huawei.com


   Renwei Li
   Huawei
   2330 Central expressway
   Santa Clara, CA
   USA

   Email: renwei.li@huawei.com


   Anil Kumar S N
   Huawei
   Bangalore
   India

   Email: anil.sn@huawei.com


   Alvaro Retana
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Raleigh, NC  27709
   USA

   Email: aretana@cisco.com




Chen, et al.            Expires January 21, 2018               [Page 16]


Internet-Draft          Topology-Transparent Zone              July 2017


   Ning So
   Tata Communications
   2613 Fairbourne Cir.
   Plano, TX  75082
   USA

   Email: ningso01@gmail.com


   Vic Liu
   China Mobile
   No.32 Xuanwumen West Street, Xicheng District
   Beijing,   100053
   China

   Email: liu.cmri@gmail.com


   Mehmet Toy
   Verizon
   USA

   Email: mehmet.toy@verizon.com


   Lei Liu
   Fijitsu
   USA

   Email: lliu@us.fujitsu.com





















Chen, et al.            Expires January 21, 2018               [Page 17]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/