Before the Montreal IETF, we re-last called this document as a standards
track based on the fact that we had two implementations in progress. The
draft-ietf-ospf-multi-area-adj-06.txt contains a few comments from that
last call.
Attached is a diff between the two versions (with most header only changes
filtered). Please let me know ASAP if you have any problems with the
changes.
Thanks,
Acee
*** draft-ietf-ospf-multi-area-adj-05.txt Thu Apr 13 15:37:36 2006
--- draft-ietf-ospf-multi-area-adj-06.txt Sun Jun 25 10:53:24 2006
***************
*** 3,18 ****
Network Working Group S. Mirtorabi
Internet-Draft P. Psenak
! Expires: October 15, 2006 Cisco Systems
A. Lindem (Editor)
Cisco Systems, Inc
A. Oswal
Cisco Systems
! April 13, 2006
OSPF Multi-Area Adjacency
! draft-ietf-ospf-multi-area-adj-05.txt
Status of this Memo
--- 3,18 ----
Network Working Group S. Mirtorabi
Internet-Draft P. Psenak
! Expires: December 25, 2006 Cisco Systems
A. Lindem (Editor)
Cisco Systems, Inc
A. Oswal
Cisco Systems
! June 23, 2006
OSPF Multi-Area Adjacency
! draft-ietf-ospf-multi-area-adj-06.txt
Status of this Memo
***************
*** 37,43 ****
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
! This Internet-Draft will expire on October 15, 2006.
Copyright Notice
--- 37,43 ----
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
! This Internet-Draft will expire on December 25, 2006.
Copyright Notice
***************
*** 76,81 ****
--- 76,82 ----
2.6 Neighbor Data Structure and Neighbor FSM . . . . . . . . . 5
2.7 Advertising Multi-Area Adjacencies . . . . . . . . . . . . 5
3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1 Adjacency Endpoint Compatibility . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
***************
*** 120,126 ****
There could be a requirement to have a link in multiple areas in
order to allow the link to be considered as an intra-area link in
multiple areas and be preferred over high cost intra-area paths. A
! simple example is to use a high speed backbone link between two Area
Border Routers (ABRS) to create multi-area adjacencies belonging to
different areas.
--- 120,126 ----
There could be a requirement to have a link in multiple areas in
order to allow the link to be considered as an intra-area link in
multiple areas and be preferred over high cost intra-area paths. A
! simple example is to use a high-speed backbone link between two Area
Border Routers (ABRS) to create multi-area adjacencies belonging to
different areas.
***************
*** 136,142 ****
Allowing a link with a single address to simply be configured in
multiple areas would also solve the problem. However, this would
result in the subnet corresponding to the interface residing in
! multiple areas which is contrary to the definition of an OSPF area as
a collection of subnets.
Another approach is to simply allow unnumbered links to be configured
--- 136,142 ----
Allowing a link with a single address to simply be configured in
multiple areas would also solve the problem. However, this would
result in the subnet corresponding to the interface residing in
! multiple areas that is contrary to the definition of an OSPF area as
a collection of subnets.
Another approach is to simply allow unnumbered links to be configured
***************
*** 160,165 ****
1.4 Other Solutions
The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate
! mechanism which satisfies this requirement as well as others.
--- 160,166 ----
1.4 Other Solutions
The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate
! mechanism that satisfies this requirement as well as others.
***************
*** 276,293 ****
! Mirtorabi, et al. Expires October 15, 2006 [Page 5]
! Internet-Draft OSPF Multi-Area Adjacency April 2006
Advertisement (LSA) with:
Link ID = Remote's Router ID
! Link Data = IfIndex
This will announce a topological path through the corresponding area.
--- 276,298 ----
! Mirtorabi, et al. Expires December 25, 2006 [Page 5]
! Internet-Draft OSPF Multi-Area Adjacency June 2006
Advertisement (LSA) with:
Link ID = Remote's Router ID
! Link Data = Neighbor's IP Address or IfIndex if underlying
! interface is unnumbered.
This will announce a topological path through the corresponding area.
+ While advertising the neighbor's IP address in the link data isn't
+ consistent with the unnumbered link model, it is required to
+ eliminate ambiguity when there are parallel point-to-point
+ adjacencies.
***************
*** 327,348 ****
!
!
!
!
! Mirtorabi, et al. Expires October 15, 2006 [Page 6]
!
! Internet-Draft OSPF Multi-Area Adjacency April 2006
3. Compatibility
! All mechanisms described in this document are backward-compatible
with standard OSPF implementations [OSPF].
--- 332,354 ----
+ Mirtorabi, et al. Expires December 25, 2006 [Page 6]
! Internet-Draft OSPF Multi-Area Adjacency June 2006
3. Compatibility
! All mechanisms described in this document are backward compatible
with standard OSPF implementations [OSPF].
+ 3.1 Adjacency Endpoint Compatibility
+ 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
+ adjacency to model the adjacency as a point-to-point link. However,
+ it will be cleaner from a deployment standpoint for both neighbors to
+ be configured as multi-area adjacencies.
***************
*** 624,632 ****
Thanks to Mitchell Erblich's for his last call review and comments.
! The RFC text was produced using Marshall Rose's xml2rfc tool.
!
--- 624,632 ----
Thanks to Mitchell Erblich's for his last call review and comments.
! Thanks to Padma Pillay-Esnault for her last call review and comments.
+ The RFC text was produced using Marshall Rose's xml2rfc tool.
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
