Diff: draft-ietf-ospf-multi-area-adj-08.txt - draft-ietf-ospf-multi-area-adj-09.txt

	< draft-ietf-ospf-multi-area-adj-08.txt	draft-ietf-ospf-multi-area-adj-09.txt >

	Network Working Group S. Mirtorabi	Network Working Group S. Mirtorabi
	Internet-Draft Nuova Systems	Internet-Draft Nuova Systems
	Intended status: Standards Track P. Psenak	Intended status: Standards Track P. Psenak

	Expires: September 2, 2008 Cisco Systems	Expires: October 25, 2008 Cisco Systems
	A. Lindem (Editor)	A. Lindem (Editor)
	A. Oswal	A. Oswal
	Redback Networks	Redback Networks

	March 2008	April 23, 2008

	OSPF Multi-Area Adjacency	OSPF Multi-Area Adjacency

	draft-ietf-ospf-multi-area-adj-08.txt	draft-ietf-ospf-multi-area-adj-09.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 38 ¶	skipping to change at page 1, line 38 ¶
	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 September 2, 2008.	This Internet-Draft will expire on October 25, 2008.

	Copyright Notice	Copyright Notice

	Copyright (C) The IETF Trust (2008).	Copyright (C) The IETF Trust (2008).

	Abstract	Abstract

	This document describes an extension to the Open Shortest Path First	This document describes an extension to the Open Shortest Path First
	(OSPF) protocol to allow a single physical link to be shared by	(OSPF) protocol to allow a single physical link to be shared by
	multiple areas. This is necessary to allow the link to be considered	multiple areas. This is necessary to allow the link to be considered

	skipping to change at page 4, line 37 ¶	skipping to change at page 4, line 37 ¶
	operation over LAN in link-state routing protocols" [P2PLAN], it may	operation over LAN in link-state routing protocols" [P2PLAN], it may
	not be acceptable to configure the link as unnumbered due to network	not be acceptable to configure the link as unnumbered due to network
	management policies. Many popular network management applications	management policies. Many popular network management applications
	individually test the path to each interface and an IP address	individually test the path to each interface and an IP address
	facilitates this task.	facilitates this task.

	1.4. Proposed Solution	1.4. Proposed Solution

	ABRs will simply establish multiple adjacencies belonging to	ABRs will simply establish multiple adjacencies belonging to
	different areas. Each multi-area adjacency is announced as a point-	different areas. Each multi-area adjacency is announced as a point-

	to-point unnumbered link in the configured area. This point-to-point	to-point link in the configured area. However, unlike numbered
	link will provide a topological path for that area. The first or	point-to-point links, no type 3 link is advertised for multi-area
	primary adjacency using the link will operate and advertise the link	adjacencies. This point-to-point link will provide a topological
	in a manner consistent with RFC 2328 [OSPF].	path for that area. The first or primary adjacency using the link
		will operate and advertise the link in a manner consistent with RFC
		2328 [OSPF].

	2. Functional Specifications	2. Functional Specifications

	2.1. Multi-Area Adjacency Configuration and Neighbor Discovery	2.1. Multi-Area Adjacency Configuration and Neighbor Discovery

	Multi-area adjacencies are configured between two routers having a	Multi-area adjacencies are configured between two routers having a
	common interface. On point-to-point interfaces, there is no need to	common interface. On point-to-point interfaces, there is no need to
	configure the neighbor's address since there can be only one	configure the neighbor's address since there can be only one
	neighbor. For all other network types, the neighbor address of each	neighbor. For all other network types, the neighbor address of each
	multi-area adjacency must be configured or automatically discovered	multi-area adjacency must be configured or automatically discovered

	skipping to change at page 6, line 50 ¶	skipping to change at page 6, line 50 ¶
	The interface FSM will be the same as a point-to-point link	The interface FSM will be the same as a point-to-point link
	irrespective of the underlying physical link.	irrespective of the underlying physical link.

	2.6. Neighbor Data Structure and Neighbor FSM	2.6. Neighbor Data Structure and Neighbor FSM

	Both the neighbor data structure and neighbor FSM are the same as for	Both the neighbor data structure and neighbor FSM are the same as for
	standard OSPF, specified in section 10 of [OSPF].	standard OSPF, specified in section 10 of [OSPF].

	2.7. Advertising Multi-Area Adjacencies	2.7. Advertising Multi-Area Adjacencies


	Multi-area adjacencies are announced as unnumbered point-to-point	Multi-area adjacencies are announced as point-to-point links. Once
	links. Once the router's multi-area adjacency reaches the FULL state	the router's multi-area adjacency reaches the FULL state it will be
	it will be added as a link type 1 to the Router Link State	added as a link type 1 to the Router Link State Advertisement (LSA)
	Advertisement (LSA) with:	with:

	Link ID = Remote's Router ID	Link ID = Remote's Router ID

	Link Data = Neighbor's IP Address or IfIndex (if the underlying	Link Data = Neighbor's IP Address or IfIndex (if the underlying
	interface is unnumbered).	interface is unnumbered).


	This will announce a topological path through the corresponding area.	Unlike numbered point-to-point links, no type 3 link is advertised
	While advertising the neighbor's IP address in the link data isn't	for multi-area adjacencies.
	consistent with the unnumbered link model, it is required to
	eliminate ambiguity when there are parallel point-to-point
	adjacencies.

	3. Compatibility	3. Compatibility

	All mechanisms described in this document are backward compatible	All mechanisms described in this document are backward compatible
	with standard OSPF implementations [OSPF].	with standard OSPF implementations [OSPF].

	3.1. Adjacency Endpoint Compatibility	3.1. Adjacency Endpoint Compatibility

	Since multi-area adjacencies are modeled as unnumbered point-to-point	Since multi-area adjacencies are modeled as unnumbered point-to-point
	links, it is only necessary for the router at the other end of the	links, it is only necessary for the router at the other end of the

	skipping to change at page 13, line 21 ¶	skipping to change at page 13, line 21 ¶

	Thanks to Padma Pillay-Esnault for her last call review and comments.	Thanks to Padma Pillay-Esnault for her last call review and comments.
	Also thanks to Padma for comments on the OSPFv3 applicability section	Also thanks to Padma for comments on the OSPFv3 applicability section
	that was last called separately.	that was last called separately.

	Thanks to Nischal Seth for pointing out that the document	Thanks to Nischal Seth for pointing out that the document
	inadvertently precluded point-to-point over LAN interfaces.	inadvertently precluded point-to-point over LAN interfaces.

	Thanks to Ben Campbell for performing the General Area Review.	Thanks to Ben Campbell for performing the General Area Review.


		Thanks to Jari Arkko for comments during the IESG review.

	The RFC text was produced using Marshall Rose's xml2rfc tool.	The RFC text was produced using Marshall Rose's xml2rfc tool.

	Authors' Addresses	Authors' Addresses

	Sina Mirtorabi	Sina Mirtorabi
	Nuova Systems	Nuova Systems
	3 West Plumeria Drive	3 West Plumeria Drive
	San Jose, CA 95134	San Jose, CA 95134
	USA	USA


End of changes. 8 change blocks.
	17 lines changed or deleted	18 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/