idnits 2.17.1 draft-ietf-lsr-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 ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [BCP14], but that reference does not seem to mention RFC 2119 either. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == 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 RI LSA can be advertised at any of the defined opaque flooding scopes (link, area, or Autonomous System (AS)). For the purpose of OSPF FAD TLV advertisement, area-scoped flooding is REQUIRED. The Autonomous System flooding scope SHOULD not be used by default unless local configuration policy on the originating router indicates domain wide flooding. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: ISIS FAEAG Sub-TLV MAY NOT appear more then once in an ISIS FAD Sub-TLV. If it appears more then once, the ISIS FAD Sub-TLV MUST be ignored by the receiver. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV MAY NOT appear more then once in an ISIS FAD Sub-TLV. If it appears more then once, the ISIS FAD Sub-TLV MUST be ignored by the receiver. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: ISIS Flexible Algorithm Include-All Admin Group Sub-TLV MAY NOT appear more then once in an ISIS FAD Sub-TLV. If it appears more then once, the ISIS FAD Sub-TLV MUST be ignored by the receiver. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: OSPF FAEAG Sub-TLV MAY NOT appear more then once in an OSPF FAD TLV. If it appears more then once, the OSPF FAD TLV MUST be ignored by the receiver. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV MAY NOT appear more then once in an OPSF FAD TLV. If it appears more then once, the OSPF FAD TLV MUST be ignored by the receiver. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: OSPF Flexible Algorithm Include-All Admin Group Sub-TLV MAY NOT appear more then once in an OPSF FAD TLV. If it appears more then once, the OSPF FAD TLV MUST be ignored by the receiver. -- The document date (May 13, 2019) is 1811 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. 'BCP14' == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-24 == Outdated reference: A later version (-19) exists of draft-ietf-isis-te-app-06 == Outdated reference: A later version (-16) exists of draft-ietf-ospf-te-link-attr-reuse-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). 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 5 Expires: November 14, 2019 Juniper Networks, Inc. 6 C. Filsfils 7 K. Talaulikar 8 Cisco Systems, Inc. 9 A. Gulko 10 Thomson Reuters 11 May 13, 2019 13 IGP Flexible Algorithm 14 draft-ietf-lsr-flex-algo-02.txt 16 Abstract 18 IGP protocols traditionally compute best paths over the network based 19 on the IGP metric assigned to the links. Many network deployments 20 use RSVP-TE based or Segment Routing based Traffic Engineering to 21 enforce traffic over a path that is computed using different metrics 22 or constraints than the shortest IGP path. This document proposes a 23 solution that allows IGPs themselves to compute constraint based 24 paths over the network. This document also specifies a way of using 25 Segment Routing Prefix-SIDs to steer packets along the constraint- 26 based paths. 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 https://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 November 14, 2019. 45 Copyright Notice 47 Copyright (c) 2019 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 (https://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 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Flexible Algorithm . . . . . . . . . . . . . . . . . . . . . 4 66 5. Flexible Algorithm Definition Advertisement . . . . . . . . . 5 67 5.1. ISIS Flexible Algorithm Definition Sub-TLV . . . . . . . 5 68 5.2. OSPF Flexible Algorithm Definition TLV . . . . . . . . . 7 69 5.3. Common Handling of Flexible Algorithm Definition TLV . . 8 70 6. Sub-TLVs of ISIS FAD Sub-TLV . . . . . . . . . . . . . . . . 9 71 6.1. ISIS Flexible Algorithm Exclude Admin Group Sub-TLV . . . 9 72 6.2. ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV . 10 73 6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV . 10 74 7. Sub-TLVs of OSPF FAD TLV . . . . . . . . . . . . . . . . . . 11 75 7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV . . . 11 76 7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV . 11 77 7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV . 12 78 8. Advertisement of Node Participation in a Flex-Algorithm . . . 12 79 8.1. Advertisement of Node Participation for Segment Routing . 12 80 8.2. Advertisement of Node Participation for Other 81 Applications . . . . . . . . . . . . . . . . . . . . . . 13 82 9. Advertisement of Link Attributes for Flex-Algorithm . . . . . 13 83 10. Calculation of Flexible Algorithm Paths . . . . . . . . . . . 13 84 11. Flex-Algorithm and Forwarding Plane . . . . . . . . . . . . . 15 85 11.1. Segment Routing MPLS Forwarding for Flex-Algorithm . . . 15 86 11.2. Other Applications' Forwarding for Flex-Algorithm . . . 16 87 12. Backward Compatibility . . . . . . . . . . . . . . . . . . . 16 88 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 14.1. IGP IANA Considerations . . . . . . . . . . . . . . . . 16 91 14.1.1. IGP Algorithm Types Registry . . . . . . . . . . . . 16 92 14.1.2. Flexible Algorithm Definition Metric-Type Registry . 17 94 14.2. ISIS IANA Considerations . . . . . . . . . . . . . . . . 17 95 14.2.1. Sub TLVs for Type 242 . . . . . . . . . . . . . . . 17 96 14.2.2. Sub-Sub-TLVs for Flexible Algorithm Definition Sub- 97 TLV . . . . . . . . . . . . . . . . . . . . . . . . 17 98 14.3. OSPF IANA Considerations . . . . . . . . . . . . . . . . 18 99 14.3.1. OSPF Router Information (RI) TLVs Registry . . . . . 18 100 14.3.2. OSPF Flexible Algorithm Definition TLV Sub-TLV 101 Registry . . . . . . . . . . . . . . . . . . . . . . 18 102 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 103 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 105 16.2. Informative References . . . . . . . . . . . . . . . . . 21 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 108 1. Introduction 110 An IGP computed path based on the shortest IGP metric must often be 111 replaced by traffic engineered path due to the traffic requirements 112 which are not reflected by the IGP metric. Some networks engineer 113 the IGP metric assignments in a way that the IGP Metric reflects the 114 link bandwidth or delay. If, for example, the IGP metric is 115 reflecting the bandwidth on the link and the application traffic is 116 delay sensitive, the best IGP path may not reflect the best path from 117 such application's perspective. 119 To overcome this limitation, various sorts of traffic engineering 120 have been deployed, including RSVP-TE and SR-TE, in which case the TE 121 component is responsible for computing the path based on additional 122 metrics and/or constraints. Such paths need to be installed in the 123 forwarding tables in addition to, or as a replacement for the 124 original paths computed by IGPs. Tunnels are often used to represent 125 the engineered paths and mechanisms like one described in [RFC3906] 126 are used to replace the native IGP paths with such tunnel paths. 128 This document specifies a set of extensions to ISIS, OSPFv2 and 129 OSPFv3 that enable a router to send TLVs that (a) describe a set of 130 constraints on the topology, (b) identify calculation-type, and (c) 131 metric-type that are to be used to compute the best paths along the 132 constrained topology. A given combination of calculation-type, 133 metric-type and constraints is known as a "Flexible Algorithm 134 Definition". A router that sends such a set of TLVs also assigns a 135 specific value, Flex-Algorithm, to the specified combination of 136 calculation-type, metric-type and constraints. 138 This document also specifies a way for a router to use IGPs to 139 associate one or more Segment Routing Prefix-SIDs with a particular 140 Flex-Algorithm. Each such Prefix-SID then represents a path that is 141 computed according to the identified Flex-Algorithm. 143 2. Requirements notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 [BCP14] [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 3. Terminology 153 This section defines terms that are often used in this document. 155 Flexible Algorithm Definition - the set consisting of (a) 156 calculation-type, (b) metric-type and (c) a set of constraints. 158 Flexible Algorithm - a numeric identifier in the range 128-255 that 159 is associated via provisioning with the Flexible-Algorithm 160 Definition. 162 Local Flexible Algorithm Definition - Flexible Algorithm Definition 163 defined locally on the node. 165 Remote Flexible Algorithm Definition - Flexible Algorithm Definition 166 received from other nodes via IGP flooding. 168 Flexible Algorithm Participation - per application configuration 169 state that expresses whether the node is participating in a 170 particular Flexible Algorithm. 172 IGP Algorithm - value from the the "IGP Algorithm Types" registry 173 defined under "Interior Gateway Protocol (IGP) Parameters" IANA 174 registries. IGP Algorithms represents the triplet (Calculation Type, 175 Metric, Constraints), where the second and third elements of the 176 triple MAY not exist. 178 4. Flexible Algorithm 180 Many possible constraints may be used to compute a path over a 181 network. Some networks are deployed as multiple planes. A simple 182 form of constraint may be to use a particular plane. A more 183 sophisticated form of constraint can include some extended metric as 184 described in [RFC7810]. Constraints which restrict paths to links 185 with specific affinities or avoid links with specific affinities are 186 also possible. Combinations of these are also possible. 188 To provide maximum flexibility, we want to provide a mechanism that 189 allows a router to (a) identify a particular calculation-type, (b) 190 metric-type, (c) describe a particular set of constraints, and (d) 191 assign a numeric identifier, referred to as Flex-Algorithm, to the 192 combination of that calculation-type, metric-type and those 193 constraints. We want the mapping between the Flex-Algorithm and it's 194 meaning to be flexible and defined by the user. As long as all 195 routers in the domain have a common understanding as to what a 196 particular Flex-Algorithm represents, the resulting routing 197 computation is consistent and traffic is not subject to any looping. 199 The set consisting of (a) calculation-type, (b) metric-type and (c) a 200 set of constraints is referred to as a Flexible-Algorithm Definition. 202 Flexible-Algorithm is a numeric identifier in the range 128-255 that 203 is associated via provisioning with the Flexible-Algorithm 204 Definition. 206 IANA "IGP Algorithm Types" registry defines the set of values for IGP 207 Algorithms. We propose to allocate the following values for Flex- 208 Algorithms from this registry: 210 128-255 - Flex-Algorithms 212 5. Flexible Algorithm Definition Advertisement 214 To guarantee the loop free forwarding for paths computed for a 215 particular Flex-Algorithm, all routers that (a) are configured to 216 participate in a particular Flex-Algorithm, and (b) are in the same 217 Flex-Algorithm definition advertisement scope MUST agree on the 218 definition of the Flex-Algorithm. 220 5.1. ISIS Flexible Algorithm Definition Sub-TLV 222 ISIS Flexible Algorithm Definition Sub-TLV (FAD Sub-TLV) is used to 223 advertise the definition of the Flex-Algorithm. 225 ISIS FAD Sub-TLV is advertised as a Sub-TLV of the ISIS Router 226 Capability TLV-242 that is defined in [RFC7981]. 228 ISIS FAD Sub-TLV has the following format: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Length |Flex-Algorithm | Metric-Type | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Calc-Type | Priority | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Sub-TLVs | 238 + + 239 | ... | 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 where: 246 Type: TBD, suggested value 26 248 Length: variable, dependent on the included Sub-TLVs 250 Flex-Algorithm: Single octet value between 128 and 255 inclusive. 252 Metric-Type: Type of metric to be used during the calculation. 253 Following values are defined: 255 0: IGP Metric 257 1: Min Unidirectional Link Delay as defined in [RFC7810]. 259 2: TE default metric as defined in [RFC5305]. 261 Calc-Type: value from 0 to 127 inclusive from the "IGP Algorithm 262 Types" registry defined under "Interior Gateway Protocol (IGP) 263 Parameters" IANA registries. IGP algorithms in the range of 0-127 264 have a defined triplet (Calculation Type, Metric, Constraints). 265 When used to specify the Calc-Type in the FAD Sub-TLV, only the 266 Calculation Type defined for the specified IGP Algorithm is used. 267 The Metric/Constraints MUST NOT be inherited. If the required 268 calculation type is Shortest Path First, the value 0 SHOULD appear 269 in this field. 271 Priority: Value between 0 and 255 inclusive that specifies the 272 priority of the advertisement. 274 Sub-TLVs - optional sub-TLVs. 276 The ISIS FAD Sub-TLV MAY be flooded only in a given level or 277 throughout the domain. In the latter case the S-flag is set as 278 described in [RFC7981]. It is recommended that domain-wide flooding 279 NOT be the default behavior. 281 5.2. OSPF Flexible Algorithm Definition TLV 283 OSPF FAD TLV is advertised as a top-level TLV of the RI LSA that is 284 defined in [RFC7770]. 286 OSPF FAD TLV has the following format: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |Flex-Algorithm | Metric-Type | Calc-Type | Priority | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Sub-TLVs | 296 + + 297 | ... | 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 where: 304 Type: TBD, suggested value 16 306 Length: variable, dependent on the included Sub-TLVs 308 Flex-Algorithm:: Flex-Algorithm number. Value between 128 and 255 309 inclusive. 311 Metric-Type: as described in Section 5.1 313 Calc-Type: as described in Section 5.1 315 Priority: as described in Section 5.1 317 Sub-TLVs - optional sub-TLVs. 319 When multiple OPSF FAD TLVs, for the same Flexible-Algorithm, are 320 received from a given router, the receiver MUST use the first 321 occurrence of the TLV in the Router Information LSA. If the OSPF FAD 322 TLV, for the same Flex-Algorithm, appears in multiple Router 323 Information LSAs that have different flooding scopes, the OSPF FAD 324 TLV in the Router Information LSA with the area-scoped flooding scope 325 MUST be used. If the OSPF FAD TLV, for the same algorithm, appears 326 in multiple Router Information LSAs that have the same flooding 327 scope, the OSPF FAD TLV in the Router Information (RI) LSA with the 328 numerically smallest Instance ID MUST be used and subsequent 329 instances of the OSPF FAD TLV MUST be ignored. 331 The RI LSA can be advertised at any of the defined opaque flooding 332 scopes (link, area, or Autonomous System (AS)). For the purpose of 333 OSPF FAD TLV advertisement, area-scoped flooding is REQUIRED. The 334 Autonomous System flooding scope SHOULD not be used by default unless 335 local configuration policy on the originating router indicates domain 336 wide flooding. 338 5.3. Common Handling of Flexible Algorithm Definition TLV 340 This section describes the protocol independent handling of the FAD 341 TLV (OSPF) or FAD Sub-TLV (ISIS). We will refer to it as FAD TLV in 342 this section, even though in case of ISIS it is a Sub-TLV. 344 The value of the Flex-Algorithm MUST be between 128 and 255 345 inclusive. If it is not, the FAD TLV MUST be ignored. 347 Not every router configured to participate in a particular Flex- 348 Algorithm need a local definition of such Flex-Algorithm. Only a 349 subset of the routers participating in the particular Flex-Algorithm 350 need the local definition of the Flex-Algorithm. 352 Every router, that is configured to participate in a particular Flex- 353 Algorithm, MUST select the Flex-Algorithm definition based on the 354 following ordered rules. This allows for the consistent Flex- 355 Algorithm definition selection in cases where different routers 356 advertise different definitions for a given Flex-Algorithm: 358 1. From the advertisements of the FAD in the area (including both 359 locally generated advertisements and received advertisements) 360 select the one(s) with the highest priority. 362 2. If there are multiple advertisements of the FAD with the same 363 highest priority, select the one that is originated from the 364 router with the highest System-ID in case of ISIS or Router ID in 365 case of OSPFv2 and OSPFv3. For ISIS the System-ID is described in 366 [ISO10589]. For OSPFv2 and OSPFv3 standard Router ID is described 367 in [RFC2328] and [RFC5340] respectively. 369 A router that is not configured to participate in a particular Flex- 370 Algorithm MUST ignore FAD Sub-TLVs advertisements for such Flex- 371 Algorithm. 373 Any change in the Flex-Algorithm definition may result in temporary 374 disruption of traffic that is forwarded based on such Flex-Algorithm 375 paths. The impact is similar to any other event that requires 376 network wide convergence. 378 If a node is configured to participate in a particular Flexible- 379 Algorithm, but the selected Flex-Algorithm definition includes 380 calculation-type, metric-type or constraint that is not supported by 381 the node, it MUST stop participating in such Flexible-Algorithm. 382 That implies that it MUST NOT announce participation for such 383 Flexible-Algorithm and it MUST remove any forwarding state associated 384 with it. 386 Flex-Algorithm definition is topology independent. It applies to all 387 topologies that a router participates in. 389 6. Sub-TLVs of ISIS FAD Sub-TLV 391 6.1. ISIS Flexible Algorithm Exclude Admin Group Sub-TLV 393 The Flexible-Algorithm definition can specify 'colors' that are used 394 by the operator to exclude links during the Flex-Algorithm path 395 computation. 397 Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub-TLV) is a 398 Sub-TLV of the ISIS FAD Sub-TLV. It has the following format: 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type | Length | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Extended Admin Group | 406 +- -+ 407 | ... | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 where: 411 Type: 1 413 Length: variable, dependent on the size of the Extended Admin 414 Group. MUST be a multiple of 4 octets. 416 Extended Administrative Group: Extended Administrative Group as 417 defined in [RFC7308]. 419 ISIS FAEAG Sub-TLV MAY NOT appear more then once in an ISIS FAD Sub- 420 TLV. If it appears more then once, the ISIS FAD Sub-TLV MUST be 421 ignored by the receiver. 423 6.2. ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV 425 The Flexible-Algorithm definition can specify 'colors' that are used 426 by the operator to include link during the Flex-Algorithm path 427 computation. 429 ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV is used to 430 advertise include-any rule that is used during the Flex-Algorithm 431 path calculation as specified in Section Section 10. 433 The format of the ISIS Flexible Algorithm Include-Any Admin Group 434 Sub-TLV is identical to the format of the FAEAG Sub-TLV in 435 Section 6.1. 437 Flexible Algorithm Include-Any Admin Group Sub-TLV Type is 2. 439 ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV MAY NOT 440 appear more then once in an ISIS FAD Sub-TLV. If it appears more 441 then once, the ISIS FAD Sub-TLV MUST be ignored by the receiver. 443 6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV 445 The Flexible-Algorithm definition can specify 'colors' that are used 446 by the operator to include link during the Flex-Algorithm path 447 computation. 449 ISIS Flexible Algorithm Include-All Admin Group Sub-TLV is used to 450 advertise include-all rule that is used during the Flex-Algorithm 451 path calculation as specified in Section Section 10. 453 The format of the ISIS Flexible Algorithm Include-All Admin Group 454 Sub-TLV is identical to the format of the FAEAG Sub-TLV in 455 Section 6.1. 457 ISIS Flexible Algorithm Include-All Admin Group Sub-TLV Type is 3. 459 ISIS Flexible Algorithm Include-All Admin Group Sub-TLV MAY NOT 460 appear more then once in an ISIS FAD Sub-TLV. If it appears more 461 then once, the ISIS FAD Sub-TLV MUST be ignored by the receiver. 463 7. Sub-TLVs of OSPF FAD TLV 465 7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV 467 Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub-TLV) is a 468 Sub-TLV of the OSPF FAD TLV. It's usage is described in Section 6.1. 469 It has the following format: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Type | Length | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Extended Admin Group | 477 +- -+ 478 | ... | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 where: 482 Type: 1 484 Length: variable, dependent on the size of the Extended Admin 485 Group. MUST be a multiple of 4 octets. 487 Extended Administrative Group: Extended Administrative Group as 488 defined in [RFC7308]. 490 OSPF FAEAG Sub-TLV MAY NOT appear more then once in an OSPF FAD TLV. 491 If it appears more then once, the OSPF FAD TLV MUST be ignored by the 492 receiver. 494 7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV 496 The usage of this Sub-TLVs is described in Section 6.2. 498 The format of the OSPF Flexible Algorithm Include-Any Admin Group 499 Sub-TLV is identical to the format of the OSPF FAEAG Sub-TLV in 500 Section 7.1. 502 Flexible Algorithm Include-Any Admin Group Sub-TLV Type is 2. 504 OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV MAY NOT 505 appear more then once in an OPSF FAD TLV. If it appears more then 506 once, the OSPF FAD TLV MUST be ignored by the receiver. 508 7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV 510 The usage of this Sub-TLVs is described in Section 6.3. 512 The format of the OSPF Flexible Algorithm Include-Any Admin Group 513 Sub-TLV is identical to the format of the OSPF FAEAG Sub-TLV in 514 Section 7.1. 516 Flexible Algorithm Include-Any Admin Group Sub-TLV Type is 3. 518 OSPF Flexible Algorithm Include-All Admin Group Sub-TLV MAY NOT 519 appear more then once in an OPSF FAD TLV. If it appears more then 520 once, the OSPF FAD TLV MUST be ignored by the receiver. 522 8. Advertisement of Node Participation in a Flex-Algorithm 524 When a router is configured to support a particular Flex-Algorithm, 525 we say it is participating in that Flex-Algorithm. 527 Paths computed for a specific Flex-Algorithm MAY be used by various 528 applications, each potentially using its own specific data plane for 529 forwarding the data over such paths. To guarantee the presence of 530 the application specific forwarding state associated with a 531 particular Flex-Algorithm, a router MUST advertise its participation 532 for a particular Flex-Algorithm for each application specifically. 534 8.1. Advertisement of Node Participation for Segment Routing 536 [I-D.ietf-isis-segment-routing-extensions], 537 [I-D.ietf-ospf-segment-routing-extensions] and 538 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] (IGP Segment 539 Routing extensions) describe how SR-Algorithm is used to define how 540 the best path is computed by the IGP. 542 Routers advertise the support for the SR-Algorithm as a node 543 capability as described in the above mentioned IGP Segment Routing 544 extensions. To advertise participation for a particular Flex- 545 Algorithm for Segment Routing, the Flex-Algorithm value MUST be 546 advertised in the SR-Algorithm TLV (OSPF) or sub-TLV (ISIS). 548 Segment Routing Flex-Algorithm participation advertisement is 549 topology independent. When a router advertises participation in an 550 SR-Algorithm, the participation applies to all topologies in which 551 the advertising node participates. 553 8.2. Advertisement of Node Participation for Other Applications 555 This section describes considerations related to how other 556 applications can advertise its participation in a specific Flex- 557 Algorithm. 559 Application specific Flex-Algorithm participation advertisements MAY 560 be topology specific or MAY be topology independent, depending on the 561 application itself. 563 Application specific advertisement for Flex-Algorithm participation 564 MUST be defined for each application and is outside of the scope of 565 this document. 567 9. Advertisement of Link Attributes for Flex-Algorithm 569 Various link include or exclude rules can be part of the Flex- 570 Algorithm definition. These rules use Admin Groups (AG) as defined 571 in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG) 572 as defined in [RFC7308]. 574 To advertise a link affinity in a form of the AG or EAG that is used 575 during Flex-Algorithm calculation, an Application Specific Link 576 Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV 577 of Extended Link TLV as described in 578 [I-D.ietf-ospf-te-link-attr-reuse] MUST be used. The advertisement 579 MUST indicate that it is usable by the Flex-Algorithm application. 581 10. Calculation of Flexible Algorithm Paths 583 A router MUST be configured to participate in a given Flex-Algorithm 584 K before it can compute any path for that Flex-Algorithm. 586 A router which participates in a given Flex Algorithm MUST use the 587 FAD selected based on the rules defined in Section Section 5.3. 589 As described in Section 8, participation for any particular Flex- 590 Algorithm MUST be advertised on a per application basis. Calculation 591 of the paths for any particular Flex-Algorithm MUST be application 592 specific. 594 The way applications handle nodes that do not participate in 595 Flexible-Algorithm is application specific. If the application only 596 wants to consider participating nodes during the Flex-Algorithm 597 calculation, then when computing paths for a given Flex-Algorithm, 598 all nodes that do not advertise participation for that Flex-Algorithm 599 in the application specific advertisements MUST be pruned from the 600 topology. MPLS Segment Routing is an application that MUST use such 601 pruning when computing Flex-Algorithm paths. 603 When computing the path for a give Flex-Algorithm, the metric-type 604 that is part of the Flex-Algorithm definition (Section 5) MUST be 605 used. 607 When computing the path for a given Flex-Algorithm, the calculation- 608 type that is part of the Flex-Algorithm definition (Section 5) MUST 609 be used. 611 Various link include or exclude rules can be part of the Flex- 612 Algorithm definition. To refer to particular bit within an AG or EAG 613 we uses term 'color'. 615 Rules, in the order as specified below, MUST be used to prune link 616 from the topology during the Flex-Algorithm computation. 618 For all links in the topology: 620 1. Check if any exclude rule is part of the Flex-Algorithm 621 definition. If such exclude rule exists, check if any color that 622 is part of the exclude rule is also set on the link. If such a 623 color exist, the link MUST be pruned from the computation. 625 2. Check if any include-any rule is part of the Flex-Algorithm 626 definition. if such include-any rule exists, check if any color 627 that is part of the include-any rule is also set on the link. If 628 such color does not exist, the link MUST be pruned from the 629 computation. 631 3. Check if any include-all rule is part of the Flex-Algorithm 632 definition. If such include-all rule exists, check if all colors 633 that are part of the include-all rule are also set on the link. 634 If not all such colors are set on the link, the link MUST be 635 pruned from the computation. 637 4. If the Flex-Algorithm definition uses other than IGP metric 638 (Section 5), and such metric is not advertised for the particular 639 link in a topology for which the computation is done, such link 640 MUST be pruned from the computation. A metric of value 0 MUST NOT 641 be assumed in such case. 643 Any IGP Shortest Path Tree calculation is limited to a single area. 644 Same applies to Flex-Algorithm calculations. Given that the 645 computing router may not have the visibility to the topology of 646 remote areas, the Flex-Algorithm specific path to an inter-area 647 prefix will only be computed for the local area only. The egress L1/ 648 L2 router (ABR in OSPF) will be selected based on the best path for 649 the given Flex-Algorithm in the local area and such egress L1/L2 (ABR 650 in OSPF) router will be responsible to compute the best Flex- 651 Algorithm specific path over the next area. This may produce an end- 652 to-end path, which is sub-optimal based on Flex-Algorithm 653 constraints. If the best end-to-end path for a given Flex-Algorithm 654 needs to be used for inter-area destinations, paths for such 655 destinations need to be computed by the entity that has the 656 topological information about all areas. 658 11. Flex-Algorithm and Forwarding Plane 660 This section describes how Flex-Algorithm paths are used with 661 forwarding. 663 11.1. Segment Routing MPLS Forwarding for Flex-Algorithm 665 This section describes how Flex-Algorithm paths are used with SR MPLS 666 forwarding. 668 Prefix SID advertisements include an SR-Algorithm value and as such 669 are associated with the specified SR-Algorithm. Prefix-SIDs are also 670 associated with a specific topology which is inherited from the 671 associated prefix reachability advertisement. When the algorithm 672 value advertised is a Flex-Algorithm value, the Prefix SID is 673 associated with paths calculated using that Flex-Algorithm in the 674 associated topology. 676 A Flex-Algorithm path MUST be installed in the MPLS forwarding plane 677 using the MPLS label that corresponds to the Prefix-SID that was 678 advertised for that Flex-algorithm. If the Prefix SID for a given 679 Flex-algorithm is not known, the Flex-Algorithm specific path cannot 680 be installed in the MPLS forwarding plane. 682 Traffic that is supposed to be routed via Flex-Algorithm specific 683 paths, MUST be dropped where there are no such paths available. 685 Loop Free Alternate (LFA) paths for a given Flex-Algorithm MUST be 686 computed using the same constraints as the calculation of the primary 687 paths for that Flex-Algorithm. LFA paths MUST only use Prefix-SIDs 688 advertised specifically for the given algorithm. LFA paths MUST NOT 689 use an Adjacency-SID that belongs to a link that has been pruned from 690 the Flex-Algorithm computation. 692 If LFA protection is being used to protect a given Flex-Algorithm 693 paths, all routers in the area participating in the given Flex- 694 Algorithm SHOULD advertise at least one Flex-Algorithm specific Node- 695 SID. These Node-SIDs are used to enforce traffic over the LFA 696 computed backup path. 698 11.2. Other Applications' Forwarding for Flex-Algorithm 700 Any application that wants to use Flex-Algorithm specific forwarding 701 need to install some form of Flex-Algorithm specific forwarding 702 entries. 704 Application specific forwarding for Flex-Algorithm MUST be defined 705 for each application and is outside of the scope of this document. 707 12. Backward Compatibility 709 This extension brings no new backward compatibility issues. 711 13. Security Considerations 713 This draft adds a two new ways to disrupt the IGP networks: 715 An attacker can hijack a particular Flex-Algorithm by advertising 716 a FAD with a priority of 255 (or any priority higher than that of 717 the legitimate nodes). 719 An attacker could make it look like a router supports a particular 720 Flex-Algorithm when it actually doesn't, or vice versa. 722 Both of these attacks can be addressed by the existing security 723 extensions as described in [RFC5304] and [RFC5310] for ISIS, in 724 [RFC2328] and [RFC7474] for OSPFv2 and in [RFC5340] and [RFC4552] for 725 OSPFv3. 727 14. IANA Considerations 729 14.1. IGP IANA Considerations 731 14.1.1. IGP Algorithm Types Registry 733 This document makes the following registrations in the "IGP Algorithm 734 Types" registry: 736 Type: 128-255. 738 Description: Flexible Algorithms. 740 Reference: This document (Section 4). 742 14.1.2. Flexible Algorithm Definition Metric-Type Registry 744 IANA is requested to set up a registry called "Flexible Algorithm 745 Definition Metric-Type Registry" under a "Interior Gateway Protocol 746 (IGP) Parameters" IANA registries. The registration policy for this 747 registry is "Standards Action" ([RFC8126] and [RFC7120]). 749 Values in this registry come from the range 0-255. 751 This document registers following values in the "Flexible Algorithm 752 Definition Metric-Type Registry": 754 Type: 0 756 Description: IGP metric 758 Reference: This document (Section 5.1) 760 Type: 1 762 Description: Min Unidirectional Link Delay [RFC7810] 764 Reference: This document (Section 5.1) 766 Type: 2 768 Description: TE Default Metric [RFC5305] 770 Reference: This document (Section 5.1) 772 14.2. ISIS IANA Considerations 774 14.2.1. Sub TLVs for Type 242 776 This document makes the following registrations in the "sub-TLVs for 777 TLV 242" registry. 779 Type: TBD (suggested value 26). 781 Description: Flexible Algorithm Definition Sub-TLV. 783 Reference: This document (Section 5.1). 785 14.2.2. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 787 This document creates the following Sub-Sub-TLV Registry: 789 Registry: Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 790 Registration Procedure: Expert review 792 Reference: This document (Section 5.1) 794 This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs 795 for Flexible Algorithm Definition Sub-TLV" registry: 797 Type: 1 799 Description: Flexible Algorithm Exclude Admin Group Sub-TLV 801 Reference: This document (Section 6.1). 803 Type: 2 805 Description: Flexible Algorithm Include-Any Admin Group Sub-TLV 807 Reference: This document (Section 6.2). 809 Type: 3 811 Description: Flexible Algorithm Include-All Admin Group Sub-TLV 813 Reference: This document (Section 6.3). 815 14.3. OSPF IANA Considerations 817 14.3.1. OSPF Router Information (RI) TLVs Registry 819 This specification updates the OSPF Router Information (RI) TLVs 820 Registry with the following value: 822 o TBD (suggested value 16) - Flexible Algorithm Definition TLV 824 14.3.2. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry 826 This document creates the following registry: 828 Registry: OSPF Flexible Algorithm Definition TLV sub-TLV 830 Registration Procedure: Expert review 832 Reference: This document (Section 5.2) 834 The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry will 835 define sub-TLVs at any level of nesting for Flexible Algorithm TLV 836 and should be added to the "Open Shortest Path First (OSPF) 837 Parameters" registries group. New values can be allocated via IETF 838 Review or IESG Approval. 840 This document resisters following Sub-TLVs in the "TLVs for Flexible 841 Algorithm Definition TLV" registry: 843 Type: 1 845 Description: Flexible Algorithm Exclude Admin Group Sub-TLV 847 Reference: This document (Section 7.1). 849 Type: 2 851 Description: Flexible Algorithm Include-Any Admin Group Sub-TLV 853 Reference: This document (Section 7.2). 855 Type: 3 857 Description: Flexible Algorithm Include-All Admin Group Sub-TLV 859 Reference: This document (Section 7.3). 861 Types in the range 32768-33023 are for experimental use; these will 862 not be registered with IANA, and MUST NOT be mentioned by RFCs. 864 Types in the range 33024-65535 are not to be assigned at this time. 865 Before any assignments can be made in the 33024-65535 range, there 866 MUST be an IETF specification that specifies IANA Considerations that 867 covers the range being assigned. 869 15. Contributors 871 This draft, among other things, is also addressing the problem that 872 the [I-D.gulkohegde-routing-planes-using-sr] was trying to solve. 873 All authors of that draft agreed to join this draft. 875 Thanks to Eric Rosen, Les Ginsberg and Tony Przygienda for their 876 detailed review and excellent comments. 878 Thanks to Cengiz Halit for his review and feedback during initial 879 phase of the solution definition. 881 Thanks to Kenji Kumaki for his comments. 883 16. References 885 16.1. Normative References 887 [BCP14] , . 889 [I-D.ietf-isis-segment-routing-extensions] 890 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 891 Gredler, H., and B. Decraene, "IS-IS Extensions for 892 Segment Routing", draft-ietf-isis-segment-routing- 893 extensions-24 (work in progress), April 2019. 895 [I-D.ietf-isis-te-app] 896 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 897 J. Drake, "IS-IS TE Attributes per application", draft- 898 ietf-isis-te-app-06 (work in progress), April 2019. 900 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 901 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 902 Routing", draft-ietf-ospf-ospfv3-segment-routing- 903 extensions-23 (work in progress), January 2019. 905 [I-D.ietf-ospf-segment-routing-extensions] 906 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 907 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 908 Extensions for Segment Routing", draft-ietf-ospf-segment- 909 routing-extensions-27 (work in progress), December 2018. 911 [I-D.ietf-ospf-te-link-attr-reuse] 912 Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J., 913 and J. Drake, "OSPF Link Traffic Engineering (TE) 914 Attribute Reuse", draft-ietf-ospf-te-link-attr-reuse-07 915 (work in progress), April 2019. 917 [ISO10589] 918 International Organization for Standardization, 919 "Intermediate system to Intermediate system intra-domain 920 routeing information exchange protocol for use in 921 conjunction with the protocol for providing the 922 connectionless-mode Network Service (ISO 8473)", ISO/ 923 IEC 10589:2002, Second Edition, Nov 2002. 925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 926 Requirement Levels", BCP 14, RFC 2119, 927 DOI 10.17487/RFC2119, March 1997, 928 . 930 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 931 Traffic Engineering (MPLS-TE)", RFC 7308, 932 DOI 10.17487/RFC7308, July 2014, 933 . 935 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 936 S. Shaffer, "Extensions to OSPF for Advertising Optional 937 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 938 February 2016, . 940 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 941 for Advertising Router Information", RFC 7981, 942 DOI 10.17487/RFC7981, October 2016, 943 . 945 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 946 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 947 May 2017, . 949 16.2. Informative References 951 [I-D.gulkohegde-routing-planes-using-sr] 952 Hegde, S. and a. arkadiy.gulko@thomsonreuters.com, 953 "Separating Routing Planes using Segment Routing", draft- 954 gulkohegde-routing-planes-using-sr-00 (work in progress), 955 March 2017. 957 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 958 DOI 10.17487/RFC2328, April 1998, 959 . 961 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 962 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 963 RFC 3906, DOI 10.17487/RFC3906, October 2004, 964 . 966 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 967 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 968 . 970 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 971 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 972 2008, . 974 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 975 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 976 2008, . 978 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 979 and M. Fanto, "IS-IS Generic Cryptographic 980 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 981 2009, . 983 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 984 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 985 . 987 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 988 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 989 2014, . 991 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 992 "Security Extension for OSPFv2 When Using Manual Key 993 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 994 . 996 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 997 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 998 RFC 7810, DOI 10.17487/RFC7810, May 2016, 999 . 1001 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1002 Writing an IANA Considerations Section in RFCs", BCP 26, 1003 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1004 . 1006 Authors' Addresses 1008 Peter Psenak (editor) 1009 Cisco Systems 1010 Apollo Business Center 1011 Mlynske nivy 43 1012 Bratislava, 82109 1013 Slovakia 1015 Email: ppsenak@cisco.com 1017 Shraddha Hegde 1018 Juniper Networks, Inc. 1019 Embassy Business Park 1020 Bangalore, KA, 560093 1021 India 1023 Email: shraddha@juniper.net 1024 Clarence Filsfils 1025 Cisco Systems, Inc. 1026 Brussels 1027 Belgium 1029 Email: cfilsfil@cisco.com 1031 Ketan Talaulikar 1032 Cisco Systems, Inc. 1033 S.No. 154/6, Phase I, Hinjawadi 1034 PUNE, MAHARASHTRA 411 057 1035 India 1037 Email: ketant@cisco.com 1039 Arkadiy Gulko 1040 Thomson Reuters 1042 Email: arkadiy.gulko@thomsonreuters.com