< draft-ietf-ospf-ospfv2-hbit-00.txt		draft-ietf-ospf-ospfv2-hbit-01.txt >
	OSPF K. Patel		OSPF K. Patel
	Internet-Draft P. Pillay-Esnault		Internet-Draft Cisco Systems
	Intended status: Standards Track M. Bhardwaj		Intended status: Standards Track P. Pillay-Esnault
	Expires: April 20, 2016 S. Bayraktar		Expires: January 6, 2017 Huawei Technologies
			M. Bhardwaj
			S. Bayraktar
	Cisco Systems		Cisco Systems
	October 18, 2015		July 5, 2016
	H-bit Support for OSPFv2		H-bit Support for OSPFv2
	draft-ietf-ospf-ospfv2-hbit-00		draft-ietf-ospf-ospfv2-hbit-01
	Abstract		Abstract
	OSPFv3 defines an option field for router-LSAs known as a R-bit in		OSPFv3 defines an option field for router-LSAs known as a R-bit in
	RFC5340. If the R-bit is clear, an OSPFv3 router can participate in		RFC5340. If the R-bit is clear, an OSPFv3 router can participate in
	OSPF topology distribution without acting as a forwarder to forward		OSPF topology distribution without acting as a forwarder to forward
	the transit traffic. In such cases, an OSPF router would only accept		the transit traffic. In such cases, an OSPF router would only accept
	traffic intended for local delivery. This draft defines R-bit		traffic intended for local delivery. This draft defines R-bit
	functionality for OSPFv2 defined in RFC2328.		functionality for OSPFv2 defined in RFC2328.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 39 ¶
	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 20, 2016.		This Internet-Draft will expire on January 6, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
	3. H-bit Support . . . . . . . . . . . . . . . . . . . . . . . . 3		3. H-bit Support . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 4		4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 5
	5. Auto Discovery and Backwards Compatibility . . . . . . . . . 5		5. Auto Discovery and Backwards Compatibility . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 6		7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	10.1. Normative References . . . . . . . . . . . . . . . . . . 6		10.1. Normative References . . . . . . . . . . . . . . . . . . 6
	10.2. Informative References . . . . . . . . . . . . . . . . . 6		10.2. Informative References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	OSPFv3 [RFC5340] defines an option field for router-LSAs known as a		OSPFv3 [RFC5340] defines an option field for router-LSAs known as a
	R-bit. If the R-bit is clear, an OSPF router can participate in		R-bit. If the R-bit is clear, an OSPF router can participate in
	OSPFv3 topology distribution without acting as a forwarder to forward		OSPFv3 topology distribution without acting as a forwarder to forward
	the transit traffic. In such cases, an OSPF router would only accept		the transit traffic. In such cases, an OSPF router would only accept
	traffic intended for local delivery.		traffic intended for local delivery.
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 48 ¶
	the cost to an adjacent vertex. For		the cost to an adjacent vertex. For
	each described link, (say it joins		each described link, (say it joins
	vertex V to vertex W):		vertex V to vertex W):
	5. Auto Discovery and Backwards Compatibility		5. Auto Discovery and Backwards Compatibility
	To avoid the possibility of any routing loops due to partial		To avoid the possibility of any routing loops due to partial
	deployments, this draft defines a new OSPF Router Functional		deployments, this draft defines a new OSPF Router Functional
	Capability known as a Host Support Capability. The value of this		Capability known as a Host Support Capability. The value of this
	capability is a bit value to be assigned by IANA from OSPF Router		capability is a bit value to be assigned by IANA from OSPF Router
	Functional Capability Bits registry [I-D.ietf-ospf-rfc4970bis].		Functional Capability Bits registry [RFC7770] .
	The Auto Discovery via announcement of the Host Support Functional		The Auto Discovery via announcement of the Host Support Functional
	Capability ensures that the H-bit functionality and its associated		Capability ensures that the H-bit functionality and its associated
	SPF changes SHOULD only take effect if all the routers in a given		SPF changes SHOULD only take effect if all the routers in a given
	OSPF area support this functionality.		OSPF area support this functionality.
	Implementations are encouraged to provide a knob to manually override		Implementations are encouraged to provide a knob to manually override
	enforcement of the H-bit functionality in partial deployment		enforcement of the H-bit functionality in partial deployment
	scenarios for cases where the topology guarantees that the router		scenarios for cases where the topology guarantees that the router
	supporting the H-bit will not cause routing loops.		supporting the H-bit will not cause routing loops.
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 45 ¶
	Ward, Burjiz Pithawala and Michael Barnes for their comments.		Ward, Burjiz Pithawala and Michael Barnes for their comments.
	9. Change Log		9. Change Log
	Initial Version: April 23 2015		Initial Version: April 23 2015
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-ospf-rfc4970bis]
	Lindem, A., Shen, N., Vasseur, J., Aggarwal, R., and S.
	Shaffer, "Extensions to OSPF for Advertising Optional
	Router Capabilities", draft-ietf-ospf-rfc4970bis-07 (work
	in progress), October 2015.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/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,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,		DOI 10.17487/RFC2328, April 1998,
	<http://www.rfc-editor.org/info/rfc2328>.		<http://www.rfc-editor.org/info/rfc2328>.
	[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF		[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
	for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,		for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
	<http://www.rfc-editor.org/info/rfc5340>.		<http://www.rfc-editor.org/info/rfc5340>.
			[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
			S. Shaffer, "Extensions to OSPF for Advertising Optional
			Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
			February 2016, <http://www.rfc-editor.org/info/rfc7770>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-idr-bgp-optimal-route-reflection]		[I-D.ietf-idr-bgp-optimal-route-reflection]
	Raszuk, R., Cassar, C., Aman, E., Decraene, B., and S.		Raszuk, R., Cassar, C., Aman, E., Decraene, B., Litkowski,
	Litkowski, "BGP Optimal Route Reflection (BGP-ORR)",		S., and K. Wang, "BGP Optimal Route Reflection (BGP-ORR)",
	draft-ietf-idr-bgp-optimal-route-reflection-10 (work in		draft-ietf-idr-bgp-optimal-route-reflection-11 (work in
	progress), July 2015.		progress), January 2016.
	[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.		[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
	McPherson, "OSPF Stub Router Advertisement", RFC 6987,		McPherson, "OSPF Stub Router Advertisement", RFC 6987,
	DOI 10.17487/RFC6987, September 2013,		DOI 10.17487/RFC6987, September 2013,
	<http://www.rfc-editor.org/info/rfc6987>.		<http://www.rfc-editor.org/info/rfc6987>.
	Authors' Addresses		Authors' Addresses
	Keyur Patel		Keyur Patel
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95124 95134		San Jose CA 95134,
	USA		USA
	Email: keyupate@cisco.com		Email: keyupate@cisco.com
	Padma Pillay-Esnault		Padma Pillay-Esnault
	Cisco Systems		Huawei Technologies
	170 W. Tasman Drive		2330 Central Expressway
	San Jose, CA 95124 95134		Santa Clara, CA 95050
	USA		USA
	Email: ppe@cisco.com		Email: padma@huawei.com
	Manish Bhardwaj		Manish Bhardwaj
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95124 95134		San Jose, CA 95134
	USA		USA
	Email: manbhard@cisco.com		Email: manbhard@cisco.com
	Serpil Bayraktar		Serpil Bayraktar
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95124 95134		San Jose, CA 95134
	USA		USA
	Email: serpil@cisco.com		Email: serpil@cisco.com
End of changes. 17 change blocks.
	29 lines changed or deleted		29 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/