Subject: [OSPF] OSPF Multi-Area Adjacency - draft-ietf-ospf-multi-area-adj-06.txt

From: Acee Lindem <[email-masked]>
Date: Tue, 05 Sep 2006 16:35:29 -0400

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-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Tue, 12 Sep 2006 17:04:34 -0400

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:
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>