Network Working Group                                   Sina Mirtorabi
Internet Draft                                          Peter Psenak
Document: draft-mirtorabi-ospf-multi-area-adj-00.txt    Cisco Systems, Inc
Expiration Date: July 2004
                                                        Acee Lindem
                                                        Anand Oswal
                                                        Redback Networks

                                                        January 2004






                         OSPF Multi-Area Adjacency
                 draft-mirtorabi-ospf-multi-area-adj-00.txt






Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

Abstract

    This memo documents an extension to OSPF to allow a single physical
    link to be shared by multiple areas. This is necessary to allow the
    link to be considered an intra-area link in multiple areas.
    This would create an intra-area path to the corresponding areas
    sharing the same link.


Mirtorabi et al.                                                [Page 1]


Internet Draft           OSPF Multi-area adjacency          January 2004



Table of Contents

             Abstract ...............................................1
    1.       Motivation..............................................2
    2.       Possible Soultions .....................................2
    3.       Proposed Soultion ......................................3
    4.       Bringing up multi-area adjacencies .....................3
    5.       Neighbor discovery......................................3
    6.       Interface data structure................................3
    7.       Interface FSM...........................................3
    8.       Neighbor data structure and neighbor FSM................3
    9.       Advertising multi-area adjacencies .....................3
    10.      Compatibility Issues....................................4
    11.      Other Solutions.........................................4
    12.      Security................................................4
    13.      Acknowledgments.........................................4
    14.      Reference...............................................4
    15.      Authors' Addresses .....................................4


1.  Motivation

    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
    ABRs to create multi-area adjacencies belonging to different areas.

2.  Possible Solutions

    For numbered interfaces, the OSPF specification [OSPF] allows a
    separate OSPF interface to be configured in each area using a
    secondary address. The disadvantages of this approach are that
    it requires additional IP address configuration, doesn't apply to
    unnumbered interfaces, and advertising secondary addresses will
    result in a larger overall routing table.

    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 in multiple areas. Section 8.2. of the OSPF
    specification already specifies that the OSPF area ID should
    be used to de-multiplex received OSPF packets. One limitation
    of this approach is that multi-access networks are not supported.
    Although this limitation may be overcome for LAN media with
    support of "Point-to-Point operation over LAN in link-state
    routing protocols" [P2PLAN], it may not be acceptable to
    configure the link as unnumbered.


Mirtorabi et al.                                                [Page 2]


Internet Draft           OSPF Multi-area adjacency          January 2004



3.  Proposed Solution

    ABRs will simply establish multiple adjacencies belonging to different
    areas. Each multi-area adjacency is announced as a point-to-point
    unnumbered link in the configured area. This point-to-point link will
    provide a topological path for that area. The first or primary
    adjacency using the link will operate and advertise the link
    consistent with RFC 2328 [OSPF].

4. Bringing up multi-area adjacencies

   Multi-area adjacencies are configured between two routers having a
   common interface. On physical point-to-point networks, packets are
   sent to the AllSPFRouters address. For all other network types,
   packets are unicast to the remote neighbor's IP address.

5. Neighbor discovery

   On point-to-point networks, neighbor discovery is dynamic since Hello
   packets are sent to the AllSPFRouters address. For all other network
   types, one needs to configure remote neighbor IP address for the
   multi-area adjacency.

6. Interface data structure

   An OSPF interface data structure is built for each configured
   multi-area adjacency as specified in section 9 of OSPF [OSPF]. The
   interface type will always be point-to-point.

7. Interface FSM

   The interface FSM will be the same as a point-to-point link
   irrespective of the underlying physical link.

8. Neighbor data structure and neighbor FSM

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

9. Advertising multi-area adjacencies

   Multi-area adjacencis are announced as unnumbered point-to-point
   links. Once the router's secondary adjacency reaches the FULL state
   it will be added as a link type 1 to the Router LSA with:

   Link ID = remote's Router ID
   Link ID = IfIndex

   This will announce a topological path through the corresponding
   area.


Mirtorabi et al.                                                [Page 3]


Internet Draft           OSPF Multi-area adjacency          January 2004



10. Compatibility Issues

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

11. Other Solutions

    The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate
    mechanism which satisfies this requirement as well as others.

12. Security

   This document does not raise any security issues that are not
   already covered in [OSPF].

13. Acknowledgments

   The authors wish to acknowledge Pat Murphy for bringing focus
   to the requirement.

14. References

     [OSPF]   Moy, J., "OSPF Version 2", RFC 2328, April 1998.

     [P2PLAN] Shen, N., et al,  "Point-to-point operation over LAN in
              link-state routing protocols",
              draft-ietf-isis-igp-p2p-over-lan-01.txt,
              Work in progress.

     [OSPFTA] Mirtorabi, S., Psenak, P., Lindem, A., "OSPF Tunnel
              Adjacency", draft-mirtorabi-ospf-tunnel-adjacency-01.txt,
              Work in Progress.

15. Authors' Addresses

   Sina Mirtorabi                             Peter Psenak
   Cisco Systems                              Cisco Systems
   225 West Tasman drive                      Parc Pegasus, De Kleetlaan 6A
   San Jose, CA 95134                         1831 Diegem, Belgium
   e-mail: sina@cisco.com                     e-mail: ppsenak@cisco.com

   Acee Lindem                                Anand Oswal
   Redback Networks                           Redback Networks
   102 Carric Bend Court                      300 Holger Way
   Cary, NC 27519                             San Jose, CA  95134
   email: acee@redback.com                    e-mail: aoswal@redback.com


Mirtorabi et al.                                                [Page 4]