Internet Engineering Task Force H. Chen
Internet-Draft R. Li
Intended status: Informational Huawei Technologies
Expires: April 24, 2014 G. Cauchie
N. So
Tata Communications
V. Liu
China Mobile
M. Toy
Comcast
L. Liu
UC Davis
October 21, 2013
Requirements for OSPF Topology-Transparent Zone
draft-chen-ospf-ttz-req-00.txt
Abstract
This document presents a list of requirements for OSPF topology-
transparent zone in a domain. A topology-transparent zone comprises
a group of routers and a number of links connecting these routers.
Any router outside of the zone is not aware of the zone. The
information about the links and routers inside the zone is not
distributed to any router outside of the zone. Any link state change
such as a link down inside the zone is not seen by any router outside
of the zone.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright Notice
Chen, et al. Expires April 24, 2014 [Page 1]
Internet-Draft Requirements for TTZ October 2013
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Chen, et al. Expires April 24, 2014 [Page 2]
Internet-Draft Requirements for TTZ October 2013
1. Introduction
The number of routers in a network becomes larger and larger as the
Internet traffic keeps growing. Through splitting the network into
multiple areas, we can extend the network further. However, there
are a number of issues when a network is split further into more
areas.
At first, dividing an AS or an area into multiple areas is a very
challenging task since it is involved in significant network
architecture changes.
Secondly, it is complex for a Multi-Protocol Label Switching (MPLS)
Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple
areas to be setup. In one option, a TE path crossing multiple areas
is computed by using collaborating Path Computation Elements (PCEs)
[RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440],
which is not easy to configure by operators since the manual
configuration of the sequence of domains is required. Although this
issue can be addressed by using the Hierarchical PCE, this solution
may further increase the complexity of network design. Especially,
the current PCE standard method may not guarantee that the path found
is optimal.
Furthermore, some policies need to be configured on area border
routers for reducing the number of link states such as summary Link-
State Advertisements (LSAs) to be distributed to other routers in
other areas.
OSPF topology-transparent zone may resolve the issues above.
A topology-transparent zone comprises a group of routers and a number
of links connecting these routers. Any router outside of the zone is
not aware of the zone. The information about the links and routers
inside the zone is not distributed to any router outside of the zone.
Any link state change such as a link down inside the zone is not seen
by any router outside of the zone.
This document presents requirements for OSPF topology-transparent
zone.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Chen, et al. Expires April 24, 2014 [Page 3]
Internet-Draft Requirements for TTZ October 2013
3. Requirements
Topology-Transparent Zone (TTZ) may be deployed for resolving some
critical issues in existing networks and future networks. The
requirements for TTZ are listed as follows:
o TTZ MUST be backward compatible. When a TTZ is deployed on a set
of routers in a network, the routers outside of the TTZ in the
network do not need to know or support TTZ.
o A group of nodes in an existing network SHOULD be able to migrate
to a TTZ smoothly after the configuration of TTZ on these nodes is
activated.
o All the nodes in an existing TTZ SHOULD be able to migrate back to
their OSPF area smoothly after the configuration of TTZ on these
nodes is deleted.
o TTZ MUST support at least one more levels of network hierarchies,
in addition to the hierarchies supported by existing routing
protocols.
o Users SHOULD be able to easily set up an end to end service
crossing TTZs.
o The protections on the service crossing TTZs SHOULD be transparent
to TTZ.
o The configuration for a TTZ in a network SHOULD be minimum.
o The changes on the existing protocols for supporting TTZ SHOULD be
minimum.
4. Security Considerations
The mechanism described in this document does not raise any new
security issues.
5. IANA Considerations
6. Acknowledgement
7. References
Chen, et al. Expires April 24, 2014 [Page 4]
Internet-Draft Requirements for TTZ October 2013
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
7.2. Informative References
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
Authors' Addresses
Huaimo Chen
Huawei Technologies
Boston, MA
USA
Email: huaimo.chen@huawei.com
Renwei Li
Huawei Technologies
2330 Central expressway
Santa Clara, CA
USA
Email: renwei.li@huawei.com
Chen, et al. Expires April 24, 2014 [Page 5]
Internet-Draft Requirements for TTZ October 2013
Gregory Cauchie
FRANCE
Email: greg.cauchie@gmail.com
Ning So
Tata Communications
2613 Fairbourne Cir.
Plano, TX 75082
USA
Email: ning.so@tatacommunications.com
Vic Liu
China Mobile
No.32 Xuanwumen West Street, Xicheng District
Beijing, 100053
China
Email: liuzhiheng@chinamobile.com
Mehmet Toy
Comcast
1800 Bishops Gate Blvd.
Mount Laurel, NJ 08054
USA
Email: mehmet_toy@cable.comcast.com
Lei Liu
UC Davis
CA
USA
Email: liulei.kddi@gmail.com
Chen, et al. Expires April 24, 2014 [Page 6]