< draft-ietf-ospf-2547-dnbit-03.txt		draft-ietf-ospf-2547-dnbit-04.txt >
	Network Working Group Eric C. Rosen		Network Working Group Eric C. Rosen
	Internet Draft Peter Psenak		Internet Draft Peter Psenak
	Expiration Date: July 2004 Cisco Systems, Inc.		Expiration Date: September 2004 Cisco Systems, Inc.
	Padma Pillay-Esnault		Padma Pillay-Esnault
	Juniper Networks, Inc.		Juniper Networks, Inc.
	January 2004		March 2004
	Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs		Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs
	draft-ietf-ospf-2547-dnbit-03.txt		draft-ietf-ospf-2547-dnbit-04.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document specifies a procedure that deals with a particular		This document specifies a procedure that deals with a particular
	issue that may arise when a Service Provider (SP) provides "BGP/MPLS		issue that may arise when a Service Provider (SP) provides "BGP/MPLS
	IP VPN" service to a customer, and the customer uses OSPF to		IP VPN" service to a customer, and the customer uses OSPFv2 to
	advertise its routes to the SP. In this situation, a Customer Edge		advertise its routes to the SP. In this situation, a Customer Edge
	(CE) Router and a Provider Edge (PE) Router are OSPF peers, and		(CE) Router and a Provider Edge (PE) Router are OSPF peers, and
	customer routes are sent via OSPF from the CE to the PE. The		customer routes are sent via OSPFv2 from the CE to the PE. The
	customer routes are converted into BGP routes, and BGP carries them		customer routes are converted into BGP routes, and BGP carries them
	across the backbone to other PE routers. The routes are then		across the backbone to other PE routers. The routes are then
	converted back to OSPF routes sent via OSPF to other CE routers. As		converted back to OSPF routes sent via OSPF to other CE routers. As
	a result of converting the routes from OSPF to BGP and back to OSPF,		a result of converting the routes from OSPF to BGP and back to OSPF,
	some of the information needed to prevent loops may be lost. A		some of the information needed to prevent loops may be lost. A
	procedure is needed to ensure that once a route is sent from a PE to		procedure is needed to ensure that once a route is sent from a PE to
	a CE, the route will be ignored by any PE which receives it back from		a CE, the route will be ignored by any PE which receives it back from
	a CE. This document specifies the necessary procedure, using one of		a CE. This document specifies the necessary procedure, using one of
	the options bits in the LSA (Link State Advertisements) to indicate		the options bits in the LSA (Link State Advertisements) to indicate
	that an LSA has already been forwarded by a PE, and should be ignored		that an LSA has already been forwarded by a PE, and should be ignored
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	Table of Contents		Table of Contents
	1 Specification of Requirements ........................ 2		1 Specification of Requirements ........................ 2
	2 Introduction ......................................... 2		2 Introduction ......................................... 2
	3 Information Loss and Loops ........................... 4		3 Information Loss and Loops ........................... 4
	4 Using the LSA Options to Prevent Loops ............... 5		4 Using the LSA Options to Prevent Loops ............... 5
	5 Security Considerations .............................. 5		5 Security Considerations .............................. 5
	6 Acknowledgments ...................................... 6		6 Acknowledgments ...................................... 6
	7 Authors' Addresses ................................... 6		7 Authors' Addresses ................................... 6
	8 Normative References ................................. 6		8 Normative References ................................. 7
	9 Intellectual Property ................................ 7		9 Intellectual Property Statement ...................... 7
	10 Full Copyright Statement ............................. 7		10 Full Copyright Statement ............................. 7
	1. Specification of Requirements		1. Specification of Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119.		document are to be interpreted as described in RFC 2119.
	2. Introduction		2. Introduction
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	the following two conditions hold:		the following two conditions hold:
	- each address prefix in the set can be reached via that CE		- each address prefix in the set can be reached via that CE
	- the path from that CE to each such address prefix does NOT		- the path from that CE to each such address prefix does NOT
	include the SP backbone (i.e., does not include any PE routers).		include the SP backbone (i.e., does not include any PE routers).
	The PE routers which attach to a particular VPN redistribute routes		The PE routers which attach to a particular VPN redistribute routes
	to these address prefixes into BGP, so that they can use BGP to		to these address prefixes into BGP, so that they can use BGP to
	distribute the VPN's routes to each other. BGP carries these routes		distribute the VPN's routes to each other. BGP carries these routes
	in the "VPN-IP address family", so that they are distinct from		in the "VPN-IPv4 address family", so that they are distinct from
	ordinary Internet routes. The VPN-IP address family also extends the		ordinary Internet routes. The VPN-IPv4 address family also extends
	IP addresses on the left so that address prefixes from two different		the IP addresses on the left so that address prefixes from two
	VPNs are always distinct to BGP, even if both VPNs use the same piece		different VPNs are always distinct to BGP, even if both VPNs use the
	of the private RFC1918 address space. Thus routes from different		same piece of the private RFC1918 address space. Thus routes from
	VPNs can be carried by a single BGP instance, and can be stored in a		different VPNs can be carried by a single BGP instance, and can be
	common BGP table, without fear of conflict.		stored in a common BGP table, without fear of conflict.
	If a PE router receives a particular VPN-IP route via BGP, and if		If a PE router receives a particular VPN-IPv4 route via BGP, and if
	that PE is attached to a CE in the VPN to which the route belongs,		that PE is attached to a CE in the VPN to which the route belongs,
	then BGP's decision process may install that route in the BGP route		then BGP's decision process may install that route in the BGP route
	table. If so, the PE translates the route back into an IP route, and		table. If so, the PE translates the route back into an IP route, and
	redistributes it to the routing protocol which is running on the link		redistributes it to the routing protocol which is running on the link
	to that CE.		to that CE.
	This methodology provides a "peer model"; CE routers peer with PE		This methodology provides a "peer model"; CE routers peer with PE
	routers, but CE routers at different sites do not peer with each		routers, but CE routers at different sites do not peer with each
	other.		other.
	If a VPN uses OSPF as its internal routing protocol, it is not		If a VPN uses OSPFv2 as its internal routing protocol, it is not
	necessarily the case that the CE routers of that VPN use OSPF to peer		necessarily the case that the CE routers of that VPN use OSPFv2 to
	with the PE routers. Each site in a VPN can use OSPF as its intra-		peer with the PE routers. Each site in a VPN can use OSPFv2 as its
	site routing protocol, while using, e.g., BGP or RIP to distribute		intra-site routing protocol, while using, e.g., BGP or RIP to
	routes to a PE router. However, it is certainly convenient, when		distribute routes to a PE router. However, it is certainly
	OSPF is being used intra-site, to use it on the PE-CE link as well,		convenient, when OSPFv2 is being used intra-site, to use it on the
	and [VPN] explicitly allows this. In this case, a PE will run a		PE-CE link as well, and [VPN] explicitly allows this. In this case,
	separate instance of OSPF for each VPN which is attached to the PE;		a PE will run a separate instance of OSPFv2 for each VPN which is
	the PE will in general have multiple VPN-specific OSPF routing		attached to the PE; the PE will in general have multiple VPN-specific
	tables.		OSPFv2 routing tables.
	When OSPF is used on a PE-CE link which belongs to a particular VPN,		When OSPFv2 is used on a PE-CE link which belongs to a particular
	the PE router must redistribute to that VPN's OSPF instance certain		VPN, the PE router must redistribute to that VPN's OSPFv2 instance
	routes which have been installed in the BGP routing table.		certain routes which have been installed in the BGP routing table.
	Similarly, a PE router must redistribute to BGP routes which have		Similarly, a PE router must redistribute to BGP routes which have
	been installed in the VPN-specific OSPF routing tables. Procedures		been installed in the VPN-specific OSPF routing tables. Procedures
	for this are specified in [VPN-OSPF].		for this are specified in [VPN-OSPF].
	The routes which are redistributed from BGP to OSPF are advertised in		The routes which are redistributed from BGP to OSPFv2 are advertised
	LSAs that are originated by the PE. The PE acts as an OSPF border		in LSAs that are originated by the PE. The PE acts as an OSPF border
	router, advertising some of these routes in AS-external LSAs, and		router, advertising some of these routes in AS-external LSAs, and
	some in summary LSAs, as specified in [VPN-OSPF].		some in summary LSAs, as specified in [VPN-OSPF].
	Similarly, when a PE router receives an LSA from a CE router, it runs		Similarly, when a PE router receives an LSA from a CE router, it runs
	the OSPF routing computation. Any route that gets installed in the		the OSPF routing computation. Any route that gets installed in the
	OSPF routing table must be translated into a VPN-IP route and then		OSPF routing table must be translated into a VPN-IPv4 route and then
	redistributed into BGP. BGP will then distribute these routes to the		redistributed into BGP. BGP will then distribute these routes to the
	other PE routers.		other PE routers.
	3. Information Loss and Loops		3. Information Loss and Loops
	A PE, say PE1, may learn a route to a particular VPN-IP address		A PE, say PE1, may learn a route to a particular VPN-IPv4 address
	prefix via BGP. This may cause it to generate a summary LSA or an		prefix via BGP. This may cause it to generate a summary LSA or an
	AS-external LSA in which it reports that address prefix. This LSA		AS-external LSA in which it reports that address prefix. This LSA
	may then be distributed to a particular CE, say CE1. The LSA may		may then be distributed to a particular CE, say CE1. The LSA may
	then be distributed throughout a particular OSPF area, reaching		then be distributed throughout a particular OSPF area, reaching
	another CE, say CE2. CE2 may then distribute the LSA to another PE,		another CE, say CE2. CE2 may then distribute the LSA to another PE,
	say PE2.		say PE2.
	As stated in the previous section, PE2 must run the OSPF routing		As stated in the previous section, PE2 must run the OSPF routing
	computation to determine whether a particular address prefix,		computation to determine whether a particular address prefix,
	reported in an LSA from CE2, is reachable from CE2 via a path which		reported in an LSA from CE2, is reachable from CE2 via a path which
	does not include any PE router. Unfortunately, there is no standard		does not include any PE router. Unfortunately, there is no standard
	way to do this. The OSPF LSAs do not necessarily carry the		way to do this. The OSPFv2 LSAs do not necessarily carry the
	information needed to enables PE2 to determine that the path to		information needed to enables PE2 to determine that the path to
	address prefix X in a particular LSA from CE2 is actually a path that		address prefix X in a particular LSA from CE2 is actually a path that
	includes, say, PE1. If PE2 then leaks X into BGP as a VPN-IP route,		includes, say, PE1. If PE2 then leaks X into BGP as a VPN-IPv4
	then PE2 is violating one of the constraints for loop-freedom in BGP,		route, then PE2 is violating one of the constraints for loop-freedom
	viz., that routes learned from a particular BGP domain not be		in BGP, viz., that routes learned from a particular BGP domain not be
	redistributed back into that BGP domain. This could cause a routing		redistributed back into that BGP domain. This could cause a routing
	loop to be created.		loop to be created.
	It is therefore necessary to have a means by which an LSA may carry		It is therefore necessary to have a means by which an LSA may carry
	the information that a particular address prefix has been learned		the information that a particular address prefix has been learned
	from a PE router. Any PE router which receives an LSA with this		from a PE router. Any PE router which receives an LSA with this
	information would omit the information in this LSA from its OSPF		information would omit the information in this LSA from its OSPF
	routing computation, and thus would not leak the information back		routing computation, and thus would not leak the information back
	into BGP.		into BGP.
	When a PE generates an AS-external LSA, it could use a distinct tag		When a PE generates an AS-external LSA, it could use a distinct tag
	value to indicate that the LSA is carrying information about an		value to indicate that the LSA is carrying information about an
	address prefix for whom the path includes a PE router. However, this		address prefix for whom the path includes a PE router. However, this
	method is not available in the case where the PE generates a Summary		method is not available in the case where the PE generates a Summary
	LSA. Per [OSPF-VPN], each PE router must function as an OSPF area 0		LSA. Per [VPN-OSPF], each PE router must function as an OSPF area 0
	router. If the PE-CE link is an area 0 link, then it is possible for		router. If the PE-CE link is an area 0 link, then it is possible for
	the PE to receive, over that link, a summary LSA which originated at		the PE to receive, over that link, a summary LSA which originated at
	another PE router. Thus we need some way of marking a summary LSA to		another PE router. Thus we need some way of marking a summary LSA to
	indicate that it is carrying information about a path via a PE		indicate that it is carrying information about a path via a PE
	router.		router.
	4. Using the LSA Options to Prevent Loops		4. Using the LSA Options to Prevent Loops
	The high-order bit of the LSA Options field (a previously unused bit)		The high-order bit of the LSA Options field (a previously unused bit)
	is used to solve the problem described in the previous section. We		is used to solve the problem described in the previous section. We
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	Options Field with DN Bit		Options Field with DN Bit
	(RFC 2328, Section A.2)		(RFC 2328, Section A.2)
	When the PE receives, from a CE router, a type 3, 5, or 7 LSA with		When the PE receives, from a CE router, a type 3, 5, or 7 LSA with
	the DN bit set, the information from that LSA MUST NOT be used during		the DN bit set, the information from that LSA MUST NOT be used during
	the OSPF route calculation. As a result, the LSA is not translated		the OSPF route calculation. As a result, the LSA is not translated
	into a BGP route. The DN bit MUST be ignored in all other LSA types.		into a BGP route. The DN bit MUST be ignored in all other LSA types.
	This prevents routes learned via BGP from being redistributed to BGP.		This prevents routes learned via BGP from being redistributed to BGP.
			(This restriction is analogous to the usual OSPF restriction that
			inter-area routes which are learned from area 0 are not passed back
			to area 0.)
	Note that the DN bit has no other effect on LSA handling. In		Note that the DN bit has no other effect on LSA handling. In
	particular, an LSA with the DN bit set will be put in the topological		particular, an LSA with the DN bit set will be put in the topological
	database, aged, flooded, etc., just as if DN was not set.		database, aged, flooded, etc., just as if DN were not set.
	5. Security Considerations		5. Security Considerations
	An attacker may cause the DN bit to be set, in an LSA traveling from		An attacker may cause the DN bit to be set, in an LSA traveling from
	CE to PE, when the DN bit should really be clear. This may cause the		CE to PE, when the DN bit should really be clear. This may cause the
	address prefixes mentioned in that LSA to be unreachable from other		address prefixes mentioned in that LSA to be unreachable from other
	sites of the VPN. Similarly, an attacker may cause the DN bit to be		sites of the VPN. Similarly, an attacker may cause the DN bit to be
	clear, in an LSA traveling in either direction, when the DN bit		clear, in an LSA traveling in either direction, when the DN bit
	should really be set. This may cause routing loops for traffic which		should really be set. This may cause routing loops for traffic which
	is destined to the address prefixes mentioned in that LSA.		is destined to the address prefixes mentioned in that LSA.
	These possibilities may be eliminated by using cryptographic		These possibilities may be eliminated by using cryptographic
	authentication as specified in section D of [OSPF].		authentication as specified in section D of [OSPFv2].
	6. Acknowledgments		6. Acknowledgments
	The idea of using the high-order options bit for this purpose is due		The idea of using the high-order options bit for this purpose is due
	to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this		to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this
	work. We also wish to thank Acee Lindem for his helpful comments.		work. We also wish to thank Acee Lindem for his helpful comments.
	7. Authors' Addresses		7. Authors' Addresses
	Eric C. Rosen		Eric C. Rosen
	skipping to change at page 6, line 37 ¶		skipping to change at page 7, line 7 ¶
	Padma Pillay-Esnault		Padma Pillay-Esnault
	Juniper Networks		Juniper Networks
	1194 N. Mathilda Avenue		1194 N. Mathilda Avenue
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	E-mail: padma@juniper.net		E-mail: padma@juniper.net
	8. Normative References		8. Normative References
	[OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998		[OSPFv2] "OSPF Version 2", RFC 2328, Moy, J., April 1998
	[VPN] "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen,		[VPN] "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen,
	Rekhter, et. al., September 2003		Rekhter, et. al., September 2003
	[OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-		[VPN-OSPF] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-
	ietf-l3vpn-ospf-2547-00.txt, Rosen, Psenak, Pillay-Esnault, June 2003		ietf-l3vpn-ospf-2547-01.txt, Rosen, Psenak, Pillay-Esnault, February
			2004
	9. Intellectual Property		9. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the procedures with respect to rights in RFC documents can be
	standards-related documentation can be found in BCP-11. Copies of		found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at ietf-
	Director.		ipr@ietf.org.
	10. Full Copyright Statement		10. Full Copyright Statement
	"Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). This document is subject
			to the rights, licenses and restrictions contained in BCP 78 and
	This document and translations of it may be copied and furnished to		except as set forth therein, the authors retain all their rights.
	others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 27 change blocks.
	74 lines changed or deleted		65 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/