idnits 2.17.1 draft-ietf-babel-source-specific-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 163: '...l implementation MUST choose routing t...' RFC 2119 keyword, line 176: '...l implementation MAY use them directly...' RFC 2119 keyword, line 178: '...cs, then the Babel implementation MUST...' RFC 2119 keyword, line 182: '...l implementation MUST silently ignore ...' RFC 2119 keyword, line 200: '...nd a Seqno Request MUST carry a source...' (20 more instances...) -- The draft header indicates that this document updates RFC6126bis, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 11, 2017) is 2450 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) == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boutier 3 Internet-Draft J. Chroboczek 4 Updates: 6126bis IRIF, University of Paris-Diderot 5 (if approved) August 11, 2017 6 Intended status: Standards Track 7 Expires: February 12, 2018 9 Source-Specific Routing in Babel 10 draft-ietf-babel-source-specific-00 12 Abstract 14 This document describes an extension to the Babel routing protocol to 15 support source-specific routing. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 12, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. TODOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction and background . . . . . . . . . . . . . . . . . 3 53 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 3 56 3.3. The Table of Pending Requests . . . . . . . . . . . . . . 4 57 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Source-specific messages . . . . . . . . . . . . . . . . . 5 60 5.2. Route Acquisition . . . . . . . . . . . . . . . . . . . . 5 61 5.3. Wildcard retractions (update) . . . . . . . . . . . . . . 6 62 5.4. Wildcard requests . . . . . . . . . . . . . . . . . . . . 6 63 6. Compatibility with the base protocol . . . . . . . . . . . . . 8 64 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . . 8 65 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 9 66 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 9 68 7.2. Source-specific Update . . . . . . . . . . . . . . . . . . 10 69 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 10 70 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 10 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 9. Security considerations . . . . . . . . . . . . . . . . . . . 11 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. TODOs 80 o Source Prefix sub-TLV type: TBD 81 o check references (Section) for BABEL in 6126bis 82 o define wildcard Requests behaviour 84 2. Introduction and background 86 Source-specific routing (also known as Source Address Dependant 87 Routing, SAD Routing or SADR) is an extension to traditional next-hop 88 routing where packets are routed according to both their destination 89 and their source address. This document describes the source- 90 specific routing extension to the Babel routing protocol as defined 91 in 6126bis [BABEL]. 93 Background information about source-specific routing is provided in 94 [SS-ROUTING]. 96 3. Data Structures 98 This extension adds some data to the data structures maintained by a 99 Babel node. 101 3.1. The Source Table 103 Every Babel node maintains a source table, as described in [BABEL], 104 Section 3.2.5. A source-specific Babel node extends this table with 105 the following field: 107 o the source prefix (sprefix, splen) specifying the source address 108 of packets to which this entry applies. 110 If a source table entry has a zero length source prefix (splen equals 111 to 0), then the entry is a non-source-specific entry, and is treated 112 just like a source table entry defined by the original Babel 113 protocol. 115 With this extension the route entry contains a source which itself 116 contains a source prefix. These are two very different concepts, and 117 should not be confused. 119 3.2. The Route Table 121 Every Babel node maintains a route table, as described in [BABEL], 122 Section 3.2.6. With this extension, this table is indexed by the 123 5-tuple (prefix, plen, source prefix, source plen, router-id) 124 obtained from the associated source table entry. 126 If a route table entry has a zero length source prefix, then the 127 entry is a non-source-specific entry, and is treated just like a 128 route table entry defined by the original Babel protocol. 130 3.3. The Table of Pending Requests 132 Every Babel node maintains a table of pending requests, as described 133 in [BABEL], Section 3.2.7. A source-specific Babel node extends this 134 table with the following entry: 136 o the source prefix being requested. 138 4. Data Forwarding 140 In next-hop routing, if two routing table entries overlap, then one 141 is necessarily more specific than the other; the "longest prefix 142 rule" specifies that the most specific applicable routing table entry 143 is chosen. 145 With source-specific routing, there might no longer be a most 146 specific applicable prefix: two routing table entries might match a 147 given packet without one necessarily being more specific than the 148 other. Consider for example the following fragment of a routing 149 table: 151 (2001:DB8:0:1::/64, ::/0, A) 152 (::/0, 2001:DB8:0:2::/64, B) 154 This specifies that all packets with destination in 2001:DB8:0:1::/64 155 are to be routed through A, while packets with a source in 2001:DB8: 156 0:2::/64 are to be routed through B. A packet with source 2001:DB8:0: 157 2::42 and destination 2001:DB8:0:1::57 matches both rules, although 158 neither is more specific than the other. A choice is necessary, and 159 unless the choice being made is the same on all routers in a routing 160 domain, persistent routing loops may occur. More informations are 161 available in [SS-ROUTING] Section IV.C. 163 A Babel implementation MUST choose routing table entries by using the 164 so-called destination-first ordering, where a routing table entry R1 165 is preferred to a routing table entry R2 when either R1's destination 166 prefix is more specific than R2's, or the destination prefixes are 167 equal and R1's source prefix is more specific than R2's. (In more 168 formal terms, routing table entries are compared using the 169 lexicographic product of the destination prefix ordering by the 170 source prefix ordering.) 171 In practice, this means that a source-specific Babel implementation 172 must take care that any lower layer that performs packet forwarding 173 obey this semantics. In particular: 175 o If the lower layers implement the destination-first ordering, then 176 the Babel implementation MAY use them directly; 177 o If the lower layers can hold source-specific routes, but not with 178 the right semantics, then the Babel implementation MUST 179 disambiguate the routing table by using a suitable disambiguation 180 algorithm (see [SS-ROUTING] Section V.B for such an algorithm); 181 o If the lower layers cannot hold source-specific routes, then a 182 Babel implementation MUST silently ignore (drop) any source- 183 specific routes. 185 5. Protocol Operation 187 This extension does not fundamentally change the operation of the 188 Babel protocol. We only describe the fundamental differences between 189 the original protocol and the extension in this section. The other 190 mechanisms described in [BABEL] (Section 3) are extended to pairs of 191 (destination, source) prefixes instead of just (destination) 192 prefixes. 194 5.1. Source-specific messages 196 Three messages are used to communicate informations on routes: 197 Updates, Route Requests and Seqno Requests. With this extension, 198 these messages carry an additionnal source prefix if (and only if) 199 the corresponding route is source-specific. More formally, an 200 Update, a Route Request and a Seqno Request MUST carry a source 201 prefix if they concern a source-specific route (non-zero length 202 source prefix) and MUST NOT carry a source prefix otherwise (zero 203 length source prefix). A message which carries a source prefix is 204 said to be source-specific. 206 5.2. Route Acquisition 208 When a non-source-specific Babel node receives a source-specific 209 update, it silently ignores it. 211 TODO{On receipt of a source-specific update (id, prefix, source 212 prefix, seqno, metric), a source-specific Babel node behaves as 213 described in [BABEL] Section 3.5.4 though indexing entries by (neigh, 214 id, prefix, source prefix).} When a source-specific Babel node 215 receives a non-source-specific update, it MUST treat this update as 216 carrying a zero length source prefix. 218 5.3. Wildcard retractions (update) 220 The original protocol defines a wildcard update with AE equals to 0 221 as being a wildcard retraction. A node receiving a wildcard 222 retraction on an interface must consider that the sending node 223 retracts all the routes it advertised on this interface. 225 Wildcard retractions are used when a node is about to leave the 226 network. Thus, this extension does not define source-specific 227 wildcard retraction, but extends wildcard retraction to apply also to 228 source-specific routes. More formally, a wildcard update MUST NOT 229 carry a source prefix, and a source-specific Babel node receiving a 230 (legacy) wildcard update MUST retracts all routes it learns from this 231 node (including source-specific ones). 233 5.4. Wildcard requests 235 TODO: behaviour to be defined. 237 5.4.1. Proposal 1 239 The original Babel protocol states that when a node receives a 240 wildcard route request, it SHOULD send a full routing table dump. 241 This extension does not change this statement: a source-specific node 242 SHOULD send a full routing table dump when receiving a wildcard 243 request. 245 Source-specific wildcard requests does not exist: a wildcard request 246 SHOULD NOT carry a source prefix. 248 5.4.2. Proposal 2 250 We assume that a mandatory sub-TLV has a corresponding non-mandatory 251 sub-TLV. This proposal is like Proposal 3 but instead of having 252 multiple wildcard request TLVs, one for each kind of route 253 understood, we use one wildcard request with sub-TLVs corresponding 254 to the extension. To have a full routing table dump, a node sends a 255 wildcard requests with a non-mandatory Source sub-TLV. 257 A source-specific node SHOULD always attach a non-mandatory Source 258 sub-TLV to its wildcard requests. 260 This proposal has been rejected because it implies to share the space 261 of non-mandatory and mandatory sub-TLVs. 263 5.4.3. Proposal 3 (mentionned by Juliusz) 265 The Babel protocol provides the ability to request a full routing 266 table dump by sending a "wildcard request", a route request with the 267 AE field set to 0. As the original protocol has no source-specific 268 routes, such a request may only concern non-source-specific routes. 269 This extension does not modify the semantics of wildcard requests in 270 that sense: a wildcard request prompts the receiver to send its non- 271 source-specific routes only, and a Babel node SHOULD NOT send any 272 source-specific updates in reply to a wildcard request. 274 To obtain a dump of the source-specific routes, a source-specific 275 wildcard request MUST be used. A source-specific wildcard request is 276 a wildcard request carrying a zero length source prefix. 278 When a node receives a source-specific wildcard request, it SHOULD 279 send a dump of its routes which are source-specific "only". It 280 SHOULD NOT send any non-source-specific routes in reply to a source- 281 specific wildcard request. It SHOULD NOT send any source-specific 282 routes which are under the effect of a future extension. Such 283 extension should detail how to handle the possible combinations. 285 In consequence, a node requiring a full routing table dump must send 286 both a non-source-specific wildcard request and a source-specific 287 wildcard request. 289 5.4.4. Proposal 4 (mentionned by Juliusz) 291 Wildcard requests are deprecated. Either deprecate it in 6126bis, or 292 say the following. 294 A node receiving a wildcard request SHOULD ignore it. 296 This proposal has been rejected because wildcard requests speeds up 297 the convergence of the network on boot. This is considered 298 important. 300 5.4.5. Proposal 5 (mentionned by David) 302 By default, a vanilla wildcard request triggers a dump of all non- 303 specific routes. We define a new non-mandatory sub-TLV on Route 304 Requests called "Requested Route Types" that contains an array of all 305 the types of routes this request is requesting. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Type = TBD | Length | RR Type 1 | RR Type 2... 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 314 We also create a registry of Requested Route (RR) types, for example: 316 0 = Regular 317 1 = Source-Specific 318 2 = TOS-specific 319 etc. 321 A node receiving a Requested Route Types sub-TLV in a wildcard 322 request SHOULD sends back a dump of all its routes corresponding to 323 the requested types or to a combination of these types. 325 6. Compatibility with the base protocol 327 The protocol extension defined in this document is, to a great 328 extent, interoperable with the base protocol defined in [BABEL] (and 329 all its known extensions). More precisely, if non-source-specific 330 routers and source-specific routers are mixed in a single routing 331 domain, Babel's loop-avoidance properties are preserved, and, in 332 particular, no persistent routing loops will occur. 334 However, this extension is not compatible with the Experimental 335 Track's Babel Routing Protocol (RFC 6126). It requires the mandatory 336 sub-TLV introduced in [BABEL]. Consequently, this extension MUST NOT 337 be used with routers implementing RFC 6126, otherwise persistent 338 routing loops may occur. 340 6.1. Loop-avoidance 342 The extension defined in this protocol uses a new Mandatory sub-TLV 343 to carry the source prefix information. As discussed in Section 4.4 344 of [BABEL], this encoding ensures that non-source-specific routers 345 will silently ignore the whole TLV, which is necessary to avoid 346 persistent routing loops in hybrid networks. 348 Consider two nodes A and B, with A source-specific announcing a route 349 to (D, S). Suppose that B merely ignores the source prefix 350 information when it receives the update rather than ignoring the sub- 351 TLV, and reannounces the route as D. This reannouncement reaches A, 352 which treats it as (D, ::/0). Packets destined to D but not sourced 353 in S will be forwarded by A to B, and by B to A, causing a persistent 354 routing loop: 356 (D,S) (D) 357 <-- <-- 358 ------ A ----------------- B 359 --> 360 (D,::/0) 362 6.2. Starvation and Blackholes 364 In general, discarding source-specific routes by non-source-specific 365 routers will cause route starvation. Intuitively, unless there are 366 enough non-source-specific routes in the network, non-source-specific 367 routers will suffer starvation, and discard packets for destinations 368 that are only announced by source-specific routers. 370 A simple yet sufficient condition for avoiding starvation is to build 371 a connected source-specific backbone that includes all of the edge 372 routers, and announce a (non-source-specific) default route towards 373 the backbone. 375 7. Protocol Encoding 377 This extension defines a new sub-TLV used to carry a source prefix by 378 the three following existing messages: Update, Route Request and 379 Seqno Request. 381 7.1. Source Prefix sub-TLV 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type = TBD | Length | Source Plen | Source Prefix... 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 389 Fields: 390 Type Set to TBD to indicate a Source Prefix sub-TLV. 391 Length The length of the body, exclusive of the Type and Length 392 fields. 393 Source Plen The length of the advertised source prefix. This MUST 394 NOT be 0. 395 Source Prefix The source prefix being advertised. This field's size 396 is (Source Plen)/8 rounded upwards. 398 The Source Prefix field's encoding (AE) is the same as the Prefix's. 399 It is defined by the AE field of the corresponding TLV. 401 Note that this sub-TLV is a Mandatory sub-TLV. The whole TLV MUST be 402 ignored if that TLV is not recognized as described in Section 4.4. 404 Otherwise, routing loops may occur. 406 7.2. Source-specific Update 408 The source-specific Update is an Update TLV with a Source Prefix sub- 409 TLV. It advertises or retracts source-specific routes in the same 410 manner than routes with non-source-specific Updates (see [BABEL]). 411 This TLV MUST NOT be attached to wildcard updates. 413 Contrary to the destination prefix, this extension does not compress 414 the source prefix attached to Updates. The destination prefix uses 415 compression as defined in [BABEL] for Updates with Mandatory 416 extensions. 418 However, as defined in [BABEL] (Section 4.5), the compression is 419 allowed for the destination prefix of source-specific routes. Legacy 420 implementation will correctly update their parser state, while 421 ignoring the whole TLV afterwards. 423 7.3. Source-specific (Route) Request 425 TODO: A source-specific Route Request prompts the receiver to send an 426 update for a given pair of destination and source prefixes. It MUST 427 NOT be used to request a full routing table dump. The Source Prefix 428 sub-TLV of a wildcard source-specific Route Request (Request with AE 429 equals to 0 and a Source Prefix sub-TLV) MIGHT be ignored: a receiver 430 MIGHT reply by a full routing table dump. 432 7.4. Source-Specific Seqno Request 434 A source-specific Seqno Request is just like a Seqno Request for a 435 source-specific route. It uses the same mechanisms described in 436 [BABEL]. 438 8. IANA Considerations 440 IANA is instructed to add the following entry to the "Babel sub-TLV 441 Types" registry: 443 +------+---------------+-----------------+ 444 | Type | Name | Reference | 445 +------+---------------+-----------------+ 446 | TBD | Source Prefix | (this document) | 447 +------+---------------+-----------------+ 449 9. Security considerations 451 The extension defined in this document adds a new sub-TLV to three 452 TLVs already present in the original Babel protocol. It does not by 453 itself change the security properties of the protocol. 455 10. References 457 10.1. Normative References 459 [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet 460 Draft draft-ietf-babel-rfc6126bis-02, May 2017. 462 10.2. Informative References 464 [SS-ROUTING] 465 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 466 August 2014. 468 In Proc. IFIP Networking 2015. A slightly earlier 469 version is available online from 470 http://arxiv.org/pdf/1403.0445. 472 Authors' Addresses 474 Matthieu Boutier 475 IRIF, University of Paris-Diderot 476 Case 7014 477 75205 Paris Cedex 13, 478 France 480 Email: boutier@irif.fr 482 Juliusz Chroboczek 483 IRIF, University of Paris-Diderot 484 Case 7014 485 75205 Paris Cedex 13, 486 France 488 Email: jch@irif.fr