Network Working Group                                           N. Sheth
Internet-Draft                                          Contrail Systems
Updates: 2328, 5340 (if approved)                                L. Wang
Intended status: Standards Track                                J. Zhang
Expires: April 20, 2013                                 Juniper Networks
                                                        October 17, 2012


             OSPF Hybrid Broadcast and P2MP Interface Type
              draft-ietf-ospf-hybrid-bcast-and-p2mp-06.txt

Abstract

   This document describes a mechanism to model a broadcast network as a
   hybrid of broadcast and point-to-multipoint networks for purposes of
   OSPF operation.  Neighbor discovery and maintenance as well as Link
   State Advertisement (LSA) database synchronization are performed
   using the broadcast model, but the network is represented using the
   point-to-multipoint model in the router LSAs of the routers connected
   to it.  This allows an accurate representation of the cost of
   communication between different routers on the network, while
   maintaining the network efficiency of broadcast operation.  This
   approach is relatively simple and requires minimal changes to OSPF.

   This document updates both OSPFv2 [RFC2328] and OSPFv3 [RFC5340].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 20, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Sheth, et al.            Expires April 20, 2013                 [Page 1]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Interface Parameters . . . . . . . . . . . . . . . . . . .  6
     4.2.  Neighbor Data Structure  . . . . . . . . . . . . . . . . .  6
     4.3.  Neighbor Discovery and Maintenance . . . . . . . . . . . .  6
     4.4.  Database Synchronization . . . . . . . . . . . . . . . . .  6
     4.5.  Generating Network LSAs  . . . . . . . . . . . . . . . . .  6
     4.6.  Generating Router and Intra-Area-Prefix-LSAs . . . . . . .  7
       4.6.1.  Stub Links in OSPFv2 Router LSA  . . . . . . . . . . .  7
       4.6.2.  OSPFv3 Intra-Area-Prefix-LSA . . . . . . . . . . . . .  7
     4.7.  Next-Hop Calculation . . . . . . . . . . . . . . . . . . .  7
     4.8.  Graceful Restart . . . . . . . . . . . . . . . . . . . . .  8
   5.  Compatibility Considerations . . . . . . . . . . . . . . . . .  9
   6.  Scalability and Deployment Considerations  . . . . . . . . . . 10
   7.  Management Considerations  . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
















Sheth, et al.            Expires April 20, 2013                 [Page 2]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


1.  Introduction

   OSPF [RFC2328] operation on broadcast interfaces takes advantage of
   the broadcast capabilities of the underlying medium for doing
   neighbor discovery and maintenance.  Further, it uses a Designated
   Router (DR) and Backup Designated Router (BDR) to keep the LSA
   databases of the routers on the network synchronized in an efficient
   manner.  However, it has the limitation that a router cannot
   advertise different costs to each of the neighboring routers on the
   network in its router LSA.

   Consider a radio network that supports true broadcast, yet the
   metrics between different pairs of terminals could be different for
   various reasons (e.g. different signal strength due to placement).
   When running OSPF over the radio network, for a router to advertise
   different costs to different neighbors, the interface must be treated
   as point-to-multipoint, even though the network has true broadcast
   capability.

   Operation on point-to-multipoint interfaces could require explicit
   configuration of the identity of neighboring routers.  It also
   requires the router to send separate hellos to each neighbor on the
   network.  Further, it mandates establishment of adjacencies to all
   configured or discovered neighbors on the network.  However, it gives
   the routers the flexibility to advertise different costs to each of
   the neighboring routers in their router LSAs.

   This document proposes a new interface type that can be used on
   networks that have broadcast capability.  In this mode, neighbor
   discovery and maintenance, as well as database synchronization are
   performed using existing procedures for broadcast mode.  The network
   is modeled as a collection of point-to-point links in the router LSA,
   just as it would be in point-to-multipoint mode.  This new interface
   type is referred to as hybrid-broadcast-and-p2mp in the rest of this
   document.
















Sheth, et al.            Expires April 20, 2013                 [Page 3]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Sheth, et al.            Expires April 20, 2013                 [Page 4]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


3.  Motivation

   There are some networks that are broadcast capable but have a
   potentially different cost associated with communication between any
   given pair of nodes.  The cost could be based on the underlying
   topology as well as various link quality metrics such as bandwidth,
   delay and jitter, among others.

   It is not accurate to treat such networks as OSPF broadcast networks
   since that does not allow a router to advertise a different cost to
   each of the other routers.  Using OSPF point-to-multipoint mode would
   satisfy the requirement to correctly describe the cost to reach each
   router.  However, it would be inefficient in the sense that it would
   require forming O(N^2) adjacencies when there are N routers on the
   network.

   It is advantageous to use the hybrid-broadcast-and-p2mp type for such
   networks.  This combines the flexibility of point-to-multipoint type
   with the advantages and efficiencies of broadcast interface type.
































Sheth, et al.            Expires April 20, 2013                 [Page 5]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


4.  Operation

   OSPF routers supporting the capabilities described herein should have
   support for an additional hybrid-broadcast-and-p2mp type for the Type
   data item described in section 9 of [RFC2328].

   The following sub-sections describe salient aspects of OSPF operation
   on routers configured with a hybrid-broadcast-and-p2mp interface.

4.1.  Interface Parameters

   The "Router Priority" interface parameter as specified in OSPFv2
   [RFC2328] and OSPFv3 [RFC5340] applies to a hybrid-broadcast-and-p2mp
   interface.

   The "LinkLSASuppression" interface parameter as specified in OSPFv3
   [RFC5340] applies to a hybrid-broadcast-and-p2mp interface.  The
   default value is "disabled".  It may be set to "enabled" via
   configuration.

4.2.  Neighbor Data Structure

   An additional field called the Neighbor Output is added to the
   neighbor data structure.  This is the cost of sending a data packet
   to the neighbor, expressed in the link state metric.  The default
   value of this field is the Interface output cost.  It may be set to a
   different value using mechanisms which are outside the scope of this
   document, like static per-neighbor configuration, or any dynamic
   discovery mechanism that is supported by the underlying network.

4.3.  Neighbor Discovery and Maintenance

   Routers send and receive Hellos so as to perform neighbor discovery
   and maintenance on the interface using the procedures specified for
   broadcast interfaces in [RFC2328] and [RFC5340].

4.4.  Database Synchronization

   Routers elect a DR and BDR for the interface and use them for initial
   and ongoing database synchronization using the procedures specified
   for broadcast interfaces in [RFC2328] and [RFC5340].

4.5.  Generating Network LSAs

   Since a hybrid-broadcast-and-p2mp interface is described in router
   LSAs using a collection of point-to-point links, the DR MUST NOT
   generate a network LSA for the interface.




Sheth, et al.            Expires April 20, 2013                 [Page 6]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


4.6.  Generating Router and Intra-Area-Prefix-LSAs

   Routers describe the interface in their router LSA as specified for a
   point-to-multipoint interface in section 12.4.1.4 of [RFC2328] and
   section 4.4.3.2 of [RFC5340], with the following modifications for
   Type 1 links:

   o  If a router is not the DR, it MUST NOT add any Type 1 links if it
      does not have a full adjacency to the DR.

   o  If a router is not the DR and has a full adjacency to the DR, and
      both the DR and this router agree on the DR role, it MUST add a
      Type 1 link corresponding to each neighbor that is in state 2-Way
      or higher and to which the DR's router LSA includes a link.

   o  The cost for a Type 1 link corresponding to a neighbor SHOULD be
      set to the value of the Neighbor Output Cost field as defined in
      Section 4.2

4.6.1.  Stub Links in OSPFv2 Router LSA

   Routers MUST add a Type 3 link for their own IP address to the router
   LSA as described in section 12.4.1.4 of [RFC2328].  Further, they
   MUST also add a Type 3 link with the Link ID set to the IP subnet
   address, Link Data set to the IP subnet mask, and cost equal to the
   configured output cost of the interface.

4.6.2.  OSPFv3 Intra-Area-Prefix-LSA

   Routers MUST add global scoped IPv6 addresses on the interface to the
   intra-area-prefix-LSA as described for point-to-multipoint interfaces
   in section 4.4.3.9 of [RFC5340].  In addition, they MUST also add all
   global scoped IPv6 prefixes on the interface to the LSA by specifying
   the PrefixLength, PrefixOptions, and Address Prefix fields.  The
   Metric field for each of these prefixes is set to the configured
   output cost of the interface.

   The DR MUST NOT generate an intra-area-prefix-LSA for the transit
   network for this interface since it does not generate a network LSA
   for the interface.  Note that the global prefixes associated with the
   interface are advertised in the intra-area-prefix-LSA for the router
   as described above.

4.7.  Next-Hop Calculation

   Next-Hops to destinations that are directly connected to a router via
   the interface are calculated as specified for a point-to-multipoint
   interface in section 16.1.1 of [RFC2328].



Sheth, et al.            Expires April 20, 2013                 [Page 7]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


4.8.  Graceful Restart

   The following modifications to the procedures defined in section 2.2,
   item 1 of [RFC3623] are required in order to ensure that the router
   correctly exits graceful restart.

   o  If a router is the DR on the interface, the pre-restart network
      LSA for the interface MUST NOT be used to determine the previous
      set of adjacencies.

   o  If a router is in state DROther on the interface, an adjacency to
      a non-DR or non-BDR neighbor is considered as reestablished when
      the neighbor state reaches 2-Way.






































Sheth, et al.            Expires April 20, 2013                 [Page 8]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


5.  Compatibility Considerations

   All routers on the network must support the hybrid-broadcast-and-p2mp
   interface type for successful operation.  Otherwise, the interface
   should be configured as a standard broadcast interface.

   If some routers on the network treat the interface as broadcast and
   others as hybrid-broadcast-and-p2mp, neighbors and adjacencies will
   still get formed as for a broadcast interface.  However, due to the
   differences in how router and network LSAs are built for these two
   interface types, there will be no traffic traversing certain pairs of
   routers.  Note that this will not cause any persistent loops or black
   holing of traffic.

   To detect and flag possible mismatched configurations, an
   implementation of this specification SHOULD log a message if a
   Network LSA is received for a locally configured hybrid interface.


































Sheth, et al.            Expires April 20, 2013                 [Page 9]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


6.  Scalability and Deployment Considerations

   Treating a broadcast interface as hybrid-broadcast-and-p2mp results
   in O(N^2) links to represent the network instead of O(N), when there
   are N routers on the network.  This will increase memory usage and
   have a negative impact on route calculation performance on all the
   routers in the area.  Network designers should carefully weigh the
   benefits of using the new interface type against the disadvantages
   mentioned here.










































Sheth, et al.            Expires April 20, 2013                [Page 10]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


7.  Management Considerations

   The following MIB variable/value should be added to the appropriate
   OSPFv2 and OSPFv3 MIBs ([RFC4750], [RFC5643]).

   o  For ospfIfType/ospfv3IfType, a new value broadcast-p2mp-hybrid (X)
      for the hybrid interface type (X to be defined when the revised
      MIB documents are approved).

   o  For ospfNbrEntry/ospfv3NbrEntry, an ospfNbrMetricValue/
      ospfv3NbrMetricValue attribute for per-neigbhor metrics.  In case
      of non-hybrid interfaces, the value is the same as the interface
      metric.

   This section is not normative.




































Sheth, et al.            Expires April 20, 2013                [Page 11]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


8.  Security Considerations

   This document raises no new security issues for OSPF.  Security
   considerations for the base OSPF protocol are covered in [RFC2328],
   [RFC5340], and [RFC6506].














































Sheth, et al.            Expires April 20, 2013                [Page 12]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


9.  IANA Considerations

   This document has no IANA considerations.

   This section should be removed by the RFC Editor to final
   publication.













































Sheth, et al.            Expires April 20, 2013                [Page 13]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


10.  Acknowledgements

   The authors would like to thank Acee Lindem and Richard Ogier for
   their comments and suggestions.















































Sheth, et al.            Expires April 20, 2013                [Page 14]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


11.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

   [RFC3623]  Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
              Restart", RFC 3623, November 2003.

   [RFC4750]  Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F.
              Baker, "OSPF Version 2 Management Information Base",
              RFC 4750, December 2006.

   [RFC5643]  Joyal, D. and V. Manral, "Management Information Base for
              OSPFv3", RFC 5643, August 2009.

   [RFC6506]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
              Authentication Trailer for OSPFv3", RFC 6506,
              February 2012.




























Sheth, et al.            Expires April 20, 2013                [Page 15]


Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2012


Authors' Addresses

   Nischal Sheth
   Contrail Systems
   2350 Mission College Blvd, #1140
   Santa Clara, CA  95054
   US

   Email: nsheth@contrailsystems.com


   Lili Wang
   Juniper Networks
   10 Technology Park Dr.
   Westford, MA  01886
   US

   Email: liliw@juniper.net


   Jeffrey Zhang
   Juniper Networks
   10 Technology Park Dr.
   Westford, MA  01886
   US

   Email: zzhang@juniper.net
























Sheth, et al.            Expires April 20, 2013                [Page 16]