OSPF Hybrid Broadcast and P2MP Interface Type
draft-ietf-ospf-hybrid-bcast-and-p2mp-00

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

3.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, 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 3.2

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

3.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 SHOULD 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.

3.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 7, 2012                 [Page 7]
Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2011

3.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, it MUST NOT examine the
      pre-restart network LSA for the interface in order to determine
      the previous set of adjacencies.

   o  If a router is in state DROther on the interface, it MUST consider
      an adjacency to non-DR and non-BDR neighbors as reestablished when
      the neighbor state reaches 2-Way.

Sheth, et al.             Expires April 7, 2012                 [Page 8]
Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2011

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

Sheth, et al.             Expires April 7, 2012                 [Page 9]
Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2011

5.  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 7, 2012                [Page 10]
Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2011

6.  Security Considerations

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

Sheth, et al.             Expires April 7, 2012                [Page 11]
Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2011

7.  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 7, 2012                [Page 12]
Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2011

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

Sheth, et al.             Expires April 7, 2012                [Page 13]
Internet-Draft  OSPF Hybrid Broadcast and P2MP Intf Type    October 2011

Authors' Addresses

   Nischal Sheth
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: nsheth@juniper.net

   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 7, 2012                [Page 14]