Network Working Group P. Pillay-Esnault Internet-Draft M. Barnes Intended status: Standards Track P. Wells Expires: September 2, 2010 Cisco Systems March 1, 2010 OSPFv2 No Transit Capability draft-pillay-esnault-ospf-rbit-00 Abstract Open Shortest Path First for IPv6 incorporates an R-bit in the router Link State Advertisement that controls whether or not other routers will compute transit paths through that node when they perform their Shortest Path First computation. This is a very useful feature of the protocol which is currently unavailable in Open Shortest Path First Version 2. This document extends the Open Shortest Path First Version 2 specification by adding a similar capability in a way that can safely coexist with implementations lacking this feature. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on September 2, 2010. Copyright Notice Pillay-Esnault, et al. Expires September 2, 2010 [Page 1] Internet-Draft OSPFv2 No Transit Capability March 2010 Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. New bits in the Router LSA . . . . . . . . . . . . . . . . . . 3 5. Advertising of local addresses in the Router LSA . . . . . . . 5 6. Modification in SPF calculation . . . . . . . . . . . . . . . . 5 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . . 6 11.2. Informative References . . . . . . . . . . . . . . . . . . 6 Pillay-Esnault, et al. Expires September 2, 2010 [Page 2] Internet-Draft OSPFv2 No Transit Capability March 2010 1. Introduction When OSPFv3 was first developed, a number of improvements were made over the existing OSPFv2 protocol. One of these was the addition of the R option bit in the router LSA to indicate whether the originator is an active router. If the "R-bit" is clear, an OSPF speaker can actively participate in the protocol without being used to forward transit traffic. There are a number of cases where this capability is very useful. For example, a multi-homed BGP route reflector may want to participate in routing, but should not be used to forward non-locally addressed packets. Note this is not the same capability provided by OSPF Stub Router Advertisement [RFC3137]. That technique can be used to make a node undesirable for transit traffic by increasing its cost, but other routers will still compute paths through it if no others are available. We presuppose familiarity with the contents of [RFC5340] and [RFC2328]. 2. Specification of Requirements 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 RFC 2119 [RFC2119]. 3. Requirements The benefits and considerations associated with deploying an OSPFv2 no-transit router are similar to those described in section 2.7 of [RFC5340]. In addition, a no-transit router should not be an Area Border Router or Autonomous System Boundary Router. 4. New bits in the Router LSA Two new bits are defined in the Router-LSA to define the support and state of the capability. The S-Bit is set to indicate that a router has the capability to process the R-bit. The R-bit is clear when a router is effectively functioning as a no-transit node. S/R possible settings 1/1 - Router has capability for no-transit and is transit 1/0 - Router has capability for no-transit and is no-transit 0/x - Router does not have no-transit capability and Pillay-Esnault, et al. Expires September 2, 2010 [Page 3] Internet-Draft OSPFv2 No Transit Capability March 2010 is always a transit router (backward compatibility) All routers implementing this capability MUST set the S-bit in their Router-LSAs. The R-bit SHOULD be set unless the router does not participate in any transit routing. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|R|S|N|W|V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | The OSPFv2 Router LSA with new R and S bits R-bit The "Router" bit indicates whether the originator is an active router. If the router bit is clear, then routes that transit the advertising node cannot be computed. Clearing the router bit would be appropriate for a multi-homed host that wants to participate in Pillay-Esnault, et al. Expires September 2, 2010 [Page 4] Internet-Draft OSPFv2 No Transit Capability March 2010 routing, but does not want to forward non- locally addressed packets. S-bit The "Support" bit indicates whether the originator can process the R-Bit. 5. Advertising of local addresses in the Router LSA When the R-bit is clear in the router-LSA: 1. All local addresses on the router are advertised as stub links in the router-LSA with a metric set to the interface output cost. 2. The cost of other links should be set to LSInfinity as defined in section 2 of [RFC3137]. 6. Modification in SPF calculation The step 2 in section 16.1 of [RFC2328] is modified as follows: Call the vertex just added to the tree vertex V. Examine the LSA associated with vertex V. This is a lookup in the Area A's link state database based on the Vertex ID. If this is a router-LSA, and bit V of the router-LSA (see Section A.4.2) is set, set Area A's TransitCapability to TRUE. In any case, each link described by the LSA gives the cost to an adjacent vertex. If all the router-LSAs in the area have the S-Bit set and vertex V is a router-LSA with R-bit clear and it is not the root, then all vertex V's links are ignored and the next vertex on the candidate list should be examined as described in Step 3. 7. Backward compatibility For the modification in the SPF processing defined in section 6 of this document to take effect, all routers in the area MUST have the S-bit set. When an area switches from being all S-bit capable routers to a mix of S-bit capable and non-capable, previous no-transit routers may now considered as potential transit nodes. Likewise, when a mixed area switches to being all S-bit capable, paths will no longer be computed through no-transit nodes. If a new router not supporting the R-Bit joins the area (S-bit clear): Pillay-Esnault, et al. Expires September 2, 2010 [Page 5] Internet-Draft OSPFv2 No Transit Capability March 2010 1. The new step defined in section 6 of this document will be ignored. 2. Any no-transit router with link cost set to LSInfinity will be treated like a stub router as defined in [RFC3137]. 8. IANA Considerations This document has no actions for IANA. 9. Security Considerations The new extensions defined in this document do not introduce any new security concerns other than those already defined in [RFC2328]. 10. Acknowledgments The authors would like to thank Liem Nguyen and Abhay Roy for their comments. This document was produced using Marshall Rose's xml2rfc tool. 11. References 11.1. 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", RFC 2328, April 1998. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. 11.2. Informative References [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", June 2001. Pillay-Esnault, et al. Expires September 2, 2010 [Page 6] Internet-Draft OSPFv2 No Transit Capability March 2010 Authors' Addresses Padma Pillay-Esnault Cisco Systems 510 McCarty Blvd Milpitas, CA 95035 USA EMail: ppe@cisco.com Michael Barnes Cisco Systems 510 McCarty Blvd Milpitas, CA 95035 USA EMail: mjbarnes@cisco.com Paul Wells Cisco Systems 510 McCarty Blvd Milpitas, CA 95035 USA EMail: pauwells@cisco.com Pillay-Esnault, et al. Expires September 2, 2010 [Page 7]