draft-ietf-ospf-ttz-00.txt   draft-ietf-ospf-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 A. Kumar S N Intended status: Experimental A. Kumar S N
Expires: July 29, 2015 Huawei Technologies Expires: January 3, 2016 Huawei Technologies
G. Cauchie G. Cauchie
A. Retana A. Retana
Cisco Systems, Inc. Cisco Systems, Inc.
N. So N. So
Tata Communications Tata Communications
V. Liu V. Liu
China Mobile China Mobile
M. Toy M. Toy
Comcast Comcast
L. Liu L. Liu
UC Davis UC Davis
January 25, 2015 July 2, 2015
OSPF Topology-Transparent Zone OSPF Topology-Transparent Zone
draft-ietf-ospf-ttz-00.txt draft-ietf-ospf-ttz-01.txt
Abstract Abstract
This document presents a topology-transparent zone in a domain. A This document presents a topology-transparent zone in a domain. A
topology-transparent zone comprises a group of routers and a number 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
inside the zone is not distributed to any router outside of the zone. inside the zone is not distributed to any router outside of the zone.
Any link state change such as a link down inside the zone is not seen Any link state change such as a link down inside the zone is not seen
by any router outside of the zone. by any router outside of the zone.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 July 29, 2015. This Internet-Draft will expire on January 3, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 29 skipping to change at page 3, line 29
7.2. Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 12 7.2. Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 12
7.3. Adjacency between TTZ Edge and Router outside . . . . . . 13 7.3. Adjacency between TTZ Edge and Router outside . . . . . . 13
8. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 13 8. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 13
8.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 14 8.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 14
8.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 14 8.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 14
9. Computation of Routing Table . . . . . . . . . . . . . . . . . 14 9. Computation of Routing Table . . . . . . . . . . . . . . . . . 14
10. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 14 10.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 14
10.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 15 10.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 15
10.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 16 10.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 16
11. Prototype Implementation . . . . . . . . . . . . . . . . . . . 16 11. Prototype Implementation . . . . . . . . . . . . . . . . . . . 17
11.1. What are Implemented and Tested . . . . . . . . . . . . . 16 11.1. What are Implemented and Tested . . . . . . . . . . . . . 17
11.2. Implementation Experience . . . . . . . . . . . . . . . . 18 11.2. Implementation Experience . . . . . . . . . . . . . . . . 18
12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . . 19
16.2. Informative References . . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
skipping to change at page 16, line 10 skipping to change at page 16, line 10
work as a TTZ router, generates and distributes a TTZ control LSA work as a TTZ router, generates and distributes a TTZ control LSA
with M=1 (indicating Migrating to TTZ) after it receives the command. with M=1 (indicating Migrating to TTZ) after it receives the command.
After a router in the TTZ receives the TTZ control LSA with M=1, it After a router in the TTZ receives the TTZ control LSA with M=1, it
also transfers to work as a TTZ router. Thus, activating the TTZ on also transfers to work as a TTZ router. Thus, activating the TTZ on
one TTZ router makes every router in the TTZ transfer to work as a one TTZ router makes every router in the TTZ transfer to work as a
TTZ router, which flushes its normal router LSA and network LSAs, TTZ router, which flushes its normal router LSA and network LSAs,
computes routes through using the TTZ topology represented by TTZ computes routes through using the TTZ topology represented by TTZ
LSAs and the topology outside of the TTZ. LSAs and the topology outside of the TTZ.
The old normal LSAs should be flushed by TTZ routers after the
migration to TTZ is complete for some time such as one minute. A TTZ
router may determine if the migration to TTZ is complete through
checking whether it has received all the new TTZ LSAs and the LSAs
for virtualizing the TTZ. Optionally, it may just let the old normal
LSAs age out.
For an edge router of the TTZ, transferring to work as a TTZ router For an edge router of the TTZ, transferring to work as a TTZ router
comprises generating a router LSA to virtualize the TTZ and flooding comprises generating a router LSA to virtualize the TTZ and flooding
this LSA to all its neighboring routers. this LSA to all its neighboring routers.
Virtualizing the TTZ by an edge router should be done in two steps.
At first, the router updates its normal router LSA by adding a point-
to-point link to each of the other edge routers of the TTZ and a stub
link for each of the loopback addresses in the TTZ to be leaked. And
then it removes the links configured as TTZ links from its updated
router LSA after sending its updated router LSA and receiving the
updated router LSAs originated by the other TTZ edge routers for a
short time such as 0.1 second. Alternatively, it may remove the
links from its updated router LSA after sending the LSA for a short
time such as 0.3 second.
10.3. Adding a Router into TTZ 10.3. Adding a Router into TTZ
When a non TTZ router (say R1) is connected via a P2P link to a TTZ When a non TTZ router (say R1) is connected via a P2P link to a TTZ
router (say T1) working as TTZ and there is a normal adjacency router (say T1) working as TTZ and there is a normal adjacency
between them over the link, a user can configure TTZ on two ends of between them over the link, a user can configure TTZ on two ends of
the link to add R1 into the TTZ to which T1 belongs. They discover the link to add R1 into the TTZ to which T1 belongs. They discover
TTZ each other in the same way as described in section 7.1. TTZ each other in the same way as described in section 7.1.
When a number of non TTZ routers are connected via a broadcast link When a number of non TTZ routers are connected via a broadcast link
to a TTZ router (say T1) working as TTZ and there are normal to a TTZ router (say T1) working as TTZ and there are normal
skipping to change at page 19, line 42 skipping to change at page 20, line 11
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007. Router Capabilities", RFC 4970, July 2007.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
July 1998. OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
16.2. Informative References 16.2. Informative References
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 2009. Engineering Label Switched Paths", RFC 5441, April 2009.
 End of changes. 9 change blocks. 
9 lines changed or deleted 27 lines changed or added

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