< draft-chen-ospf-ttz-app-04.txt		draft-chen-ospf-ttz-app-05.txt >
	Internet Engineering Task Force H. Chen		Internet Engineering Task Force H. Chen
	Internet-Draft R. Li		Internet-Draft R. Li
	Intended status: Informational Huawei Technologies		Intended status: Informational Huawei Technologies
	Expires: April 24, 2014 G. Cauchie		Expires: January 5, 2015 G. Cauchie
	N. So		N. So
	Tata Communications		Tata Communications
	V. Liu		V. Liu
	China Mobile		China Mobile
	L. Liu		L. Liu
	UC Davis		UC Davis
	October 21, 2013		July 4, 2014
	Applicability of OSPF Topology-Transparent Zone		Applicability of OSPF Topology-Transparent Zone
	draft-chen-ospf-ttz-app-04.txt		draft-chen-ospf-ttz-app-05.txt
	Abstract		Abstract
	This document discusses the applicability of "OSPF Topology-		This document discusses the applicability of "OSPF Topology-
	Transparent Zone". It briefs the protocol and its operations first,		Transparent Zone". It briefs the protocol and its operations first,
	and then illustrates the application scenarios of OSPF Topology-		and then illustrates the application scenarios of OSPF Topology-
	Transparent Zone. This document is intended for accompanying "OSPF		Transparent Zone. This document is intended for accompanying "OSPF
	Topology-Transparent Zone" to the Internet standards track.		Topology-Transparent Zone" to the Internet standards track.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 April 24, 2014.		This Internet-Draft will expire on January 5, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	2.1. Definitions of Topology-Transparent Zone . . . . . . . . . 3		2.1. Definitions of Topology-Transparent Zone . . . . . . . . . 3
	2.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 4		2.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 4
	3. Applicability of Topology-Transparent Zone . . . . . . . . . . 6		3. Applicability of Topology-Transparent Zone . . . . . . . . . . 6
	3.1. One Area Network . . . . . . . . . . . . . . . . . . . . . 6		3.1. One Area Network . . . . . . . . . . . . . . . . . . . . . 6
	3.1.1. Issues on Splitting Network into Areas . . . . . . . . 6		3.1.1. Issues on Splitting Network into Areas . . . . . . . . 6
	3.1.2. Use of TTZ in One Area Network . . . . . . . . . . . . 7		3.1.2. Use of TTZ in One Area Network . . . . . . . . . . . . 7
	3.2. Multi-Area Network . . . . . . . . . . . . . . . . . . . . 9		3.2. Multi-Area Network . . . . . . . . . . . . . . . . . . . . 9
	3.2.1. Issues on Splitting Network into More Areas . . . . . 9		3.2.1. Issues on Splitting Network into More Areas . . . . . 9
	3.2.2. Use of TTZ in Multi-Area Network . . . . . . . . . . . 10		3.2.2. Use of TTZ in Multi-Area Network . . . . . . . . . . . 10
	3.3. Use of TTZ on Routers in POP . . . . . . . . . . . . . . . 11		3.3. Use of TTZ on Routers in POP . . . . . . . . . . . . . . . 11
	3.4. Use of TTZ on Routers in IPRAN . . . . . . . . . . . . . . 12		3.4. Use of TTZ on Routers in IPRAN . . . . . . . . . . . . . . 11
	3.5. Use of TTZ on Routers from Same Vendor . . . . . . . . . . 12		3.5. Use of TTZ on Routers from Same Vendor . . . . . . . . . . 12
	3.6. Use of TTZ on Routers in a Power Saving Group . . . . . . 12		3.6. Use of TTZ on Routers in a Power Saving Group . . . . . . 12
	4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13		6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 13		7.2. Informative References . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The number of routers in a network becomes larger and larger as the		The number of routers in a network becomes larger and larger as the
	Internet traffic keeps growing. Through splitting the network into		Internet traffic keeps growing. Through splitting the network into
	multiple areas, we can extend the network further. However, there		multiple areas, we can extend the network further. However, there
	are a number of issues when a network is split further into more		are a number of issues when a network is split further into more
	areas.		areas.
	At first, dividing an AS or an area into multiple areas is a very		At first, dividing an AS or an area into multiple areas is a very
	challenging task since it is involved in significant network		challenging task since it is involved in significant network
	architecture changes.		architecture changes.
	Secondly, it is complex for a Multi-Protocol Label Switching (MPLS)		Secondly, the services carried by the network may be interrupted
			while the network is being split from one area into multiple areas or
			from a number of existing areas into even more areas.
			Moreover, it is complex for a Multi-Protocol Label Switching (MPLS)
	Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple		Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple
	areas to be setup. In one option, a TE path crossing multiple areas		areas to be setup. In one option, a TE path crossing multiple areas
	is computed by using collaborating Path Computation Elements (PCEs)		is computed by using collaborating Path Computation Elements (PCEs)
	[RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440],		[RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440],
	which is not easy to configure by operators since the manual		which is not easy to configure by operators since the manual
	configuration of the sequence of domains is required. Although this		configuration of the sequence of domains is required. Although this
	issue can be addressed by using the Hierarchical PCE, this solution		issue can be addressed by using the Hierarchical PCE, this solution
	may further increase the complexity of network design. Especially,		may further increase the complexity of network design. Especially,
	the current PCE standard method may not guarantee that the path found		the current PCE standard method may not guarantee that the path found
	is optimal.		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.
	This document introduces a technology called Topology-Transparent		This document introduces a technology called Topology-Transparent
	Zone (TTZ), presents a number of application scenarios of TTZ and		Zone (TTZ), presents a number of application scenarios of TTZ and
	illustrates that TTZ can resolve the issues above.		illustrates that TTZ can resolve the issues above.
	2. Overview of Topology-Transparent Zone		2. Overview of Topology-Transparent Zone
	This section briefs the concept of Topology-Transparent Zone (TTZ)		This section briefs the concept of Topology-Transparent Zone (TTZ)
	and explains the TTZ in some details through an example.		and explains the TTZ in some details through an example.
	2.1. Definitions of Topology-Transparent Zone		2.1. Definitions of Topology-Transparent Zone
	skipping to change at page 6, line 48 ¶		skipping to change at page 6, line 48 ¶
	transmission on the backbone area, and hence to all other area border		transmission on the backbone area, and hence to all other area border
	routers.		routers.
	Before splitting the network into areas, every router in the network		Before splitting the network into areas, every router in the network
	has the information about the network topology. However, after		has the information about the network topology. However, after
	splitting the network into areas, each router in an area has the		splitting the network into areas, each router in an area has the
	information of the topology of the area, and it does not have the		information of the topology of the area, and it does not have the
	information of the topology of any other area. It has only the		information of the topology of any other area. It has only the
	summary information about the other areas.		summary information about the other areas.
	2. Complex for MPLS TE Tunnel Setup		2. Service Interruptions
			The services carried by the network may be interrupted while the
			network is being split from one area into multiple areas.
			3. Complex for MPLS TE Tunnel Setup
	Each of the MPLS TE LSP tunnels originally in one area, which has its		Each of the MPLS TE LSP tunnels originally in one area, which has its
	ingress and egress in different areas after the network splitting,		ingress and egress in different areas after the network splitting,
	needs to be re-configured and re-established. It is very complex for		needs to be re-configured and re-established. It is very complex for
	a MPLS TE LSP tunnel crossing areas to be set up.		a MPLS TE LSP tunnel crossing areas to be set up.
	In order to reduce the manual configurations for a MPLS TE LSP tunnel		In order to reduce the manual configurations for a MPLS TE LSP tunnel
	crossing multiple areas, we use PCEs to compute the path for the		crossing multiple areas, we use PCEs to compute the path for the
	tunnel. Thus we must configure PCEs for the network split into		tunnel. Thus we must configure PCEs for the network split into
	multiple areas.		multiple areas.
	skipping to change at page 7, line 23 ¶		skipping to change at page 7, line 28 ¶
	In addition, we need to provide a sequence of areas for the tunnel		In addition, we need to provide a sequence of areas for the tunnel
	through manual configurations. The tunnel will go through the		through manual configurations. The tunnel will go through the
	sequence of areas provided.		sequence of areas provided.
	More critically, there are some issues on using PCEs. One of them is		More critically, there are some issues on using PCEs. One of them is
	that the path computed by PCEs for the tunnel may not be optimal. If		that the path computed by PCEs for the tunnel may not be optimal. If
	the optimal path for the tunnel is not in the sequence of areas		the optimal path for the tunnel is not in the sequence of areas
	configured by users, the path found by PCEs for the tunnel will not		configured by users, the path found by PCEs for the tunnel will not
	be optimal.		be optimal.
	3. Policy Configurations
	Some policies need to be applied on area border routers for reducing
	the number of link states such as summary LSAs to be distributed to
	other routers in other areas.
	On an ABR between a non backbone area (say area A) and the backbone
	area (say area B), there are four sets of policies, which may be
	configured. One set of them is the policies that block some summary
	LSA distributions from area B to area A. The second set of them is
	the policies that aggregate some routes for reducing the number of
	summary LSAs to be distributed from area B to area A. The third set
	is the policies that block some summary LSA distributions from area A
	to area B. The forth set of them is the policies that aggregate some
	routes for reducing the number of summary LSAs to be distributed to
	area A from area B.
	In addition, OSPF need to be disabled before any of the policy
	commands is issued. And then OSPF must be enabled after the policies
	are configured.
	3.1.2. Use of TTZ in One Area Network		3.1.2. Use of TTZ in One Area Network
	The issues mentioned above on splitting network into areas disappear		The issues mentioned above on splitting network into areas disappear
	if we do not split network into areas and use OSPF Topology		if we do not split network into areas and use OSPF Topology
	Transparent Zone (TTZ) instead.		Transparent Zone (TTZ) instead.
	TTZ may be applied to a group of routers and links in the network		TTZ may be applied to a group of routers and links in the network
	directly. For a group of routers and links connecting the routers in		directly. For a group of routers and links connecting the routers in
	the group in the network, no matter where it resides in the network,		the group in the network, no matter where it resides in the network,
	we may configure it as an OSPF TTZ as long as each router in the		we may configure it as an OSPF TTZ as long as each router in the
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 10 ¶
	Secondly, every router outside of the TTZ is not aware of the TZZ.		Secondly, every router outside of the TTZ is not aware of the TZZ.
	Even the router directly connecting to the TTZ is not aware of the		Even the router directly connecting to the TTZ is not aware of the
	TTZ.		TTZ.
	Furthermore, every router in the network still has a topology view of		Furthermore, every router in the network still has a topology view of
	the network. Except for those internal TTZ routers and links, which		the network. Except for those internal TTZ routers and links, which
	are hidden, every router outside of the TTZ has the link state		are hidden, every router outside of the TTZ has the link state
	information about all the routers and links in the network.		information about all the routers and links in the network.
	2. Easy for MPLS TE Tunnel Setup		2. No Service Interruption
			For a group of routers and a number of links connecting the routers
			in an area, they can transfer to work as a TTZ without any service
			interruptions.
			There is not any route change while these routers are migrating to
			work as a TTZ. Every router in the TTZ "sees" the same network
			topology (the TTZ topology and the topology outside of the TTZ) and
			uses it to compute the routes. Thus the routing table on the router
			will not change.
			For every router outside of the TTZ, its routing table will not
			change either while those routers are migrating to work as a TTZ.
			Even though there are some new router LSAs for virtualizing TTZ,
			these LSAs will not change any routes. Each link in any of these
			LSAs represents a shortest path between two TTZ edge routers within
			the TTZ.
			3. Easy for MPLS TE Tunnel Setup
	After a group of routers and links in the network is configured as an		After a group of routers and links in the network is configured as an
	OSPF TTZ, a MPLS TE LSP tunnel with an ingress router and an egress		OSPF TTZ, a MPLS TE LSP tunnel with an ingress router and an egress
	router, which are anywhere in the network, can be configured in a		router, which are anywhere in the network, can be configured in a
	way, which is the same as or similar to the way in which a MPLS TE		way, which is the same as or similar to the way in which a MPLS TE
	LSP tunnel in one area network is configured.		LSP tunnel in one area network is configured.
	For example, in the network in Figure 1 above, a MPLS TE LSP tunnel		For example, in the network in Figure 1 above, a MPLS TE LSP tunnel
	from ingress router R15 to egress router R29 can be configured in the		from ingress router R15 to egress router R29 can be configured in the
	same way as a MPLS TE LSP tunnel in one area network through		same way as a MPLS TE LSP tunnel in one area network through
	skipping to change at page 9, line 11 ¶		skipping to change at page 9, line 14 ¶
	For example, in the network in Figure 1 above, the constrained path		For example, in the network in Figure 1 above, the constrained path
	computed for the tunnel from ingress router R15 to egress router R29		computed for the tunnel from ingress router R15 to egress router R29
	may be from ingress router R15, to edge router R61 of TTZ 600, to		may be from ingress router R15, to edge router R61 of TTZ 600, to
	edge router R63 of TTZ 600 and then to egress router R29.		edge router R63 of TTZ 600 and then to egress router R29.
	As soon as the constrained path for a MPLS TE LSP tunnel is computed		As soon as the constrained path for a MPLS TE LSP tunnel is computed
	or given through configuration, the LSP can be established along the		or given through configuration, the LSP can be established along the
	path by the signaling protocol RSVP-TE.		path by the signaling protocol RSVP-TE.
	3. No Policy Configurations
	There is not any policy configuration for the use of TTZ in one area
	network. When we apply a TTZ to a group of routers and links
	connecting the routers, we just configure a TTZ link attribute TTZ ID
	on each of the links.
	3.2. Multi-Area Network		3.2. Multi-Area Network
	For a network with multiple areas, it typically needs to be split		For a network with multiple areas, it typically needs to be split
	into more areas when the size of the network becomes larger and		into more areas when the size of the network becomes larger and
	larger as the traffic in the network keeps growing.		larger as the traffic in the network keeps growing.
	3.2.1. Issues on Splitting Network into More Areas		3.2.1. Issues on Splitting Network into More Areas
	What would happen when we split a network with multiple areas into		What would happen when we split a network with multiple areas into
	even more areas?		even more areas?
	skipping to change at page 9, line 49 ¶		skipping to change at page 9, line 45 ¶
	number of routers and links to create new areas and make some of the		number of routers and links to create new areas and make some of the
	existing areas to become smaller. Some of the routers and links in a		existing areas to become smaller. Some of the routers and links in a
	new area may be from the backbone area, and the other from some of		new area may be from the backbone area, and the other from some of
	the non backbone areas.		the non backbone areas.
	In the network after splitting, there is still one backbone area,		In the network after splitting, there is still one backbone area,
	which must be changed and be surrounded by the new non backbone areas		which must be changed and be surrounded by the new non backbone areas
	and the existing non backbone areas some of which have been changed.		and the existing non backbone areas some of which have been changed.
	Each of the non backbone areas is connected to the backbone area.		Each of the non backbone areas is connected to the backbone area.
	2. More Configurations for Tunnel Setup		2. Service Interruptions
			The services carried by the network may be interrupted while the
			network is being split from a number of existing areas into even more
			areas.
			3. More Configurations for Tunnel Setup
	For reducing the manual configurations for a MPLS TE LSP tunnel		For reducing the manual configurations for a MPLS TE LSP tunnel
	crossing multiple areas, we use PCEs to compute the path for the		crossing multiple areas, we use PCEs to compute the path for the
	tunnel. Thus more configurations for tunnel setup is needed. We		tunnel. Thus more configurations for tunnel setup is needed. We
	must configure PCEs for each of the new areas and peer relations		must configure PCEs for each of the new areas and peer relations
	among the PCEs for the new areas and the PCEs for the existing areas.		among the PCEs for the new areas and the PCEs for the existing areas.
	3. More Policy Configurations
	More policy configurations may be needed. For each of the new non
	backbone areas and each of the existing non backbone areas that have
	been changed, some policies may need to be configured on the area
	border router connecting it to the backbone area to aggregate the
	routes in the non backbone area for transmission to the backbone
	area.
	3.2.2. Use of TTZ in Multi-Area Network		3.2.2. Use of TTZ in Multi-Area Network
	The issues described above on splitting network into even more areas		The issues described above on splitting network into even more areas
	disappear if we do not split network into more areas and use OSPF TTZ		disappear if we do not split network into more areas and use OSPF TTZ
	instead.		instead.
	A TTZ may be applied to a group of routers and links in any area in		A TTZ may be applied to a group of routers and links in any area in
	the network directly. For a group of routers and links connecting		the network directly. For a group of routers and links connecting
	the routers in the group in an area, no matter where it resides in		the routers in the group in an area, no matter where it resides in
	the area, we may configure it as an OSPF TTZ as long as each router		the area, we may configure it as an OSPF TTZ as long as each router
	skipping to change at page 10, line 49 ¶		skipping to change at page 10, line 41 ¶
	Secondly, every router outside of the TTZ is not aware of the TZZ.		Secondly, every router outside of the TTZ is not aware of the TZZ.
	Even the router directly connecting to the TTZ is not aware of the		Even the router directly connecting to the TTZ is not aware of the
	TTZ.		TTZ.
	Furthermore, every router in the area still has a topology view of		Furthermore, every router in the area still has a topology view of
	the area. Except for those internal TTZ routers and links, which are		the area. Except for those internal TTZ routers and links, which are
	hidden, every router outside of the TTZ has the link state		hidden, every router outside of the TTZ has the link state
	information about all the routers and links in the area.		information about all the routers and links in the area.
	2. No Extra Configurations for Tunnel Setup		2. No Service Interruption
			For a group of routers and a number of links connecting the routers
			in an area, they can transfer to work as a TTZ without any service
			interruptions.
			There is not any route change in the network while those routers are
			transferring to work as a TTZ.
			3. No Extra Configurations for Tunnel Setup
	After a group of routers and links in an area in the network is		After a group of routers and links in an area in the network is
	configured as an OSPF TTZ, there is not any extra configuration for		configured as an OSPF TTZ, there is not any extra configuration for
	supporting setup of a MPLS TE tunnel. We do not need to configure		supporting setup of a MPLS TE tunnel. We do not need to configure
	any new PCE since there is not any new area generated after applying		any new PCE since there is not any new area generated after applying
	a TTZ to a group of routers and links in an area.		a TTZ to a group of routers and links in an area.
	3. No More Policy Configurations
	The architecture of areas is not changed after applying a TTZ to a
	group of routers and links in an area. Thus there is no more policy
	configuration on the existing area border routers connecting existing
	non backbone areas to the existing backbone area to aggregate the
	routes in the non backbone area for transmission to the backbone area
	in general.
	3.3. Use of TTZ on Routers in POP		3.3. Use of TTZ on Routers in POP
	A Point of Presence (POP) comprises the routers in a room, a floor, a		A Point of Presence (POP) comprises the routers in a room, a floor, a
	building or a group of buildings. These routers are normally in an		building or a group of buildings. These routers are normally in an
	AS or OSPF area.		AS or OSPF area.
	We may increase the network scalability significantly through		We may increase the network scalability significantly through
	configuring a POP as an OSPF TTZ. When a POP becomes a TTZ, the link		configuring a POP as an OSPF TTZ. When a POP becomes a TTZ, the link
	state information about every link and every router inside the POP is		state information about every link and every router inside the POP is
	hidden from a router outside of the POP. Only very small amount of		hidden from a router outside of the POP. Only very small amount of
	skipping to change at page 12, line 48 ¶		skipping to change at page 12, line 38 ¶
	In a power saving group, when the usage of a link within the group		In a power saving group, when the usage of a link within the group
	between two routers crosses a given threshold value for shutting down		between two routers crosses a given threshold value for shutting down
	the link to save energy, the link will be shut down. This link down		the link to save energy, the link will be shut down. This link down
	in the power saving group will not be distributed to any router		in the power saving group will not be distributed to any router
	outside of the group. The traffic outside of the group will not be		outside of the group. The traffic outside of the group will not be
	affected by the link down inside the group.		affected by the link down inside the group.
	From the characteristics of a power saving group, we can see that a		From the characteristics of a power saving group, we can see that a
	power saving group is very suitable to be configured as a TTZ.		power saving group is very suitable to be configured as a TTZ.
	4. Limitations		4. Security Considerations
	A topology transparent zone is within an OSPF area. It can not be in
	more than one OSPF areas.
	A router may belong to a topology transparent zone. It can not
	belong to more than one topology transparent zones.
	5. Security Considerations
	This document does not introduce any new security issues.		This document does not introduce any new security issues.
	6. Contributors		5. Contributors
	Yuanbin Yin		Yuanbin Yin
	Huawei Technologies		Huawei Technologies
	Beijing,		Beijing,
	China		China
	Email: yinyuanbin@huawei.com		Email: yinyuanbin@huawei.com
	7. Acknowledgement		6. Acknowledgement
	The authors would like to thank Alvaro Retana, Acee Lindem, and Dean		The authors would like to thank Alvaro Retana, Acee Lindem, and Dean
	Cheng for their valuable comments on this draft.		Cheng for their valuable comments on this draft.
	8. References		7. References
	8.1. Normative References		7.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, 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.
	[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",		[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
	RFC 2740, December 1999.		RFC 2740, December 1999.
	8.2. Informative References		7.2. Informative References
	[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,		[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
	July 1998.		July 1998.
	[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,
	September 2003.		September 2003.
	[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's		[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
	Local Addresses in OSPF Traffic Engineering (TE)		Local Addresses in OSPF Traffic Engineering (TE)
	skipping to change at page 14, line 23 ¶		skipping to change at page 14, line 4 ¶
	Progress, July 2012.		Progress, July 2012.
	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
	Gregory Cauchie		Gregory Cauchie
	FRANCE		FRANCE
	Email: greg.cauchie@gmail.com		Email: greg.cauchie@gmail.com
	Ning So		Ning So
	Tata Communications		Tata Communications
	2613 Fairbourne Cir.		2613 Fairbourne Cir.
	Plano, TX 75082		Plano, TX 75082
	USA		USA
	Email: ning.so@tatacommunications.com		Email: ningso01@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: liuzhiheng@chinamobile.com
	Lei Liu		Lei Liu
	UC Davis		UC Davis
End of changes. 28 change blocks.
	87 lines changed or deleted		67 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/