idnits 2.17.1 draft-hegdeppsenak-isis-sr-flex-algo-02.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 == 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 'SHOULD not' in this paragraph: The FAD Sub-TLV of the IS-IS Router Capability TLV-242 MUST be propagated throughout the level. It MAY be advertised across level boundaries, if the S-flag in the Router Capability TLV is set. The S-Flag SHOULD not be set by default unless local configuration policy on the originating router indicates domain wide flooding. -- The document date (February 16, 2018) is 2260 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 (-25) exists of draft-ietf-isis-segment-routing-extensions-15 ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Psenak, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Hegde, Ed. 5 Expires: August 20, 2018 Juniper Networks, Inc. 6 C. Filsfils 7 Cisco Systems, Inc. 8 A. Gulko 9 Thomson Reuters 10 February 16, 2018 12 ISIS Segment Routing Flexible Algorithm 13 draft-hegdeppsenak-isis-sr-flex-algo-02.txt 15 Abstract 17 IGP protocols traditionally compute best paths over the network based 18 on the IGP metric assigned to the links. Many network deployments 19 use RSVP-TE based or Segment Routing based Traffic Engineering to 20 enforce traffic over a path that is computed using different metrics 21 or constraints than the shortest IGP path. Various mechanisms are 22 used to steer the traffic towards such traffic engineered paths. 23 This document proposes a solution that allows IGPs themselves to 24 compute constraint based paths over the network without the use of 25 the above mentioned traffic engineering technologies. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 20, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 63 2. Flexible Algorithm . . . . . . . . . . . . . . . . . . . . . 3 64 3. Flexible Algorithm Advertisement . . . . . . . . . . . . . . 3 65 4. Flexible Algorithm Definition Advertisement . . . . . . . . . 4 66 4.1. Flexible Algorithm Definition Sub-TLV . . . . . . . . . . 4 67 4.2. Flexible Algorithm Exclude Admin Group Sub-TLV . . . . . 7 68 4.3. Flexible Algorithm Include Admin Group Sub-TLVs . . . . . 7 69 5. Calculation of Flexible Algorithm Paths . . . . . . . . . . . 8 70 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 10 74 8.2. New Sub-Sub-TLV registry . . . . . . . . . . . . . . . . 10 75 8.2.1. Flexible Algorithm Definition TLV Metric Registry . . 11 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 10.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 IGP computed path based on the shortest IGP metric must often be 85 replaced by traffic engineered path due to the traffic requirements 86 which are not reflected in the IGP metric. Some networks engineer 87 the IGP metric assignments in a way that the IGP Metric reflects the 88 link bandwidth or delay. If, for example, the IGP metric is 89 reflecting the bandwidth on the link and the application traffic is 90 delay sensitive, the best IGP path may not reflect the best path from 91 such application's perspective. 93 To overcome such IGP limitation, various sorts of traffic engineering 94 has been deployed, including RSVP-TE or SR-TE, in which case the TE 95 component is responsible for computing the path based on additional 96 metrics and/or constraints. Such paths need to be installed in the 97 forwarding and replace the original paths computed by IGPs. Tunnels 98 are often used to represent the engineered paths and mechanisms like 99 one described in [RFC3906] are used to replace the native IGP paths 100 with such tunnel paths. 102 Segment Routing (SR) allows a flexible definition of end-to-end paths 103 within IGP topologies by encoding paths as sequences of topological 104 sub-paths, called segments. It also defines an algorithm that 105 defines how the paths are computed. It also provides a way to 106 associate Prefix-SID with an algorithm. This allows IGPs to compute 107 paths based on various algorithms and cause traffic to be forwarded 108 on such paths using the algorithm specific segments. 110 This document describes the IS-IS extension to support Segment 111 Routing Flexible Algorithm on an MPLS data-plane. 113 1.1. Requirements notation 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. Flexible Algorithm 121 Many possible constraints may be used to compute a path over a 122 network. Some networks are deployed as multiple planes. A simple 123 form of constraint may be to use a particular plane. A more 124 sophisticated form of constraint can include some extended metric as 125 described in [RFC7810]. Constraints which restrict paths to links 126 with specific affinities or avoid links with specific affinities are 127 also possible. Combinations of these are also possible. 129 To provide maximum flexibility we do not want to provide a strict 130 mapping between the set of constraints and the algorithm that is 131 associated with it. We want the mapping between the algorithm value 132 and it's meaning to be flexible and defined by the user. As far as 133 all routers in the domain have the common understanding what the 134 particular algorithm value represents, the computation for such 135 algorithm is consistent and traffic is not subject to any looping. 137 Because the meaning of the algorithm is not defined by any standard, 138 but is defined by the user, we call it Flex-Algorithm. 140 3. Flexible Algorithm Advertisement 142 [I-D.ietf-isis-segment-routing-extensions] defines an SR-Algorithm. 143 This algorithm defines how the best path is computed by the IGP. 144 Routers advertise the support for the algorithm as a node capability. 146 Prefix SIDs are also advertised with an algorithm value and as such 147 are tightly coupled with the algorithm. 149 Existing advertisement of the SR-Algorithm is used for the Flex- 150 Algorithm advertisements as defined in 151 [I-D.ietf-isis-segment-routing-extensions]. 153 SR-Algorithm is a one octet value. We propose to split the range of 154 values as follows: 156 0-127 - standardised values assigned by IANA 158 128-255 - user defined values. 160 4. Flexible Algorithm Definition Advertisement 162 To guarantee the loop free forwarding for paths computed for a 163 particular Flex-Algorithm, all routers in the flooding scope of the 164 algorithm definition MUST agree on the definition of the Flex- 165 Algorithm. 167 4.1. Flexible Algorithm Definition Sub-TLV 169 Flexible Algorithm Definition Sub-TLV (FAD Sub-TLV) is used to 170 advertise the definition of the Flex-Algorithm. 172 FAD Sub-TLV is advertised as Sub-TLV of the IS-IS Router Capability 173 TLV-242 that is defined in [RFC7981]. 175 When the definition of the Flex Algorithm is advertised, it is 176 applicable to all topologies supported on the receiving node. 178 FAD Sub-TLV has the following format: 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Length | Algorithm | Metric Type | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Alg. Type | Priority | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Sub-TLVs | 188 + + 189 | ... | 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 where: 196 Type: TBD1 198 Length: variable, dependent on the included Sub-TLVs 200 Algorithm: Flex-Algorithm number. Value between 128 and 255 201 inclusive. 203 Metric Type: Type of metric to be used during the calculation. 204 Following values are defined: 206 0: IGP Metric 208 1: Min Unidirectional Link Delay as defined in [RFC7810]. 210 2: TE default metric as defined in [RFC5305]. 212 Algorithm Type: Single octet identifying the algorithm type used 213 to compute paths for the Flex-Algoritm. Values are defined in 214 "IGP Algorithm Types" registry defined under "Interior Gateway 215 Protocol (IGP) Parameters" IANA registries. 217 Priority: Single octet that specifies the priority of the 218 advertisement. 220 Sub-TLVs - optional sub-TLVs. 222 When the router is configured with the local definition of the Flex- 223 Algorithm, the router MUST advertise its local definition in the FAD 224 Sub-TLV. If the local definition of the Flex-Algorithm is not 225 advertised, the inconsistency in the configuration of the Flex- 226 Algorithm on various nodes cannot be detected and traffic routed 227 based on a Flex-Algorithm path may loop permanently. 229 Every router, that is configured to support a particular Flex- 230 Algorithm, MUST select the Flex-Algorithm definition based on the 231 following rules: 233 From the received advertisements of the FAD, select the one(s) 234 with the highest priority. 236 If there are multiple advertisements of the FAD with the same 237 highest priority, select the one that is originated from the 238 router with the highest Router ID. Router ID is required to be 239 advertised in every Router Capability TLV [RFC7981]. 241 If the router has a local definition of the Flex-Algorithm, 242 compare it with the received FAD advertisements using the same 243 rules as have been used to pick the best FAD advertisement, e.g., 244 priority and Router ID. 246 A router that is not configured to support a particular Flex- 247 Algorithm MUST ignore FAD Sub-TLVs advertisements for such Flex- 248 Algorithm. 250 Having a deterministic way that always produces a valid Flex- 251 Algorithm definition avoids conflicts and maximizes the availability 252 of the forwarding for the traffic that is using the Flex-Algorithm 253 paths. 255 Any change in the Flex-Algorithm definition may result in temporary 256 disruption of traffic that is forwarded based on such Flex-Algorithm 257 paths. The impact is similar to any other event that requires 258 network wide convergence 260 The FAD Sub-TLV of the IS-IS Router Capability TLV-242 MUST be 261 propagated throughout the level. It MAY be advertised across level 262 boundaries, if the S-flag in the Router Capability TLV is set. The 263 S-Flag SHOULD not be set by default unless local configuration policy 264 on the originating router indicates domain wide flooding. 266 Flex-Algorithm definition is topology independent. A node which 267 advertises support for a given Flex-Algorithm may support that Flex- 268 Algorithm on any subset of the topologies it supports. Enabling of a 269 supported Flex-Algorithm on a given topology is a matter of local 270 configuration. For a given topology, if out of the set of nodes 271 supporting that topology AND advertising support for a given Flex- 272 Algorithm only a subset of the nodes actually compute/install Flex- 273 Algorithm specific paths in the forwarding plane for that topology, 274 some traffic intended for such topology/Flex-Algorithm could be 275 dropped if forwarded to a node on which the Flex-Algorithm is not 276 enabled on that topology. 278 4.2. Flexible Algorithm Exclude Admin Group Sub-TLV 280 The Flexible-Algorithm definition can specify 'colors' that are used 281 by the operator to exclude links during the Flex-Algorithm path 282 computation. 284 Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub-TLV) is a 285 Sub-TLV of the FAD Sub-TLV. It has the following format: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Length | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Extended Admin Group | 293 +- -+ 294 | ... | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 where: 298 Type: 1 300 Length: variable, dependent on the size of the Extended Admin 301 Group. MUST be a multiple of 4 octets. 303 Extended Administrative Group: Extended Administrative Group as 304 defined in [RFC7308]. 306 FAEAG Sub-TLV SHOULD only appear once in FAD Sub-TLV. If it appears 307 more then once, FAD Sub-TLV MUST be ignored by the receiver. 309 4.3. Flexible Algorithm Include Admin Group Sub-TLVs 311 The Flexible-Algorithm definition can specify 'colors' that are used 312 by the operator to include links during the Flex-Algorithm path 313 computation. 315 The format of the include Sub-TLVs is identical to the format of the 316 FAEAG Sub-TLV in Section 4.2. 318 Two forms of inclusion are available - include-any and include-all. 320 Flexible Algorithm Include-Any Admin Group Sub-TLV - Type 2. 322 Flexible Algorithm Include-All Admin Group Sub-TLV - Type 3. 324 Flexible Algorithm Include Admin Group Sub-TLVs SHOULD only appear 325 once in FAD Sub-TLV. If any of these Sub-TLVs appear more then once, 326 FAD Sub-TLV MUST be ignored by the receiver. 328 5. Calculation of Flexible Algorithm Paths 330 A router may compute path for multiple Flex-Algorithms. 332 A router MUST be configured to support Flex-Algorithm K before it can 333 compute any path for Flex-Algorithm K. 335 A router MUST either be configured with a local definition of Flex- 336 Algorithm K or receive the definition via the FAD Sub-TLV, as 337 described in Section 4.1, before it can compute any path for Flex- 338 Algorithm K. 340 When computing the path for Flex-Algorithm K, all nodes that do not 341 advertise support for Flex-Algorithm K in SR-Algorithm Sub-TLV 342 ([I-D.ietf-isis-segment-routing-extensions]), MUST be pruned from the 343 topology. 345 When computing the path for Flex-Algorithm K, the metric that is part 346 of the Flex-Algorithm definition (Section 4.1) MUST be used. 348 Various link include or exclude rules can be part of the Flex- 349 Algorithm definition. These rules use Extended Administrative Groups 350 (EAG) as defined in [RFC7308]. [RFC7308] uses term 'colors' as a 351 shorthand to refer to particular bits with an EAG. Link 352 advertisement CAN also include EAG, which describe which color is set 353 on the link. 355 Link advertisement CAN also include Administrative Group (AG) TLV 356 ([RFC5305]). The coexistence of EAG and AG is described in the 357 section 2.3.1 of [RFC7308]. 359 Rules, in the order as specified below, MUST be used to prune link 360 from the topology during the Flex-Algorithm computation. 362 For all links in the topology: 364 1. Check if any exclude rule is part of the Flex-Algorithm 365 definition. If such exclude rule exists, check if any color that 366 is part of the exclude rule is also set on the link. If such a 367 color exist, the link MUST be pruned from the computation. 369 2. Check if any include-any rule is part of the Flex-Algorithm 370 definition. if such include-any rule exists, check if any color 371 that is part of the include-any rule is also set on the link. If 372 such color does not exist, the link MUST be pruned from the 373 computation. 375 3. Check if any include-all rule is part of the Flex-Algorithm 376 definition. If such include-all rule exists, check if all colors 377 that are part of the include-all rule are also set on the link. 378 If not all such colors are set on the link, the link MUST be 379 pruned from the computation. 381 4. If the Flex-Algorithm definition uses other than IGP metric 382 (Section 4.1), and such metric is not advertised for the 383 particular link in a topology for which the computation is done, 384 such link MUST be pruned from the computation. A metric of value 385 0 MUST NOT be assumed in such case. 387 Flex-Algorithm K path MUST be installed in the MPLS forwarding plane 388 using the MPLS label that corresponds to the Prefix-SID that was 389 advertised for algorithm K. If the Prefix SID for algorithm K is not 390 known, the Flex-Algorithm K path to such prefix MUST NOT be installed 391 in the MPLS forwarding plane. 393 Loop Free Alternate (LFA) paths for Flex-Algorithm K path MUST be 394 computed using the same constraints as the calculation of the primary 395 paths for Flex-Algorithm K. LFA path MUST only use Prefix-SIDs 396 advertised specifically for algorithm K to enforce the traffic over 397 such path. LFA path MUST NOT use Adjacency-SID that belong to the 398 link that has been pruned from the computation. 400 If LFA protection is being used to protect Flex-Algorithm K paths, 401 all routers in the area SHOULD advertise at least one Flex-Algorithm 402 K specific Prefix-SID. These Prefix-SIDs are used to enforce traffic 403 over the LFA computed backup path. 405 Flex-Algorithm paths MAY be used by other applications, that do not 406 utilize MPLS forwarding plane. It is outside of the sope of this 407 specification, how these application learn and use the Flex-Algorithm 408 specific paths. 410 Any Shortest Path Tree calculation is limited to a single area. Same 411 applies to Flex-Algorithm calculations. Given that the computing 412 router may not have the visibility to the topology of remote areas, 413 the Flex-Algorithm K path to an inter-area prefix will only be 414 computed for the local area. The egress L1/L2 router will be 415 selected based on the best path for the Flex-Algorithm K in the local 416 area and such egress L1/L2 router will be responsible to compute the 417 best Flex-Algorithm K path over the next area. This may produce end- 418 to-end path, which is not the best from the Flex-Algorithm K 419 perspective. If the best end-to-end path for Flex-Algorithm K needs 420 to be used for inter-area destinations, paths for such destinations 421 need to be computed by the entity that has the topological 422 information about all areas. 424 6. Backward Compatibility 426 This extension brings no new backward compatibility issues. 428 7. Security Considerations 430 This extension adds no new security considerations. 432 8. IANA Considerations 434 This documents request allocation for the following ISIS TLVs and 435 subTLVs. 437 8.1. Sub TLVs for Type 242 439 This document makes the following registrations in the "sub-TLVs for 440 TLV 242" registry. 442 Type: TBD1 (suggested value 24). 444 Description: Flexible Algorithm Definition Sub-TLV. 446 Reference: This document (Section 4.1). 448 8.2. New Sub-Sub-TLV registry 450 This document creates the following Sub-TLV Registry: 452 Registry: Sub-TLVs for Flexible Algorithm Definition Sub-TLV 454 Registration Procedure: Expert review 456 Reference: This document (Section 4.1) 458 This document resisters following Sub-TLVs in the "Sub-TLVs for 459 Flexible Algorithm Definition Sub-TLV" registry: 461 Type: 1 463 Description: Flexible Algorithm Exclude Admin Group Sub-TLV 465 Reference: This document (Section 4.2). 467 Type: 2 468 Description: Flexible Algorithm Include-Any Admin Group Sub-TLV 470 Reference: This document (Section 4.3). 472 Type: 3 474 Description: Flexible Algorithm Include-All Admin Group Sub-TLV 476 Reference: This document (Section 4.3). 478 8.2.1. Flexible Algorithm Definition TLV Metric Registry 480 This document creates the following Registry: 482 Registry: Flexible Algorithm Definition TLV Metric Registry 484 Registration Procedure: Expert review 486 Reference: This document (Section 4.1) 488 This document registers following values in the "Flexible 489 Algorithm Definition TLV Metric Registry": 491 Type: TBD, suggested value 0 493 Description: IGP metric 495 Reference: This document (Section 4.1) 497 Type: TBD, suggested value 1 499 Description: Min Unidirectional Link Delay [RFC7810] 501 Reference: This document (Section 4.1) 503 Type: TBD, suggested value 2 505 Description: TE Default Metric [RFC5305] 507 Reference: This document (Section 4.1) 509 9. Acknowledgments 511 This draft, among other things, is also addressing the problem that 512 the [I-D.gulkohegde-routing-planes-using-sr] was trying to solve. 513 All authors of that draft agreed to join this draft. 515 Thanks to Les Ginsberg and Ketan Talaulikar for review and useful 516 comments. 518 Thanks to Cengiz Halit for his review and feedback during initial 519 phase of the solution definition. 521 10. References 523 10.1. Normative References 525 [I-D.ietf-isis-segment-routing-extensions] 526 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 527 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 528 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 529 segment-routing-extensions-15 (work in progress), December 530 2017. 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, 534 DOI 10.17487/RFC2119, March 1997, 535 . 537 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 538 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 539 2008, . 541 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 542 Traffic Engineering (MPLS-TE)", RFC 7308, 543 DOI 10.17487/RFC7308, July 2014, 544 . 546 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 547 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 548 RFC 7810, DOI 10.17487/RFC7810, May 2016, 549 . 551 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 552 for Advertising Router Information", RFC 7981, 553 DOI 10.17487/RFC7981, October 2016, 554 . 556 10.2. Informative References 558 [I-D.gulkohegde-routing-planes-using-sr] 559 Hegde, S. and a. arkadiy.gulko@thomsonreuters.com, 560 "Separating Routing Planes using Segment Routing", draft- 561 gulkohegde-routing-planes-using-sr-00 (work in progress), 562 March 2017. 564 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 565 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 566 RFC 3906, DOI 10.17487/RFC3906, October 2004, 567 . 569 Authors' Addresses 571 Peter Psenak (editor) 572 Cisco Systems 573 Apollo Business Center 574 Mlynske nivy 43 575 Bratislava, 82109 576 Slovakia 578 Email: ppsenak@cisco.com 580 Shraddha Hegde (editor) 581 Juniper Networks, Inc. 582 Embassy Business Park 583 Bangalore, KA, 560093 584 India 586 Email: shraddha@juniper.net 588 Clarence Filsfils 589 Cisco Systems, Inc. 590 Brussels 591 Belgium 593 Email: cfilsfil@cisco.com 595 Arkadiy Gulko 596 Thomson Reuters 598 Email: arkadiy.gulko@thomsonreuters.com