idnits 2.17.1 draft-ietf-isis-node-admin-tag-01.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 ([RFC1195], [ISO10589]), 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: As mentioned earlier, to avoid incomplete or inconsistent interpretations of the per-node administrative tags the same tag value MUST NOT be advertised by a router in Router Capabilities of different scopes. Implementations MUST NOT allow configuring the same tag value across domain-wide and 'level-wide' scopes. The same tag value MAY be allowed to be configured and advertised under 'level-wide' scope for all levels. A IS-IS Area Border Router (ABR) participating in both levels 1 and 2 MAY advertise the same tag value in the level-specific Router Capability TLVs with 'level-wide' scope generated by it. But the same tag value MUST not be advertised in any of level 1 or level 2 Router-Capability TLV with 'domain-wide' flooding scope (refer to [RFC4971] for more details). -- The document date (March 9, 2015) is 3341 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-lfa-manageability-04 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-09 -- Obsolete informational reference (is this intentional?): RFC 4971 (Obsoleted by RFC 7981) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets P. Sarkar, Ed. 3 Internet-Draft H. Gredler 4 Intended status: Standards Track S. Hegde 5 Expires: September 10, 2015 Juniper Networks, Inc. 6 S. Litkowski 7 B. Decraene 8 Orange 9 Z. Li 10 Huawei Technologies 11 E. Aries 12 R. Rodriguez 13 Facebook 14 H. Raghuveer 15 March 9, 2015 17 Advertising Per-node Admin Tags in IS-IS 18 draft-ietf-isis-node-admin-tag-01 20 Abstract 22 This document describes an extension to IS-IS protocol [ISO10589], 23 [RFC1195] to add an optional operational capability, that allows 24 tagging and grouping of the nodes in an IS-IS domain. This allows 25 simple management and easy control over route and path selection, 26 based on local configured policies. 28 This document describes the protocol extensions to disseminate per- 29 node administrative tags in IS-IS protocols. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 10, 2015. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Administrative Tag . . . . . . . . . . . . . . . . . . . . . 3 73 3. TLV format . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.1. Per-node Admin Tag sub-TLV . . . . . . . . . . . . . . . 4 75 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 5 76 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 9.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 This document provides mechanisms to advertise per-node 88 administrative tags in the IS-IS Link State PDU [RFC1195]. In 89 certain path-selection applications like for example in traffic- 90 engineering or LFA [RFC5286] selection there is a need to tag the 91 nodes based on their roles in the network and have policies to prefer 92 or prune a certain group of nodes. 94 2. Administrative Tag 96 For the purpose of advertising per-node administrative tags within 97 IS-IS, a new sub-TLV to the IS-IS Router Capability TLV-242 that is 98 defined in [RFC4971] is proposed. Path selection is a functional set 99 which applies both to TE and non-TE applications. Per-node 100 administrative tags are used to advertise an attribute of the node. 101 As such they are independent of the routing protocol used to 102 advertise them. Because per-node administrative tags may be used to 103 advertise many different attributes, associating the advertisement to 104 TLVs specific to a particular use case (e.g. TE extensions to IS- 105 Neighbors TLVs [RFC5305] in the case of TE path selection) is not 106 appropriate. 108 An administrative Tag is a 32-bit integer value that can be used to 109 identify a group of nodes in the IS-IS domain. The new sub-TLV 110 specifies one or more administrative tag values. An IS-IS router 111 advertises the set of groups it is part of in the specific IS-IS 112 level. As an example, all PE-nodes may be configured with certain 113 tag value, whereas all P-nodes are configured with a different tag 114 value. 116 The new sub-TLV defined will be carried inside the IS-IS Router 117 Capability TLV-242 [RFC4971]) in the Link State PDUs originated by 118 the router. Link State PDUs [ISO10589] can be either flooded within 119 the specific level (i.e. L1 or L2) or can be relayed across from one 120 level to another. Per-node administrative tags included in a TLV 242 121 to be distributed within the specific level are perceived to have 122 'level-wide' scope only. On the other hand, per-node administrative 123 tag included in a TLV 242 to be distributed across levels are 124 perceived to have 'domain-wide' scope. 126 Choosing the flooding scope to be associate with group tags are 127 defined by the needs of the operator's usage and is a matter of local 128 policy or configuration. Operator may choose to advertise a set of 129 per-node administrative tags across levels and another set of per- 130 node administrative tags within the specific level. But evidently 131 the same set of per-node administrative tags cannot be advertised 132 both across levels and within a specific level. A receiving IS-IS 133 router will not be able to distinguish between the significance of a 134 per-node administrative tag advertised globally from that of an 135 administrative tag advertised locally if they have the same value 136 associated but different significance across different scopes. 138 Implementations SHOULD allow configuring one or more per-node 139 administrative tags to be advertised from a given device along with 140 the floofing scope associated with the same. It SHOULD allow 141 provisioning a set of per-node administrative tags having a 'domain- 142 wide' flooding scope, as well as, a set of per-node administrative 143 tags with 'level-wide' flooding scope only. A given per-node 144 administrative tag MAY be advertised with level-specific scope 145 (Level-1 and/or Level-2) or with domain-wide scope, but MUST NOT be 146 advertised in both scopes. Hence implementations MUST NOT allow 147 configuring the same per-node administrative tag values in both 148 'domain-wide' and 'level-wide' scopes. However the same 149 administrative tag value MAY be allowed under multiple levels with 150 'level-wide' scope. 152 In deployments using multi-topology routing [RFC5120], since multiple 153 topologies within same IS-IS level do not use seprate Router 154 Capability TLVs (i.e. they share the same flooding scope) a given 155 per-node administrative tag cannot be associated with different 156 charateristic or attribute under different topology. 157 Implementations, in addition to letting user configuring a set of 158 'level-wide' and 'domain-wide' per-node administrative tags for each 159 level, MAY also allow configuring a set of 'level-wide' and 'domain- 160 wide' tags for each topology. Operators may like to associate a 161 single per-node administrative tag with same attribute across all 162 topologies under a specific (or all) levels. The same should be 163 provisioned under specific 'level-wide' (or 'domain-wide') 164 configurations. However advertising the same tag value across 165 multiple topologies will lead to same inconsistencies as with the 166 case of advertising same tag value across 'domain-wide' and 'level- 167 wide' flooding scope. Hence such implementations that allow 168 configuring topology-specific per-node administrative tags, MUST NOT 169 allow configuring the same topology-specific per-node administrative 170 tag across different topologies. They MUST only allow disjoint sets 171 of topology-specific 'level-wide' and 'domain-wide' per-node 172 administrative tags across different topologies. 174 3. TLV format 176 3.1. Per-node Admin Tag sub-TLV 178 The new Per-node Administrative Tag sub-TLV, like other ISIS 179 Capability sub-TLVs, is formatted as Type/Length/Value (TLV)triplets. 180 Figure 1 below shows the format of the new sub-TLV. 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type | Length | 186 +- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Administrative Tag #1 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Administrative Tag #2 | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 // // 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Administrative Tag #N | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Type : TBA 198 Length: A 8-bit field that indicates the length of the value 199 portion in octets and will be a multiple of 4 octets 200 dependent on the number of tags advertised. 202 Value: A sequence of multiple 4 octets defining the 203 administrative tags. 205 Figure 1: IS-IS Per-node Administrative Tag sub-TLV 207 The 'Per-node Admin Tag' sub-TLV may be generated more than once by 208 an originating router. This MAY happen if a node carries more than 209 63 per-node administrative groups and a single sub-TLV does not 210 provide sufficient space. As such occurence of the 'Per-node Admin 211 Tag' sub-TLV does not cancel previous announcements, but rather is 212 cumulative. 214 4. Elements of Procedure 216 Meaning of the Per-node administrative tags is generally opaque to 217 IS-IS. Router advertising the per-node administrative tag (or tags) 218 may be configured to do so without knowing (or even explicitly 219 supporting) functionality implied by the tag. 221 Interpretation of tag values is specific to the administrative domain 222 of a particular network operator. The meaning of a per-node 223 administrative tag is defined by the network local policy and is 224 controlled via the configuration. If a receiving node does not 225 understand the tag value, it ignores the specific tag and floods the 226 Router Capability TLV without any change as defined in [RFC4971]. 228 The semantics of the tag order has no meaning. There is no implied 229 meaning to the ordering of the tags that indicates a certain 230 operation or set of operations that need to be performed based on the 231 ordering. 233 Each tag SHOULD be treated as an independent identifier that MAY be 234 used in policy to perform a policy action. Tags carried by the 235 administrative tag TLV SHOULD be used to indicate independent 236 characteristics of a node. The TLV SHOULD be considered as an 237 unordered list. Whilst policies may be implemented based on the 238 presence of multiple tags (e.g., if tag A AND tag B are present), 239 they MUST NOT be reliant upon the order of the tags (i.e., all 240 policies should be considered commutative operations, such that tag A 241 preceding or following tag B does not change their outcome). 243 As mentioned earlier, to avoid incomplete or inconsistent 244 interpretations of the per-node administrative tags the same tag 245 value MUST NOT be advertised by a router in Router Capabilities of 246 different scopes. Implementations MUST NOT allow configuring the 247 same tag value across domain-wide and 'level-wide' scopes. The same 248 tag value MAY be allowed to be configured and advertised under 249 'level-wide' scope for all levels. A IS-IS Area Border Router (ABR) 250 participating in both levels 1 and 2 MAY advertise the same tag value 251 in the level-specific Router Capability TLVs with 'level-wide' scope 252 generated by it. But the same tag value MUST not be advertised in 253 any of level 1 or level 2 Router-Capability TLV with 'domain-wide' 254 flooding scope (refer to [RFC4971] for more details). 256 The per-node administrative tags sub-TLV don't need to be extended to 257 advertise newer per-node attributes or capabilities in future. 258 Future IS-IS protocol extensions MUST NOT require use of per-node 259 administrative tags or define well-known tag values to advertise 260 well-known capabilities. Per-node administrative tags are for 261 generic use and do not require IANA registry. Theny future IS-IS 262 extensions requiring well known values to advertise well-known 263 capabilities MAY define and use new Router Capability sub-TLVs 264 tailored to the needs of the specific solution (refer to [RFC4971] 265 for more details). 267 Being part of the Router Capability TLV, the per-node administrative 268 tag sub-TLV MUST be reasonably small and stable. In particular, but 269 not limited to, implementations supporting the per-node 270 administrative tags MUST NOT associate advertised tags to changes in 271 the network topology (both within and outside the IS-IS domain) or 272 reachability of routes. 274 5. Applications 276 This section lists several examples of how implementations might use 277 the Per-node administrative tags. These examples are given only to 278 demonstrate generic usefulness of the router tagging mechanism. 279 Implementation supporting this specification is not required to 280 implement any of the use cases. It is also worth noting that in some 281 described use cases routers configured to advertise tags help other 282 routers in their calculations but do not themselves implement the 283 same functionality. 285 1. Auto-discovery of Services 287 Router tagging may be used to automatically discover group of 288 routers sharing a particular service. 290 For example, service provider might desire to establish full mesh 291 of MPLS TE tunnels between all PE routers in the area of MPLS VPN 292 network. Marking all PE routers with a tag and configuring 293 devices with a policy to create MPLS TE tunnels to all other 294 devices advertising this tag will automate maintenance of the 295 full mesh. When new PE router is added to the area, all other PE 296 devices will open TE tunnels to it without the need of 297 reconfiguring them. 299 2. Policy-based Fast-Reroute 301 Increased deployment of Loop Free Alternates (LFA) as defined in 302 [RFC5286] poses operation and management challenges. 303 [I-D.ietf-rtgwg-lfa-manageability] proposes policies which, when 304 implemented, will ease LFA operation concerns. 306 One of the proposed refinements is to be able to group the nodes 307 in IGP domain with administrative tags and engineer the LFA based 308 on configured policies. 310 (a) Administrative limitation of LFA scope 312 Service provider access infrastructure is frequently designed 313 in layered approach with each layer of devices serving 314 different purposes and thus having different hardware 315 capabilities and configured software features. When LFA 316 repair paths are being computed, it may be desirable to 317 exclude devices from being considered as LFA candidates based 318 on their layer. 320 For example, if the access infrastructure is divided into the 321 Access, Distribution and Core layers it may be desirable for 322 a Distribution device to compute LFA only via Distribution or 323 Core devices but not via Access devices. This may be due to 324 features enabled on Access routers; due to capacity 325 limitations or due to the security requirements. Managing 326 such a policy via configuration of the router computing LFA 327 is cumbersome and error prone. 329 With the Per-node administrative tags it is possible to 330 assign a tag to each layer and implement LFA policy of 331 computing LFA repair paths only via neighbors which advertise 332 the Core or Distribution tag. This requires minimal per-node 333 configuration and network automatically adapts when new links 334 or routers are added. 336 (b) Optimizing LFA calculations 338 Calculation of LFA paths may require significant resources of 339 the router. One execution of Dijkstra algorithm is required 340 for each neighbor eligible to become next hop of repair 341 paths. Thus a router with a few hundreds of neighbors may 342 need to execute the algorithm hundreds of times before the 343 best (or even valid) repair path is found. Manually 344 excluding from the calculation neighbors which are known to 345 provide no valid LFA (such as single-connected routers) may 346 significantly reduce number of Dijkstra algorithm runs. 348 LFA calculation policy may be configured so that routers 349 advertising certain tag value are excluded from LFA 350 calculation even if they are otherwise suitable. 352 3. Controlling Remote LFA tunnel termination 354 [I-D.ietf-rtgwg-remote-lfa] proposed method of tunneling traffic 355 after connected link failure to extend the basic LFA coverage and 356 algorithm to find tunnel tail-end routers fitting LFA 357 requirement. In most cases proposed algorithm finds more than 358 one candidate tail-end router. In real life network it may be 359 desirable to exclude some nodes from the list of candidates based 360 on the local policy. This may be either due to known limitations 361 of the per-node (the router does accept targeted LDP sessions 362 required to implement Remote LFA tunneling) or due to 363 administrative requirements (for example, it may be desirable to 364 choose tail-end router among co-located devices). 366 The Per-node administrative tag delivers simple and scalable 367 solution. Remote LFA can be configured with a policy to accept 368 during the tail-end router calculation as candidates only routers 369 advertising certain tag. Tagging routers allows to both exclude 370 nodes not capable of serving as Remote LFA tunnel tail-ends and 371 to define a region from which tail-end router must be selected. 373 4. Mobile backhaul network service deployment 375 The topology of mobile backhaul network usually adopts ring 376 topology to save fiber resource and it is divided into the 377 aggregate network and the access network. Cell Site 378 Gateways(CSGs) connects the eNodeBs and RNC(Radio Network 379 Controller) Site Gateways(RSGs)connects the RNCs. The mobile 380 traffic is transported from CSGs to RSGs. The network takes a 381 typical aggregate traffic model that more than one access rings 382 will attach to one pair of aggregate site gateways(ASGs) and more 383 than one aggregate rings will attach to one pair of RSGs. 385 ---------------- 386 / \ 387 / \ 388 / \ 389 +------+ +----+ Access +----+ 390 |eNodeB|---|CSG1| Ring 1 |ASG1|------------- 391 +------+ +----+ +----+ \ 392 \ / \ 393 \ / +----+ +---+ 394 \ +----+ |RSG1|----|RNC| 395 -------------| | Aggregate +----+ +---+ 396 |ASG2| Ring | 397 -------------| | +----+ +---+ 398 / +----+ |RSG2|----|RNC| 399 / \ +----+ +---+ 400 / \ / 401 +------+ +----+ Access +----+ / 402 |eNodeB|---|CSG2| Ring 2 |ASG3|------------ 403 +------+ +----+ +----+ 404 \ / 405 \ / 406 \ / 407 ----------------- 409 Figure 2: Mobile Backhaul Network 411 A typical mobile backhaul network with access rings and aggregate 412 links is shown in figure above. The mobile backhaul networks 413 deploy traffic engineering due to the strict Service Level 414 Agreements(SLA). The TE paths may have additional constraints to 415 avoid passing via different access rings or to get completely 416 disjoint backup TE paths. The mobile backhaul networks towards 417 the access side change frequently due to the growing mobile 418 traffic and addition of new eNodeBs. It's complex to satisfy the 419 requirements using cost, link color or explicit path 420 configurations. The per-node administrative tag defined in this 421 document can be effectively used to solve the problem for mobile 422 backhaul networks. The nodes in different rings can be assigned 423 with specific tags. TE path computation can be enhanced to 424 consider additional constraints based on per-node administrative 425 tags. 427 5. Policy-based Explicit Routing 429 Partially meshed network provides multiple paths between any two 430 nodes in the network. In a data center environment, the topology 431 is usually highly symmetric with many/all paths having equal 432 cost. In a long distance network, this is usually less the case 433 for a variety of reasons (e.g. historic, fiber availability 434 constraints, different distances between transit nodes, different 435 roles ...). Hence between a given source and destination, a path 436 is typically preferred over the others, while between the same 437 source and another destination, a different path may be 438 preferred. 440 +--------------------+ 441 | | 442 | +----------+ | 443 | | | | 444 T-10-T | | 445 /| /| | | 446 / | / | | | 447 --+ | | | | | 448 / +--+-+ 100 | | 449 / / | | | | 450 / / R-18-R | | 451 / / /\ /\ | | 452 / | / \ / \ | | 453 / | / x \ | | 454 A-25-A 10 10 \ \ | | 455 / / 10 10 | | 456 / / \ \ | | 457 A-25-A A-25-A | | 458 \ \ / / | | 459 201 201 201 201 | | 460 \ \ / / | | 461 \ x / | | 462 \ / \ / | | 463 \/ \/ | | 464 I-24-I 100 100 465 | | | | 466 | +-----------+ | 467 | | 468 +---------------------+ 470 Figure 3: Explicit Routing topology 472 In the above topology, operator may want to enforce the following 473 high level explicitly routed policies: - Traffic from A nodes to 474 A nodes must not go through I nodes - Traffic from A nodes to I 475 nodes must not go through R and T nodes with per-node 476 administrative tag, tag A can be configured on all A nodes, 477 (similarly I, R, T), and then configure this single CSPF policy 478 on all A nodes to avoid I nodes for path calculation. 480 6. Security Considerations 482 This document does not introduce any further security issues other 483 than those discussed in [ISO10589] and [RFC1195]. 485 7. IANA Considerations 487 IANA maintains the registry for the Router Capability sub-TLVs. IS- 488 IS Administrative Tags will require new type code for the following 489 new sub-TLV defined in this document. 491 i) Per-Node-Admin-Tag Sub-TLV, Type: TBD 493 8. Acknowledgments 495 Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri for useful 496 inputs. Thanks to Chris Bowers for providing useful inputs to remove 497 ambiguity related to tag-ordering. 499 9. References 501 9.1. Normative References 503 [ISO10589] 504 "Intermediate system to Intermediate system intra-domain 505 routeing information exchange protocol for use in 506 conjunction with the protocol for providing the 507 connectionless-mode Network Service (ISO 8473), ISO/IEC 508 10589:2002, Second Edition.", Nov 2002. 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 9.2. Informative References 515 [I-D.ietf-rtgwg-lfa-manageability] 516 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 517 Horneffer, M., and p. psarkar@juniper.net, "Operational 518 management of Loop Free Alternates", draft-ietf-rtgwg-lfa- 519 manageability-04 (work in progress), August 2014. 521 [I-D.ietf-rtgwg-remote-lfa] 522 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 523 So, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-09 (work 524 in progress), December 2014. 526 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 527 dual environments", RFC 1195, December 1990. 529 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 530 System to Intermediate System (IS-IS) Extensions for 531 Advertising Router Information", RFC 4971, July 2007. 533 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 534 Topology (MT) Routing in Intermediate System to 535 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 537 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 538 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 540 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 541 Engineering", RFC 5305, October 2008. 543 Authors' Addresses 545 Pushpasis Sarkar (editor) 546 Juniper Networks, Inc. 547 Electra, Exora Business Park 548 Bangalore, KA 560103 549 India 551 Email: psarkar@juniper.net 553 Hannes Gredler 554 Juniper Networks, Inc. 555 1194 N. Mathilda Ave. 556 Sunnyvale, CA 94089 557 US 559 Email: hannes@juniper.net 561 Shraddha Hegde 562 Juniper Networks, Inc. 563 Electra, Exora Business Park 564 Bangalore, KA 560103 565 India 567 Email: shraddha@juniper.net 569 Stephane Litkowski 570 Orange 572 Email: stephane.litkowski@orange.com 573 Bruno Decraene 574 Orange 576 Email: bruno.decraene@orange.com 578 Li Zhenbin 579 Huawei Technologies 580 Huawei Bld. No.156 Beiqing Rd 581 Beijing, KA 100095 582 China 584 Email: lizhenbin@huawei.com 586 Ebben Aries 587 Facebook 589 Email: exa@fb.com 591 Rafael Rodriguez 592 Facebook 594 Email: rafael@fb.com 596 Harish Raghuveer 598 Email: harish.r.prabhu@gmail.com