Internet Engineering Task Force                                  H. Chen
Internet-Draft                                                     R. Li
Intended status: Experimental                                  Futurewei
Expires: March 18, April 6, 2021                                           Y. Yang
                                                                     IBM
                                                            A. Kumar S N
                                                                 RtBrick
                                                                  Y. Fan
                                                            Casa Systems
                                                                   N. So

                                                                  V. Liu

                                                                  M. Toy
                                                                 Verizon
                                                                  L. Liu
                                                                 Fujitsu
                                                            K. Makhijani
                                                               Futurewei
                                                      September 14,
                                                         October 3, 2020

                    IS-IS Topology-Transparent Zone
                     draft-ietf-lsr-isis-ttz-00.txt
                     draft-ietf-lsr-isis-ttz-01.txt

Abstract

   This document presents specifies a topology-transparent zone in an area.  A
   zone is a block/piece subset (block/piece) of an area, which comprises a group of
   routers and a number of circuits connecting them.  It is abstracted
   as a virtual entity such as a single virtual node or zone edges mesh.
   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 18, April 6, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Zone Abstraction  . . . . . . . . . . . . . . . . . . . . . .   4   5
   4.  Topology-Transparent Zone . . . . . . . . . . . . . . . . . .   5
     4.1.  Zone as a Single Node . . . . . . . . . . . . . . . . . .   5
       4.1.1.  An Example of Zone as a Single Node . . . . . . . . .   5
       4.1.2.  Zone Leader Election  . . . . . . . . . . . . . . . .   7
       4.1.3.  LS Generation for Zone as a Single Node . . . . . . .   8
       4.1.4.  Adjacency Establishment and Termination . . . . . . . . . . . . . . .   8
       4.1.5.  Computation of Routes . . . . . . . . . . . . . . . .  10
       4.1.6.   9
     4.2.  Extensions to Protocols . . . . . . . . . . . . . . .  11
     4.2. . .   9
       4.2.1.  Zone as Edges Full Mesh ID TLV . . . . . . . . . . . . . . . . . .  14
       4.2.1.  Extensions to IS-IS . . .   9
     4.3.  Zone as Edges Full Mesh . . . . . . . . . . . . . . .  14
     4.3. . .  11
       4.3.1.  Updating LSPs for Zone as Edges' Mesh . . . . . . . .  12
     4.4.  Advertisement of LSs LSPs . . . . . . . . . . . . . . . . . .  15
       4.3.1.  12
       4.4.1.  Advertisement of LSs LSPs within Zone . . . . . . . . . .  15
       4.3.2.  12
       4.4.2.  Advertisement of LSs LSPs through Zone  . . . . . . . . . .  16  13
   5.  Seamless Migration  . . . . . . . . . . . . . . . . . . . . .  16  13
     5.1.  Transfer Zone to a Single Node  . . . . . . . . . . . . .  16  13
     5.2.  Roll Back from Zone as a Single Node  . . . . . . . . . .  16  14
   6.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .  19  15
     6.1.  Configuring Zone  . . . . . . . . . . . . . . . . . . . .  15
     6.2.  Transferring Zone to Node . . . . . . . . . . . . . . . .  16
     6.3.  Rolling back Node to Zone . . . . . . . . . . . . . . . .  16

   7.  Security  Considerations  . . . . . . . . . . . . . . . . . .  19  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19  17
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  20  17
   10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  20  18
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20  18
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  20  18
     11.2.  Informative References . . . . . . . . . . . . . . . . .  21  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21  19

1.  Introduction

   [ISO10589] describes two levels of areas, which are areas in IS-IS, level 1 and level
   2 areas in IS-IS. areas.  There are scalability issues in using areas as the number
   of routers in a network becomes larger and larger.

   Through splitting the network into multiple areas, level 1 areas connected
   by level 2, we may extend the network further.  However, dividing a
   network from one area into multiple areas or from a number of
   existing areas to even more areas
   is can be a very challenging and time
   consuming task since it is involved in involves significant network architecture
   changes.

   These issues can be resolved by using topology-transparent zone
   (TTZ), which abstracts a zone (i.e., a block/piece subset of an area) as a single
   virtual node or zone edges' mesh with minimum efforts and minimum
   service interruption.  Note that a zone can be an area (i.e.,
   the entire piece of an area). area.

   This document presents a topology-transparent zone and describes specifies
   extensions to IS-IS for supporting the that support topology-transparent zone. zones.

1.1.  Requirements Language

   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 [RFC2119]. [RFC2119] [RFC8174]
   when, and only when, they appear in all capitals, as shown here.

1.2.  Terminology

   LSP:  A Link State Protocol Data Unit (PDU) in IS-IS.

   LS:   A Link Sate, which is short for LSP in IS-IS.

   TTZ:  A Topology-Transparent Zone.

   Zone:  A block subset (block or piece piece) of an area.  In a special case, a
       zone is an
       area (i.e., the entire piece of an area). area.

   Zone External Node:  A node outside of a zone.

   Zone Internal Node:  A node of within a zone without any connection to a
       node outside of the zone.

   Zone Edge/Border: Edge/Border Node:  A node that is part of a zone connecting to a
       node outside of the zone.

   Zone Node:  A zone internal node or a zone edge/border node (i.e., a
       node that is part of a zone).

   Zone Link:  A link connecting zone nodes (i.e., a link that is part
       of a zone).

   Zone Neighbor: Neighbor Node:   A node outside of a zone that is a neighbor of
       a zone edge/border.

2.  Requirements

   Topology-Transparent Zone (TTZ) may be deployed for resolving some
   critical issues such as scalability edge/border node.

   CLI:  Command Line Interface.

   LSP:  A Link State Protocol Data Unit (PDU) in existing networks and future
   networks.  The requirements for IS-IS.  An LSP
       contains link state information.  In general, a router/node
       originates multiple LSPs, distinguished by LSP fragment number,
       to carry the link state information about it and the links
       attached to it.

   LS: Link State.  In general, the LS for a node is all the LSPs that
       the node originates.  The LS for a zone is the set of LSPs that
       all the nodes in the zone originate to carry the information
       about them and the links attached to them inside the zone.

2.  Requirements

   A Topology-Transparent Zone (TTZ) may be deployed to resolve some
   critical issues such as scalability in existing networks and future
   networks.  The requirements for a 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 the TTZ.

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

   o  Abstracting a zone as a TTZ virtual entity, which is a single
      virtual node or zone edges' mesh, SHOULD be smooth with minimum
      service interruption.

   o  De-abstracting (or say rolling back) a TTZ virtual entity to a
      zone SHOULD be smooth with minimum service interruption.

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

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

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

3.  Zone Abstraction

   A zone can be abstracted as a single virtual node or the zone edges'
   full mesh.

   When a zone is abstracted as a single virtual node, this single node
   is appears
   to be connected to all the neighbors of the zone, and is to be in the
   same area as the those neighbors.

   When a zone is abstracted as its edges' full mesh, there is a full
   mesh connections among the edges and each edge is also connected to
   its neighbors outside of the zone.

4.  Topology-Transparent Zone

   A Topology-Transparent Zone (TTZ) comprises an Identifier (ID) and a
   piece/block
   subset (piece/block) of an area such as a Level 2 area in IS-IS.  It
   is abstracted as a single virtual node or its edges' full mesh.  TTZ
   and zone as well as node and router will be used exchangably interchangeably
   below.

4.1.  Zone as a Single Node

   After a zone is abstracted as a single virtual node having a virtual
   node ID, every node outside of the zone sees a number of links
   connected to this single node.  Each of these links connects a zone
   neighbor.  The link states inside the zone are not advertised to any
   node outside of the zone.  The virtual node ID may be derived from
   the zone ID.

4.1.1.  An Example of Zone as a Single Node

   The figure below shows an example of an area 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 600

   The area 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/border routers.  A TTZ internal router is a router inside the
   TTZ and its adjacent routers are inside the TTZ.  A TTZ edge/border
   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/border routers
   R61, R63, R65 and R67.  Each TTZ edge/border router is connected to
   at least one router outside of the TTZ.  For instance, router R61 is
   a TTZ edge/border 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.

   From a router outside of the TTZ, a TTZ is seen as a single node
   (refer to the Figure below).  For instance, router R15, which is
   outside of TTZ 600, sees TTZ 600 as a single node Rz, which has
   normal connections to R15, R29, R17 and R23, R25 and R31.

                 TTZ 600
                   \
                    \ ^~^~^~^~^~^~^~^~^~^~^~^~
                     (                        )
    ===[R15]========(                          )======[R29]===
        ||         (                            )       ||
        ||         (                            )       ||
        ||         (                            )       ||
        ||         (                            )       ||
        ||         (             Rz             )       ||
        ||         (                            )       ||
        ||         (                            )       ||
        ||         (                            )       ||
        ||         (                            )       ||
    ===[R17]========(                          )======[R31]===
         \\          (                        )       //
          ||         //v~v~v~v~v~v~v~v~v~v~v~\\      ||
          ||        //                        \\     ||
          ||       //                          \\    ||
           \\     //                            \\  //
       ======[R23]==============================[R25]=====
             //                                     \\
            //                                       \\

                    Figure 2: TTZ 600 as Single Node Rz

4.1.2.  Zone Leader Election

   A node in a zone is elected as a leader for the zone, which is the
   node with the highest priority (and the highest node ID when there
   are more than one nodes having the same highest priority) in the
   zone.  The leader election mechanism described in

   [I-D.ietf-lsr-dynamic-flooding] may be used to elect the leader for
   the zone.

4.1.3.  LS Generation for Zone as a Single Node

   The leader for the zone originates an the LS (i.e., an LSP in IS-IS) set of LSPs) for the
   zone as a single virtual node and sends it to its neighbors.

   The

   This LS comprises all the links connecting adjacencies between the virtual node and
   the zone neighbors.  The LS System ID of each LSP ID is the ID of the
   virtual node for the zone.  The Source ID or Advertising Node/Router
   ID is the ID of the virtual node.

   In addition, the this LS may contain the stub links for the routes IP prefixes such as the loopback
   IP addresses inside the zone to be accessed by zone external nodes
   (i.e., nodes outside of the zone).  These IP prefixes are included in
   the IP internal reachability TLV.

4.1.4.  Adjacency Establishment and Termination

   A zone edge node, node X, acting as a proxy for the single virtual node for
   the zone, forms an adjacency with between the virtual node and a node Y
   that is outside of the zone and in a way node X's area as described below.

   Case 1 for

   For a new adjacency (i.e., no adjacency exists between the
   edge X and the node outside of the zone also called zone neighbor):

   The Y):

   Every IS-IS protocol packet, such as Hello, that edge node X
   originates and sends the zone neighbor every protocol
   packet such as Hello, which contains node Y, uses the virtual node ID as Source ID.

   When the edge node X synchronizes its link state database (LSDB) with
   the zone neighbor, node Y,
   it sends the zone neighbor the information about Y all the link states state information except for the link states state
   belonging to the zone that are is hidden from any node the nodes outside of the
   zone.

   At the end of the LSDB synchronization, the LS for the zone as the a
   single virtual node is originated by the zone leader and distributed
   to the zone neighbor. node Y.  This LS contains the links connecting adjacencies between the virtual node
   and all the zone neighbors, including this newly formed zone neighbor.

   Case 2 for neighbor
   Y.

   For an existing adjacency (i.e., an adjacency already exists between the zone edge
   X and the zone neighbor): Y):

   At first, the edge node X acting as a proxy for the virtual node creates
   a new adjacency between the virtual node for the zone and the zone external node Y in a
   normal way.  It sends Hellos and other packets containing the virtual
   node ID as Source ID to the zone external node.  The zone external node Y.  Node Y establishes the an adjacency with
   the virtual node in the normal way.

   And then, the edge

   Then, node X terminates the existing adjacency between the edge node X and the external
   node Y after the zone has been transferred transitioned to be the virtual node.  It
   stops sending Hellos for the adjacency to the zone
   external node. node Y.  Without receiving
   Hellos from the edge node X for a given time such as hold-timer interval, the zone external node
   Y removes the adjacency to the edge node. node X.  Even though this adjacency
   terminates, the edge node X keeps the link to the external node Y in its LS.

   In another option, the zone edge sends Hellos to case where node Y is not in node X's area, is in the zone neighbor
   with additional information, including a flag T-bit set to one backbone
   and connected to node X, node X, acting as a
   TLV with proxy for the virtual node ID.  This information requests the zone
   neighbor to transfer the existing adjacency to the
   node, creates a new adjacency
   smoothly through working together with between the zone edge virtual node and node Y in following
   steps.

        Zone Edge                                Zone Neighbor
     (Transfer Zone
     to Virtual Node)    Hello(T=1, Virtual ID)
                        ----------------------> OK for Transfer
                                                Adjacency
                         Hello(T=1, Virtual ID)
      Remote Ready for <----------------------
      Transfer
                       Hello(Source=Virtual ID)
      Start Transfer   -----------------------> Transfer to New
                                                Adjacency
                        Hello
      Transfer to New  <-----------------------
      Adjacency                  . . .

   Step 1:  When "Transfer Zone to Virtual Node" is triggered, the zone
      edge sends the zone neighbor
   a Hello containing additional
      information T=1 normal way and Virtual node ID.

   Step 2:  After receiving sends the LS for the Hello with T=1 and virtual node ID from
      the zone edge, to node Y if the
   zone neighbor sends includes all the nodes in its area.

4.1.5.  Computation of Routes

   After a zone edge is transferred/migrated to a Hello with
      T=1 and single virtual node, every
   zone node ID, which means ok for transfer computes the routes (i.e., shortest paths to the new
      adjacency.

   Step 3:  The edge sends
   destinations) using the zone neighbor a Hello containing the
      virtual node ID as Source ID after receiving topology, the Hello with T=1 connections between each
   zone edge and virtual node ID from the its zone neighbor, which starts to
      transfer to and the topology outside of the new adjacency.

   Step 4:  The zone neighbor changes
   without the existing adjacency to the new
      adjacency after receiving the Hello containing the virtual node ID
      as Source ID from the zone edge; and sends the zone edge a Hello
      without the additional information, which means that it
      transferred to the new adjacency.

   Step 5:  The zone edge changes the existing adjacency to the new
      adjacency after receiving the Hello without the additional
      information from the zone neighbor; and continues to send the zone
      neighbor a Hello containing the virtual node ID as Source ID.  At
      this point, the old adjacency is transferred to the new one.

   For the zone neighbor, changing the existing adjacency to the new one
   includes:

   o  Changing the existing adjacency ID from the edge node ID to the
      virtual node ID through either removing the existing adjacency and
      adding a new adjacency with the virtual node ID or just changing
      the existing adjacency ID from the edge node ID to the virtual
      node ID,

   o  Removing the link to the zone edge node from its LS and adding a
      new link to the virtual node (or just changing the link to the
      edge node to the link to the virtual node in its LS), and

   o  Continuing sending the zone edge Hellos without additional
      information.

   For the zone edge, changing the existing adjacency to the new one
   includes:

   o  Keeping the link to the zone neighbor in its LS, and

   o  Continuing sending the zone neighbor Hellos containing the virtual
      node ID as Source ID.

4.1.5.  Computation of Routes

   After a zone edge migrates to zone as a virtual node, it computes the
   routes (i.e., shortest paths to the destinations) in the zone using
   the zone topology (i.e., the topology of the zone without the virtual
   node).

   For the routes outside of the zone, it computes them using the zone
   topology, the topology outside of the zone without the virtual node
   and the connections between each zone edge and its zone neighbor.

   After a zone internal node migrates to zone as a virtual node, it
   computes the routes using the zone topology, the topology outside of
   the zone without the virtual node and the connections between each
   zone edge and its zone neighbor.

4.1.6.  Extensions to Protocols

   The following TLVs are defined in IS-IS.

   o  Adjacent Node ID TLV: containing an adjacent node ID, to which an
      adjacency is transferred or rolled back.  In case of transfer, the
      TLV contains the virtual node ID; in case of roll back, the TLV
      contains the edge node ID.

   o  Zone TLV: containing a zone ID, a flags field and optional sub-
      TLVs.

4.1.6.1.  Adjacent Node ID TLV

   The format of Adjacent Node ID TLV is illustrated below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type (TBD1)  |  Length (8)   |     Virtual/Edge Node ID      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Virtual/Edge Node ID (Continue)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Flags         |N|T|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (1 byte): To be assigned by IANA.

   Length (1 byte): Its value is 8.

   Virtual/Edge Node ID (6 bytes): An adjacent node ID, to which an
   adjacency is transferred or rolled back.

   Flags field (16 bits): two new flag bits are defined as follows:

   o  T-bit: Short for Transfer Adjacency bit.  The T-bit set to one
      indicates a request for transferring to a new 'virtual' adjacency
      from the existing adjacency and the new adjacency is identified by
      the virtual node ID (or say abstract node ID).

   o  N-bit: Short for Roll Back to Normal Adjacency bit. virtual node.  The N-bit set
      to metric of a link outside of the zone
   is one indicates order of magnitude larger than the metric of a request for rolling back link inside the
   zone.

4.2.  Extensions to Protocols

   The following TLV is defined in IS-IS.

   o  Zone ID TLV: containing a Normal adjacency
      from the existing 'virtual' adjacency zone ID, a flags field and the normal adjacency is
      identified by the edge node ID.

4.1.6.2. optional sub-
      TLVs.

4.2.1.  Zone ID TLV

   The format of IS-IS Zone ID TLV is illustrated below.  It may be
   added into an LSP or a Hello PDU for a zone node.  When a node in a zone
   receives a CLI command triggering zone information distribution for
   migration, it updates its LSP by adding an IS-IS Zone TLV with T set
   to 1.  When a node in a zone receives a CLI command activating
   migration zone to an abstracted entity, it sets M to 1 in the Zone
   TLV in its LSP.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (TBD2) (TBD1)  |     Length    |            Zone ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Zone ID (Continue)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Flags             |E|Z|S|  RESV                 |E|  OP |            Sub TLVs           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3: IS-IS Zone ID TLV

   Type (1 byte): To be assigned by IANA. TBD1.

   Length (1 byte): Its value is variable. variable with a minimum of 8.  A value
   larger than 8 means that sub-TLVs are present.  If length is less
   than 8, the TLV MUST be ignored.

   Zone ID (6 bytes): It is the identifier (ID) of a zone.

   Flags field (16 bits): Three one flag bits bit E, Z and S, and OP of 3 bits bits, and a reserved
   subfield are defined. as follows:

      RESV: Reserved. MUST be send as zero and ignored on receipt.
      E = 1: Indicating a node is a zone edge node
      Z
      E = 1: 0: Indicating a node has migrated is a zone internal node

   When a Zone ID is configured on a zone node (refer to Section 6.1),
   the node updates its LSP by adding an IS-IS Zone as ID TLV with the Zone
   ID.  If it is a virtual entity
      S = 1: Indicating zone internal node, the virtual entity TLV has its flag E = 0;
   otherwise (i.e., it is a Single virtual node

   When zone edge node) the TLV has its flag E = 1
   and may include a Zone ISN Sub TLV containing the zone links
   configured.  Every link of a zone internal node originates an LS containing is a zone TLV, it MUST set
   flag E to 1 if it is link.  If
   every link of a zone edge node and to 0 if it is a zone-
   internal node.  It MUST set flag Z to zone link, the TLV with E = 1 after it has migrated to
   does not include any Zone ISN Sub TLV; otherwise (i.e., some of its
   links are zone
   as a virtual entity and to 0 before links), it migrates zone to includes the virtual
   entity or after it rolls back from zone as a virtual entity.  When Zone ISN Sub TLV containing
   the entity abstracted from a zone is a Single virtual node, flag S
   MUST be set to 1. links.

     OP Value    Meaning (Operation)
     0x001 (T):  Advertising Zone Topology Information for Migration
     0x010 (M):  Migrating Zone to a Virtual Entity such as Virtual Node
     0x011 (N):  Advertising Normal Topology Information for Rollback
     0x100 (R):  Rolling Back from the Virtual Entity

   The value of OP indicates one of the four operations above.  When any
   of the other values is received, it is the TLV MUST be ignored.

   When a node in a zone node, such as the zone leader, receives a CLI command triggering via
   management, such as a CLI command, to advertise zone information distribution for
   migration, or determines to advertise, it updates its LSP by adding
   an IS-IS sets OP = T (i.e., 0x001)
   in the Zone ID TLV with T set to 1. of its LSP.  When a node in a zone node receives a
   CLI command activating migration
   to migrate zone to a virtual entity, or determines to migrate, it
   sets OP = M (i.e., 0x010) in the Zone ID TLV of its LSP.  When a zone
   node receives a command to 1 advertise Normal topology information for
   roll back, it sets OP = N (i.e., 0x011) in the Zone ID TLV of its
   LSP.  When a zone node receives a command to roll back or determines
   to roll back, it sets OP = R (i.e., 0x100) in the Zone ID TLV of its
   LSP.

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

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (TBD)   |    Length    |DefaultMetric(i| DelayMetric(i)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |ExpenseMetric(i| ErrorMetric(i)|     |        Neighbor ID(i)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      +               +-----------------------------------------------+
      |               |           Metric (i)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 4: Zone ISN Sub TLV

   A Zone ISN Sub TLV has 1 byte of Type, 1 byte of Length of
   n*(IDLength + 4), 3), which is followed by n tuples of Default Metric,
   Delay Metric, Expense Metric, Error Metric and Neighbor ID. ID and
   Metric.

   A Zone ESN sub-TLV contains the information about a number of ES
   neighbors in the zone connected to a zone edge node.  It has the
   format below.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (TBD)   |    Length    |Default Metric |  DelayMetric  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Expense Metric |  Error Metric     |        Neighbor ID(i)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      +               +-----------------------------------------------+
      |               |           Metric (i)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 5: Zone ESN Sub TLV

4.2.

4.3.  Zone as Edges Full Mesh

   OSPF Topology-Transparent Zone [RFC8099] describes the zone as edges'
   full mesh and the extensions to OSPF for supporting zone as edges'
   full mesh.  Based on these extensions, IS-IS is extended by a few new
   TLVs or Sub-TLVs.

4.2.1.  Extensions to IS-IS

4.2.1.1.
4.3.1.  Updating LSPs for Zone

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

   When a node inside the zone receives an LSP containing an IS-IS Zone
   TLV from a neighboring node in the zone, it stores the LSP and floods
   the LSP to the other neighboring nodes in the zone. as Edges' Mesh

   For every zone edge node, it updates its LSP in three steps and
   floods the LSP to all its neighbors.

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

   Secondly, all its neighbors.

   At first, it adds each of the other zone edge nodes as an IS neighbor
   into the Intermediate System Neighbors TLV in the its LSP after it
   receives an LSP containing an IS-IS Zone ID TLV with M OP = 1 M or a CLI
   command activating migration zone to an abstracted entity.  The
   metric to the neighbor is the metric of the shortest path to the edge
   node within the zone.

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

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

4.3.

4.4.  Advertisement of LSs

   LSs LSPs

   LSPs can be divided into a couple of classes according to their
   Advertisements.  The first class of LSs LSPs is advertised within a zone.
   The second is advertised through a zone.

4.3.1.

4.4.1.  Advertisement of LSs LSPs within Zone

   Any LS LSP about a link state in a zone is advertised only within the
   zone.  It is not advertised to any router outside of the zone.  For
   example, a router LS LSP generated for a zone internal router node is advertised only
   within the zone.

   Any network LS LSP generated for a broadcast network in a zone is advertised
   only within the zone.  It is not advertised outside of the zone.

   After migrating to a zone as a single virtual node or edges' full
   mesh, every zone edge MUST NOT advertise any LS LSP belonging to the
   zone or any information in a LS LSP belonging to the zone to any node
   outside of the zone.  The zone edge determines whether an LS LSP is
   about a zone internal link state by checking if the advertising router originating node
   of the LS LSP is a zone internal router. node.

   For any zone LS LSP originated by a node within the zone, every zone edge
   node MUST NOT advertise it to any node outside of the zone.

4.3.2.

4.4.2.  Advertisement of LSs LSPs through Zone

   Any LS LSP about a link state outside of a zone received by a zone edge
   is advertised using the zone as transit.  For example, when a zone
   edge node receives an LS LSP from a node outside of the zone, it floods
   the LS LSP to its neighbors both inside and outside of the zone.  This LS
   may be any LS such as a router LSA that is advertised within an OSPF
   area.

   The nodes in the zone continue to flood the LS. LSP.  When another zone
   edge receives the LS, LSP, it floods the LS LSP to its neighbors both inside
   and outside of the zone.

5.  Seamless Migration

   This section presents the seamless migration between a zone and its
   single virtual node.  The seamless migration between a zone and its
   edges' full mesh for IS-IS is similar to that described in OSPF
   Topology-Transparent Zone [RFC8099] for OSPF.

5.1.  Transfer Zone to a Single Node

   After transfer

   Transferring a Zone zone to a Single Virtual Node is triggered, single virtual node smoothly takes a few
   steps or stages.

   At first, a user configures the zone
   is abstracted on every node of the zone (refer
   to Section 6.1).  Every zone node updates its LSP by including a Zone
   ID TLV.  For a zone edge node, the TLV has the Zone ID configured,
   its flag E = 1 and a Zone ISN Sub TLV containing the zone links
   configured.  For a zone internal node, the TLV has the Zone ID
   configured and its flag E = 0.

   Second, after finishing the configuration of the zone, a user may
   issue a command, such as a CLI command, on a zone node, such as the
   zone leader, to trigger transferring the zone to the single virtual
   node.  When the node receives the command, it updates its LSP by
   setting OP = T in two steps:

   Step 1:  Every its Zone ID TLV, which is distributed to every zone edge node works together
   node.  After receiving the Zone ID TLV with each of its OP = T, every zone
      neighbor nodes to create edge
   node, acting as a proxy of the virtual node, establishes a new
   adjacency between the virtual node and the each of its zone neighbor node in
   nodes.

   The command may be replaced by the way described in Section 4.1.4 for
      Adjacency Establishment and Termination procedure for case 2. determination made by a zone node,
   such as the zone leader.  After creating determining that the adjacency, each configuration of
   the zone neighbor nodes
      update is finished for a given time such as 10 seconds, it updates
   its LS LSP by adding the adjacency/link into setting OP = T in its LS.

   Step 2: Zone ID TLV.  The configuration is
   complete if every zone leader originates link configured is bidirectional.  For every
   zone internal node configured with the Zone ID, there is an LS for LSP
   containing its Zone ID TLV with E = 0 in the virtual LSDB, which indicates
   that each link from the node (one direction) is a zone link.  For
   every zone edge node, each of its zone links configured from the edge
   node (one direction) is included in its LSP containing its Zone ID
   TLV with E = 1 and Zone ISN Sub TLV in the LSDB.

   Third, after receiving the updated LSes originated by LSPs from all the zone neighbor
   nodes, where the updated LSes contain zone leader checks if all the zone neighbors.

   Step 3:  After receiving new adjacencies between the
   virtual node and the zone neighbor nodes have been established.  If
   so, it originates an LS for the virtual node, node and updates its LSP
   (i.e., the LSP for itself zone leader) by setting OP = M in its Zone
   ID TLV, which is distributed to every zone node.

   After receiving the Zone ID TLV with OP = M, every zone node migrates
   to zone as virtual node.  Every zone edge node does not send any LS
   inside the zone to any zone neighbors.  It advertises its LS LSP without
   any links inside the zone links to the nodes outside of the zone and or purges its LSP
   outside of the zone, terminates its adjacency to each of its zone neighbors in
   neighbors, but contains the way described adjacency in its LSP that is distributed
   within the zone.  Every zone node computes the routes according to
   Section 4.1.4 for Adjacency
      Establishment and Termination procedure for case 2. 4.1.5.

5.2.  Roll Back from Zone as a Single Node

   After abstracting a zone to a single virtual node, we may want to
   roll back from Zone as a Signle Virtual Node is triggered, the node to the zone smoothly in some cases.  The process
   of rolling back is done in following steps:

   Step 1:  Every has a few steps or stages.

   At first, a user issues a command, such as a CLI command, on a zone edge creates an adjacency
   node, such as the zone leader, to each of start (or prepare) for roll back.
   When receiving the command, the node updates its zone
      neighbors LSP by setting OP =
   N in a normal way.

   Step 2: its Zone ID TLV, which will be distributed to every node in the
   zone.  After all receiving the adjacencies Zone ID TLV with OP = N, every zone edge
   node establishes a normal adjacency between the edge node and each of
   its zone edges neighbor nodes, and advertises the link state of the zone neighbors are created,
   over the adjacency if it crosses the adjacency, but holds off its LSP
   containing the normal adjacency.

   Second, a user may issue a command, such as a CLI command, on a zone leader updates
   node, such as the LS for zone leader, to roll back from the virtual node by changing every link metric to
   the maximum metric
      in the LS.

   Step 3:  Every zone edge sends its LS with if the links inside following conditions are met.

   Condition 1:  All the normal adjacencies between every zone edge node
      and all each of its zone neighbor nodes have been established.

   Condition 2:  All the LSes inside link state about the zone that is supposed to
      be advertised outside of the zone has been advertised.

   After receiving the command, the node updates its LSP by setting OP =
   R in its Zone ID TLV, which is distributed to every zone neighbors.  Every node.  After
   receiving the Zone ID TLV with OP = R,

   o  every zone edge node, acting as a proxy of the virtual node node,
      terminates the adjacency between the virtual node and each of its
      zone neighbors through
      stopping Hellos to the neighbors.

   In another option, rolling back is done as follows:

   Step 1:  Using the procedure described in the following, every zone
      edge rolls back the existing virtual adjacency between the edge
      node acting as the virtual node neighbor nodes and advertises its LSP containing the zone neighbor node to a normal adjacency
      adjacencies between the edge node it and the neighbor.

   Step 2: each of its zone neighbor nodes;

   o  The zone leader may flush purges the LS for the virtual node. node abstracted from
      the zone; and

   o  Every zone edge sends Hello and other packets node rolls back to its normal.

   The command may be replaced by the determination made by a zone
      neighbors, where node,
   such as the packets contain zone leader.  After determining that all the edge node conditions
   are met, it updates its LSP by setting OP = R in its Zone ID as Source
      ID.

   The procedure below smoothly rolls back the existing virtual
   adjacency between TLV,
   which is distributed to every zone node.

   Condition 1 is met if it has its LSDB containing the link from each
   zone neighbor node to its zone edge node.  That is that for every
   link from a zone neighbor node acting as to the virtual node and in the LSDB, there
   is a corresponding link from the zone neighbor to a zone edge node.

   Condition 2 is met after Condition 1 has been met for a given time,
   such as maximum LSP advertisement time (MaxLSPAdvTime) crossing a
   network.  We may assume that MaxLSPAdvTime is 5 seconds.

6.  Operations

6.1.  Configuring Zone

   In general, a zone is a subset of an area and has a zone ID.  It
   consists of some zone internal nodes and zone edge nodes.  To
   configure it, a user configures this zone ID on every zone internal
   node and on every zone link of each zone edge node.

   A node configured with the zone ID has all its links to a normal adjacency between be the edge node zone
   links.  The zone internal nodes and all their links plus the neighbor node.

   The zone
   edge node sends nodes and their zone links constitute the neighbor node Hellos with additional
   information, including zone.

   In a flag N-bit set to one special case, a zone is an entire area and has a TLV with the
   edge node ID such as the Adjacent Node ID TLV with the edge node zone ID.
   This information requests the neighbor node to roll back  All
   the existing
   virtual adjacency to links in the normal adjacency smoothly through working
   together with area are the edge node.

   The following steps will roll back zone links of the existing virtual adjacency to zone.  To configure
   this zone, a user configures the normal one: zone Edge ID on every zone Neighbor
     (Roll Back to
     Normal Adjacency)   Hello (N=1, Edge ID)
                        ----------------------> OK to Roll Back to
                                                Normal Adjacency
                         Hello (N=1, Edge ID)
      Remote Ready for <----------------------
      Rolling Back
                         Hello(Source=Edge ID)
      Start Roll Back  -----------------------> Roll Back node.

6.2.  Transferring Zone to
                                                Normal Adjacency
                         Hello
      Roll Back Node

   Transferring a zone to     <-----------------------
      Normal Adjacency           . . .

   Step 1:  When "Roll Back from Zone as a Single Node" is triggered,
      the edge node sends the neighbor single virtual node smoothly may take a Hello with the additional
      information N=1 and Edge ID as normal adjacency ID in order to
      roll back to few
   steps or stages.

   At first, a user configures the normal adjacency from zone on every node of the virtual adjacency.

   Step 2: zone.

   After receiving the Hello with the additional information
      from finishing the edge node, configuration of the neighbor node sends zone, the edge node user may issue a Hello
      with the additional information (i.e., N=1 and Edge ID
   command, such as normal
      adjacency ID), which means ok for rolling back to the normal
      adjacency.

   Step 3:  The edge sends the neighbor a Hello containing the edge node
      ID CLI command, on a zone node, such as Source ID after receiving the Hello with the additional
      information from the neighbor, which starts to roll back zone
   leader, to trigger transferring the
      normal adjacency.

   Step 4:  The neighbor node changes the existing adjacency zone to the
      normal adjacency after node.  When receiving
   the Hello containing command, the edge node ID as Source ID from the distributes it to every zone node.  After
   receiving it, every zone edge node; and sends node, acting as a proxy of the edge node virtual
   node, establishes a
      Hello without new adjacency between the additional information, which means that it
      rolled back virtual node and each
   of its zone neighbor nodes.

   If automatic transferring zone to the normal adjacency.

   Step 5:  The edge node changes is enabled, the existing adjacency user does not
   need to issue the normal
      adjacency command.  A zone node, such as the zone leader,
   will distribute the "command" to every zone node after receiving determining
   that the Hello without configuration of the additional
      information from zone has been finished.

   Then, all the neighbor node; zone nodes, including the zone leader, zone edge nodes
   and continues zone internal nodes, work together to send the
      neighbor Hello containing make the edge node ID zone to appear as Source ID.  At this
      point, the
   a single virtual adjacency is rolled node smoothly in a couple of steps.

6.3.  Rolling back Node to Zone

   After abstracting a zone to a single virtual node, we may want to
   roll back the normal
      adjacency.

   For node to the neighbor zone smoothly in some cases.  The process
   of rolling back has a few steps or stages.

   At first, a user issues a command, such as a CLI command, on a zone
   node, changing such as the existing virtual adjacency zone leader, to start (or prepare) for roll back.
   When receiving the
   normal one includes:

   o  Changing the existing adjacency ID from command, the virtual node ID distributes it to every node in
   the zone.  After receiving it, every zone edge node ID through either removing the existing establishes a
   normal adjacency between the edge node and
      adding a new each of its zone neighbor
   nodes, and advertises the link state of the zone over the adjacency with
   if it crosses the edge node ID or just changing adjacency, but holds off its LSP containing the
      existing adjacency ID
   normal adjacency.

   Second, a user may issue a command, such as a CLI command, on a zone
   node, such as the zone leader, to roll back from the virtual node ID to
   the edge node
      ID,

   o  Removing zone if it is ready for roll back.

   After receiving the link to command, the virtual node from its LS and adding a new
      link distributes it to the edge every node (or just changing in
   the link zone.  After receiving it, all the zone nodes work together to
   roll back from the virtual node to the link zone.

   If automatic roll back Node to Zone is enabled, the edge node in its LS), and

   o  Continuing sending the edge node Hellos without additional
      information.

   For user does not
   need to issue the edge command.  A zone node, changing such as the existing virtual adjacency to zone leader,
   will distribute the
   normal one includes:

   o  Sending its LS "command" to the neighbor, and

   o  Continuing sending the neighbor node Hellos containing the edge every zone node ID as Source ID without additional information.

6.  Operations

   The Operations on TTZ described in OSPF Topology-Transparent Zone
   [RFC8099] are for Zone as Edges Full Mesh in OSPF.  They can be used
   for Zone as Edges Full Mesh in IS-IS.  They can also be used after determining
   that it is ready for Zone
   as a Single Virtual Node in IS-IS. roll back.

7.  Security Considerations

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

8.  IANA Considerations

   Under the registry name "IS-IS TLV Codepoints", IANA is requested to
   assign a new registry types type for Adjacent Node ID, Zone ID and Zone
   Options as follows:

     +==============+===================+=====================+
     |  TLV Type    |      TLV Name     |    reference        |
     +==============+===================+=====================+
     | 26(suggested)| Adjacent  TBD1        | Zone ID           |    This document    |
     +--------------+-------------------+---------------------+

   IANA is requested to create a new sub-registry "Adjacent Node ID Sub-
   TLVs" on the IANA IS-IS TLV Codepoints web page as follows:

     +==============+===================+=====================+
     |     Type     |      Name         |    reference        |
     +==============+===================+=====================+
     |     0        |                Reserved                 |
     +--------------+-------------------+---------------------+
     |     1        |    Zone ISN       |    This document    |
     +--------------+-------------------+---------------------+
     | 27(suggested)|     2        |    Zone ESN       |    This document    |
     +--------------+-------------------+---------------------+
     |     3 - 255  |                Unassigned               |
     +--------------+-------------------+---------------------+

9.  Contributors

        Alvaro Retana
        Futurewei
        Raleigh, NC
        USA

        Email: alvaro.retana@futurewei.com

10.  Acknowledgement

   The authors would like to thank Acee Lindem, Abhay Roy, Christian
   Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han,
   Kiran Makhijani,
   Donald Eastlake, Tony Li, Robert Raszuk, Padmadevi Pillay Esnault,
   and Yang Yu for their valuable comments on TTZ.

11.  References

11.1.  Normative References

   [I-D.ietf-lsr-dynamic-flooding]
              Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda,
              T., Cooper, D., Jalil, L., Dontula, S., and G. Mishra,
              "Dynamic Flooding on Dense Graphs", draft-ietf-lsr-
              dynamic-flooding-07 (work in progress), June 2020.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

   [ISO10589]
              International Organization for Standardization,
              "Intermediate System to Intermediate System Intra-Domain
              Routing Exchange Protocol for use in Conjunction with the
              Protocol for Providing the Connectionless-mode Network
              Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002.

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

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

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

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

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

   [RFC8099]  Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF
              Topology-Transparent Zone", RFC 8099,
              DOI 10.17487/RFC8099, February 2017,
              <https://www.rfc-editor.org/info/rfc8099>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2.  Informative References

   [Clos]     Clos, C., "A Study of Non-Blocking Switching Networks",
              The Bell System Technical Journal Vol. 32(2), DOI
              10.1002/j.1538-7305.1953.tb01433.x, March 1953,
              <http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x>.

   [RFC5307]  Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
              in Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
              <https://www.rfc-editor.org/info/rfc5307>.

Authors' Addresses

   Huaimo Chen
   Futurewei
   Boston, MA
   USA

   Email: huaimo.chen@futurewei.com

   Richard Li
   Futurewei
   2330 Central expressway
   Santa Clara, CA
   USA

   Email: richard.li@futurewei.com
   Yi Yang
   IBM
   Cary, NC
   United States of America

   Email: yyietf@gmail.com

   Anil Kumar S N
   RtBrick
   Bangalore
   India

   Email: anil.ietf@gmail.com

   Yanhe Fan
   Casa Systems
   USA

   Email: yfan@casa-systems.com

   Ning So
   Plano, TX  75082
   USA

   Email: ningso01@gmail.com

   Vic Liu
   USA

   Email: liu.cmri@gmail.com

   Mehmet Toy
   Verizon
   USA

   Email: mehmet.toy@verizon.com

   Lei Liu
   Fujitsu
   USA

   Email: liulei.kddi@gmail.com
   Kiran Makhijani
   Futurewei
   USA

   Email: kiranm@futurewei.com