idnits 2.17.1 draft-pillay-esnault-ospf-rbit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2010) is 5170 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pillay-Esnault 3 Internet-Draft M. Barnes 4 Intended status: Standards Track P. Wells 5 Expires: September 2, 2010 Cisco Systems 6 March 1, 2010 8 OSPFv2 No Transit Capability 9 draft-pillay-esnault-ospf-rbit-00 11 Abstract 13 Open Shortest Path First for IPv6 incorporates an R-bit in the router 14 Link State Advertisement that controls whether or not other routers 15 will compute transit paths through that node when they perform their 16 Shortest Path First computation. This is a very useful feature of 17 the protocol which is currently unavailable in Open Shortest Path 18 First Version 2. 20 This document extends the Open Shortest Path First Version 2 21 specification by adding a similar capability in a way that can safely 22 coexist with implementations lacking this feature. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 2, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. New bits in the Router LSA . . . . . . . . . . . . . . . . . . 3 67 5. Advertising of local addresses in the Router LSA . . . . . . . 5 68 6. Modification in SPF calculation . . . . . . . . . . . . . . . . 5 69 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 5 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 6 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 When OSPFv3 was first developed, a number of improvements were made 80 over the existing OSPFv2 protocol. One of these was the addition of 81 the R option bit in the router LSA to indicate whether the originator 82 is an active router. If the "R-bit" is clear, an OSPF speaker can 83 actively participate in the protocol without being used to forward 84 transit traffic. 86 There are a number of cases where this capability is very useful. 87 For example, a multi-homed BGP route reflector may want to 88 participate in routing, but should not be used to forward non-locally 89 addressed packets. 91 Note this is not the same capability provided by OSPF Stub Router 92 Advertisement [RFC3137]. That technique can be used to make a node 93 undesirable for transit traffic by increasing its cost, but other 94 routers will still compute paths through it if no others are 95 available. 97 We presuppose familiarity with the contents of [RFC5340] and 98 [RFC2328]. 100 2. Specification of Requirements 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 3. Requirements 108 The benefits and considerations associated with deploying an OSPFv2 109 no-transit router are similar to those described in section 2.7 of 110 [RFC5340]. In addition, a no-transit router should not be an Area 111 Border Router or Autonomous System Boundary Router. 113 4. New bits in the Router LSA 115 Two new bits are defined in the Router-LSA to define the support and 116 state of the capability. The S-Bit is set to indicate that a router 117 has the capability to process the R-bit. The R-bit is clear when a 118 router is effectively functioning as a no-transit node. 120 S/R possible settings 122 1/1 - Router has capability for no-transit and is transit 123 1/0 - Router has capability for no-transit and is no-transit 124 0/x - Router does not have no-transit capability and 125 is always a transit router (backward compatibility) 127 All routers implementing this capability MUST set the S-bit in their 128 Router-LSAs. The R-bit SHOULD be set unless the router does not 129 participate in any transit routing. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | LS age | Options | 1 | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Link State ID | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Advertising Router | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | LS sequence number | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | LS checksum | length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 |0|R|S|N|W|V|E|B| 0 | # links | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Link ID | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Link Data | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Type | # TOS | metric | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | ... | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | TOS | 0 | TOS metric | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Link ID | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Link Data | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | ... | 162 The OSPFv2 Router LSA with new R and S bits 164 R-bit 166 The "Router" bit indicates whether the originator is an active 167 router. If the router bit is clear, then routes that transit the 168 advertising node cannot be computed. Clearing the router bit would 169 be appropriate for a multi-homed host that wants to participate in 170 routing, but does not want to forward non- locally addressed packets. 172 S-bit 174 The "Support" bit indicates whether the originator can process the 175 R-Bit. 177 5. Advertising of local addresses in the Router LSA 179 When the R-bit is clear in the router-LSA: 181 1. All local addresses on the router are advertised as stub links in 182 the router-LSA with a metric set to the interface output cost. 184 2. The cost of other links should be set to LSInfinity as defined in 185 section 2 of [RFC3137]. 187 6. Modification in SPF calculation 189 The step 2 in section 16.1 of [RFC2328] is modified as follows: 191 Call the vertex just added to the tree vertex V. Examine the LSA 192 associated with vertex V. This is a lookup in the Area A's link state 193 database based on the Vertex ID. If this is a router-LSA, and bit V 194 of the router-LSA (see Section A.4.2) is set, set Area A's 195 TransitCapability to TRUE. In any case, each link described by the 196 LSA gives the cost to an adjacent vertex. 198 If all the router-LSAs in the area have the S-Bit set and vertex V is 199 a router-LSA with R-bit clear and it is not the root, then all vertex 200 V's links are ignored and the next vertex on the candidate list 201 should be examined as described in Step 3. 203 7. Backward compatibility 205 For the modification in the SPF processing defined in section 6 of 206 this document to take effect, all routers in the area MUST have the 207 S-bit set. 209 When an area switches from being all S-bit capable routers to a mix 210 of S-bit capable and non-capable, previous no-transit routers may now 211 considered as potential transit nodes. Likewise, when a mixed area 212 switches to being all S-bit capable, paths will no longer be computed 213 through no-transit nodes. 215 If a new router not supporting the R-Bit joins the area (S-bit 216 clear): 218 1. The new step defined in section 6 of this document will be 219 ignored. 221 2. Any no-transit router with link cost set to LSInfinity will be 222 treated like a stub router as defined in [RFC3137]. 224 8. IANA Considerations 226 This document has no actions for IANA. 228 9. Security Considerations 230 The new extensions defined in this document do not introduce any new 231 security concerns other than those already defined in [RFC2328]. 233 10. Acknowledgments 235 The authors would like to thank Liem Nguyen and Abhay Roy for their 236 comments. 238 This document was produced using Marshall Rose's xml2rfc tool. 240 11. References 242 11.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 249 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 250 for IPv6", RFC 5340, July 2008. 252 11.2. Informative References 254 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 255 McPherson, "OSPF Stub Router Advertisement", June 2001. 257 Authors' Addresses 259 Padma Pillay-Esnault 260 Cisco Systems 261 510 McCarty Blvd 262 Milpitas, CA 95035 263 USA 265 EMail: ppe@cisco.com 267 Michael Barnes 268 Cisco Systems 269 510 McCarty Blvd 270 Milpitas, CA 95035 271 USA 273 EMail: mjbarnes@cisco.com 275 Paul Wells 276 Cisco Systems 277 510 McCarty Blvd 278 Milpitas, CA 95035 279 USA 281 EMail: pauwells@cisco.com