idnits 2.17.1 draft-baker-fun-routing-class-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 abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2011) is 4681 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational July 1, 2011 5 Expires: January 2, 2012 7 Routing a Traffic Class 8 draft-baker-fun-routing-class-00 10 Abstract 12 This note addresses the concept of routing a traffic class. This has 13 many possible implementations, IGP and BGP, and link state as well as 14 distance vector. The fundamental impetus is the question raised in 15 RFC 3704 and shim6 of exit routing, the question raised by Mike 16 O'Dell of source/destination routing, and the "fish" problem, raised 17 in many networks, in which distinct traffic classes that could 18 conceivably use the same route predictably use different routes. 19 Instead of handling these as "destination routing with a twist", the 20 paper looks at the matter systemically. 22 Requirements 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 2, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Structure of the paper . . . . . . . . . . . . . . . . . . 3 65 2. The fundamental concept of routing a class . . . . . . . . . . 3 66 2.1. Define: "traffic class" . . . . . . . . . . . . . . . . . 4 67 2.2. Define: "metric" . . . . . . . . . . . . . . . . . . . . . 5 68 2.3. Define: "route announcement" . . . . . . . . . . . . . . . 5 69 2.4. Route Precedence . . . . . . . . . . . . . . . . . . . . . 7 70 3. Sketch of a distance vector implementation . . . . . . . . . . 8 71 4. Sketch of a link state implementation . . . . . . . . . . . . 10 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 This note addresses the concept of routing a traffic class. This has 84 many possible implementations, IGP and BGP, and link state as well as 85 distance vector. The fundamental impetus is the question raised in 86 [RFC3704] and shim6 of exit routing, the question raised by Mike 87 O'Dell of source/destination routing, and the "fish" problem, raised 88 in many networks, in which distinct traffic classes that could 89 conceivably use the same route predictably use different routes. 90 Instead of handling these as "destination routing with a twist", the 91 paper looks at the matter systemically. 93 1.1. Scope 95 The question of implementation of IPv4 or IPv6 routes is moot; the 96 algorithms discussed here can be used for either. Examples, however, 97 will be drawn from IPv6 [RFC2460] and will presume its addressing 98 architecture [RFC4291]. 100 1.2. Structure of the paper 102 The paper looks first at the fundamental concept in Section 2. It 103 then goes on to imagine an IS-IS-like [RFC5308] [RFC6119] 104 implementation. Unfortunately, this really can't be implemented in 105 IS-IS by adding a TLV, which is our usual approach, due to the 106 changed concept of a metric. However, given the changed concepts of 107 a metric and a TLV, it shows how the same exchange and calculation 108 algorithms can be used to build such a routing protocol. It also 109 looks at a RIP-like [RFC2080] algorithm that includes a sequence 110 number (derived from AODV [RFC3561]) to simplify count-to-infinity- 111 related problems. It stops short of a BGP implementation, although 112 one modeled on the distance vector model would make sense. 114 2. The fundamental concept of routing a class 116 This section introduces the fundamental concepts involved in routing 117 a traffic class. These include the definitions of 119 o a "traffic class", which is a set-theoretic definition - all 120 traffic matching a constraint, 122 o a "metric", which is an administrative number applied to a class 123 of traffic crossing an interface, and 125 o a "route announcement", which is the accumulation of information 126 regarding the routing of a traffic class as modified by various 127 metrics en route. 129 In addition, it describes the fundamental algorithm applied in 130 modifying a route announced by a predecessor node using a metric for 131 announcement on the interface implied. 133 2.1. Define: "traffic class" 135 A "class" of traffic, in any routing protocol, is the selector that 136 is used to identify a traffic stream for the purpose of routing. For 137 traditional internet routing protocols like RIP, OSPF, IS-IS, EIGRP, 138 or BGP, a "traffic class" is "the traffic destined to a stated 139 prefix". In the context of this design, a traffic class is the 140 traffic that goes 142 o to a destination prefix, which may be a default route (::/0), a 143 host route (any /128 prefix), or anything in between, 145 o from a source prefix, which may be a default route (::/0), a host 146 route (any /128 prefix), or anything in between, and 148 o using one of a set of DSCP [RFC2474] values. 150 The set of DSCP values includes and "any DSCP". "Any DSCP" has the 151 obvious meaning: we are not really looking at the DSCP in traffic 152 classification. 154 A protocol could also identify a route as a "null route"; this is 155 like any other route, but specifically directs that traffic matching 156 the traffic class is to be dropped. 158 A traffic class is represented in this document as 160 {destination, source, {list of DSCPs}|any|none} 162 Examples of common traffic classes include: 164 Standard Default Route: {::/0, ::/0, any} 166 Default Route using a source prefix {::/0, source, any} 168 Default route used only for a QoS Traffic Class: {::/0, ::/0, {list 169 of DSCPs}} 171 Examples of QoS traffic classes are found in the Configuration 172 Guidelines for DiffServ Service Classes [RFC4594] and related 173 documents [RFC5127] and [RFC5865]. 175 2.2. Define: "metric" 177 A "metric" is an attribute of an interface, and associates a traffic 178 class with a administrative value used in comparison of routes. In 179 this document, it is represented as 181 {{destination, source, {DSCP}|any|none}, administrative value} 183 and should be understood as "the metric for traffic from source to 184 destination using DSCP". 186 For example, if an interface is available to all VoIP traffic, one of 187 the metrics on an interface might be 189 {{::/0, ::/0, {EF}}, administrative value} 191 2.3. Define: "route announcement" 193 A route announcement is identical to a metric in structure, but is 194 semantically different. Where a metric is an attribute of an 195 interface, a route is an entry in the route table calculated by the 196 routing protocol, and is used in making forwarding decisions. 198 The calculation of a route follows the following logic: 200 1. Inputs to the route calculation are a route announcement (which 201 may be derived from an interface metric in the case of local 202 routes, or received from a neighboring route for remote routes), 203 and a metric associated with an interface. 205 2. The source, destination, and set of DSCPs of the route 206 announcement and the metric are intersected to generate the 207 traffic class for the resulting route. 209 3. The resulting route's administrative value is the sum of the 210 original route's administrative value and the interface's 211 administrative value. 213 For example, in Figure 1, if the prefix allocated by ISP-1 to a 214 network is 2001:db8:1::/48 and the prefix allocated by ISP-2 to the 215 network is 2001:db8:2::/48, the exit routers for the network might 216 advertise into the network the default routes 218 o {{2000::/3, 2001:db8:1::/48, any}, 1} ("unicast traffic using 219 source addresses in 2001:db8:1::/48 for any application"), and 221 o {{::/0, 2001:db8:2::/48, any}, 2} ("all traffic using source 222 addresses in 2001:db8:2::/48 for any application"). 224 \ / \ / 225 `. ISP-1 ,' `. ISP-2 ,' 226 '--. _.-' '--. _.-' 227 `---+--'' `--+---'' 228 | | 229 +--+---+ +--+---+ 230 | Exit | | Exit | 231 |Router| |Router| 232 +---+--+ +---+--+ 233 ------+------------+- -+-------------+----- 234 +-+----+-+ 235 |Interior| 236 | Router | 237 +---+----+ 238 -------+-------- 240 Figure 1: Simple multihomed network 242 One edge case is the case in which a route intersected with the 243 available metrics yields the null set. In such a case, the resulting 244 route cannot be used as no traffic matches it. 246 If an interior distance vector router in the network receives 248 {{2000::/3, 2001:db8:1::/48, any}, 1} and 250 {{::/0, 2001:db8:2::/48, any}, 2} 252 from its upstream router, and on a given interface has a metric 254 {{::/0, ::/0, {EF}}, 5} ("any VoIP traffic"), 256 it would validly infer the routes 258 {{2000::/3, 2001:db8:1::/48, {EF}}, 6} ("unicast VoIP traffic 259 using source addresses in 2001:db8:1::/48") and 261 {{::/0, 2001:db8:2::/48, {EF}}, 7} ("all VoIP traffic using source 262 addresses in 2001:db8:2::/48"). 264 It would install the routes it received into its own route table, and 265 advertise the calculated routes to neighboring routers. 267 Note that there is no question of a unicast RPF or other forms of 268 Ingress Filtering [RFC2827] required in such a network. If a host 269 spoofs a source address in another routing domain and sends a 270 datagram upstream, there is no route in the network "from" that 271 routing domain, and the router has no idea what to do with it. In 272 such cases the router would silently drop the traffic (it might be 273 nice to respond with an ICMP, but to whom?); it should of course 274 maintain appropriate counters and/or logs. Similarly, since traffic 275 is routed according to both its source and destination addresses, 276 traffic using a source address in 2001:db8:2::/48 would have no 277 chance of existing to ISP-1. It is still possible for traffic from 278 outside to come in, however, as such routes would have a source 279 prefix of ::/0 or 2000::/3. 281 2.4. Route Precedence 283 Precedence in selection of routes is based on intersection, and 284 follows the rule "most specific first". This is a generalization of 285 the "longest match first" rule used in destination routing. That may 286 require, in generating the Forwarding Information Base (FIB) from the 287 Routing Information Base (RIB), that we calculate the least 288 intersection of two route announcements. 290 In calculating routes, either one route's traffic class is a subset 291 of another's, or they mutually incompatible. If one is a subset of 292 the other, we consider the superset to be "less specific" and the 293 subset to be "more specific"; the most specific matching traffic 294 class rules. If the most specific option is in fact multiple traffic 295 classes none of which are subsets of the others, we calculate the 296 intersections of those routes for the purpose of comparison, and 297 apply the rule to the resulting route announcements. 299 For example, consider the two routes 301 {{2000::/3, ::/0, any}, 1} and 303 {{::/0, 2000::/3, any}, 5}. 305 They are not comparable because neither is a subset of the other. We 306 therefore calculate the intersection, which is a choice between 308 {{2000::/3, 2000::/3, any}, 1} and 310 {{2000::/3, 2000::/3, any}, 5}. 312 Given that choice, the metric clearly selects {{2000::/3, 2000::/3, 313 any}, 1}. So we install in the RIB the three routes 315 {{2000::/3, 2000::/3, any}, 1}, 317 {{2000::/3, ::/0, any}, 1}, and 318 {{::/0, 2000::/3, any}, 5}. 320 The first is used by unicast traffic, as it is the most specific that 321 matches traffic from and to addresses in 2000::/3. The second is 322 used, for example, with traffic that is from addresses whose most 323 significant three bits are not 001 and to an address in 2000::/3. 324 The third is used for traffic that is to addresses whose most 325 significant three bits are not 001 but are from addresses in 326 2000::/3. 328 3. Sketch of a distance vector implementation 330 A distance vector implementation would operate much as described in 331 Section 2. In addition, however, we might take advantage of an 332 algorithm used in AODV [RFC3561]) to simplify count-to-infinity- 333 related problems. 335 To this end, we use the mechanisms and algorithms of [RFC2080] with 336 certain modifications. 338 A Route Table Entry (RTE), in this model, might be structured as in 339 Figure 2. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | route tag (2) |A|N| flags | metric (1) | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Announcement sequence number (4) | 347 +---------------------------------------------------------------+ 348 | | 349 ~ IPv6 originator address (16) ~ 350 | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |dest prefix len|source prf len | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 ~ IPv6 destination prefix (up to 16) ~ 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 ~ IPv6 source prefix (up to 16) ~ 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | IPv6 Traffic Class DSCP (64 bits) | 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 2: Route Table Entry 368 The fields are: 370 Route Tag: The Route Tag is as defined in [RFC2080]. 372 A: If 1, any DSCP applies, and the IPv6 Traffic Class DSCP mask is 373 absent. If 0, the IPv6 Traffic Class DSCP is present. 375 N: if 1, a null route; traffic in this traffic class and not in more 376 explicit match SHOULD be dropped. 378 flags: unspecified in this version of the specification. Set to 0 379 on transmission and ignored on receipt. Future versions may 380 specify additional flags. 382 Metric: The Metric is as defined in [RFC2080]. 384 Announcement sequence number: 0..FFFFFFFF, follows the rules for a 385 sequence number specified in [RFC3561]. 387 IPv6 originator address: One of the global addresses of the router 388 originating this RTE, presumably the one used on the relevant 389 interface, which is in control of the sequence number. See 390 [RFC3561] for considerations and algorithms. 392 Destination Prefix Length: 0..128 394 Source Prefix Length: 0..128 396 IPv6 destination prefix: The significant bits of the prefix in 397 question. Occupies ceiling(destination prefix length/8) bytes. 399 IPv6 source prefix: The significant bits of the prefix in question. 400 Occupies ceiling(source prefix length/8) bytes. 402 IPv6 Traffic Class DSCP: if A=0, not present; if A=0, the most 403 significant bit is numbered 0, and indicates that the traffic 404 class includes traffic with a DSCP of 000000; if A=1, not present. 406 Distribution and calculation of routes follows [RFC2080], including 407 split horizon (an announcement received from a router on the 408 interface should not be reannounced to the same router). and poison 409 reverse (which should be used on triggered updates but not regular 410 announcements). 412 Elimination of stale routing information of routes follows the 413 algorithm with the sequence number specified in [RFC3561]. 415 Intersection of route announcements with interface metric data is as 416 described in Section 2. 418 4. Sketch of a link state implementation 420 A link state (SPF) implementation would also operate much as 421 described in Section 2, although the algorithm operates in memory as 422 opposed to being distributed. 424 To this end, we use the mechanisms and algorithms of [RFC5308] with 425 certain modifications. 427 IS-IS structures its network as a lattice of routers that lead one to 428 sets of hosts identified by "TLVs". A TLV, in this model, might be 429 structured as in Figure 3. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type = ??? | Length | Metric .. | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | .. Metric |U|X|S| Reserve | TLV 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | TLV ... 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |Sub-TLV Len(*) | Sub-TLVs(*) ... 441 * - if present 443 TLV or sub-TLV format: 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |dest prefix len|source prf len |A|N|flags | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 ~ IPv6 destination prefix (up to 16) ~ 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 ~ IPv6 source prefix (up to 16) ~ 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | IPv6 Traffic Class DSCP (64 bits) | 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 3: Link State Advertisement TLV 463 The fields are: 465 U: up/down bit 467 X: external original bit 469 S: subtlv present bit 471 A: If 1, any DSCP applies, and the IPv6 Traffic Class DSCP mask is 472 absent. If 0, the IPv6 Traffic Class DSCP is present. 474 N: if 1, a null route; traffic in this traffic class and not in more 475 explicit match SHOULD be dropped. 477 flags: unspecified in this version of the specification. Set to 0 478 on transmission and ignored on receipt. Future versions may 479 specify additional flags. 481 Destination Prefix Length: 0..128 483 Source Prefix Length: 0..128 485 IPv6 destination prefix: The significant bits of the prefix in 486 question. Occupies ceiling(destination prefix length/8) bytes. 488 IPv6 source prefix: The significant bits of the prefix in question. 489 Occupies ceiling(source prefix length/8) bytes. 491 IPv6 Traffic Class DSCP: if A=0, not present; if A=0, the most 492 significant bit is numbered 0, and indicates that the traffic 493 class includes traffic with a DSCP of 000000; if A=1, not present. 495 Distribution and calculation of routes follows [RFC5308]. 497 Intersection of route announcements with interface metric data is as 498 described in Section 2. 500 5. IANA Considerations 502 At this point, this memo asks the IANA for no new parameters and 503 gives the IANA no instructions. As development progresses, that 504 might change. 506 6. Security Considerations 508 Security issues in routing protocols such as these are the same as in 509 other distance vector and link state routing protocols, and need to 510 be mitigated in the same ways. Since this paper looks primarily at 511 the algorithms for route calculation, those issues are largely 512 ignored. If a protocol such as described in Section 3 or Section 4 513 is implemented, however, care must be taken to ensure the integrity 514 of communications between routers and their mutual authentication. 516 7. Acknowledgements 518 Dana Blair reviewed the initial version of the draft. 520 8. Change Log 522 Initial Version: Sat Mar 26 12:25:46 CET 2011 524 9. References 526 9.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 532 (IPv6) Specification", RFC 2460, December 1998. 534 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 535 Architecture", RFC 4291, February 2006. 537 9.2. Informative References 539 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 540 January 1997. 542 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 543 "Definition of the Differentiated Services Field (DS 544 Field) in the IPv4 and IPv6 Headers", RFC 2474, 545 December 1998. 547 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 548 Defeating Denial of Service Attacks which employ IP Source 549 Address Spoofing", BCP 38, RFC 2827, May 2000. 551 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 552 Demand Distance Vector (AODV) Routing", RFC 3561, 553 July 2003. 555 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 556 Networks", BCP 84, RFC 3704, March 2004. 558 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 559 Guidelines for DiffServ Service Classes", RFC 4594, 560 August 2006. 562 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 563 DiffServ Service Classes", RFC 5127, February 2008. 565 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 566 October 2008. 568 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 569 Services Code Point (DSCP) for Capacity-Admitted Traffic", 570 RFC 5865, May 2010. 572 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 573 Engineering in IS-IS", RFC 6119, February 2011. 575 Author's Address 577 Fred Baker 578 Cisco Systems 579 Santa Barbara, California 93117 580 USA 582 Email: fred@cisco.com