draft-ietf-ospf-ttz-04.txt   draft-ietf-ospf-ttz-05.txt 
Internet Engineering Task Force H. Chen Internet Engineering Task Force H. Chen
Internet-Draft R. Li Internet-Draft R. Li
Intended status: Experimental Huawei Technologies Intended status: Experimental Huawei Technologies
Expires: December 30, 2016 A. Retana Expires: June 16, 2017 A. Retana
Y. Yang
Cisco Systems, Inc. Cisco Systems, Inc.
Y. Yang
V. Liu V. Liu
China Mobile China Mobile
M. Toy M. Toy
Comcast Verizon
June 28, 2016 December 13, 2016
OSPF Topology-Transparent Zone OSPF Topology-Transparent Zone
draft-ietf-ospf-ttz-04.txt draft-ietf-ospf-ttz-05.txt
Abstract Abstract
This document presents a topology-transparent zone in an OSPF area. This document presents a topology-transparent zone in an OSPF area.
A topology-transparent zone comprises a group of routers and a number A topology-transparent zone comprises a group of routers and a number
of links connecting these routers. Any router outside of the zone is of links connecting these routers. Any router outside of the zone is
not aware of the zone. The information about the links and routers not aware of the zone. The information about the links and routers
such as a link down inside the zone is not advertised to any router such as a link down inside the zone is not advertised to any router
outside of the zone. outside of the zone.
skipping to change at page 1, line 42 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 30, 2016. This Internet-Draft will expire on June 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 24 skipping to change at page 3, line 24
6. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 7 6. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 7
6.1. General Format of TTZ LSA . . . . . . . . . . . . . . . . 8 6.1. General Format of TTZ LSA . . . . . . . . . . . . . . . . 8
6.2. TTZ ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. TTZ ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. TTZ Router TLV . . . . . . . . . . . . . . . . . . . . . . 9 6.3. TTZ Router TLV . . . . . . . . . . . . . . . . . . . . . . 9
6.4. TTZ Options TLV . . . . . . . . . . . . . . . . . . . . . 10 6.4. TTZ Options TLV . . . . . . . . . . . . . . . . . . . . . 10
6.5. Link Scope TTZ LSA . . . . . . . . . . . . . . . . . . . . 11 6.5. Link Scope TTZ LSA . . . . . . . . . . . . . . . . . . . . 11
7. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 12 7. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 12
7.1. TTZ Migration Process . . . . . . . . . . . . . . . . . . 13 7.1. TTZ Migration Process . . . . . . . . . . . . . . . . . . 13
8. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 14 8. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 14
8.1. Discovery of TTZ Neighbors . . . . . . . . . . . . . . . . 14 8.1. Discovery of TTZ Neighbors . . . . . . . . . . . . . . . . 14
8.2. Adjacency between TTZ Edge and TTZ External Router . . . . 16 8.2. Adjacency between TTZ Edge and TTZ External Router . . . . 17
9. Advertisement of LSAs . . . . . . . . . . . . . . . . . . . . 17 9. Advertisement of LSAs . . . . . . . . . . . . . . . . . . . . 17
9.1. Advertisement of LSAs within TTZ . . . . . . . . . . . . . 17 9.1. Advertisement of LSAs within TTZ . . . . . . . . . . . . . 17
9.2. Advertisement of LSAs through TTZ . . . . . . . . . . . . 17 9.2. Advertisement of LSAs through TTZ . . . . . . . . . . . . 18
10. Computation of Routing Table . . . . . . . . . . . . . . . . . 17 10. Computation of Routing Table . . . . . . . . . . . . . . . . . 18
11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 18 11.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 18
11.2. Migration to TTZ . . . . . . . . . . . . . . . . . . . . . 18 11.2. Migration to TTZ . . . . . . . . . . . . . . . . . . . . . 19
11.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 20 11.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 21
12. Manageability Considerations . . . . . . . . . . . . . . . . . 20 12. Manageability Considerations . . . . . . . . . . . . . . . . . 22
13. Prototype Implementation . . . . . . . . . . . . . . . . . . . 21 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
13.1. What are Implemented and Tested . . . . . . . . . . . . . 21 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13.2. Implementation Experience . . . . . . . . . . . . . . . . 22 15. Contributors and Other Authors . . . . . . . . . . . . . . . . 23
14. Security Considerations . . . . . . . . . . . . . . . . . . . 22 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
16. Contributors and Other Authors . . . . . . . . . . . . . . . . 23 17.1. Normative References . . . . . . . . . . . . . . . . . . . 24
17. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 17.2. Informative References . . . . . . . . . . . . . . . . . . 24
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Prototype Implementation . . . . . . . . . . . . . . 25
18.1. Normative References . . . . . . . . . . . . . . . . . . . 24 A.1. What are Implemented and Tested . . . . . . . . . . . . . 25
18.2. Informative References . . . . . . . . . . . . . . . . . . 25 A.2. Implementation Experience . . . . . . . . . . . . . . . . 26
Appendix A. Constants for LSA Advertisement . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Networks expand as business grows and traffic increases. For Networks expand as business grows and traffic increases. For
scalability and manageability, a hierarchical network architecture is scalability and manageability, a hierarchical network architecture is
usually deployed in OSPF networks by re-grouping routers into areas, usually deployed in OSPF networks by re-grouping routers into areas,
which is often challenging and causes service interruptions. which is often challenging and causes service interruptions.
At first, reorganizing a network from one area into multiple areas or At first, reorganizing a network from one area into multiple areas or
from a number of existing areas into even more areas is a very from a number of existing areas into even more areas is a very
skipping to change at page 4, line 34 skipping to change at page 4, line 34
modifications of configurations on many routers to ensure consistent modifications of configurations on many routers to ensure consistent
routing. routing.
Secondly, the services carried by the network may be interrupted Secondly, the services carried by the network may be interrupted
while the network is being reorganized from one area into multiple while the network is being reorganized from one area into multiple
areas or from a number of existing areas into even more areas since areas or from a number of existing areas into even more areas since
every OSPF interface with an area change is going down with its old every OSPF interface with an area change is going down with its old
area and then up with a new area. area and then up with a new area.
This document presents a topology-transparent zone (TTZ) in an OSPF This document presents a topology-transparent zone (TTZ) in an OSPF
area and describes extensions to OSPF for supporting the topology- area and describes extensions to OSPFv2 for supporting the topology-
transparent zone, which is scalable and resolves the issues above. transparent zone, which is scalable and resolves the issues above.
2. Terminology 2. Terminology
TTZ link or TTZ internal link: A link whose ends are within a single TTZ link or TTZ internal link: A link whose ends are within a single
TTZ. TTZ.
TTZ internal router: A router whose links are TTZ internal links TTZ internal router: A router whose links are TTZ internal links
inside a single TTZ. inside a single TTZ.
skipping to change at page 5, line 36 skipping to change at page 5, line 36
5. Topology-Transparent Zone 5. Topology-Transparent Zone
5.1. Overview of Topology-Transparent Zone 5.1. Overview of Topology-Transparent Zone
A Topology-Transparent Zone is identified by a TTZ identifier (ID), A Topology-Transparent Zone is identified by a TTZ identifier (ID),
and it consists of a group of routers and a number of links and it consists of a group of routers and a number of links
connecting the routers. A TTZ MUST be contained within an OSPF area. connecting the routers. A TTZ MUST be contained within an OSPF area.
A TTZ ID is a 32-bit number that is unique for identifying a TTZ. A TTZ ID is a 32-bit number that is unique for identifying a TTZ.
The TTZ ID SHOULD NOT be 0. The TTZ ID SHOULD NOT be 0. The same TTZ ID MUST be configured on
the routers and/or links that make up a specific instance of a TTZ.
All TTZ instances in a network MUST be unique.
In addition to having similar functions of an OSPF area, an OSPF TTZ In addition to having similar functions of an OSPF area, an OSPF TTZ
makes some improvements on an OSPF area, which include: makes some improvements on an OSPF area, which include:
o An OSPF TTZ represents a set of TTZ edge routers, connected by a o An OSPF TTZ represents a set of TTZ edge routers, connected by a
full mesh of virtual connections between them. full mesh of virtual connections between them.
o Non-TTZ link state information is handled as normal. TTZ Routers o Non-TTZ link state information is handled as normal. TTZ Routers
receive the link state information about the topology outside of receive the link state information about the topology outside of
the TTZ, store the information, and flood the information through the TTZ, store the information, and flood the information through
skipping to change at page 8, line 19 skipping to change at page 8, line 19
6.1. General Format of TTZ LSA 6.1. General Format of TTZ LSA
The following is the general format of a TTZ LSA. It has an LS Type The following is the general format of a TTZ LSA. It has an LS Type
= 10/9 and TTZ-LSA-Type, and contains a number of TLVs. = 10/9 and TTZ-LSA-Type, and contains a number of TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type = 10/9| | LS age | Options | LS Type = 10/9|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TTZ-LSA-Type(9)| Instance ID | |TTZ-LSA-Type(TBD)| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number | | LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length | | LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where TTZ-LSA-Type is 9, the exact number is to be assigned by IANA.
There are three TTZ LSAs of LS Type 10 defined: There are three TTZ LSAs of LS Type 10 defined:
o TTZ Router LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ Router o TTZ Router LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ Router
TLV. TLV.
o TTZ Control LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ o TTZ Control LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ
Options TLV. Options TLV.
o TTZ Indication LSA: a TTZ LSA containing a TTZ ID TLV with E = 0, o TTZ Indication LSA: a TTZ LSA containing a TTZ ID TLV with E = 0,
which indicates that the router originating this LSA is a TTZ which indicates that the router originating this LSA is a TTZ
internal router. internal router.
There is one TTZ LSA of LS Type 9: There is one TTZ LSA of LS Type 9:
o TTZ Discovery LSA: a TTZ LSA containing a TTZ ID TLV and a o TTZ Discovery LSA: a TTZ LSA containing a TTZ ID TLV and a
optional TTZ Options TLV. optional TTZ Options TLV.
6.2. TTZ ID TLV 6.2. TTZ ID TLV
A TTZ ID TLV has the following format. It contains a TTZ ID and some A TTZ ID TLV has the following format. It contains a TTZ ID (refer
flags. to section 5.1) and some flags. It has the TLV-Length of 8 octets.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ-ID-TLV-Type (1) | TLV-Length | | TTZ-ID-TLV-Type (TBD) | TLV-Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ ID | | TTZ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MUST be zero) |E|Z| | Reserved (MUST be zero) |E|Z|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E = 1: Indicating a router is a TTZ Edge router E = 1: Indicating a router is a TTZ Edge router
Z = 1: Indicating a router has migrated to TTZ Z = 1: Indicating a router has migrated to TTZ
When a TTZ router originates a TTZ LSA containing a TTZ ID TLV, it When a TTZ router originates a TTZ LSA containing a TTZ ID TLV, it
sets flag E to 1 in the TTZ ID TLV if it is a TTZ edge router, and to sets flag E to 1 in the TTZ ID TLV if it is a TTZ edge router, and to
0 if it is a TTZ internal router. It sets flag Z to 1 after it has 0 if it is a TTZ internal router. It sets flag Z to 1 after it has
migrated to TTZ. migrated to TTZ, and to 0 before it migrates to TTZ or after it rolls
back from TTZ (refer to section 6.4).
6.3. TTZ Router TLV 6.3. TTZ Router TLV
The format of a TTZ Router TLV is as follows. It has the same The format of a TTZ Router TLV is as follows. It has the same
content as a standard OSPF Router LSA (RFC 2328) with the following content as a standard OSPF Router LSA (RFC 2328) with the following
modifications. modifications.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ-RT-TLV-Type (2) | TLV-Length | | TTZ-RT-TLV-Type (TBD) | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |V|E|B| 0 | # links | | 0 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID | | Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data | | Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric | | Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
For a router link, the existing eight bit Type field for a router For a router link, the existing eight bit Link Type field for a
link is split into two fields as follows: router link is split into two fields as follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| I | Type-1 | | I | Type-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit flag: I bit flag:
1: Router link is a TTZ internal link. 1: Router link is a TTZ internal link.
0: Router link is a TTZ external link. 0: Router link is a TTZ external link.
Type-1: The kind of the link. The values for Type-1 are the same Type-1: The kind of the link. The values for Type-1 are the same
as those for Type defined in RFC 2328 section 12.4.1. as those for Type defined in RFC 2328 section 12.4.1.
The Link Type field is 8 bits, the values 128-255 of the field are
reserved (refer to RFC 4940), which allows the reuse of the bottom 7
bits to indicate the type of a TTZ internal or external link.
6.4. TTZ Options TLV 6.4. TTZ Options TLV
The format of a TTZ Options TLV is as follows. The format of a TTZ Options TLV is as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ-OP-TLV-Type (3) | TLV-Length | | TTZ-OP-TLV-Type (TBD) | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP | Reserved (MUST be zero) | | OP | Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OP Value Meaning (Operation) OP Value Meaning (Operation)
0x001 (T): Advertising TTZ Topology Information for Migration 0x001 (T): Advertising TTZ Topology Information for Migration
0x010 (M): Migrating to TTZ 0x010 (M): Migrating to TTZ
0x011 (N): Advertising Normal Topology Information for Rollback 0x011 (N): Advertising Normal Topology Information for Rollback
0x100 (R): Rolling back from TTZ 0x100 (R): Rolling back from TTZ
A OP field of three bits is defined. It may have a value of 0x001 A OP field of three bits is defined. It may have a value of 0x001
for T, 0x010 for M, 0x011 for N, or 0x100 for R, which indicates one for T, 0x010 for M, 0x011 for N, or 0x100 for R, which indicates one
of the four operations above. When any of the other values is of the four operations above. When any of the other values is
received, it is ignored. received, it is ignored.
Advertising TTZ Topology Information for Migration (T): After a user Advertising TTZ Topology Information for Migration (T): After a user
configures a TTZ router to advertise TTZ topology information, configures a TTZ router to advertise TTZ topology information,
advertising TTZ topology information for migration is triggered. The advertising TTZ topology information for migration is triggered. The
TTZ router originates a TTZ Control LSA having a TTZ Options TLV with TTZ router originates a TTZ Control LSA having a TTZ Options TLV with
OP for T. It also originates its other TTZ LSA such as a TTZ router OP for T. It also originates its other TTZ LSA such as a TTZ router
LSA or TTZ indication LSA. When another TTZ router receives the LSA LSA or TTZ indication LSA. When another TTZ router receives the LSA
with OP for T, it originates its TTZ LSA as described below. with OP for T, it originates its TTZ LSA as described in section 7.
Migrating to TTZ (M): After a user configures a TTZ router to migrate Migrating to TTZ (M): After a user configures a TTZ router to migrate
to TTZ, migrating to TTZ is triggered. The TTZ router originates a to TTZ, migrating to TTZ is triggered. The TTZ router originates a
TTZ Control LSA having a TTZ Options TLV with OP for M and migrates TTZ Control LSA having a TTZ Options TLV with OP for M and migrates
to TTZ. When another TTZ router receives the LSA with OP for M, it to TTZ. When another TTZ router receives the LSA with OP for M, it
also migrates to TTZ. When a router migrates to TTZ, it computes also migrates to TTZ. When a router migrates to TTZ, it computes
routes using the TTZ topology and the topology outside of the TTZ. routes using the TTZ topology and the topology outside of the TTZ.
For a TTZ internal router, it also updates its TTZ indication LSA For a TTZ internal router, it also updates its TTZ indication LSA
with Z = 1. For a TTZ edge router, it updates its TTZ router LSA with Z = 1. For a TTZ edge router, it updates its TTZ router LSA
with Z = 1 and its router LSA for virtualizing the TTZ. with Z = 1 and its router LSA for virtualizing the TTZ. A TTZ router
determines whether it is internal or edge based on configurations
(refer to section 11.1).
Advertising Normal Topology Information for Rollback (N): After a Advertising Normal Topology Information for Rollback (N): After a
user configures a TTZ router to advertise normal topology user configures a TTZ router to advertise normal topology
information, advertising Normal topology information for rollback is information, advertising Normal topology information for rollback is
triggered. The TTZ router originates a TTZ Control LSA having a TTZ triggered. The TTZ router originates a TTZ Control LSA having a TTZ
Options TLV with OP for N. It also advertises its normal LSAs such as Options TLV with OP for N. It also advertises its normal LSAs such as
its normal router LSA and stops advertising its other TTZ LSAs. When its normal router LSA and stops advertising its other TTZ LSAs. When
another TTZ router receives the LSA with OP for N, it advertises its another TTZ router receives the LSA with OP for N, it forwards the
normal LSAs and stops advertising its TTZ LSAs. LSA, advertises its normal LSAs, and stops advertising its TTZ LSAs.
Rolling back from TTZ (R): After a user configures a TTZ router to Rolling back from TTZ (R): After a user configures a TTZ router to
roll back from TTZ, rolling back from TTZ is triggered. The TTZ roll back from TTZ, rolling back from TTZ is triggered. The TTZ
router originates a TTZ Control LSA having a TTZ Options TLV with OP router originates a TTZ Control LSA having a TTZ Options TLV with OP
for R and rolls back from TTZ. When another TTZ router receives the for R and rolls back from TTZ. When another TTZ router receives the
LSA with OP for R, it also rolls back from TTZ. LSA with OP for R, it also rolls back from TTZ.
After a TTZ router originates a TTZ control LSA in response to a After a TTZ router originates a TTZ control LSA in response to a
configuration described above to control TTZ, it flushes the TTZ configuration described above to control TTZ, it flushes the TTZ
control LSA if OP in the LSA is set for the configuration and the control LSA if OP in the LSA is set for the configuration and the
skipping to change at page 11, line 38 skipping to change at page 12, line 10
6.5. Link Scope TTZ LSA 6.5. Link Scope TTZ LSA
A TTZ LSA of LS Type 9 has the following format. A TTZ LSA of LS Type 9 has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type = 9 | | LS age | Options | LS Type = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TTZ-LSA-Type(9)| Instance ID | |TTZ-LSA-Type(TBD)| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number | | LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length | | LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TTZ ID TLV ~ ~ TTZ ID TLV ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
skipping to change at page 12, line 12 skipping to change at page 12, line 32
~ (TTZ Options TLV) ~ ~ (TTZ Options TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It contains a mandatory TTZ ID TLV, which may be followed by a It contains a mandatory TTZ ID TLV, which may be followed by a
optional TTZ Options TLV. It is used to discover a TTZ neighbor. optional TTZ Options TLV. It is used to discover a TTZ neighbor.
7. Constructing LSAs for TTZ 7. Constructing LSAs for TTZ
For a TTZ, its topology is represented by the LSAs generated by its For a TTZ, its topology is represented by the LSAs generated by its
TTZ routers for the link states in the TTZ, which include TTZ router TTZ routers for the link states in the TTZ, which include TTZ router
LSAs, TTZ indication LSAs, normal router LSAs and network LSAs. The LSAs by TTZ edge routers, TTZ indication LSAs by TTZ internal
TTZ router LSAs and TTZ indication LSAs are generated after routers, normal router LSAs and network LSAs. The TTZ router LSAs
advertising TTZ topology information for migration is triggered. and TTZ indication LSAs are generated after advertising TTZ topology
information for migration is triggered.
A TTZ router LSA generated by a TTZ edge router has a TTZ ID TLV and A TTZ edge router generates a TTZ router LSA that has a TTZ ID TLV
a TTZ Router TLV. The former includes the ID of the TTZ to which the and a TTZ Router TLV. The former includes the ID of the TTZ to which
router belongs and flag E set to 1, which indicates the originator of the router belongs and flag E set to 1, which indicates the
the LSA is a TTZ Edge router. For a TTZ edge router, its normal originator of the LSA is a TTZ Edge router. The TTZ router TLV
Router LSA content is copied into a TTZ Router TLV with the contains the TTZ external links to the routers outside of the TTZ and
modifications described in section 6, and a TTZ router LSA containing the TTZ internal links to the routers inside the TTZ as described in
this TLV is constructed and advertised. section 6. The TTZ router LSA containing this TLV is constructed and
advertised within the TTZ.
A TTZ indication LSA generated by a TTZ internal router has a TTZ ID A TTZ internal router generates a TTZ indication LSA that has a TTZ
TLV containing the ID of the TTZ to which the router belongs and flag ID TLV containing the ID of the TTZ to which the router belongs and
E set to 0, which indicates the originator of the LSA is a TTZ flag E set to 0, which indicates the originator of the LSA is a TTZ
internal router. For a TTZ internal router, its regular Router LSA internal router. For a TTZ internal router, its regular Router LSA
is still generated. If a TTZ router is a DR, it originates its is still generated. If a TTZ router is a DR, it originates its
regular network LSA. regular network LSA.
After receiving a trigger to migrate to TTZ such as a TTZ control LSA After receiving a trigger to migrate to TTZ such as a TTZ control LSA
with OP for M, a TTZ edge router originates its normal router LSA for with OP for M, a TTZ edge router originates its normal router LSA for
virtualizing a TTZ, which comprises three groups of links in general. virtualizing a TTZ, which comprises three groups of links in general.
The first group are the router links connecting the TTZ external The first group are the router links connecting the TTZ external
routers. These router links are normal router links. There is a routers. These router links are normal router links. There is a
skipping to change at page 13, line 15 skipping to change at page 13, line 36
7.1. TTZ Migration Process 7.1. TTZ Migration Process
After migration to TTZ is triggered, a TTZ router computes routes After migration to TTZ is triggered, a TTZ router computes routes
using its TTZ topology (refer to section 10) and a TTZ edge router using its TTZ topology (refer to section 10) and a TTZ edge router
originates its normal router LSA for virtualizing the TTZ in two originates its normal router LSA for virtualizing the TTZ in two
steps: steps:
Step 1: The router updates its router LSA by adding a point-to-point Step 1: The router updates its router LSA by adding a point-to-point
link to each of the other known edge routers in the TTZ, and also link to each of the other known edge routers in the TTZ, and also
by adding the stub links for the loopback addresses in the TTZ to by adding the stub links for the loopback addresses in the TTZ to
be accessed outside of the TTZ. be accessed outside of the TTZ according to configuration policies
of operators.
Step 2: After MaxLSAGenAdvTime (0.3 s) or sr-time + MaxLSAAdvTime Step 2: After MaxLSAGenAdvTime (0.3 s) or sr-time + MaxLSAAdvTime
(0.1 s), it removes the TTZ links from its router LSA, where sr- (0.1 s), it removes the TTZ links from its router LSA, where sr-
time is the time from updating its router LSA to receiving the ack time is the time from updating its router LSA to receiving the ack
for its router LSA and receiving the updated router LSAs for its router LSA and receiving the updated router LSAs
originated by the other TTZ edge routers. In other words, it originated by the other TTZ edge routers. In other words, it
removes the TTZ links from its router LSA after sending its removes the TTZ links from its router LSA after sending its
updated router LSA and receiving the updated router LSAs updated router LSA and receiving the updated router LSAs
originated by the other TTZ edge routers for MaxLSAAdvTime or originated by the other TTZ edge routers for MaxLSAAdvTime or
after sending its updated router LSA for MaxLSAGenAdvTime (refer after sending its updated router LSA for MaxLSAGenAdvTime.
to Appendix A). MaxLSAAdvTime and MaxLSAGenAdvTime SHOULD be set to 100ms and
300ms respectively, but MAY be configurable. The former is the
maximum time for an LSA to be advertised to all the routers in an
area. The latter is the maximum time for all TTZ router LSAs to
be generated by all TTZ edge routers and advertised to all the
routers in an area after a first TTZ router LSA is generated.
This is to avoid a possible short route down or change in a TTZ This is to avoid a possible short route down or change in a TTZ
external router while the TTZ is being virtualized. If each TTZ edge external router while the TTZ is being virtualized. If each TTZ edge
router originates its router LSA by adding its point-to-point links router originates its router LSA by adding its point-to-point links
to the other TTZ edge routers and removing its TTZ links in one step, to the other TTZ edge routers and removing its TTZ links in one step,
a route taking a path through the TTZ in the TTZ external router may a route taking a path through the TTZ in the TTZ external router may
be down or changed before all the router LSAs generated by the TTZ be down or changed before all the router LSAs generated by the TTZ
edge routers reach the TTZ external router. When the TTZ external edge routers reach the TTZ external router. When the TTZ external
router computes routes with some router LSAs originated by the TTZ router computes routes with some router LSAs originated by the TTZ
edge routers, bi-directional check for some of the point-to-point edge routers, bi-directional check for some of the point-to-point
skipping to change at page 14, line 17 skipping to change at page 14, line 45
This section describes the TTZ adjacencies. This section describes the TTZ adjacencies.
8.1. Discovery of TTZ Neighbors 8.1. Discovery of TTZ Neighbors
For two routers A and B connected by a P2P link and having a normal For two routers A and B connected by a P2P link and having a normal
adjacency, they TTZ discover each other through a TTZ LSA of LS Type adjacency, they TTZ discover each other through a TTZ LSA of LS Type
9 with a TTZ ID TLV. We call this LSA D-LSA for short. 9 with a TTZ ID TLV. We call this LSA D-LSA for short.
If two ends of the link have different TTZ IDs or only one end is If two ends of the link have different TTZ IDs or only one end is
configured with TTZ ID, no TTZ adjacency over the link will be configured with TTZ ID, TTZ adjacency over the link MUST NOT be
"formed". "formed".
If two ends of the link have the same TTZ ID and Z flag value, A and If two ends of the link have the same TTZ ID and Z flag value, A and
B are TTZ neighbors. The following is a sequence of events related B are TTZ neighbors. The following is a sequence of events related
to TTZ for this case. to TTZ for this case.
A B A B
Configure TTZ Configure TTZ Configure TTZ Configure TTZ
D-LSA (TTZ-ID=100) D-LSA (TTZ-ID=100)
----------------------> Same TTZ ID and Z ----------------------> Same TTZ ID and Z
skipping to change at page 14, line 48 skipping to change at page 15, line 29
the TTZ LSAs it has and originates its TTZ LSA when one of the the TTZ LSAs it has and originates its TTZ LSA when one of the
following conditions is met. following conditions is met.
o Z = 0 and there is a TTZ LSA with OP for T. o Z = 0 and there is a TTZ LSA with OP for T.
o Z = 1. o Z = 1.
B is symmetric to A and acts similarly to A. B is symmetric to A and acts similarly to A.
If two ends of the link have the same TTZ ID but Z flags are If two ends of the link have the same TTZ ID but Z flags are
different, a TTZ adjacency over the link is "formed" in the following different, a TTZ adjacency over the link MUST be "formed" in the
steps. Suppose that A has migrated to TTZ and B has not (i.e., flag following steps. Suppose that A has migrated to TTZ and B has not
Z in A's D-LSA is 1 and flag Z in B's D-LSA is 0). (i.e., flag Z in A's D-LSA is 1 and flag Z in B's D-LSA is 0).
A B A B
Configure TTZ Configure TTZ Configure TTZ Configure TTZ
D-LSA(TTZ-ID=100,Z=1) D-LSA(TTZ-ID=100,Z=1)
----------------------> Same TTZ ID, but ----------------------> Same TTZ ID, but
different Z different Z
A is B's TTZ Neighbor A is B's TTZ Neighbor
D-LSA(TTZ-ID=100,Z=0) D-LSA(TTZ-ID=100,Z=0)
Same TTZ ID, but <---------------------- Same TTZ ID, but <----------------------
different Z different Z
skipping to change at page 16, line 4 skipping to change at page 16, line 30
When B receives the D-LSA from A with OP for M, it starts to migrate When B receives the D-LSA from A with OP for M, it starts to migrate
to TTZ. B updates and advertises its LSAs as needed. to TTZ. B updates and advertises its LSAs as needed.
After receiving B's D-LSA with Z = 1, A updates and sends B its D-LSA After receiving B's D-LSA with Z = 1, A updates and sends B its D-LSA
by removing the TTZ Options TLV. It also updates and advertises its by removing the TTZ Options TLV. It also updates and advertises its
LSAs as needed. LSAs as needed.
For a number of routers connected through a broadcast link and having For a number of routers connected through a broadcast link and having
normal adjacencies among them, they also TTZ discover each other normal adjacencies among them, they also TTZ discover each other
through D-LSAs. The DR for the link "forms" TTZ adjacencies with the through D-LSAs. The DR for the link MUST "form" TTZ adjacencies with
other routers if all the routers attached to the link have the same the other routers if all the routers attached to the link have the
TTZ ID configured on the connections to the link. Otherwise, the DR same TTZ ID configured on the connections to the link. Otherwise,
does not "form" any TTZ adjacency with any router attached to the the DR MUST NOT "form" any TTZ adjacency with any router attached to
link. the link.
For a number of routers connected through a broadcast link and having For a number of routers connected through a broadcast link and having
TTZ adjacencies among them, if a mis-configured router is introduced TTZ adjacencies among them, if a mis-configured router is introduced
on the broadcast link, the DR for the link will not "form" any TTZ on the broadcast link, the DR for the link MUST NOT "form" any TTZ
adjacency with this mis-configured router. adjacency with this mis-configured router.
For routers connected via a link without any adjacency among them, For routers connected via a link without any adjacency among them,
they TTZ discover each other through D-LSAs in the same way as they TTZ discover each other through D-LSAs in the same way as
described above after they form a normal adjacency. described above after they form a normal adjacency.
A TTZ adjacency over a link is removed when one of the following A TTZ adjacency over a link MUST be removed when one of the following
events happens. events happens.
o TTZ ID on one end of the link is changed to a different one. o TTZ ID on one end of the link is changed to a different one.
o TTZ ID on one end of the link is removed. o TTZ ID on one end of the link is removed.
o D-LSA is not received for sometime such as 60 minutes or is o The D-LSA is not received after the D-LSA-MAX-RETRANSMIT-TIME or
flushed. is explicitly flushed. The D-LSA-MAX-RETRANSMIT-TIME SHOULD be
set to 60 minutes, but MAY be configurable.
o Normal adjacency over the link is down. o Normal adjacency over the link is down.
When the TTZ ID on one end of the link is removed, the corresponding When the TTZ ID on one end of the link is removed, the corresponding
D-LSA is flushed. D-LSA is flushed.
8.2. Adjacency between TTZ Edge and TTZ External Router 8.2. Adjacency between TTZ Edge and TTZ External Router
A TTZ edge router forms an adjacency with any TTZ external router to A TTZ edge router forms an adjacency with any TTZ external router to
which it is connected. which it is connected.
skipping to change at page 17, line 27 skipping to change at page 18, line 5
Any network LSA generated for a broadcast or NBMA network in a TTZ is Any network LSA generated for a broadcast or NBMA network in a TTZ is
advertised only within the TTZ. It is not advertised outside of the advertised only within the TTZ. It is not advertised outside of the
TTZ. TTZ.
Any opaque LSA generated for a TTZ internal TE link is advertised Any opaque LSA generated for a TTZ internal TE link is advertised
only within the TTZ. only within the TTZ.
After migrating to TTZ, every edge router of a TTZ MUST NOT advertise After migrating to TTZ, every edge router of a TTZ MUST NOT advertise
any LSA about a link state in the TTZ to any router outside of the any LSA about a link state in the TTZ to any router outside of the
TTZ. TTZ. The TTZ edge router determines whether an LSA is about a TTZ
internal link state by checking if the advertising router of the LSA
is a TTZ internal router (i.e., there is a TTZ indication LSA
generated by the TTZ internal router and having the same advertising
router).
For any TTZ LSA originated by a router within the TTZ, every edge For any TTZ LSA originated by a router within the TTZ, every edge
router of the TTZ MUST NOT advertise it to any router outside of the router of the TTZ MUST NOT advertise it to any router outside of the
TTZ. TTZ.
9.2. Advertisement of LSAs through TTZ 9.2. Advertisement of LSAs through TTZ
Any LSA about a link state outside of a TTZ received by an edge Any LSA about a link state outside of a TTZ received by an edge
router of the TTZ is advertised using the TTZ as transit. For router of the TTZ is advertised using the TTZ as transit. For
example, when an edge router of a TTZ receives an LSA from a router example, when an edge router of a TTZ receives an LSA from a router
skipping to change at page 17, line 51 skipping to change at page 18, line 33
The routers in the TTZ continue to flood the LSA. When another edge 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 router of the TTZ receives the LSA, it floods the LSA to its
neighboring routers both outside of the TTZ and inside the TTZ. neighboring routers both outside of the TTZ and inside the TTZ.
10. Computation of Routing Table 10. Computation of Routing Table
After a router migrates to TTZ, the computation of the routing table After a router migrates to TTZ, the computation of the routing table
on the router is the same as that described in RFC 2328 section 16 on the router is the same as that described in RFC 2328 section 16
with one exception. The router in a TTZ ignores the router LSAs with one exception. The router in a TTZ ignores the router LSAs
generated by the TTZ edge routers for virtualizing the TTZ. This can generated by the TTZ edge routers for virtualizing the TTZ. It
be achieved by adding a flag into every link stored in LSDB and computes routes using the TTZ router LSAs and the regular LSAs,
setting this flag to 1 in every link in these router LSAs, which excluding the router LSAs for virtualizing the TTZ. That is that it
indicates that the link is unusable. It computes routes using the computes routes using the TTZ topology and the topology outside of
TTZ topology (i.e., using LSAs for representing the TTZ) and the the TTZ, excluding the links for virtualizing the TTZ.
topology outside of the TTZ, excluding any unusable links. The LSAs
for representing a TTZ are described in Section 7.
11. Operations 11. Operations
11.1. Configuring TTZ 11.1. Configuring TTZ
This section proposes some options for configuring a TTZ. This section proposes some options for configuring a TTZ.
1. Configuring TTZ on Every Link in 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 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 link, the TTZ is determined. A router with some links in a TTZ and
normal links is a TTZ edge router. A router with only TTZ links is a some links not in this TTZ is a TTZ edge router. A router with all
TTZ internal router. its links in a TTZ is a TTZ internal router.
2. Configuring TTZ on Every Router in TTZ 2. Configuring TTZ on Routers in TTZ
A same TTZ ID is configured on every router in a TTZ, and on every A same TTZ ID is configured on every TTZ internal router in a TTZ,
TTZ edge router's links connecting to the routers in the TTZ. and on every TTZ 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 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 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 internal router. All the links on a TTZ internal router are TTZ
links. This option is simpler than option 1 above. links. This option is simpler than option 1 above.
For a TTZ edge router X with different TTZ IDs on its different
links, router X connects two or more different TTZs. In this case,
router X originates its router LSA for virtualizing the TTZs. This
LSA includes the normal links connecting to routers outside of these
TTZs and the virtual links to the other edge routers of each of these
TTZs. Router X also originates its TTZ router LSA for each of TTZs.
The TTZ router LSA for TTZ N includes the links to routers outside of
these TTZs, the virtual links to the other edge routers of the other
TTZs, and the TTZ links to the routers in TTZ N.
11.2. Migration to TTZ 11.2. Migration to TTZ
For a group of routers and a number of links connecting the routers 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 in an area, making them transfer to work as a TTZ without any service
interruption takes a few of steps or stages. interruption takes a few of steps or stages.
At first, a user configures the TTZ feature on every router in the At first, a user configures the TTZ feature on every router in the
TTZ. In this stage, a router does not originate or advertise its TTZ TTZ. In this stage, a router does not originate or advertise its TTZ
topology information. It will discover its TTZ neighbors. topology information. It will discover its TTZ neighbors.
Secondly, after configuring the TTZ, a user issues a CLI command on Secondly, after configuring the TTZ, a user issues a configuration on
one router in the TTZ, which triggers every router in the TTZ to one router in the TTZ, which triggers every router in the TTZ to
generate and advertise TTZ information among the routers in the TTZ. generate and advertise TTZ information among the routers in the TTZ.
When the router receives the command, it originates a TTZ control LSA When the router receives the configuration, it originates a TTZ
with OP for T (indicating TTZ information generation and control LSA with OP for T (indicating TTZ information generation and
advertisement for migration). It also originates its TTZ LSA such as advertisement for migration). It also originates its TTZ LSA such as
TTZ router LSA or TTZ indication LSA, and advertises the LSA to its TTZ router LSA or TTZ indication LSA, and advertises the LSA to its
TTZ neighbors. When another router in the TTZ receives the LSA with TTZ neighbors. When another router in the TTZ receives the LSA with
OP for T, it originates its TTZ LSA. In this stage, every router in OP for T, it originates its TTZ LSA. In this stage, every router in
the TTZ has dual roles. One is to function as a normal router. The the TTZ has dual roles. One is to function as a normal router. The
other is to generate and advertise TTZ information. other is to generate and advertise TTZ information.
Thirdly, a user checks whether a router in the TTZ is ready for Thirdly, a user checks whether a router in the TTZ is ready for
migration to TTZ. A router in the TTZ is ready after it has received migration to TTZ. A router in the TTZ is ready after it has received
all the necessary information from all the routers in the TTZ. This all the TTZ LSAs including TTZ router LSAs from TTZ edge routers and
information may be displayed on a router through a CLI command. TTZ indication LSAs from TTZ internal routers. This information may
be displayed on a router through a configuration.
And then a user activates the TTZ through using a CLI command such as And then a user activates the TTZ through using a configuration such
migrate to TTZ on one router in the TTZ. The router migrates to TTZ, as migrate to TTZ on one router in the TTZ. The router migrates to
generates and advertises a TTZ control LSA with OP for M (indicating TTZ, generates and advertises a TTZ control LSA with OP for M
Migrating to TTZ) after it receives the command. After another (indicating Migrating to TTZ) after it receives the configuration.
router in the TTZ receives the TTZ control LSA with OP for M, it also After another router in the TTZ receives the TTZ control LSA with OP
migrates to TTZ. Thus, activating the TTZ on one TTZ router for M, it also migrates to TTZ. Thus, activating the TTZ on one TTZ
propagates to every router in the TTZ, which migrates to TTZ. router propagates to every router in the TTZ, which migrates to TTZ.
For an edge router of the TTZ, migrating to work as a TTZ router For an edge router of the TTZ, migrating to work as a TTZ router
comprises generating a router LSA to virtualize the TTZ and flooding comprises generating a router LSA to virtualize the TTZ and flooding
this LSA to all its neighboring routers in two steps as described in this LSA to all its neighboring routers in two steps as described in
section 7. section 7.
In normal operations for migration to TTZ and rollback from TTZ, a In normal operations for migration to TTZ and rollback from TTZ, a
user issues a series of commands according to certain procedures. In user issues a series of configurations according to certain
an abnormal case, for example two conflicting commands are issued on procedures. In an abnormal case, for example two conflicting
two TTZ routers in a TTZ at the same time, a TTZ router issues an configurations are issued on two TTZ routers in a TTZ at the same
error and logs the error when it detects a conflict. time, a TTZ router issues an error and logs the error when it detects
a conflict.
A conflicting command may be detected on a router on which the A conflicting configuration may be detected on a router on which the
command is issued. Thus some abnormal cases may be prevented. When configuration is issued. Thus some abnormal cases may be prevented.
a command for migration/rollback is issued on a router, the router When a configuration for migration/rollback is issued on a router,
checks whether it is in a correct sequence of commands for migration/ the router checks whether it is in a correct sequence of
rollback through using the information it has. For migrating a part configurations for migration/rollback through using the information
of an area to a TTZ, the correct sequence of commands is as follows it has. For migrating a part of an area to a TTZ, the correct
in general: sequence of configurations is as follows in general:
1) configure TTZ on every router in the part of the area to be 1) configure TTZ on every router in the part of the area to be
migrated to TTZ; migrated to TTZ;
2) configure on one router in the TTZ to trigger every router in the 2) configure on one router in the TTZ to trigger every router in the
TTZ to generate and advertise TTZ information for migration; and TTZ to generate and advertise TTZ information for migration; and
3) configure on one router in the TTZ to trigger every router in the 3) configure on one router in the TTZ to trigger every router in the
TTZ to migrate to TTZ. TTZ to migrate to TTZ.
For rolling back from TTZ, it is similar. After receiving a configuration on a router to migrate to TTZ, which
is for 3), the router checks whether 2) is performed through checking
After receiving a command on a router to migrate to TTZ, which is for if it has received/originated TTZ LSAs. If it has not, it issues an
3), the router checks whether 2) is performed through checking if it error to an operator (generation and advertisement of TTZ information
has received/originated TTZ LSAs. If it has not, it issues an error for migration to TTZ is not done yet) and rejects the configuration
to an operator (generation and advertisement of TTZ information for at this time.
migration to TTZ is not done yet) and rejects the command at this
time.
After a router receives a TTZ LSA with OP for M for 3) from another After a router receives a TTZ LSA with OP for M for 3) from another
router, it checks whether 2) is performed through checking if it has router, it checks whether 2) is performed through checking if it has
received/originated TTZ LSAs. If it has not, it issues an error and received/originated TTZ LSAs. If it has not, it issues an error and
logs the error. The operation for migration will continue. logs the error, and does not migrate to TTZ. In this case, it does
not originate its router LSA for virtualizing the TTZ if it is a TTZ
edge router.
After receiving a command on a router to generate and advertise TTZ After receiving a configuration on a router to generate and advertise
information, which is for 2), the router checks whether 1) is TTZ information, which is for 2), the router checks whether 1) is
performed through checking if TTZ is configured on it. If it is not, performed through checking if TTZ is configured on it. If it is not,
it issues an error to an operator (TTZ is not configured on it yet) it issues an error to an operator (TTZ is not configured on it yet)
and rejects the command at this time. and rejects the configuration at this time.
For rolling back from TTZ, the correct sequence of configurations is
below.
1) configure on one router in the TTZ to trigger every router in the
TTZ to advertise normal LSAs and stop advertising TTZ LSAs;
2) configure on one router in the TTZ to trigger every router in the
TTZ to roll back from TTZ.
After receiving a configuration on a router to roll back from TTZ,
which is for 2), the router checks whether 1) is performed through
checking if it has received TTZ LSA with OP for N. If it has not, it
issues an error to an operator (advertise normal LSAs and stop
advertising TTZ LSAs for rolling back from TTZ is not done yet) and
rejects the configuration at this time.
After a router receives a TTZ LSA with OP for R for 2) from another
router, it checks whether 1) is performed through checking if it has
received TTZ LSA with OP for N. If it has not, it issues an error and
logs the error, and does not roll back from TTZ.
After receiving a configuration on a router to advertise normal LSAs
and stop advertising TTZ LSAs for rolling back from TTZ, which is for
1), the router checks whether it has any TTZ LSAs. If it does not,
it issues an error to an operator (no TTZ to be rolled back) and
rejects the configuration at this time.
11.3. Adding a Router into TTZ 11.3. Adding a Router into TTZ
When a non TTZ router (say R1) is connected via a P2P link to a When a non TTZ router (say R1) is connected via a P2P link to a
migrated TTZ router (say T1), and there is a normal adjacency between migrated TTZ router (say T1), and there is a normal adjacency between
them over the link, a user can configure TTZ on both ends of the link them over the link, a user can configure TTZ on both ends of the link
to add R1 into the TTZ to which T1 belongs. They TTZ discover each to add R1 into the TTZ to which T1 belongs. They TTZ discover each
other as described in section 8. other as described in section 8.
When a number of non TTZ routers are connected via a broadcast or When a number of non TTZ routers are connected via a broadcast or
skipping to change at page 21, line 5 skipping to change at page 22, line 24
Section 11 (Operations) outlines the configuration process and Section 11 (Operations) outlines the configuration process and
deployment scenarios for a TTZ. The configurable item is enabling a deployment scenarios for a TTZ. The configurable item is enabling a
TTZ on a router and/or an interface on a router. The TTZ function TTZ on a router and/or an interface on a router. The TTZ function
may be controlled by a policy module and assigned a suitable user may be controlled by a policy module and assigned a suitable user
privilege level to enable. A suitable model may be required to privilege level to enable. A suitable model may be required to
verify the TTZ status on routers participating in the TTZ, including verify the TTZ status on routers participating in the TTZ, including
their role as internal or edge TTZ router. The mechanisms defined in their role as internal or edge TTZ router. The mechanisms defined in
this document do not imply any new liveness detection and monitoring this document do not imply any new liveness detection and monitoring
requirements in addition to those indicated in [RFC2328]. requirements in addition to those indicated in [RFC2328].
13. Prototype Implementation 13. Security Considerations
13.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 connected each
other. 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 advertised 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 advertised 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 OSPF 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 advertised to the
routers outside of the TTZ.
o The loopback addresses are accessible from a router outside of the
TTZ.
13.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 the end of July, 2014. 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, 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 where both the TTZ link and the normal link
exist, the TTZ link is used.
14. 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 OSPF protocols since a TTZ is enclosed in a security issues for OSPF since a TTZ is enclosed in a single area.
single area. TTZ relies on the OSPF security mechanisms in place and Of special concern in a TTZ is the ability of a malicious node to
has the same security threat surface. inject TTZ LSAs with the OP field set to M or R, which could trigger
the migration into/from a TTZ and may result in the isolation of some
routers in the network. A TTZ relies on authentication and other
existing OSPF security mechanisms [RFC2328] [RFC7474] to mitigate
this type of risk.
15. IANA Considerations 14. IANA Considerations
Under Registry Name: Opaque Link-State Advertisements (LSA) Option Under Registry Name: Opaque Link-State Advertisements (LSA) Option
Types [RFC5250], IANA is requested to assign a new Opaque type Types [RFC5250], IANA is requested to assign a new Opaque type
registry value for Topology-Transparent Zone (TTZ) LSA as follows: registry value for Topology-Transparent Zone (TTZ) LSA as follows:
+====================+===============+=======================+ +====================+===============+=======================+
| Registry Value | Opaque Type | reference | | Registry Value | Opaque Type | reference |
+====================+===============+=======================+ +====================+===============+=======================+
| IANA TBD | TTZ LSA | This document | | IANA TBD | TTZ LSA | This document |
| (9 Suggested) | | | | (9 Suggested) | | |
+--------------------+---------------+-----------------------+ +--------------------+---------------+-----------------------+
IANA is requested to assign Types for new TLVs in the new TTZ LSA as IANA is requested to assign Types for new TLVs in the new TTZ LSA as
follows: follows:
Type Name Allowed in Type Name Allowed in
1 TTZ ID TLV TTZ LSA of LS Type 10 and 9 1 TTZ ID TLV TTZ LSA of LS Type 10 and 9
2 TTZ Router TLV TTZ LSA of LS Type 10 2 TTZ Router TLV TTZ LSA of LS Type 10
3 TTZ Options TLV TTZ LSA of LS Type 10 and 9 3 TTZ Options TLV TTZ LSA of LS Type 10 and 9
16. Contributors and Other Authors 15. Contributors and Other Authors
1. Other Authors 1. Other Authors
Gregory Cauchie Gregory Cauchie
FRANCE FRANCE
Email: greg.cauchie@gmail.com Email: greg.cauchie@gmail.com
Anil Kumar S N Anil Kumar S N
Huawei Technologies
Banglore
India India
Email: anil.sn@huawei.com Email: anil.sn@huawei.com
Ning So Ning So
Tata Communications
2613 Fairbourne Cir.
Plano, TX 75082
USA USA
Email: ningso01@gmail.com Email: ningso01@gmail.com
Lei Liu Lei Liu
Fujitsu
USA USA
Email: lliu@us.fujitsu.com Email: lliu@us.fujitsu.com
2. Contributors 2. Contributors
Veerendranatha Reddy Vallem Veerendranatha Reddy Vallem
Huawei Technologies
Banglore
India India
Email: veerendranatharv@huawei.com Email: veerendranatharv@huawei.com
William McCall William McCall
Rightside Co.
Kirkland, WA
USA USA
will.mccall@rightside.co will.mccall@rightside.co
17. Acknowledgement 16. 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 Kiran Makhijani, Padmadevi Pillay Esnault and Yang Yu for their
valuable comments on this draft. valuable comments on this draft.
18. References 17. References
18.1. Normative References 17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/
RFC2328, April 1998, RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>. <http://www.rfc-editor.org/info/rfc2328>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <http://www.rfc-editor.org/info/rfc5250>. July 2008, <http://www.rfc-editor.org/info/rfc5250>.
18.2. Informative References [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<http://www.rfc-editor.org/info/rfc7474>.
[RFC4940] Kompella, K. and B. Fenner, "IANA Considerations for
OSPF", BCP 130, RFC 4940, DOI 10.17487/RFC4940, July 2007,
<http://www.rfc-editor.org/info/rfc4940>.
17.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>. <http://www.rfc-editor.org/info/rfc3630>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. <http://www.rfc-editor.org/info/rfc5440>.
Appendix A. Constants for LSA Advertisement Appendix A. Prototype Implementation
MaxLSAAdvTime: The maximum time for an LSA to be advertised to all A.1. What are Implemented and Tested
the routers in an area. The value of MaxLSAAdvTime is set to 0.1
second.
MaxLSAGenAdvTime: The maximum time for all TTZ router LSAs to be 1. CLI Commands for TTZ
generated by all TTZ edge routers and advertised to all the routers
in an area after a first TTZ router LSA is generated. The value of The CLIs implemented and tested include:
MaxLSAGenAdvTime is set to 0.3 second.
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 connected each
other. 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 advertised 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 advertised 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 OSPF 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 advertised to the
routers outside of the TTZ.
o The loopback addresses are accessible from a router outside of the
TTZ.
A.2. Implementation Experience
The implementation of TTZ re-uses the existing OSPF code along with
additional simple logic. A couple of engineers started to work on
implementing the TTZ from the middle of June, 2014 and finished
coding it just before the end of July, 2014. 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, 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 where both the TTZ link and the normal link
exist, the TTZ link is used.
Authors' Addresses Authors' Addresses
Huaimo Chen Huaimo Chen
Huawei Technologies Huawei Technologies
Boston, MA Boston, MA
USA USA
Email: huaimo.chen@huawei.com Email: huaimo.chen@huawei.com
Renwei Li Renwei Li
Huawei Technologies Huawei Technologies
2330 Central expressway 2330 Central expressway
Santa Clara, CA Santa Clara, CA
USA USA
Email: renwei.li@huawei.com Email: renwei.li@huawei.com
Alvaro Retana Alvaro Retana
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Raleigh, NC 27709 Raleigh, NC 27709
USA USA
Email: aretana@cisco.com Email: aretana@cisco.com
Yi Yang Yi Yang
Cisco Systems, Inc.
7025 Kit Creek Rd.
Raleigh, NC 27709
USA USA
Email: yiya@cisco.com Email: yyang1998@gmail.com
Vic Liu Vic Liu
China Mobile China Mobile
No.32 Xuanwumen West Street, Xicheng District No.32 Xuanwumen West Street, Xicheng District
Beijing, 100053 Beijing, 100053
China China
Email: liuzhiheng@chinamobile.com Email: liu.cmri@gmail.com
Mehmet Toy Mehmet Toy
Comcast Verizon
1800 Bishops Gate Blvd.
Mount Laurel, NJ 08054
USA USA
Email: mehmet_toy@cable.comcast.com Email: mtoy054@yahoo.com
 End of changes. 75 change blocks. 
245 lines changed or deleted 289 lines changed or added

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