idnits 2.17.1 draft-boutier-babel-source-specific-03.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 165: '...l implementation MUST choose routing t...' RFC 2119 keyword, line 179: '...l implementation MAY use them directly...' RFC 2119 keyword, line 182: '...cs, then the Babel implementation MUST...' RFC 2119 keyword, line 187: '...l implementation MUST silently ignore ...' RFC 2119 keyword, line 205: '...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 (July 03, 2017) is 2488 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 (if approved) IRIF, University of Paris-Diderot 5 Intended status: Standards Track July 03, 2017 6 Expires: January 4, 2018 8 Source-Specific Routing in Babel 9 draft-boutier-babel-source-specific-03 11 Abstract 13 This document describes an extension to the Babel routing protocol to 14 support source-specific routing. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 4, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. TODOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Introduction and background . . . . . . . . . . . . . . . . . 2 52 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3 54 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 3 55 3.3. The Table of Pending Requests . . . . . . . . . . . . . . 3 56 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 58 5.1. Source-specific messages . . . . . . . . . . . . . . . . 5 59 5.2. Route Acquisition . . . . . . . . . . . . . . . . . . . . 5 60 5.3. Wildcard retractions (update) . . . . . . . . . . . . . . 5 61 5.4. Wildcard requests . . . . . . . . . . . . . . . . . . . . 6 62 6. Compatibility with the base protocol . . . . . . . . . . . . 8 63 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 8 64 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8 65 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 9 67 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9 68 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 10 69 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 10 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 9. Security considerations . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 10.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. TODOs 79 o Source Prefix sub-TLV type: TBD 81 o check references (Section) for BABEL in 6126bis 83 o define wildcard Requests behaviour 85 2. Introduction and background 87 Source-specific routing (also known as Source Address Dependant 88 Routing, SAD Routing or SADR) is an extension to traditional next-hop 89 routing where packets are routed according to both their destination 90 and their source address. This document describes the source- 91 specific routing extension to the Babel routing protocol as defined 92 in 6126bis [BABEL]. 94 Background information about source-specific routing is provided in 95 [SS-ROUTING]. 97 3. Data Structures 99 This extension adds some data to the data structures maintained by a 100 Babel node. 102 3.1. The Source Table 104 Every Babel node maintains a source table, as described in [BABEL], 105 Section 3.2.5. A source-specific Babel node extends this table with 106 the following field: 108 o the source prefix (sprefix, splen) specifying the source address 109 of packets to which this entry applies. 111 If a source table entry has a zero length source prefix (splen equals 112 to 0), then the entry is a non-source-specific entry, and is treated 113 just like a source table entry defined by the original Babel 114 protocol. 116 With this extension the route entry contains a source which itself 117 contains a source prefix. These are two very different concepts, and 118 should not be confused. 120 3.2. The Route Table 122 Every Babel node maintains a route table, as described in [BABEL], 123 Section 3.2.6. With this extension, this table is indexed by the 124 5-tuple (prefix, plen, source prefix, source plen, router-id) 125 obtained from the associated source table entry. 127 If a route table entry has a zero length source prefix, then the 128 entry is a non-source-specific entry, and is treated just like a 129 route table entry defined by the original Babel protocol. 131 3.3. The Table of Pending Requests 133 Every Babel node maintains a table of pending requests, as described 134 in [BABEL], Section 3.2.7. A source-specific Babel node extends this 135 table with the following entry: 137 o the source prefix being requested. 139 4. Data Forwarding 141 In next-hop routing, if two routing table entries overlap, then one 142 is necessarily more specific than the other; the "longest prefix 143 rule" specifies that the most specific applicable routing table entry 144 is chosen. 146 With source-specific routing, there might no longer be a most 147 specific applicable prefix: two routing table entries might match a 148 given packet without one necessarily being more specific than the 149 other. Consider for example the following fragment of a routing 150 table: 152 (2001:DB8:0:1::/64, ::/0, A) 154 (::/0, 2001:DB8:0:2::/64, B) 156 This specifies that all packets with destination in 2001:DB8:0:1::/64 157 are to be routed through A, while packets with a source in 158 2001:DB8:0:2::/64 are to be routed through B. A packet with source 159 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules, 160 although neither is more specific than the other. A choice is 161 necessary, and unless the choice being made is the same on all 162 routers in a routing domain, persistent routing loops may occur. 163 More informations are available in [SS-ROUTING] Section IV.C. 165 A Babel implementation MUST choose routing table entries by using the 166 so-called destination-first ordering, where a routing table entry R1 167 is preferred to a routing table entry R2 when either R1's destination 168 prefix is more specific than R2's, or the destination prefixes are 169 equal and R1's source prefix is more specific than R2's. (In more 170 formal terms, routing table entries are compared using the 171 lexicographic product of the destination prefix ordering by the 172 source prefix ordering.) 174 In practice, this means that a source-specific Babel implementation 175 must take care that any lower layer that performs packet forwarding 176 obey this semantics. In particular: 178 o If the lower layers implement the destination-first ordering, then 179 the Babel implementation MAY use them directly; 181 o If the lower layers can hold source-specific routes, but not with 182 the right semantics, then the Babel implementation MUST 183 disambiguate the routing table by using a suitable disambiguation 184 algorithm (see [SS-ROUTING] Section V.B for such an algorithm); 186 o If the lower layers cannot hold source-specific routes, then a 187 Babel implementation MUST silently ignore (drop) any source- 188 specific routes. 190 5. Protocol Operation 192 This extension does not fundamentally change the operation of the 193 Babel protocol. We only describe the fundamental differences between 194 the original protocol and the extension in this section. The other 195 mechanisms described in [BABEL] (Section 3) are extended to pairs of 196 (destination, source) prefixes instead of just (destination) 197 prefixes. 199 5.1. Source-specific messages 201 Three messages are used to communicate informations on routes: 202 Updates, Route Requests and Seqno Requests. With this extension, 203 these messages carry an additionnal source prefix if (and only if) 204 the corresponding route is source-specific. More formally, an 205 Update, a Route Request and a Seqno Request MUST carry a source 206 prefix if they concern a source-specific route (non-zero length 207 source prefix) and MUST NOT carry a source prefix otherwise (zero 208 length source prefix). A message which carries a source prefix is 209 said to be source-specific. 211 5.2. Route Acquisition 213 When a non-source-specific Babel node receives a source-specific 214 update, it silently ignores it. 216 TODO{On receipt of a source-specific update (id, prefix, source 217 prefix, seqno, metric), a source-specific Babel node behaves as 218 described in [BABEL] Section 3.5.4 though indexing entries by (neigh, 219 id, prefix, source prefix).} When a source-specific Babel node 220 receives a non-source-specific update, it MUST treat this update as 221 carrying a zero length source prefix. 223 5.3. Wildcard retractions (update) 225 The original protocol defines a wildcard update with AE equals to 0 226 as being a wildcard retraction. A node receiving a wildcard 227 retraction on an interface must consider that the sending node 228 retracts all the routes it advertised on this interface. 230 Wildcard retractions are used when a node is about to leave the 231 network. Thus, this extension does not define source-specific 232 wildcard retraction, but extends wildcard retraction to apply also to 233 source-specific routes. More formally, a wildcard update MUST NOT 234 carry a source prefix, and a source-specific Babel node receiving a 235 (legacy) wildcard update MUST retracts all routes it learns from this 236 node (including source-specific ones). 238 5.4. Wildcard requests 240 TODO: behaviour to be defined. 242 5.4.1. Proposal 1 244 The original Babel protocol states that when a node receives a 245 wildcard route request, it SHOULD send a full routing table dump. 246 This extension does not change this statement: a source-specific node 247 SHOULD send a full routing table dump when receiving a wildcard 248 request. 250 Source-specific wildcard requests does not exist: a wildcard request 251 SHOULD NOT carry a source prefix. 253 5.4.2. Proposal 2 255 We assume that a mandatory sub-TLV has a corresponding non-mandatory 256 sub-TLV. This proposal is like Proposal 3 but instead of having 257 multiple wildcard request TLVs, one for each kind of route 258 understood, we use one wildcard request with sub-TLVs corresponding 259 to the extension. To have a full routing table dump, a node sends a 260 wildcard requests with a non-mandatory Source sub-TLV. 262 A source-specific node SHOULD always attach a non-mandatory Source 263 sub-TLV to its wildcard requests. 265 This proposal has been rejected because it implies to share the space 266 of non-mandatory and mandatory sub-TLVs. 268 5.4.3. Proposal 3 (mentionned by Juliusz) 270 The Babel protocol provides the ability to request a full routing 271 table dump by sending a "wildcard request", a route request with the 272 AE field set to 0. As the original protocol has no source-specific 273 routes, such a request may only concern non-source-specific routes. 274 This extension does not modify the semantics of wildcard requests in 275 that sense: a wildcard request prompts the receiver to send its non- 276 source-specific routes only, and a Babel node SHOULD NOT send any 277 source-specific updates in reply to a wildcard request. 279 To obtain a dump of the source-specific routes, a source-specific 280 wildcard request MUST be used. A source-specific wildcard request is 281 a wildcard request carrying a zero length source prefix. 283 When a node receives a source-specific wildcard request, it SHOULD 284 send a dump of its routes which are source-specific "only". It 285 SHOULD NOT send any non-source-specific routes in reply to a source- 286 specific wildcard request. It SHOULD NOT send any source-specific 287 routes which are under the effect of a future extension. Such 288 extension should detail how to handle the possible combinations. 290 In consequence, a node requiring a full routing table dump must send 291 both a non-source-specific wildcard request and a source-specific 292 wildcard request. 294 5.4.4. Proposal 4 (mentionned by Juliusz) 296 Wildcard requests are deprecated. Either deprecate it in 6126bis, or 297 say the following. 299 A node receiving a wildcard request SHOULD ignore it. 301 This proposal has been rejected because wildcard requests speeds up 302 the convergence of the network on boot. This is considered 303 important. 305 5.4.5. Proposal 5 (mentionned by David) 307 By default, a vanilla wildcard request triggers a dump of all non- 308 specific routes. We define a new non-mandatory sub-TLV on Route 309 Requests called "Requested Route Types" that contains an array of all 310 the types of routes this request is requesting. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type = TBD | Length | RR Type 1 | RR Type 2... 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 318 We also create a registry of Requested Route (RR) types, for example: 320 0 = Regular 322 1 = Source-Specific 324 2 = TOS-specific 326 etc. 328 A node receiving a Requested Route Types sub-TLV in a wildcard 329 request SHOULD sends back a dump of all its routes corresponding to 330 the requested types or to a combination of these types. 332 6. Compatibility with the base protocol 334 The protocol extension defined in this document is, to a great 335 extent, interoperable with the base protocol defined in [BABEL] (and 336 all its known extensions). More precisely, if non-source-specific 337 routers and source-specific routers are mixed in a single routing 338 domain, Babel's loop-avoidance properties are preserved, and, in 339 particular, no persistent routing loops will occur. 341 However, this extension is not compatible with the Experimental 342 Track's Babel Routing Protocol (RFC 6126). It requires the mandatory 343 sub-TLV introduced in [BABEL]. Consequently, this extension MUST NOT 344 be used with routers implementing RFC 6126, otherwise persistent 345 routing loops may occur. 347 6.1. Loop-avoidance 349 The extension defined in this protocol uses a new Mandatory sub-TLV 350 to carry the source prefix information. As discussed in Section 4.4 351 of [BABEL], this encoding ensures that non-source-specific routers 352 will silently ignore the whole TLV, which is necessary to avoid 353 persistent routing loops in hybrid networks. 355 Consider two nodes A and B, with A source-specific announcing a route 356 to (D, S). Suppose that B merely ignores the source prefix 357 information when it receives the update rather than ignoring the sub- 358 TLV, and reannounces the route as D. This reannouncement reaches A, 359 which treats it as (D, ::/0). Packets destined to D but not sourced 360 in S will be forwarded by A to B, and by B to A, causing a persistent 361 routing loop: 363 (D,S) (D) 364 <-- <-- 365 ------ A ----------------- B 366 --> 367 (D,::/0) 369 6.2. Starvation and Blackholes 371 In general, discarding source-specific routes by non-source-specific 372 routers will cause route starvation. Intuitively, unless there are 373 enough non-source-specific routes in the network, non-source-specific 374 routers will suffer starvation, and discard packets for destinations 375 that are only announced by source-specific routers. 377 A simple yet sufficient condition for avoiding starvation is to build 378 a connected source-specific backbone that includes all of the edge 379 routers, and announce a (non-source-specific) default route towards 380 the backbone. 382 7. Protocol Encoding 384 This extension defines a new sub-TLV used to carry a source prefix by 385 the three following existing messages: Update, Route Request and 386 Seqno Request. 388 7.1. Source Prefix sub-TLV 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type = TBD | Length | Source Plen | Source Prefix... 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 396 Fields: 398 Type Set to TBD to indicate a Source Prefix sub-TLV. 400 Length The length of the body, exclusive of the Type and Length 401 fields. 403 Source Plen The length of the advertised source prefix. This MUST 404 NOT be 0. 406 Source Prefix The source prefix being advertised. This field's size 407 is (Source Plen)/8 rounded upwards. 409 The Source Prefix field's encoding (AE) is the same as the Prefix's. 410 It is defined by the AE field of the corresponding TLV. 412 Note that this sub-TLV is a Mandatory sub-TLV. The whole TLV MUST be 413 ignored if that TLV is not recognized as described in Section 4.4. 414 Otherwise, routing loops may occur. 416 7.2. Source-specific Update 418 The source-specific Update is an Update TLV with a Source Prefix sub- 419 TLV. It advertises or retracts source-specific routes in the same 420 manner than routes with non-source-specific Updates (see [BABEL]). 421 This TLV MUST NOT be attached to wildcard updates. 423 Contrary to the destination prefix, this extension does not compress 424 the source prefix attached to Updates. The destination prefix uses 425 compression as defined in [BABEL] for Updates with Mandatory 426 extensions. 428 However, as defined in [BABEL] (Section 4.5), the compression is 429 allowed for the destination prefix of source-specific routes. Legacy 430 implementation will correctly update their parser state, while 431 ignoring the whole TLV afterwards. 433 7.3. Source-specific (Route) Request 435 TODO: A source-specific Route Request prompts the receiver to send an 436 update for a given pair of destination and source prefixes. It MUST 437 NOT be used to request a full routing table dump. The Source Prefix 438 sub-TLV of a wildcard source-specific Route Request (Request with AE 439 equals to 0 and a Source Prefix sub-TLV) MIGHT be ignored: a receiver 440 MIGHT reply by a full routing table dump. 442 7.4. Source-Specific Seqno Request 444 A source-specific Seqno Request is just like a Seqno Request for a 445 source-specific route. It uses the same mechanisms described in 446 [BABEL]. 448 8. IANA Considerations 450 IANA is instructed to add the following entry to the "Babel sub-TLV 451 Types" registry: 453 +------+---------------+-----------------+ 454 | Type | Name | Reference | 455 +------+---------------+-----------------+ 456 | TBD | Source Prefix | (this document) | 457 +------+---------------+-----------------+ 459 9. Security considerations 461 The extension defined in this document adds a new sub-TLV to three 462 TLVs already present in the original Babel protocol. It does not by 463 itself change the security properties of the protocol. 465 10. References 467 10.1. Normative References 469 [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet 470 Draft draft-ietf-babel-rfc6126bis-02, May 2017. 472 10.2. Informative References 474 [SS-ROUTING] 475 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 476 August 2014. 478 In Proc. IFIP Networking 2015. A slightly earlier 479 version is available online from http://arxiv.org/ 480 pdf/1403.0445. 482 Authors' Addresses 484 Matthieu Boutier 485 IRIF, University of Paris-Diderot 486 Case 7014 487 75205 Paris Cedex 13 488 France 490 Email: boutier@irif.fr 492 Juliusz Chroboczek 493 IRIF, University of Paris-Diderot 494 Case 7014 495 75205 Paris Cedex 13 496 France 498 Email: jch@irif.fr