idnits 2.17.1 draft-ietf-isis-node-admin-tag-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 8, 2015) is 3033 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' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) == Outdated reference: A later version (-42) exists of draft-ietf-isis-yang-isis-cfg-07 == Outdated reference: A later version (-31) exists of draft-ietf-rtgwg-policy-model-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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: June 10, 2016 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 December 8, 2015 17 Advertising Per-node Admin Tags in IS-IS 18 draft-ietf-isis-node-admin-tag-08 20 Abstract 22 This document describes an extension to the IS-IS routing protocol to 23 add an optional operational capability, that allows tagging and 24 grouping of the nodes in an IS-IS domain. This allows simple 25 management and easy control over route and path selection, based on 26 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 June 10, 2016. 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. Per-Node Administrative Tags . . . . . . . . . . . . . . . . 3 73 3. Per-Node Administrative Tag Sub-TLV . . . . . . . . . . . . . 3 74 3.1. TLV format . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 5 76 4.1. Interpretation of Per-Node Administrative Tags . . . . . 5 77 4.2. Use of Per-Node Administrative Tags . . . . . . . . . . . 5 78 4.3. Processing Per-Node Administrative Tag changes . . . . . 6 79 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 7. Operational Considerations . . . . . . . . . . . . . . . . . 11 82 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 11.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 It is useful to assign a per-node administrative tag to a router in 93 the IS-IS domain and use it as an attribute associated with the node. 94 The per-node administrative tag can be used in variety of 95 applications, for example: 97 (a) Traffic-engineering applications to provide different path- 98 selection criteria. 100 (b) Prefer or prune certain paths in Loop Free Alternate (LFA) 101 backup selection via local policies as defined in 102 [I-D.ietf-rtgwg-lfa-manageability]. 104 This document provides mechanisms to advertise per-node 105 administrative tags in IS-IS for route and path selection. Route and 106 path selection functionality applies to both to Traffic 107 Engineering(TE) and non-TE applications. Hence the new TLV for 108 carrying per-node administrative tags is included in Router 109 Capability TLV [RFC4971]. 111 2. Per-Node Administrative Tags 113 An administrative Tag is a 32-bit integer value that can be used to 114 identify a group of nodes in the IS-IS domain. An IS-IS router 115 SHOULD advertise the set of groups it is part of in the specific IS- 116 IS level. As an example, all PE-nodes may be configured with certain 117 tag value, whereas all P-nodes are configured with a different tag 118 value. 120 3. Per-Node Administrative Tag Sub-TLV 122 The new sub-TLV defined will be carried inside the IS-IS Router 123 Capability TLV-242 [RFC4971]) in the Link State PDUs originated by 124 the router. The new sub-TLV specifies one or more administrative tag 125 values. TLV 242 can be either specified to be flooded within the 126 specific level in which the same has been originated, or they can be 127 specfied to be relayed from originating level to the other levels as 128 well. Per-node administrative tags that are included in a 'level- 129 specific' TLV 242 have a 'level-wide' flooding scope associated. On 130 the other hand, per-node administrative tags included in a 'domain- 131 wide' TLV 242 have 'domain-wide' flooding scope associated. For 132 details on how TLV 242 are flooded and relayed in the entire network 133 please, refer to [RFC4971]. Choosing the flooding scope to be 134 associated with group tags, is defined by the needs of the operator's 135 usage and is a matter of local policy or configuration. Operator MAY 136 choose to advertise a different set of per-node administrative tags 137 across levels and another set of per-node administrative tags within 138 the specific level. Alternatively, the operator may use the same 139 per-node administrative tags both within the 'domain-wide' flooding 140 scope as well as within one or more 'level-wide' flooding scope. 142 Implementations SHOULD allow configuring one or more per-node 143 administrative tags to be advertised from a given device along with 144 the flooding scope associated with the same. It SHOULD allow 145 provisioning a set of per-node administrative tags having a 'domain- 146 wide' flooding scope, as well as, a set of per-node administrative 147 tags with 'level-wide' flooding scope only. A given per-node 148 administrative tag MAY be advertised within one or more 'level-wide' 149 flooding scopes and/or within the 'domain-wide' scope. 151 The format of per-node Administrative Tag sub-TLV (see Section 3.1) 152 does not include a topology identifier. Therefore it is not possible 153 to indicate a topology specific context when advertising per-node 154 admin tags. Hence, in deployments using multi-topology routing 155 [RFC5120], advertising a separate set of per-node administrative tags 156 for each topology SHOULD NOT be supported. 158 3.1. TLV format 160 The new Per-node Administrative Tag sub-TLV, like other ISIS 161 Capability sub-TLVs, is formatted as Type/Length/Value (TLV)triplets. 162 Figure 1 below shows the format of the new sub-TLV. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Type | Length | 168 +- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Administrative Tag #1 | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Administrative Tag #2 | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 // // 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Administrative Tag #N | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Type : TBA 180 Length: A 8-bit field that indicates the length of the value 181 portion in octets and will be a multiple of 4 octets 182 dependent on the number of tags advertised. 184 Value: A sequence of multiple 4 octets defining the 185 administrative tags. 187 Figure 1: IS-IS Per-node Administrative Tag sub-TLV 189 The 'Per-node Admin Tag' sub-TLV may be generated more than once by 190 an originating router. This MAY happen if a node carries more than 191 63 per-node administrative groups and a single sub-TLV does not 192 provide sufficient space. As such occurrence of the 'Per-node Admin 193 Tag' sub-TLV does not cancel previous announcements, but rather is 194 cumulative. 196 4. Elements of Procedure 198 4.1. Interpretation of Per-Node Administrative Tags 200 Meaning of the Per-node administrative tags is generally opaque to 201 IS-IS. Router advertising the per-node administrative tag (or tags) 202 may be configured to do so without knowing (or even explicitly 203 supporting) functionality implied by the tag. 205 Interpretation of tag values is specific to the administrative domain 206 of a particular network operator. The meaning of a per-node 207 administrative tag is defined by the network local policy and is 208 controlled via the configuration. If a receiving node does not 209 understand the tag value, it ignores the specific tag and floods the 210 Router Capability TLV without any change as defined in [RFC4971]. 212 The semantics of the tag order has no meaning. There is no implied 213 meaning to the ordering of the tags that indicates a certain 214 operation or set of operations that need to be performed based on the 215 ordering. 217 Each tag SHOULD be treated as an independent identifier that MAY be 218 used in policy to perform a policy action. Each tag carried by the 219 The Per-Node Administrative Tag TLVs should be used to indicate a 220 characteristic of a node that is independent of the characteristics 221 indicated by other adminsitrative tags within the same or another 222 instance of a Per-node Administrative Tag sub-TLV. The list of Per- 223 node administrative tags carried in a Per-Node Administrative Tag 224 sub-TLV MUST be considered as an unordered list. Whilst policies may 225 be implemented based on the presence of multiple tags (e.g., if tag A 226 AND tag B are present), they MUST NOT be reliant upon the order of 227 the tags (i.e., all policies should be considered commutative 228 operations, such that tag A preceding or following tag B does not 229 change their outcome). 231 4.2. Use of Per-Node Administrative Tags 233 The per-node administrative tags are not meant to be extended by 234 future IS-IS standards. New IS-IS extensions are not expected to 235 require use of per-node administrative tags or define well-known tag 236 values. Per-node administrative tags are for generic use and do not 237 require IANA registry. Future IS-IS extensions requiring well known 238 values MAY define their own data signalling tailored to the needs of 239 the feature or MAY use the capability TLV as defined in [RFC4971]. 241 Being part of the Router Capability TLV, the per-node administrative 242 tag sub-TLV MUST be reasonably small and stable. In particular, but 243 not limited to, implementations supporting the per-node 244 administrative tags MUST NOT associate advertised tags to changes in 245 the network topology (both within and outside the IS-IS domain) or 246 reachability of routes. 248 4.3. Processing Per-Node Administrative Tag changes 250 Multiple Per-Node Administrative Tag sub-TLVs MAY appear in a Router 251 Capability TLV(TLV-242) or Per-Node Administrative Tag sub-TLVs MAY 252 be contained in different instances of Router Capability TLVs. The 253 Per-node administrative tags associated with a node that originates 254 tags for the purpose of any computation or processing at a receiving 255 node SHOULD be a superset of node administrative tags from all the 256 TLVs in all the instances of Router Capability TLVs received in the 257 Link-State PDU(s) advertised by the corresponding IS-IS router. When 258 an Router Capability TLV is received that changes the set of per-node 259 administrative tags applicable to any originating node, a receiving 260 node MUST repeat any computation or processing that makes use of per- 261 node administrative tags. 263 When there is a change or removal of an administrative affiliation of 264 a node, the node MUST re-originate the Router Capability TLV(s) with 265 the latest set of per-node administrative tags. On a receiving 266 router, on detecting a change in contents (or removal) of existing 267 Per-Node Administrative Tag sub-TLV(s) or addition of new Per-Node 268 Administrative Tag sub-TLV(s) in any instance of Router Capability 269 TLV(s), implementations MUST take appropriate measures to update 270 their state according to the changed set of per-node administrative 271 tags. The exact actions needed depend on features working with per- 272 node administrative tags and is outside of scope of this 273 specification. 275 5. Applications 277 This section lists several non-normative examples of how 278 implementations might use Per-node administrative tags. These 279 examples are given only to demonstrate generic usefulness of the 280 router tagging mechanism. An implementation supporting this 281 specification is not required to implement any of the use cases. It 282 is also worth noting that in some described use cases routers 283 configured to advertise tags help other routers in their calculations 284 but do not themselves implement the same functionality. 286 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-Re-Route(FRR) 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 an IGP domain with administrative tags and engineer the LFA 308 based on configured policies. 310 (a) Administrative limitation of LFA scope 312 Service provider access infrastructure is frequently designed 313 in a 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 [RFC7490] defined method of tunneling traffic after connected 355 link failure to extend the basic LFA coverage and algorithm to 356 find tunnel tail-end routers fitting LFA requirement. In most 357 cases proposed algorithm finds more than one candidate tail-end 358 router. In real life network it may be desirable to exclude some 359 nodes from the list of candidates based on the local policy. 360 This may be either due to known limitations of the per-node (the 361 router does accept targeted LDP sessions required to implement 362 Remote LFA tunneling) or due to administrative requirements (for 363 example, it may be desirable to choose tail-end router among co- 364 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 back-haul network service deployment 375 The topology of mobile back-haul networks 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 back-haul network with access rings and 412 aggregate links is shown in figure above. The mobile back-haul 413 networks deploy traffic engineering due to the strict Service 414 Level Agreements(SLA). The TE paths may have additional 415 constraints to avoid passing via different access rings or to get 416 completely disjoint backup TE paths. The mobile back-haul 417 networks towards the access side change frequently due to the 418 growing mobile traffic and addition of new LTE Evolved NodeBs 419 (eNodeB). It's complex to satisfy the requirements using cost, 420 link color or explicit path configurations. The per-node 421 administrative tag defined in this document can be effectively 422 used to solve the problem for mobile back-haul networks. The 423 nodes in different rings can be assigned with specific tags. TE 424 path computation can be enhanced to consider additional 425 constraints based on per-node administrative tags. 427 5. Policy-based Explicit Routing 429 A partially meshed network provides multiple paths between any 430 two nodes in the network. In a data centre environment, the 431 topology is usually highly symmetric with many/all paths having 432 equal cost. In a long distance network, this is usually less the 433 case, for a variety of reasons (e.g. historic, fibre 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 | +-----------------+ x +---------+ | 443 | | \/ \/ | | 444 | | +-T-10-T | | 445 | | / | /| | | 446 | | / 100 / | | | 447 | | / | | 100 | | 448 | | / +-+-+ | | | 449 | | / / | | | | 450 | | / / R-18-R | | 451 | | 10 10 /\ /\ | | 452 | | / / / \ / \ | | 453 | | / / / x \ | | 454 | | / / 10 10 \ \ | | 455 | | / / / / 10 10 | | 456 | | / / / / \ \ | | 457 | | A-25-A A-25-A A-25-A | | 458 | | | | \ \ / / | | 459 | | | | 201 201 201 201 | | 460 | | | | \ \ / / | | 461 | | 201 201 \ x / | | 462 | | | | \ / \ / | | 463 | | | | \/ \/ | | 464 | | I-24-I I-24-I 100 100 465 | | / / | | | | 466 | +-+ / | +-----------+ | 467 +---------+ +---------------------+ 469 Figure 3: Explicit Routing topology 471 In the above topology, operator may want to enforce the following 472 high level explicit routing policies: 474 1. - Traffic from A nodes to A nodes should preferably go 475 through R or T nodes (rather than through I nodes). 477 2. - Traffic from A nodes to I nodes must not go through R and T 478 nodes. 480 With node admin tags, tag A (resp. I, R, T) can be configured on 481 all A (resp. I, R, T) nodes to advertise their role. The first 482 policy is about preferring one path over another. Given the 483 chosen metrics, it is achieved with regular SPF routing. The 484 second policy is about prohibiting (pruning) some paths. It 485 requires an explicit routing policy. With the use of node tags, 486 this may be achieved with a generic CSPF policy configured on A 487 nodes: for destination nodes having the tag "A" runs a CSPF with 488 the exclusion of nodes having the tag "I". 490 6. Security Considerations 492 Node administrative tags may be used by operators to indicate 493 geographical location or other sensitive information. The 494 information carried in node administrative tags could be leaked to an 495 IGP snooper. This document does not introduce any new security 496 issues. Security concerns for IS-IS are already addressed in 497 [ISO10589], [RFC5304], and [RFC5310] and are applicable to the 498 mechanisms described in this document. Extended authentication 499 mechanisms described in [RFC5304] or [RFC5310] SHOULD be used in 500 deployments where attackers have access to the physical networks and 501 nodes included in the IS-IS domain are vulnerable. 503 Advertisement of tag values for one administrative domain into 504 another invloves the risk mis-interpretation of the tag values (if 505 the two domains have assigned different meanings to the same values), 506 which may have undesirable and unanticipated side effects. 508 7. Operational Considerations 510 Operators can assign meaning to the per-node administrative tags 511 which is local to the operator's administrative domain. The 512 operational use of per-node administrative tags is analogical to the 513 IS-IS prefix tags [RFC5130] and BGP communities [RFC1997]. 514 Operational discipline and procedures followed in configuring and 515 using BGP communities and ISIS Prefix tags is also applicable to the 516 usage of per-node administrative tags. 518 Defining language for local policies is outside the scope of this 519 document. As in case of other policy applications, the pruning 520 policies can cause the path to be completely removed from forwarding 521 plane,and hence have the potential for more severe operational impact 522 (e.g., node unreachability due to path removal) by comparison to 523 preference policies that only affect path selection. 525 8. Manageability Considerations 527 Per-node administrative tags are configured and managed using routing 528 policy enhancements. YANG data definition language is the latest 529 model to describe and define configuration for network devices. IS- 530 IS YANG data model is described in [I-D.ietf-isis-yang-isis-cfg] and 531 routing policy configuration model is described in 532 [I-D.ietf-rtgwg-policy-model]. These two documents will be enhanced 533 to include the node administrative tag related configurations. 535 9. IANA Considerations 537 IANA maintains the registry for the Router Capability sub-TLVs. IS- 538 IS Administrative Tags will require new type code for the following 539 new sub-TLV defined in this document. 541 i) Per-Node-Admin-Tag Sub-TLV, Type: TBD 543 10. Acknowledgments 545 Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri and Chris 546 Bowers for providing useful inputs. 548 11. References 550 11.1. Normative References 552 [ISO10589] 553 "Intermediate system to Intermediate system intra-domain 554 routeing information exchange protocol for use in 555 conjunction with the protocol for providing the 556 connectionless-mode Network Service (ISO 8473), ISO/IEC 557 10589:2002, Second Edition.", Nov 2002. 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, 561 DOI 10.17487/RFC2119, March 1997, 562 . 564 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 565 "Intermediate System to Intermediate System (IS-IS) 566 Extensions for Advertising Router Information", RFC 4971, 567 DOI 10.17487/RFC4971, July 2007, 568 . 570 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 571 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 572 2008, . 574 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 575 and M. Fanto, "IS-IS Generic Cryptographic 576 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 577 2009, . 579 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 580 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 581 RFC 7490, DOI 10.17487/RFC7490, April 2015, 582 . 584 11.2. Informative References 586 [I-D.ietf-isis-yang-isis-cfg] 587 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 588 Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf- 589 isis-yang-isis-cfg-07 (work in progress), November 2015. 591 [I-D.ietf-rtgwg-lfa-manageability] 592 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 593 Horneffer, M., and P. Sarkar, "Operational management of 594 Loop Free Alternates", draft-ietf-rtgwg-lfa- 595 manageability-11 (work in progress), June 2015. 597 [I-D.ietf-rtgwg-policy-model] 598 Shaikh, A., rjs@rob.sh, r., D'Souza, K., and C. Chase, 599 "Routing Policy Configuration Model for Service Provider 600 Networks", draft-ietf-rtgwg-policy-model-00 (work in 601 progress), September 2015. 603 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 604 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 605 . 607 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 608 Topology (MT) Routing in Intermediate System to 609 Intermediate Systems (IS-ISs)", RFC 5120, 610 DOI 10.17487/RFC5120, February 2008, 611 . 613 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 614 Control Mechanism in IS-IS Using Administrative Tags", 615 RFC 5130, DOI 10.17487/RFC5130, February 2008, 616 . 618 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 619 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 620 DOI 10.17487/RFC5286, September 2008, 621 . 623 Authors' Addresses 625 Pushpasis Sarkar (editor) 626 Juniper Networks, Inc. 627 Electra, Exora Business Park 628 Bangalore, KA 560103 629 India 631 Email: psarkar@juniper.net; pushpasis.ietf@gmail.com 633 Hannes Gredler 634 Juniper Networks, Inc. 635 1194 N. Mathilda Ave. 636 Sunnyvale, CA 94089 637 US 639 Email: hannes@gredler.at 641 Shraddha Hegde 642 Juniper Networks, Inc. 643 Electra, Exora Business Park 644 Bangalore, KA 560103 645 India 647 Email: shraddha@juniper.net 649 Stephane Litkowski 650 Orange 652 Email: stephane.litkowski@orange.com 654 Bruno Decraene 655 Orange 657 Email: bruno.decraene@orange.com 658 Li Zhenbin 659 Huawei Technologies 660 Huawei Bld. No.156 Beiqing Rd 661 Beijing, KA 100095 662 China 664 Email: lizhenbin@huawei.com 666 Ebben Aries 667 Facebook 668 1 Hacker Way 669 Menlo Park, CA 94025 670 US 672 Email: exa@dscp.org 674 Rafael Rodriguez 675 Facebook 676 1 Hacker Way 677 Menlo Park, CA 94025 678 US 680 Email: rafael@fb.com 682 Harish Raghuveer 684 Email: harish.r.prabhu@gmail.com