< draft-acee-ospf-multi-instance-01.txt		draft-acee-ospf-multi-instance-02.txt >
	Network Working Group A. Lindem		Network Working Group A. Lindem
	Internet-Draft Redback Networks		Internet-Draft Redback Networks
	Intended status: Standards Track A. Roy		Intended status: Standards Track A. Roy
	Expires: August 17, 2008 Cisco Systems		Expires: March 25, 2009 Cisco Systems
	S. Mirtorabi		S. Mirtorabi
	Force10 Networks		Nuova Systems
	February 14, 2008		September 21, 2008
	OSPF Multi-Instance Extensions		OSPF Multi-Instance Extensions
	draft-acee-ospf-multi-instance-01.txt		draft-acee-ospf-multi-instance-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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."
	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.
	This Internet-Draft will expire on August 17, 2008.		This Internet-Draft will expire on March 25, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	OSPFv3 includes a mechanism for supporting multiple instances on the		OSPFv3 includes a mechanism for supporting multiple instances on the
	same link. OSPFv2 could benefit from such a mechanism in order to		same link. OSPFv2 could benefit from such a mechanism in order to
	support multiple routing domains on the same subnet. The OSPFv2		support multiple routing domains on the same subnet. The OSPFv2
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	OSPFv2 supports this capability using a separate subnet or the OSPF		OSPFv2 supports this capability using a separate subnet or the OSPF
	multi-area adjacency capability.		multi-area adjacency capability.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
	2. OSPFv2 Instance Packet Encoding . . . . . . . . . . . . . . . 4		2. OSPFv2 Instance Packet Encoding . . . . . . . . . . . . . . . 4
	3. OSPF Interface Instance ID . . . . . . . . . . . . . . . . . . 6		3. OSPF Interface Instance ID . . . . . . . . . . . . . . . . . . 6
	3.1. Sending and Receiving OSPF packets . . . . . . . . . . . . 6		3.1. Sending and Receiving OSPF packets . . . . . . . . . . . . 6
	4. Backward Compatibility and Deployment Considerations . . . . . 7		4. State Sharing Optimizations between OSPF instances . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Backward Compatibility and Deployment Considerations . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11		8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
			Intellectual Property and Copyright Statements . . . . . . . . . . 14
	1. Introduction		1. Introduction
	OSPFv3 [OSPFV3] includes a mechanism for supporting multiple		OSPFv3 [OSPFV3] includes a mechanism for supporting multiple
	instances on the same link. OSPFv2 [OSPFV2] could benefit from such		instances on the same link. OSPFv2 [OSPFV2] could benefit from such
	a mechanism in order to support multiple routing domains on the same		a mechanism in order to support multiple routing domains on the same
	subnet. The OSPFv2 instance ID is reserved for support of separate		subnet. The OSPFv2 instance ID is reserved for support of separate
	OSPFv2 protocol instances. This is different from OSPFv3 where it		OSPFv2 protocol instances. This is different from OSPFv3 where it
	could be used for other purposes such as putting the same link in		could be used for other purposes such as putting the same link in
	multiple areas. OSPFv2 supports this capability using a separate		multiple areas. OSPFv2 supports this capability using a separate
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	3.1. Sending and Receiving OSPF packets		3.1. Sending and Receiving OSPF packets
	When sending OSPF packets, if the interface instance ID has a non-		When sending OSPF packets, if the interface instance ID has a non-
	zero value, it will be set in the OSPF packet header. When receiving		zero value, it will be set in the OSPF packet header. When receiving
	OSPF packets, the OSPFv2 Header Instance ID will be used to aid in		OSPF packets, the OSPFv2 Header Instance ID will be used to aid in
	demultiplexing the packet and routing it to the correct OSPFv2		demultiplexing the packet and routing it to the correct OSPFv2
	instance. Received packets with an Instance ID not equal to one of		instance. Received packets with an Instance ID not equal to one of
	the configured OSPF Instance IDs on the receiving interface MUST be		the configured OSPF Instance IDs on the receiving interface MUST be
	discarded.		discarded.
	4. Backward Compatibility and Deployment Considerations		4. State Sharing Optimizations between OSPF instances
			This is beyond the scope of this draft and is an area for further
			study.
			5. Backward Compatibility and Deployment Considerations
	When there are OSPF routers that support this capability on the same		When there are OSPF routers that support this capability on the same
	broadcast capable link as those that do not, packets with non-zero		broadcast capable link as those that do not, packets with non-zero
	Instance IDs will be received by those legacy routers. Since the		Instance IDs will be received by those legacy routers. Since the
	authentication type will be unknown to them they will not process the		authentication type will be unknown to them they will not process the
	packet. This is exactly what is desired.		packet. This is exactly what is desired.
	Previously, a concern was that some implementations will log every		Previously, a concern was that some implementations will log every
	single authentication type mismatch. However, discussions with		single authentication type mismatch. However, discussions with
	implementers have led us to the conclusion that this is not as		implementers have led us to the conclusion that this is not as
	current a problem as we'd first thought and it will be even less of a		current a problem as we'd first thought and it will be even less of a
	problem by the time the mechanism in this draft is standardized,		problem by the time the mechanism in this draft is standardized,
	implemented, and deployed. Hence, the controversial mechanisms to		implemented, and deployed. Hence, the controversial mechanisms to
	avoid legacy routers receiving multicast OSPF packets with a non-zero		avoid legacy routers receiving multicast OSPF packets with a non-zero
	instance ID have been removed.		instance ID have been removed.
	5. Security Considerations		6. Security Considerations
	The enhancement described herein doesn't add any additional security		The enhancement described herein doesn't add any additional security
	considerations to OSPFv2. Security considerations for OSPFv2 are		considerations to OSPFv2. Security considerations for OSPFv2 are
	described in [OSPFV2].		described in [OSPFV2].
	Given that only three OSPFv2 authentication types have been		Given that only three OSPFv2 authentication types have been
	standardized, it seems reasonable to reduce the OSPF packet header		standardized, it seems reasonable to reduce the OSPF packet header
	field to 8 bits.		field to 8 bits.
	6. IANA Considerations		7. IANA Considerations
	A new registry will be added for OSPF Instance IDs. The allocation		A new registry will be added for OSPF Instance IDs. The allocation
	is TBD.		is TBD.
	Dependent on the approach, two new multicast addresses from the IPv4		Dependent on the approach, two new multicast addresses from the IPv4
	Multicast Addresses registry would need to be allocated.		Multicast Addresses registry would need to be allocated.
	Dependent on the approach, a new protocol ID may need to be allocated		Dependent on the approach, a new protocol ID may need to be allocated
	from the Protocol Numbers registry.		from the Protocol Numbers registry.
	7. Normative References		8. Normative References
	[MULTI-AREA]		[MULTI-AREA]
	Mirtorabi, S., Psenak, P., Lindem, A., and A. Oswal, "OSPF		Mirtorabi, S., Psenak, P., Lindem, A., and A. Oswal, "OSPF
	Multi-Area Adjacency",		Multi-Area Adjacency", RFC 5185, May 2008.
	draft-ietf-ospf-multi-area-adj-07.txt (work in progress).
	[OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.		[OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
	[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",		[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
	RFC 2740, April 2007.		for IPv6", RFC 5340, July 2008.
	[RFC-KEYWORDS]		[RFC-KEYWORDS]
	Bradner, S., "Key words for use in RFC's to Indicate		Bradner, S., "Key words for use in RFC's to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The RFC text was produced using Marshall Rose's xml2rfc tool.		The RFC text was produced using Marshall Rose's xml2rfc tool.
	Thanks to Paul Wells for commenting on the backward compatibility		Thanks to Paul Wells for commenting on the backward compatibility
	skipping to change at page 12, line 24 ¶		skipping to change at page 13, line 24 ¶
	Abhay Roy		Abhay Roy
	Cisco Systems		Cisco Systems
	225 West Tasman Drive		225 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: akr@cisco.com		Email: akr@cisco.com
	Sina Mirtorabi		Sina Mirtorabi
	Force10 Networks		Nuova Systems
	350 Holger Way		3 West Plumeria Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: sina@force10networks.com		Email: sina@nuovasystems.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
End of changes. 13 change blocks.
	23 lines changed or deleted		28 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/