Internet Engineering Task Force                                  H. Chen
Internet-Draft                                                     R. Li
Intended status: Experimental                               A. Kumar S N
Expires: July 29, 2015 January 3, 2016                             Huawei Technologies
                                                              G. Cauchie

                                                               A. Retana
                                                     Cisco Systems, Inc.
                                                                   N. So
                                                     Tata Communications
                                                                  V. Liu
                                                            China Mobile
                                                                  M. Toy
                                                                 Comcast
                                                                  L. Liu
                                                                UC Davis
                                                        January 25,
                                                            July 2, 2015

                     OSPF Topology-Transparent Zone
                       draft-ietf-ospf-ttz-00.txt
                       draft-ietf-ospf-ttz-01.txt

Abstract

   This document presents a topology-transparent zone in a domain.  A
   topology-transparent zone comprises a group of routers and a number
   of links connecting these routers.  Any router outside of the zone is
   not aware of the zone.  The information about the links and routers
   inside the zone is not distributed to any router outside of the zone.
   Any link state change such as a link 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 July 29, 2015. January 3, 2016.

Copyright Notice

   Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Topology-Transparent Zone  . . . . . . . . . . . . . . . . . .  5
     4.1.  Overview of Topology-Transparent Zone  . . . . . . . . . .  5
     4.2.  An Example of TTZ  . . . . . . . . . . . . . . . . . . . .  6
   5.  Extensions to OSPF Protocols . . . . . . . . . . . . . . . . .  7
     5.1.  Opaque LSAs for TTZ  . . . . . . . . . . . . . . . . . . .  7
     5.2.  A TTZ Capability TLV in Router Information LSA . . . . . . 10
   6.  Constructing LSAs for TTZ  . . . . . . . . . . . . . . . . . . 11
   7.  Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 12
     7.1.  Discover TTZ Neighbor over Normal Adjacency  . . . . . . . 12
     7.2.  Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 12
     7.3.  Adjacency between TTZ Edge and Router outside  . . . . . . 13
   8.  Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Distribution of LSAs within TTZ  . . . . . . . . . . . . . 14
     8.2.  Distribution of LSAs through TTZ . . . . . . . . . . . . . 14
   9.  Computation of Routing Table . . . . . . . . . . . . . . . . . 14
   10. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Configuring TTZ  . . . . . . . . . . . . . . . . . . . . . 14
     10.2. Smooth Migration to TTZ  . . . . . . . . . . . . . . . . . 15
     10.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 16
   11. Prototype Implementation . . . . . . . . . . . . . . . . . . . 16 17
     11.1. What are Implemented and Tested  . . . . . . . . . . . . . 16 17
     11.2. Implementation Experience  . . . . . . . . . . . . . . . . 18
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 18 19
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
   15. Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 19
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     16.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20

1.  Introduction

   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.  Considering the one area
   case, originally the network has only one area, which is the
   backbone.  This original backbone area will be split into a new
   backbone and a number of non backbone areas.  In general, each of the
   non backbone areas is connected to the new backbone area through the
   area border routers between the non backbone and the backbone area.
   There is not any direct connection between any two non backbone
   areas.  Each area border router summarizes the topology of its
   attached non backbone area for transmission on the backbone area, and
   hence to all other area border routers.

   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 an area and
   describes extensions to OSPF 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 links connecting these routers.  Any router outside of the zone is
   not aware of the zone.  The information about the links and routers
   inside the zone is not distributed to any router outside of the zone.
   Any link state change such as a link down inside the zone is not seen
   by any router outside of the zone.

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 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 links
   connecting the routers.  A TTZ is in an OSPF 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 OSPF domain.  It is not zero in
   general.

   In addition to having the functions of an OSPF area, an OSPF TTZ
   makes some improvements on an OSPF area, which include:

   o  An OSPF TTZ is virtualized as the TTZ edge routers connected.

   o  An OSPF 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 the TTZ.

4.2.  An Example of TTZ

   The figure below shows 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

   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 links 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 in 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,
   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 in 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 link 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 links on them.  In
   addition, we SHOULD configure the TTZ ID on every TTZ internal router
   which indicates that every link of the router is a TTZ internal link.

   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 OSPF Protocols

5.1.  Opaque LSAs for TTZ

   The link state information about a TTZ includes router LSAs and
   network LSAs describing the TTZ topology.  These LSAs can be
   contained and distributed in opaque LSAs within the TTZ.  Some
   control information on a TTZ can also be contained and distributed in
   opaque LSAs within the TTZ.  These opaque LSAs are called TTZ opaque
   LSAs or TTZ LSAs for short.

   The following is a general form of a TTZ LSA.  It has an LS type = 10
   and TTZ-LSA-Type, and contains a number of TLVs.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            LS age             |     Options   | LS Type = 10  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TTZ-LSA-type |                     Opaque ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Advertising Router                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      LS Sequence Number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         LS checksum           |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                              TLVs                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where TTZ-LSA-type may be TBD1 (TTZ-RT-LSA-type) for TTZ Router LSA,
   TBD2 (TTZ-NW-LSA-type) for TTZ Network LSA, and TBD3 (TTZ-CT-LSA-
   type) for TTZ Control LSA.

   There are four types of TLVs: TTZ ID TLV, TTZ Router TLV, TTZ network
   TLV and TTZ Options TLV.  A TTZ ID TLV has the following format.  It
   contains a TTZ ID.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       TTZ-ID-TLV-type         |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            TTZ ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of a TTZ Router TLV is as follows.  It contains the
   contents of a normal router LSA.  A TTZ router LSA includes a TTZ ID
   TLV and a TTZ Router TLV.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       TTZ-RT-TLV-type         |          TLV-Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |G|   0   |V|E|B|        0      |            # links            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Link ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Link Data                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     # TOS     |            metric             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                              ...                              ~

   Where G = 1/0 indicates that the router is an edge/internal router of
   TTZ.  For a router link, the existing eight bit Type field for a
   router link may be split into two fields as follows:

         0   1   2   3   4   5   6   7
       +---+---+---+---+---+---+---+---+
       | I |         Type-1            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       I bit flag:
         1: Router link is an internal link to a router inside TTZ.
         0: This indicates that the router link is an external link.
       Type-1: The kind of the link.

   For a link inside a TTZ, I bit flag is set to one, indicating that
   this link is an internal TTZ link.  For a link connecting to a router
   outside of a TTZ from a TTZ edge router, I bit flag is set to zero,
   indicating that this link is an external TTZ link.

   The value of Type-1 may be 1, 2, 3, or 4, which indicates that the
   kind of a link being described is a point-to-point connection to
   another router, a connection to a transit network, a connection to a
   stub network, or a virtual link respectively.

   A TTZ Network TLV has the following format.  It contains the contents
   of a normal network LSA.  A TTZ network LSA includes a TTZ ID TLV and
   a TTZ network TLV.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       TTZ-NW-TLV-type         |          TLV-Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Network Id                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Network Mask                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Attached Router                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                              ...                              ~

   Where Network ID is the interface address of the DR, which is
   followed by the contents of a network LSA.

   The format of TTZ Options TLV is as follows.  A TTZ control LSA
   contains a TTZ ID TLV and a TTZ Options TLV.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       TTZ-OP-TLV-type         |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|M|N|R|    0                                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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

5.2.  A TTZ Capability TLV in Router Information LSA

   A new bit such as bit 6 for TTZ capability may be defined in the
   Router Informational Capabilities TLV as follows:

           Bit     Capabilities
           0       OSPF graceful restart capable [GRACE]
           :       ...
           5       OSPF Experimental TE [EXP-TE]
           6       OSPF TTZ capable [OSPF-TTZ]
           7-31    Unassigned (Standards Action)

   When the OSPF TTZ capable bit is set to one, a TTZ capability TLV
   must follow the Router Informational Capabilities TLV to indicate a
   link/router's TTZ capability and the TTZ to which the link/router
   belongs.  It has the following format.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     TTZ-CAP-TLV-Type = 2      |          Length = 8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            TTZ ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|                              0                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   It contains a TTZ ID and a number of TTZ bits.  The following bits in
   the TLV are assigned:

           Bit     Meaning
           M       Have Migrated to TTZ (i.e., works as TTZ)
           1-31    Unassigned (Standards Action)

   A link scope RI LSA with a OSPF TTZ capable bit set to one and a TTZ
   Capability TLV will be used to discover a TTZ neighbor.

6.  Constructing LSAs for TTZ

   There are three types of LSAs for representing a TTZ: TTZ router LSA,
   TTZ network LSA and Router LSA for virtualizing TTZ.  The first two
   may be generated by a TTZ router, and the third by a TTZ edge router.

   A TTZ router LSA generated by a TTZ router has a TTZ ID TLV and a TTZ
   Router TLV.  The former includes the ID of the TTZ to which the
   router belongs.  The latter contains the links to the router.

   A TTZ network LSA for a broadcast link is generated by the DR for the
   link.  It contains a TTZ ID TLV and a TTZ network TLV.  The former
   has the ID of the TTZ to which the link belongs.  The latter includes
   the DR's address, the network mask, and the routers attached.

   A router LSA for virtualizing a TTZ generated by an edge router of
   the TTZ comprises three groups of links in general.

   The first group are the router links connecting the routers outside
   of the TTZ.  These router links are normal router links.  There is a
   router link for every adjacency between this TTZ edge router and a
   router outside of the TTZ.

   The second group are the "virtual" router links.  For each of the
   other TTZ edge routers, there is a point-to-point router link to it.

   The cost of the link may be the cost of the shortest path from this
   TTZ edge router to it within the TTZ.

   In addition, the LSA may contain a third group of links, which are
   stub links for other destinations inside the TTZ.  They may be the
   loopback addresses to be accessed by a node outside of the TTZ.

7.  Establishing Adjacencies

   This section describes the adjacencies in some different cases.

7.1.  Discover TTZ Neighbor over Normal Adjacency

   For two routers A and B connected by a P2P link and having a normal
   adjacency, they discover TTZ each other through a link scope RI LSA
   with an OSPF TTZ capable bit and a TTZ ID.  We call this LSA D-LSA
   for short.  If two ends of the link have the same TTZ ID, A and B are
   TTZ neighbors.  The following is a sequence of events related to TTZ.

              A                                   B
       Configure TTZ                             Configure TTZ
                       D-LSA (TTZ-ID=100)
                    ---------------------------> Same TTZ ID
                                                 A is B's TTZ Neighbor
                       D-LSA (TTZ-ID=100)
       Same TTZ ID  <---------------------------
       B is A's TTZ Neighbor

   A sends B a D-LSA with TTZ-ID after the TTZ is configured on it.  B
   sends A a D-LSA with TTZ-ID after the TTZ is configured on it.  When
   A receives the D-LSA from B and determines they have the same TTZ ID,
   B is A's TTZ neighbor.  When B receives the D-LSA from A and
   determines they have the same TTZ ID, A is B's TTZ neighbor.

   For a number of routers connected through a broadcast link and having
   normal adjacencies among them, they also discover TTZ each other
   through D-LSAs.  The DR for the link "forms" TTZ adjacency with each
   of the other routers if all the routers attached to the link have the
   same TTZ ID configured on the connections to the link.

7.2.  Establishing TTZ Adjacencies

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

   While A and B are forming an adjacency, they start to discover TTZ
   each other through D-LSAs in the same way as described above after
   the normal adjacency is greater than ExStart.  When the normal
   adjacency is full and B becomes A's TTZ neighbor, A forms a TTZ
   adjacency with B. Similarly, B forms a TTZ adjacency with A.

   For a number of routers connected through a broadcast link and having
   no adjacency among them, they start to form TTZ adjacencies after TTZ
   is configured on the link.  While forming adjacencies, they discover
   TTZ each other through D-LSAs in the same way as described above
   after the normal adjacency is greater than ExStart.  The DR for the
   link forms TTZ adjacency with each of the other routers if all the
   routers attached to the link have the same TTZ ID configured on the
   connections to the link.  Otherwise, the DR does not form any
   adjacency with any router attached to the link.

   An alternative way for forming an adjacency between two routers in a
   TTZ is to extend hello protocol.  Hello protocol is extended to
   include TTZ ID in LLS of a hello packet.  The procedure for handling
   hellos is changed to consider TTZ ID.  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.

7.3.  Adjacency between TTZ Edge and Router outside

   For an edge router in a TTZ, it forms an adjacency with any router
   outside of the TTZ that has a connection with it.

   When the edge router synchronizes its link state database with the
   router outside of the TTZ, it sends the router outside of the TTZ the
   information about all the LSAs except for the LSAs belonging 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 router LSA for virtualizing the TTZ and
   sends this LSA to the router outside of the TTZ.

   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 LSAs 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 LSAs

   LSAs can be divided into a couple of classes according to their
   distributions.  The first class of LSAs is distributed within a TTZ.
   The second is distributed through a TTZ.

8.1.  Distribution of LSAs within TTZ

   Any LSA about a link state in a TTZ is distributed within the TTZ.
   It is not distributed to any router outside of the TTZ.  For example,
   a router LSA generated for a router in a TTZ is distributed within
   the TTZ and not distributed to any router outside of the TTZ.

   Any network LSA generated for a broadcast or NBMA network in a TTZ is
   distributed in the TTZ and not sent to a router outside of the TTZ.

   Any opaque LSA generated for a TTZ internal TE link is distributed
   within the TTZ and not distributed to any router outside of the TTZ.

8.2.  Distribution of LSAs through TTZ

   Any LSA about a link state outside of a TTZ received by an edge
   router of the TTZ is distributed through the TTZ.  For example, when
   an edge router of a TTZ receives an LSA from a router outside of the
   TTZ, it floods it to its neighboring routers both inside the TTZ and
   outside of the TTZ.  This LSA may be any LSA such as a router LSA
   that is distributed in a domain.

   The routers in the TTZ continue to flood the LSA.  When another edge
   router of the TTZ receives the LSA, it floods the LSA 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 is the same as that
   described in RFC 2328, with one exception.  A router in a TTZ MUST
   ignore the router LSAs generated by the edge routers of the TTZ for
   virtualizing the TTZ.  It computes routes through using the TTZ
   topology represented by TTZ LSAs and the topology outside of the TTZ.

10.  Operations

10.1.  Configuring TTZ

   This section proposes some options for configuring a TTZ.

   1.  Configuring TTZ on Every Link in TTZ

   If every link in a TTZ is configured with a same TTZ ID as a TTZ
   link, the TTZ is determined.  A router with some TTZ links and some
   normal links is a TTZ edge router.  A router with only TTZ links 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 links connecting to the routers in the TTZ.

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

10.2.  Smooth Migration to TTZ

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

   At first, users configure the TTZ feature on every router in the TTZ.
   In this stage, a router does not originate its TTZ router LSA or TTZ
   network LSAs.  It will discover its TTZ neighbors.

   Secondly, after configuring the TTZ, users may issue a CLI command on
   one router in the TTZ, which triggers every router in the TTZ to
   generate and distribute TTZ information among the routers in the TTZ.
   When the router receives the command, it originates its TTZ router
   LSA and TTZ network LSAs as needed, and distributes them to its TTZ
   neighbors.  It also originates a TTZ control LSA with T=1 (indicating
   TTZ information generation and distribution for migration).  When a
   router in the TTZ receives the LSA with T=1, it originates its TTZ
   router LSA and TTZ network LSAs as needed.  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 SHOULD 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 may 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, generates and distributes a TTZ control LSA
   with M=1 (indicating Migrating to TTZ) after it receives the command.

   After a router in the TTZ receives the TTZ control LSA 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 flushes its normal router LSA and network LSAs,
   computes routes through using the TTZ topology represented by TTZ
   LSAs and the topology outside of the TTZ.

   The old normal LSAs should be flushed by TTZ routers after the
   migration to TTZ is complete for some time such as one minute.  A TTZ
   router may determine if the migration to TTZ is complete through
   checking whether it has received all the new TTZ LSAs and the LSAs
   for virtualizing the TTZ.  Optionally, it may just let the old normal
   LSAs age out.

   For an edge router of the TTZ, transferring to work as a TTZ router
   comprises generating a router LSA to virtualize the TTZ and flooding
   this LSA to all its neighboring routers.

   Virtualizing the TTZ by an edge router should be done in two steps.
   At first, the router updates its normal router LSA by adding a point-
   to-point link to each of the other edge routers of the TTZ and a stub
   link for each of the loopback addresses in the TTZ to be leaked.  And
   then it removes the links configured as TTZ links from its updated
   router LSA after sending its updated router LSA and receiving the
   updated router LSAs originated by the other TTZ edge routers for a
   short time such as 0.1 second.  Alternatively, it may remove the
   links from its updated router LSA after sending the LSA for a short
   time such as 0.3 second.

10.3.  Adding a Router into TTZ

   When a non TTZ router (say R1) is connected via a P2P link to a TTZ
   router (say T1) working as TTZ and there is a normal adjacency
   between them over the link, a user can configure TTZ on two ends of
   the link 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 link
   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 link on every router to add the non TTZ routers into the TTZ to
   which T1 belongs.  The DR for the link "forms" TTZ adjacency with
   each of the other routers if all the routers have the same TTZ ID
   configured on the connections to the link.

   When a router (say R1) is connected via a P2P link to a TTZ router
   (say T1) and there is not any adjacency between them over the link, a
   user can configure TTZ on two ends of the link 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 link to a group
   of TTZ routers on the link and there is not any adjacency between R1
   and any over the link, a user can configure TTZ on the connection to
   the link on R1 to add R1 into the TTZ to which the TTZ routers
   belong.  R1 starts to form an adjacency with the DR for the link
   after the configuration.

11.  Prototype Implementation

11.1.  What are Implemented and Tested

   1.  CLI Commands for TTZ

   The CLIs implemented and tested include:

    o the CLIs of the simpler option for configuring TTZ, and

    o the CLIs for controlling migration to TTZ.

   2.  Extensions to OSPF Protocols for TTZ

   All the extensions defined in section "Extensions to OSPF Protocols"
   are implemented and tested except for rolling back from TTZ.  The
   testing results illustrate:

    o A TTZ is virtualized to outside as its edge routers fully
      connected.  Any router outside of the TTZ sees the edge routers
      (as normal routers) connecting each other and to some other
      routers.

    o The link state information about the routers and links inside the
      TTZ is contained within the TTZ.  It is not distributed to any
      router outside of the TTZ.

    o TTZ is transparent.  From a router inside a TTZ, it sees the
      topology (link state) outside of the TTZ.  From a router outside
      of the TTZ, it sees the topology beyond the TTZ.  The link state
      information outside of the TTZ is distributed through the TTZ.

    o TTZ is backward compatible.  Any router outside of a TTZ does not
      need to support or know TTZ.

   3.  Smooth Migration to TTZ

   The procedures and related protocol extensions for smooth migration
   to TTZ are implemented and tested.  The testing results show:

    o A part of an area is smoothly migrated to a TTZ without any
      routing disruptions.  The routes on every router are stable while
      the part of the area is being migrated to the TTZ.

    o Migration to TTZ is very easy to operate.

   4.  Add a Router to TTZ

   Adding a router into TTZ is implemented and tested.  The testing
   results illustrate:

    o A router can be easily added into a TTZ and becomes a TTZ router.

    o The router added into the TTZ is not seen on any router outside of
      the TTZ, but it is a part of the TTZ.

   5.  Leak TTZ Loopbacks Outside

   Leaking loopback addresses in a TTZ to routers outside of the TTZ is
   implemented and tested.  The testing results illustrate:

    o The loopback addresses inside the TTZ are distributed to the
      routers outside of the TTZ.

    o The loopback addresses are accessable from a router outside of the
      TTZ.

11.2.  Implementation Experience

   The implementation of TTZ is relatively easy compared to other
   features of OSPF.  Re-using the existing OSPF code along with
   additional simple logic does the work.  A couple of engineers started
   to work on implementing the TTZ from the middle of June, 2014 and
   finished coding it just before IETF 90.  After some testing and bug
   fixes, it works as expected.

   In our implementation, the link state information in a TTZ opaque LSA
   is stored in the same link state database as the link state
   information in a normal LSA.  For each TTZ link in the TTZ opaque LSA
   stored, there is an additional flag, which is used to differentiate
   between a TTZ link and a Normal link.

   Before migration to TTZ, every router in the TTZ computes its routing
   table using the normal links.  After migration to TTZ, every router
   in the TTZ computes its routing table using the TTZ links and normal
   links.  In the case that there are one TTZ link and one normal link
   to select, the TTZ link is used.  In SPF calculation, the back-link
   check passes if and only if the corresponding new additional bit
   matches.  If link type bit is TTZ link, then the lookup is for
   corresponding TTZ LSA.  In case of normal link, the lookup is based
   on normal link.

12.  Security Considerations

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

13.  IANA Considerations

   TBD

14.  Contributors

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

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

15.  Acknowledgement

   The author would like to thank Acee Lindem, Abhay Roy, Dean Cheng,
   Russ White, Tony Przygienda, Lin Han and Yang Yu for their valuable
   comments on this draft.

16.  References

16.1.  Normative References

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

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC4970]  Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
              Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 4970, July 2007.

   [RFC2370]

   [RFC5250]  Berger, L., Bryskin, I., Zinin, A., and R. Coltun, R., "The
              OSPF Opaque LSA Option", RFC 2370, 5250, July 1998. 2008.

   [RFC5613]  Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
              Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.

16.2.  Informative References

   [RFC5441]  Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
              Backward-Recursive PCE-Based Computation (BRPC) Procedure
              to Compute Shortest Constrained Inter-Domain Traffic
              Engineering Label Switched Paths", RFC 5441, April 2009.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009.

Authors' Addresses

   Huaimo Chen
   Huawei Technologies
   Boston, MA
   USA

   Email: huaimo.chen@huawei.com

   Renwei Li
   Huawei Technologies
   2330 Central expressway
   Santa Clara, CA
   USA

   Email: renwei.li@huawei.com
   Anil Kumar S N
   Huawei Technologies
   Banglore
   India

   Email: anil.sn@huawei.com

   Gregory Cauchie
   FRANCE

   Email: greg.cauchie@gmail.com

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

   Email: aretana@cisco.com

   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: liuzhiheng@chinamobile.com
   Mehmet Toy
   Comcast
   1800 Bishops Gate Blvd.
   Mount Laurel, NJ  08054
   USA

   Email: mehmet_toy@cable.comcast.com

   Lei Liu
   UC Davis
   CA
   USA

   Email: liulei.kddi@gmail.com