Bill, Ross,

We last called this as an informational draft, pulled it back due to an in-progress
implementation, re-last called it as a standards track document, and now we
feel it is ready for AD review.

Thanks,
Acee

Acee Lindem wrote:
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

_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf

Reply via email to