draft-ietf-lsr-isis-ttz-00.txt   draft-ietf-lsr-isis-ttz-01.txt 
Internet Engineering Task Force H. Chen Internet Engineering Task Force H. Chen
Internet-Draft R. Li Internet-Draft R. Li
Intended status: Experimental Futurewei Intended status: Experimental Futurewei
Expires: March 18, 2021 Y. Yang Expires: April 6, 2021 Y. Yang
IBM IBM
A. Kumar S N A. Kumar S N
RtBrick RtBrick
Y. Fan Y. Fan
Casa Systems Casa Systems
N. So N. So
V. Liu V. Liu
M. Toy M. Toy
Verizon Verizon
L. Liu L. Liu
Fujitsu Fujitsu
K. Makhijani K. Makhijani
Futurewei Futurewei
September 14, 2020 October 3, 2020
IS-IS Topology-Transparent Zone IS-IS Topology-Transparent Zone
draft-ietf-lsr-isis-ttz-00.txt draft-ietf-lsr-isis-ttz-01.txt
Abstract Abstract
This document presents a topology-transparent zone in an area. A This document specifies a topology-transparent zone in an area. A
zone is a block/piece of an area, which comprises a group of routers zone is a subset (block/piece) of an area, which comprises a group of
and a number of circuits connecting them. It is abstracted as a routers and a number of circuits connecting them. It is abstracted
virtual entity such as a single virtual node or zone edges mesh. Any as a virtual entity such as a single virtual node or zone edges mesh.
router outside of the zone is not aware of the zone. The information Any router outside of the zone is not aware of the zone. The
about the circuits and routers inside the zone is not distributed to information about the circuits and routers inside the zone is not
any router outside of the zone. distributed to any router outside of the zone.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 18, 2021. This Internet-Draft will expire on April 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Zone Abstraction . . . . . . . . . . . . . . . . . . . . . . 4 3. Zone Abstraction . . . . . . . . . . . . . . . . . . . . . . 5
4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5
4.1. Zone as a Single Node . . . . . . . . . . . . . . . . . . 5 4.1. Zone as a Single Node . . . . . . . . . . . . . . . . . . 5
4.1.1. An Example of 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.2. Zone Leader Election . . . . . . . . . . . . . . . . 7
4.1.3. LS Generation for Zone as a Single Node . . . . . . . 8 4.1.3. LS Generation for Zone as a Single Node . . . . . . . 8
4.1.4. Adjacency Establishment and Termination . . . . . . . 8 4.1.4. Adjacency Establishment . . . . . . . . . . . . . . . 8
4.1.5. Computation of Routes . . . . . . . . . . . . . . . . 10 4.1.5. Computation of Routes . . . . . . . . . . . . . . . . 9
4.1.6. Extensions to Protocols . . . . . . . . . . . . . . . 11 4.2. Extensions to Protocols . . . . . . . . . . . . . . . . . 9
4.2. Zone as Edges Full Mesh . . . . . . . . . . . . . . . . . 14 4.2.1. Zone ID TLV . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Extensions to IS-IS . . . . . . . . . . . . . . . . . 14 4.3. Zone as Edges Full Mesh . . . . . . . . . . . . . . . . . 11
4.3. Advertisement of LSs . . . . . . . . . . . . . . . . . . 15 4.3.1. Updating LSPs for Zone as Edges' Mesh . . . . . . . . 12
4.3.1. Advertisement of LSs within Zone . . . . . . . . . . 15 4.4. Advertisement of LSPs . . . . . . . . . . . . . . . . . . 12
4.3.2. Advertisement of LSs through Zone . . . . . . . . . . 16 4.4.1. Advertisement of LSPs within Zone . . . . . . . . . . 12
5. Seamless Migration . . . . . . . . . . . . . . . . . . . . . 16 4.4.2. Advertisement of LSPs through Zone . . . . . . . . . 13
5.1. Transfer Zone to a Single Node . . . . . . . . . . . . . 16 5. Seamless Migration . . . . . . . . . . . . . . . . . . . . . 13
5.2. Roll Back from Zone as a Single Node . . . . . . . . . . 16 5.1. Transfer Zone to a Single Node . . . . . . . . . . . . . 13
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Roll Back from Zone as a Single Node . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . 19 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6.1. Configuring Zone . . . . . . . . . . . . . . . . . . . . 15
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Transferring Zone to Node . . . . . . . . . . . . . . . . 16
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 6.3. Rolling back Node to Zone . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[ISO10589] describes two levels of areas, which are level 1 and level [ISO10589] describes two levels of areas in IS-IS, level 1 and level
2 areas in IS-IS. There are scalability issues in using areas as the 2 areas. There are scalability issues in using areas as the number
number of routers in a network becomes larger and larger. of routers in a network becomes larger and larger.
Through splitting the network into multiple areas, we may extend the Through splitting the network into multiple level 1 areas connected
network further. However, dividing a network from one area into by level 2, we may extend the network further. However, dividing a
multiple areas or from a number of existing areas to even more areas network from one area into multiple areas or from a number of
is a very challenging and time consuming task since it is involved in existing areas to even more areas can be a challenging and time
significant network architecture changes. consuming task since it involves significant network architecture
changes.
These issues can be resolved by using topology-transparent zone These issues can be resolved by using topology-transparent zone
(TTZ), which abstracts a zone (i.e., a block/piece of an area) as a (TTZ), which abstracts a zone (i.e., a subset of an area) as a single
single virtual node or zone edges' mesh with minimum efforts and virtual node or zone edges' mesh with minimum efforts and minimum
minimum service interruption. Note that a zone can be an area (i.e., service interruption. Note that a zone can be an entire area.
the entire piece of an area).
This document presents a topology-transparent zone and describes This document presents a topology-transparent zone and specifies
extensions to IS-IS for supporting the topology-transparent zone. extensions to IS-IS that support topology-transparent zones.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
1.2. Terminology 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. TTZ: A Topology-Transparent Zone.
Zone: A block or piece of an area. In a special case, a zone is an Zone: A subset (block or piece) of an area. In a special case, a
area (i.e., the entire piece of an area). zone is an entire area.
Zone External Node: A node outside of a zone. Zone External Node: A node outside of a zone.
Zone Internal Node: A node of a zone without any connection to a Zone Internal Node: A node within a zone without any connection to a
node outside of the zone. node outside of the zone.
Zone Edge/Border: A node of a zone connecting to a node outside of Zone Edge/Border Node: A node that is part of a zone connecting to a
the zone. node outside of the zone.
Zone Node: A zone internal node or a zone edge/border node (i.e., a Zone Node: A zone internal node or a zone edge/border node (i.e., a
node of a zone). node that is part of a zone).
Zone Link: A link connecting zone nodes (i.e., a link of a zone). Zone Link: A link connecting zone nodes (i.e., a link that is part
of a zone).
Zone Neighbor: A node outside of a zone that is a neighbor of a Zone Neighbor Node: A node outside of a zone that is a neighbor of
zone edge/border. a zone edge/border node.
CLI: Command Line Interface.
LSP: A Link State Protocol Data Unit (PDU) in 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 2. Requirements
Topology-Transparent Zone (TTZ) may be deployed for resolving some A Topology-Transparent Zone (TTZ) may be deployed to resolve some
critical issues such as scalability in existing networks and future critical issues such as scalability in existing networks and future
networks. The requirements for TTZ are listed as follows: networks. The requirements for a TTZ are as follows:
o TTZ MUST be backward compatible. When a TTZ is deployed on a set 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 of routers in a network, the routers outside of the TTZ in the
network do not need to know or support TTZ. network do not need to know or support the TTZ.
o TTZ MUST support at least one more levels of network hierarchies, o TTZ MUST support at least one more levels of network hierarchy, in
in addition to the hierarchies supported by existing routing addition to the hierarchies supported by existing IS-IS.
protocols.
o Abstracting a zone as a virtual entity, which is a single virtual o Abstracting a zone as a TTZ virtual entity, which is a single
node or zone edges' mesh, SHOULD be smooth with minimum service virtual node or zone edges' mesh, SHOULD be smooth with minimum
interruption. service interruption.
o De-abstracting (or say rolling back) a virtual entity to a zone o De-abstracting (or say rolling back) a TTZ virtual entity to a
SHOULD be smooth with minimum service interruption. zone SHOULD be smooth with minimum service interruption.
o Users SHOULD be able to easily set up an end to end service o Users SHOULD be able to easily set up an end-to-end service
crossing TTZs. crossing TTZs.
o The configuration for a TTZ in a network SHOULD be minimum. o The configuration for a TTZ in a network SHOULD be minimal.
o The changes on the existing protocols for supporting TTZ SHOULD be o The changes on the existing protocols to support TTZ SHOULD be
minimum. minimal.
3. Zone Abstraction 3. Zone Abstraction
A zone can be abstracted as a single virtual node or the zone edges' A zone can be abstracted as a single virtual node or the zone edges'
full mesh. full mesh.
When a zone is abstracted as a single virtual node, this single node When a zone is abstracted as a single virtual node, this node appears
is connected to all the neighbors of the zone, and is in the same to be connected to all the neighbors of the zone, and to be in the
area as the neighbors. same area as those neighbors.
When a zone is abstracted as its edges' full mesh, there is a full 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 mesh connections among the edges and each edge is also connected to
its neighbors outside of the zone. its neighbors outside of the zone.
4. Topology-Transparent Zone 4. Topology-Transparent Zone
A Topology-Transparent Zone (TTZ) comprises an Identifier (ID) and a A Topology-Transparent Zone (TTZ) comprises an Identifier (ID) and a
piece/block of an area such as a Level 2 area in IS-IS. It is subset (piece/block) of an area such as a Level 2 area in IS-IS. It
abstracted as a single virtual node or its edges' full mesh. TTZ and is abstracted as a single virtual node or its edges' full mesh. TTZ
zone will be used exchangably below. and zone as well as node and router will be used interchangeably
below.
4.1. Zone as a Single Node 4.1. Zone as a Single Node
After a zone is abstracted as a single virtual node having a virtual 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 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 connected to this single node. Each of these links connects a zone
neighbor. The link states inside the zone are not advertised to any 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 node outside of the zone. The virtual node ID may be derived from
the zone ID. the zone ID.
skipping to change at page 8, line 10 skipping to change at page 8, line 10
A node in a zone is elected as a leader for the zone, which is the 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 node with the highest priority (and the highest node ID when there
are more than one nodes having the same highest priority) in the are more than one nodes having the same highest priority) in the
zone. The leader election mechanism described in zone. The leader election mechanism described in
[I-D.ietf-lsr-dynamic-flooding] may be used to elect the leader for [I-D.ietf-lsr-dynamic-flooding] may be used to elect the leader for
the zone. the zone.
4.1.3. LS Generation for Zone as a Single Node 4.1.3. LS Generation for Zone as a Single Node
The leader for the zone originates an LS (i.e., an LSP in IS-IS) for The leader for the zone originates the LS (i.e., set of LSPs) for the
the zone as a single virtual node and sends it to its neighbors. zone as a single virtual node and sends it to its neighbors.
The LS comprises all the links connecting the zone neighbors. The LS This LS comprises all the adjacencies between the virtual node and
ID is the ID of the virtual node for the zone. The Source ID or the zone neighbors. The System ID of each LSP ID is the ID of the
Advertising Node/Router ID is the ID of the virtual node. virtual node for the zone. The Source ID or Advertising Node/Router
ID is the ID of the virtual node.
In addition, the LS may contain the stub links for the routes such as In addition, this LS may contain the IP prefixes such as the loopback
the loopback addresses inside the zone to be accessed by zone IP addresses inside the zone to be accessed by zone external nodes
external nodes (i.e., nodes outside of the zone). (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 4.1.4. Adjacency Establishment
A zone edge node, acting as a single virtual node for the zone, forms A zone edge node X, acting as a proxy for the single virtual node for
an adjacency with a node outside of the zone in a way described the zone, forms an adjacency between the virtual node and a node Y
below. that is outside of the zone and in node X's area as described below.
Case 1 for a new adjacency (i.e., no adjacency exists between the For a new adjacency (i.e., no adjacency exists between X and Y):
edge and the node outside of the zone also called zone neighbor):
The edge node originates and sends the zone neighbor every protocol Every IS-IS protocol packet, such as Hello, that edge node X
packet such as Hello, which contains the virtual node ID as Source originates and sends node Y, uses the virtual node ID as Source ID.
ID.
When the edge node synchronizes its link state database (LSDB) with When node X synchronizes its link state database (LSDB) with node Y,
the zone neighbor, it sends the zone neighbor the information about it sends Y all the link state information except for the link state
all the link states except for the link states belonging to the zone belonging to the zone that is hidden from the nodes outside of the
that are hidden from any node outside of the zone. zone.
At the end of the LSDB synchronization, the LS for the zone as the At the end of the LSDB synchronization, the LS for the zone as a
single virtual node is originated by the zone leader and distributed single virtual node is originated by the zone leader and distributed
to the zone neighbor. This LS contains the links connecting all the to node Y. This LS contains the adjacencies between the virtual node
zone neighbors, including this newly formed zone neighbor. and all the zone neighbors, including this newly formed zone neighbor
Y.
Case 2 for an existing adjacency (i.e., an adjacency already exists For an existing adjacency (i.e., an adjacency already exists between
between the zone edge and the zone neighbor): X and Y):
At first, the edge acting as virtual node creates a new adjacency At first, edge node X acting as a proxy for the virtual node creates
between the virtual node for the zone and the zone external node in a a new adjacency between the virtual node for the zone and node Y in a
normal way. It sends Hellos and other packets containing the virtual 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 ID as Source ID to node Y. Node Y establishes an adjacency with
node establishes the adjacency with the virtual in the normal way. the virtual node in the normal way.
And then, the edge terminates the existing adjacency between the edge
and the external node after the zone has been transferred to the
virtual node. It stops sending Hellos for the adjacency to the zone
external node. Without receiving Hellos from the edge node for a
given time such as hold-timer interval, the zone external node
removes the adjacency to the edge node. Even though this adjacency
terminates, the edge node keeps the link to the external node in its
LS.
In another option, the zone edge sends Hellos to the zone neighbor
with additional information, including a flag T-bit set to one and a
TLV with the virtual node ID. This information requests the zone
neighbor to transfer the existing adjacency to the new adjacency
smoothly through working together with the zone edge 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 and Virtual node ID.
Step 2: After receiving the Hello with T=1 and virtual node ID from
the zone edge, the zone neighbor sends the zone edge a Hello with
T=1 and virtual node ID, which means ok for transfer to the new
adjacency.
Step 3: The edge sends the zone neighbor a Hello containing the
virtual node ID as Source ID after receiving the Hello with T=1
and virtual node ID from the zone neighbor, which starts to
transfer to the new adjacency.
Step 4: The zone neighbor changes 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 Then, node X terminates the existing adjacency between node X and
node Y after the zone has transitioned to be the virtual node. It
stops sending Hellos for the adjacency to node Y. Without receiving
Hellos from node X for a given time such as hold-timer interval, node
Y removes the adjacency to node X. Even though this adjacency
terminates, node X keeps the link to node Y in its LS.
o Continuing sending the zone neighbor Hellos containing the virtual In the case where node Y is not in node X's area, is in the backbone
node ID as Source ID. and connected to node X, node X, acting as a proxy for the virtual
node, creates a new adjacency between the virtual node and node Y in
a normal way and sends the LS for the virtual node to node Y if the
zone includes all the nodes in its area.
4.1.5. Computation of Routes 4.1.5. Computation of Routes
After a zone edge migrates to zone as a virtual node, it computes the After a zone is transferred/migrated to a single virtual node, every
routes (i.e., shortest paths to the destinations) in the zone using zone node computes the routes (i.e., shortest paths to the
the zone topology (i.e., the topology of the zone without the virtual destinations) using the zone topology, the connections between each
node). zone edge and its zone neighbor, and the topology outside of the zone
without the virtual node. The metric of a link outside of the zone
For the routes outside of the zone, it computes them using the zone is one order of magnitude larger than the metric of a link inside the
topology, the topology outside of the zone without the virtual node zone.
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. 4.2. Extensions to Protocols
o Adjacent Node ID TLV: containing an adjacent node ID, to which an The following TLV is defined in IS-IS.
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- o Zone ID TLV: containing a zone ID, a flags field and optional sub-
TLVs. TLVs.
4.1.6.1. Adjacent Node ID TLV 4.2.1. Zone 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. The N-bit set
to one indicates a request for rolling back to a Normal adjacency
from the existing 'virtual' adjacency and the normal adjacency is
identified by the edge node ID.
4.1.6.2. Zone TLV
The format of IS-IS Zone TLV is illustrated below. It may be added The format of IS-IS Zone ID TLV is illustrated below. It may be
into an LSP or a Hello PDU for a zone node. When a node in a zone added into an LSP for a zone node.
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
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 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) | Length | Zone ID | | Type (TBD1) | Length | Zone ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone ID (Continue) | | Zone ID (Continue) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |E|Z|S| OP | Sub TLVs | | RESV |E| OP | Sub TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IS-IS Zone TLV Figure 3: IS-IS Zone ID TLV
Type (1 byte): To be assigned by IANA. Type (1 byte): TBD1.
Length (1 byte): Its value is variable. Length (1 byte): Its value is 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. Zone ID (6 bytes): It is the identifier (ID) of a zone.
Flags field (16 bits): Three flag bits E, Z and S, and OP of 3 bits Flags field (16 bits): one flag bit E, OP of 3 bits, and a reserved
are defined. subfield are as follows:
RESV: Reserved. MUST be send as zero and ignored on receipt.
E = 1: Indicating a node is a zone edge node E = 1: Indicating a node is a zone edge node
Z = 1: Indicating a node has migrated to Zone as a virtual entity E = 0: Indicating a node is a zone internal node
S = 1: Indicating the virtual entity is a Single virtual node
When a zone node originates an LS containing a zone TLV, it MUST set When a Zone ID is configured on a zone node (refer to Section 6.1),
flag E to 1 if it is a zone edge node and to 0 if it is a zone- the node updates its LSP by adding an IS-IS Zone ID TLV with the Zone
internal node. It MUST set flag Z to 1 after it has migrated to zone ID. If it is a zone internal node, the TLV has its flag E = 0;
as a virtual entity and to 0 before it migrates zone to the virtual otherwise (i.e., it is a zone edge node) the TLV has its flag E = 1
entity or after it rolls back from zone as a virtual entity. When and may include a Zone ISN Sub TLV containing the zone links
the entity abstracted from a zone is a Single virtual node, flag S configured. Every link of a zone internal node is a zone link. If
MUST be set to 1. every link of a zone edge node is a zone link, the TLV with E = 1
does not include any Zone ISN Sub TLV; otherwise (i.e., some of its
links are zone links), it includes the Zone ISN Sub TLV containing
the zone links.
OP Value Meaning (Operation) OP Value Meaning (Operation)
0x001 (T): Advertising Zone Topology Information for Migration 0x001 (T): Advertising Zone Topology Information for Migration
0x010 (M): Migrating Zone to a Virtual Entity 0x010 (M): Migrating Zone to a Virtual Entity such as Virtual Node
0x011 (N): Advertising Normal Topology Information for Rollback 0x011 (N): Advertising Normal Topology Information for Rollback
0x100 (R): Rolling Back from the Virtual Entity 0x100 (R): Rolling Back from the Virtual Entity
The value of OP indicates one of the four operations above. When any The value of OP indicates one of the four operations above. When any
of the other values is received, it is ignored. of the other values is received, the TLV MUST be ignored.
When a node in a zone receives a CLI command triggering zone When a zone node, such as the zone leader, receives a command via
information distribution for migration, it updates its LSP by adding management, such as a CLI command, to advertise zone information for
an IS-IS Zone TLV with T set to 1. When a node in a zone receives a migration, or determines to advertise, it sets OP = T (i.e., 0x001)
CLI command activating migration zone to a virtual entity, it sets M in the Zone ID TLV of its LSP. When a zone node receives a command
to 1 in the Zone TLV in its LSP. 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 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 an IS-IS Zone Two new sub-TLVs are defined, which may be added to an IS-IS Zone ID
TLV in an LSP. One is Zone IS Neighbor sub-TLV, or Zone ISN sub-TLV TLV. One is the Zone IS Neighbor sub-TLV, or Zone ISN sub-TLV for
for short. The other is Zone ES Neighbor sub-TLV, or Zone ESN sub- 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 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. number of IS neighbors in the zone connected to a zone edge node. It
It has the format below. has the format below.
0 1 2 3 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 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)| | Type (TBD) | Length | Neighbor ID(i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ExpenseMetric(i| ErrorMetric(i)| Neighbor ID(i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +-----------------------------------------------+
| | Metric (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Zone ISN Sub TLV Figure 4: Zone ISN Sub TLV
A Zone ISN Sub TLV has 1 byte of Type, 1 byte of Length of A Zone ISN Sub TLV has 1 byte of Type, 1 byte of Length of
n*(IDLength + 4), which is followed by n tuples of Default Metric, n*(IDLength + 3), which is followed by n tuples of Neighbor ID and
Delay Metric, Expense Metric, Error Metric and Neighbor ID. Metric.
A Zone ESN sub-TLV contains the information about a number of ES 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 neighbors in the zone connected to a zone edge node. It has the
format below. format below.
0 1 2 3 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 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 | | Type (TBD) | Length | Neighbor ID(i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Expense Metric | Error Metric | Neighbor ID(i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +-----------------------------------------------+
| | Metric (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Zone ESN Sub TLV Figure 5: Zone ESN Sub TLV
4.2. Zone as Edges Full Mesh 4.3. Zone as Edges Full Mesh
4.3.1. Updating LSPs for Zone as Edges' 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. 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.
For every zone edge node, it updates its LSP in three steps and For every zone edge node, it updates its LSP in three steps and
floods the LSP to all its neighbors. floods the LSP to all its neighbors.
At first, the zone edge node adds an IS-IS Zone TLV into its LSP At first, it adds each of the other zone edge nodes as an IS neighbor
after it receives an LSP containing an IS-IS Zone TLV with T = 1 or a into the Intermediate System Neighbors TLV in its LSP after it
CLI command triggering zone information distribution for migration. receives an LSP containing an IS-IS Zone ID TLV with OP = M or a
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, it adds each of the other zone edge nodes as an IS neighbor
into the Intermediate System Neighbors TLV in the LSP after it
receives an LSP containing an IS-IS Zone TLV with M = 1 or a CLI
command activating migration zone to an abstracted entity. The command activating migration zone to an abstracted entity. The
metric to the neighbor is the metric of the shortest path to the edge metric to the neighbor is the metric of the shortest path to the edge
node within the zone. node within the zone.
In addition, it adds a Prefix Neighbors TLV into its LSP. The TLV In addition, it adds an IP internal reachability TLV into its LSP.
contains a number of address prefixes in the zone to be reachable The TLV contains a number of IP prefixes in the zone to be reachable
from outside of the zone. from outside of the zone.
And then it removes the IS neighbors corresponding to the IS And then it removes the IS neighbors corresponding to the IS
neighbors in the Zone TLV (i.e., in the Zone ISN sub TLV) from neighbors in the Zone ID TLV (i.e., in the Zone ISN sub TLV) from
Intermediate System Neighbors TLV in the LSP, and the ES neighbors Intermediate System Neighbors TLV in its LSP, and the ES neighbors
corresponding to the ES neighbors in the Zone TLV (i.e., in the Zone corresponding to the ES neighbors in the Zone ID TLV (i.e., in the
ESN sub TLV) from End System Neighbors TLV in the LSP. This SHOULD Zone ESN sub TLV) from End System Neighbors TLV in the LSP. This
be done after it receives the LSPs for virtualizing zone from the SHOULD be done after it receives the LSPs for virtualizing zone from
other zone edges for a given time. the other zone edges for a given time.
4.3. Advertisement of LSs 4.4. Advertisement of LSPs
LSs can be divided into a couple of classes according to their LSPs can be divided into a couple of classes according to their
Advertisements. The first class of LSs is advertised within a zone. Advertisements. The first class of LSPs is advertised within a zone.
The second is advertised through a zone. The second is advertised through a zone.
4.3.1. Advertisement of LSs within Zone 4.4.1. Advertisement of LSPs within Zone
Any LS about a link state in a zone is advertised only within the Any 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 zone. It is not advertised to any router outside of the zone. For
example, a router LS generated for a zone internal router is example, a LSP generated for a zone internal node is advertised only
advertised only within the zone. within the zone.
Any network LS generated for a broadcast network in a zone is Any LSP generated for a broadcast network in a zone is advertised
advertised only within the zone. It is not advertised outside of the only within the zone. It is not advertised outside of the zone.
zone.
After migrating to zone as a single virtual node or edges' full mesh, After migrating to a zone as a single virtual node or edges' full
every zone edge MUST NOT advertise any LS belonging to the zone or mesh, every zone edge MUST NOT advertise any LSP belonging to the
any information in a LS belonging to the zone to any node outside of zone or any information in a LSP belonging to the zone to any node
the zone. The zone edge determines whether an LS is about a zone outside of the zone. The zone edge determines whether an LSP is
internal link state by checking if the advertising router of the LS about a zone internal link state by checking if the originating node
is a zone internal router. of the LSP is a zone internal node.
For any zone LS originated by a node within the zone, every zone edge For any LSP originated by a node within the zone, every zone edge
node MUST NOT advertise it to any node outside of the zone. node MUST NOT advertise it to any node outside of the zone.
4.3.2. Advertisement of LSs through Zone 4.4.2. Advertisement of LSPs through Zone
Any LS about a link state outside of a zone received by a zone edge Any 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 is advertised using the zone as transit. For example, when a zone
edge node receives an LS from a node outside of the zone, it floods edge node receives an LSP from a node outside of the zone, it floods
the LS to its neighbors both inside and outside of the zone. This LS the LSP to its neighbors both inside and outside of the zone.
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. When another zone The nodes in the zone continue to flood the LSP. When another zone
edge receives the LS, it floods the LS to its neighbors both inside edge receives the LSP, it floods the LSP to its neighbors both inside
and outside of the zone. and outside of the zone.
5. Seamless Migration 5. Seamless Migration
This section presents the seamless migration between a zone and its This section presents the seamless migration between a zone and its
single virtual node. The seamless migration between a zone and its single virtual node.
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 5.1. Transfer Zone to a Single Node
After transfer a Zone to a Single Virtual Node is triggered, the zone Transferring a zone to a single virtual node smoothly takes a few
is abstracted as a single virtual node in two steps: steps or stages.
Step 1: Every zone edge node works together with each of its zone At first, a user configures the zone on every node of the zone (refer
neighbor nodes to create a new adjacency between the virtual node to Section 6.1). Every zone node updates its LSP by including a Zone
and the neighbor node in the way described in Section 4.1.4 for ID TLV. For a zone edge node, the TLV has the Zone ID configured,
Adjacency Establishment and Termination procedure for case 2. its flag E = 1 and a Zone ISN Sub TLV containing the zone links
After creating the adjacency, each of the zone neighbor nodes configured. For a zone internal node, the TLV has the Zone ID
update its LS by adding the adjacency/link into its LS. configured and its flag E = 0.
Step 2: The zone leader originates an LS for the virtual node after Second, after finishing the configuration of the zone, a user may
receiving the updated LSes originated by all the zone neighbor issue a command, such as a CLI command, on a zone node, such as the
nodes, where the updated LSes contain all the zone neighbors. 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 its Zone ID TLV, which is distributed to every zone
node. After receiving the Zone ID TLV with OP = T, every zone edge
node, acting as a proxy of the virtual node, establishes a new
adjacency between the virtual node and each of its zone neighbor
nodes.
Step 3: After receiving the LS for the virtual node, every zone edge The command may be replaced by the determination made by a zone node,
does not send any LS inside the zone to any zone neighbors. It such as the zone leader. After determining that the configuration of
advertises its LS without any links inside the zone to the nodes the zone is finished for a given time such as 10 seconds, it updates
outside of the zone and terminates its adjacency to each of its its LSP by setting OP = T in its Zone ID TLV. The configuration is
zone neighbors in the way described in Section 4.1.4 for Adjacency complete if every zone link configured is bidirectional. For every
Establishment and Termination procedure for case 2. zone internal node configured with the Zone ID, there is an LSP
containing its Zone ID TLV with E = 0 in the 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 LSPs from all the zone neighbor
nodes, the zone leader checks if all the new adjacencies between the
virtual node and the zone neighbor nodes have been established. If
so, it originates an LS for the virtual 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 LSP without
any zone links to the nodes outside of the zone or purges its LSP
outside of the zone, terminates its adjacency to each of its zone
neighbors, but contains the adjacency in its LSP that is distributed
within the zone. Every zone node computes the routes according to
Section 4.1.5.
5.2. Roll Back from Zone as a Single Node 5.2. Roll Back from Zone as a Single Node
After roll back from Zone as a Signle Virtual Node is triggered, After abstracting a zone to a single virtual node, we may want to
rolling back is done in following steps: roll back the node to the zone smoothly in some cases. The process
of rolling back has a few steps or stages.
Step 1: Every zone edge creates an adjacency to each of its zone At first, a user issues a command, such as a CLI command, on a zone
neighbors in a normal way. node, such as the zone leader, to start (or prepare) for roll back.
When receiving the command, the node updates its LSP by setting OP =
N in its Zone ID TLV, which will be distributed to every node in the
zone. After receiving the Zone ID TLV with OP = N, every zone edge
node establishes a normal adjacency between the edge node and each of
its zone neighbor nodes, and advertises the link state of the zone
over the adjacency if it crosses the adjacency, but holds off its LSP
containing the normal adjacency.
Step 2: After all the adjacencies between the zone edges and the Second, a user may issue a command, such as a CLI command, on a zone
zone neighbors are created, the zone leader updates the LS for the node, such as the zone leader, to roll back from the virtual node to
virtual node by changing every link metric to the maximum metric the zone if the following conditions are met.
in the LS.
Step 3: Every zone edge sends its LS with the links inside the zone Condition 1: All the normal adjacencies between every zone edge node
and all the LSes inside the zone to its zone neighbors. Every and each of its zone neighbor nodes have been established.
zone edge acting as the virtual 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: Condition 2: All the link state about the zone that is supposed to
be advertised outside of the zone has been advertised.
Step 1: Using the procedure described in the following, every zone After receiving the command, the node updates its LSP by setting OP =
edge rolls back the existing virtual adjacency between the edge R in its Zone ID TLV, which is distributed to every zone node. After
node acting as the virtual node and the zone neighbor node to a receiving the Zone ID TLV with OP = R,
normal adjacency between the edge node and the neighbor.
Step 2: The zone leader may flush the LS for the virtual node. o every zone edge node, acting as a proxy of the virtual node,
Every zone edge sends Hello and other packets to its zone terminates the adjacency between the virtual node and each of its
neighbors, where the packets contain the edge node ID as Source zone neighbor nodes and advertises its LSP containing the normal
ID. adjacencies between it and each of its zone neighbor nodes;
The procedure below smoothly rolls back the existing virtual o The zone leader purges the LS for the virtual node abstracted from
adjacency between the edge node acting as the virtual node and the the zone; and
zone neighbor node to a normal adjacency between the edge node and
the neighbor node.
The edge node sends the neighbor node Hellos with additional o Every zone node rolls back to normal.
information, including a flag N-bit set to one and a TLV with the
edge node ID such as the Adjacent Node ID TLV with the edge node ID.
This information requests the neighbor node to roll back the existing
virtual adjacency to the normal adjacency smoothly through working
together with the edge node.
The following steps will roll back the existing virtual adjacency to The command may be replaced by the determination made by a zone node,
the normal one: such as the zone leader. After determining that all the conditions
are met, it updates its LSP by setting OP = R in its Zone ID TLV,
which is distributed to every zone node.
zone Edge zone Neighbor Condition 1 is met if it has its LSDB containing the link from each
(Roll Back to zone neighbor node to its zone edge node. That is that for every
Normal Adjacency) Hello (N=1, Edge ID) link from a zone neighbor node to the virtual node in the LSDB, there
----------------------> OK to Roll Back to is a corresponding link from the zone neighbor to a zone edge node.
Normal Adjacency
Hello (N=1, Edge ID)
Remote Ready for <----------------------
Rolling Back
Hello(Source=Edge ID)
Start Roll Back -----------------------> Roll Back to
Normal Adjacency
Hello
Roll Back to <-----------------------
Normal Adjacency . . .
Step 1: When "Roll Back from Zone as a Single Node" is triggered, Condition 2 is met after Condition 1 has been met for a given time,
the edge node sends the neighbor node a Hello with the additional such as maximum LSP advertisement time (MaxLSPAdvTime) crossing a
information N=1 and Edge ID as normal adjacency ID in order to network. We may assume that MaxLSPAdvTime is 5 seconds.
roll back to the normal adjacency from the virtual adjacency.
Step 2: After receiving the Hello with the additional information 6. Operations
from the edge node, the neighbor node sends the edge node a Hello
with the additional information (i.e., N=1 and Edge ID 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 6.1. Configuring Zone
ID as Source ID after receiving the Hello with the additional
information from the neighbor, which starts to roll back to the
normal adjacency.
Step 4: The neighbor node changes the existing adjacency to the In general, a zone is a subset of an area and has a zone ID. It
normal adjacency after receiving the Hello containing the edge consists of some zone internal nodes and zone edge nodes. To
node ID as Source ID from the edge node; and sends the edge node a configure it, a user configures this zone ID on every zone internal
Hello without the additional information, which means that it node and on every zone link of each zone edge node.
rolled back to the normal adjacency.
Step 5: The edge node changes the existing adjacency to the normal A node configured with the zone ID has all its links to be the zone
adjacency after receiving the Hello without the additional links. The zone internal nodes and all their links plus the zone
information from the neighbor node; and continues to send the edge nodes and their zone links constitute the zone.
neighbor Hello containing the edge node ID as Source ID. At this
point, the virtual adjacency is rolled back to the normal
adjacency.
For the neighbor node, changing the existing virtual adjacency to the In a special case, a zone is an entire area and has a zone ID. All
normal one includes: the links in the area are the zone links of the zone. To configure
this zone, a user configures the zone ID on every zone node.
o Changing the existing adjacency ID from the virtual node ID to the 6.2. Transferring Zone to Node
edge node ID through either removing the existing adjacency and
adding a new adjacency with the edge node ID or just changing the
existing adjacency ID from the virtual node ID to the edge node
ID,
o Removing the link to the virtual node from its LS and adding a new Transferring a zone to a single virtual node smoothly may take a few
link to the edge node (or just changing the link to the virtual steps or stages.
node to the link to the edge node in its LS), and
o Continuing sending the edge node Hellos without additional At first, a user configures the zone on every node of the zone.
information.
For the edge node, changing the existing virtual adjacency to the After finishing the configuration of the zone, the user may issue a
normal one includes: command, such as a CLI command, on a zone node, such as the zone
leader, to trigger transferring the zone to the node. When receiving
the command, the node distributes it to every zone node. After
receiving it, every zone edge node, acting as a proxy of the virtual
node, establishes a new adjacency between the virtual node and each
of its zone neighbor nodes.
o Sending its LS to the neighbor, and If automatic transferring zone to node is enabled, the user does not
need to issue the command. A zone node, such as the zone leader,
will distribute the "command" to every zone node after determining
that the configuration of the zone has been finished.
o Continuing sending the neighbor node Hellos containing the edge Then, all the zone nodes, including the zone leader, zone edge nodes
node ID as Source ID without additional information. and zone internal nodes, work together to make the zone to appear as
a single virtual node smoothly in a couple of steps.
6. Operations 6.3. Rolling back Node to Zone
The Operations on TTZ described in OSPF Topology-Transparent Zone After abstracting a zone to a single virtual node, we may want to
[RFC8099] are for Zone as Edges Full Mesh in OSPF. They can be used roll back the node to the zone smoothly in some cases. The process
for Zone as Edges Full Mesh in IS-IS. They can also be used for Zone of rolling back has a few steps or stages.
as a Single Virtual Node in IS-IS.
At first, a user issues a command, such as a CLI command, on a zone
node, such as the zone leader, to start (or prepare) for roll back.
When receiving the command, the node distributes it to every node in
the zone. After receiving it, every zone edge node establishes a
normal adjacency between the edge node and each of its zone neighbor
nodes, and advertises the link state of the zone 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
node, such as the zone leader, to roll back from the virtual node to
the zone if it is ready for roll back.
After receiving the command, the node distributes it to every node in
the zone. After receiving it, all the zone nodes work together to
roll back from the virtual node to the zone.
If automatic roll back Node to Zone is enabled, the user does not
need to issue the command. A zone node, such as the zone leader,
will distribute the "command" to every zone node after determining
that it is ready for roll back.
7. Security Considerations 7. Security Considerations
The mechanism described in this document does not raise any new The mechanism described in this document does not raise any new
security issues for the IS-IS protocols. security issues for the IS-IS protocols.
8. IANA Considerations 8. IANA Considerations
Under the registry name "IS-IS TLV Codepoints", IANA is requested to Under the registry name "IS-IS TLV Codepoints", IANA is requested to
assign new registry types for Adjacent Node ID, Zone ID and Zone assign a new registry type for Zone ID as follows:
Options as follows:
+==============+===================+=====================+ +==============+===================+=====================+
| TLV Type | TLV Name | reference | | TLV Type | TLV Name | reference |
+==============+===================+=====================+ +==============+===================+=====================+
| 26(suggested)| Adjacent Node ID | This document | | TBD1 | Zone ID | This document |
+--------------+-------------------+---------------------+ +--------------+-------------------+---------------------+
| 27(suggested)| Zone | 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 |
+--------------+-------------------+---------------------+
| 2 | Zone ESN | This document |
+--------------+-------------------+---------------------+
| 3 - 255 | Unassigned |
+--------------+-------------------+---------------------+ +--------------+-------------------+---------------------+
9. Contributors 9. Contributors
Alvaro Retana Alvaro Retana
Futurewei Futurewei
Raleigh, NC Raleigh, NC
USA USA
Email: alvaro.retana@futurewei.com Email: alvaro.retana@futurewei.com
10. Acknowledgement 10. Acknowledgement
The authors would like to thank Acee Lindem, Abhay Roy, Christian The authors would like to thank Acee Lindem, Abhay Roy, Christian
Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han, Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han,
Kiran Makhijani, Padmadevi Pillay Esnault, and Yang Yu for their Donald Eastlake, Tony Li, Robert Raszuk, Padmadevi Pillay Esnault,
valuable comments on TTZ. and Yang Yu for their valuable comments on TTZ.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-lsr-dynamic-flooding] [I-D.ietf-lsr-dynamic-flooding]
Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda,
T., Cooper, D., Jalil, L., Dontula, S., and G. Mishra, T., Cooper, D., Jalil, L., Dontula, S., and G. Mishra,
"Dynamic Flooding on Dense Graphs", draft-ietf-lsr- "Dynamic Flooding on Dense Graphs", draft-ietf-lsr-
dynamic-flooding-07 (work in progress), June 2020. dynamic-flooding-07 (work in progress), June 2020.
skipping to change at page 21, line 22 skipping to change at page 19, line 14
[RFC7142] Shand, M. and L. Ginsberg, "Reclassification of RFC 1142 [RFC7142] Shand, M. and L. Ginsberg, "Reclassification of RFC 1142
to Historic", RFC 7142, DOI 10.17487/RFC7142, February to Historic", RFC 7142, DOI 10.17487/RFC7142, February
2014, <https://www.rfc-editor.org/info/rfc7142>. 2014, <https://www.rfc-editor.org/info/rfc7142>.
[RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF
Topology-Transparent Zone", RFC 8099, Topology-Transparent Zone", RFC 8099,
DOI 10.17487/RFC8099, February 2017, DOI 10.17487/RFC8099, February 2017,
<https://www.rfc-editor.org/info/rfc8099>. <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 11.2. Informative References
[Clos] Clos, C., "A Study of Non-Blocking Switching Networks", [Clos] Clos, C., "A Study of Non-Blocking Switching Networks",
The Bell System Technical Journal Vol. 32(2), DOI The Bell System Technical Journal Vol. 32(2), DOI
10.1002/j.1538-7305.1953.tb01433.x, March 1953, 10.1002/j.1538-7305.1953.tb01433.x, March 1953,
<http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x>. <http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
 End of changes. 121 change blocks. 
475 lines changed or deleted 401 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/