idnits 2.17.1 draft-ietf-lsr-flex-algo-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 15, 2018) is 2174 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-16 == Outdated reference: A later version (-19) exists of draft-ietf-isis-te-app-04 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-12 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-25 == Outdated reference: A later version (-16) exists of draft-ietf-ospf-te-link-attr-reuse-03 -- 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 (~~), 13 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 16, 2018 Juniper Networks, Inc. 6 C. Filsfils 7 K. Talaulikar 8 Cisco Systems, Inc. 9 A. Gulko 10 Thomson Reuters 11 May 15, 2018 13 IGP Flexible Algorithm 14 draft-ietf-lsr-flex-algo-00.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 16, 2018. 45 Copyright Notice 47 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . 10 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 . 11 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 . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . 15 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 . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 16.1. Normative References . . . . . . . . . . . . . . . . . . 19 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 SIS Flexible Algorithm Include-Any Admin Group Sub- 434 TLV is identical to the format of the FAEAG Sub-TLV in Section 6.1. 436 Flexible Algorithm Include-Any Admin Group Sub-TLV Type is 2. 438 ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV MAY NOT 439 appear more then once in an ISIS FAD Sub-TLV. If it appears more 440 then once, the ISIS FAD Sub-TLV MUST be ignored by the receiver. 442 6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV 444 The Flexible-Algorithm definition can specify 'colors' that are used 445 by the operator to include link during the Flex-Algorithm path 446 computation. 448 ISIS Flexible Algorithm Include-All Admin Group Sub-TLV is used to 449 advertise include-all rule that is used during the Flex-Algorithm 450 path calculation as specified in Section Section 10. 452 The format of the SIS Flexible Algorithm Include-All Admin Group Sub- 453 TLV is identical to the format of the FAEAG Sub-TLV in Section 6.1. 455 ISIS Flexible Algorithm Include-All Admin Group Sub-TLV Type is 3. 457 ISIS Flexible Algorithm Include-All Admin Group Sub-TLV MAY NOT 458 appear more then once in an ISIS FAD Sub-TLV. If it appears more 459 then once, the ISIS FAD Sub-TLV MUST be ignored by the receiver. 461 7. Sub-TLVs of OSPF FAD TLV 462 7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV 464 Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub-TLV) is a 465 Sub-TLV of the OSPF FAD TLV. It's usage is described in Section 6.1. 466 It has the following format: 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type | Length | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Extended Admin Group | 474 +- -+ 475 | ... | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 where: 479 Type: 1 481 Length: variable, dependent on the size of the Extended Admin 482 Group. MUST be a multiple of 4 octets. 484 Extended Administrative Group: Extended Administrative Group as 485 defined in [RFC7308]. 487 OSPF FAEAG Sub-TLV MAY NOT appear more then once in an OSPF FAD TLV. 488 If it appears more then once, the OSPF FAD TLV MUST be ignored by the 489 receiver. 491 7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV 493 The usage of this Sub-TLVs is described in Section 6.2. 495 The format of the OSPF Flexible Algorithm Include-Any Admin Group 496 Sub-TLV is identical to the format of the OSPF FAEAG Sub-TLV in 497 Section 7.1. 499 Flexible Algorithm Include-Any Admin Group Sub-TLV Type is 2. 501 OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV MAY NOT 502 appear more then once in an OPSF FAD TLV. If it appears more then 503 once, the OSPF FAD TLV MUST be ignored by the receiver. 505 7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV 507 The usage of this Sub-TLVs is described in Section 6.3. 509 The format of the OSPF Flexible Algorithm Include-Any Admin Group 510 Sub-TLV is identical to the format of the OSPF FAEAG Sub-TLV in 511 Section 7.1. 513 Flexible Algorithm Include-Any Admin Group Sub-TLV Type is 3. 515 OSPF Flexible Algorithm Include-All Admin Group Sub-TLV MAY NOT 516 appear more then once in an OPSF FAD TLV. If it appears more then 517 once, the OSPF FAD TLV MUST be ignored by the receiver. 519 8. Advertisement of Node Participation in a Flex-Algorithm 521 When a router is configured to support a particular Flex-Algorithm, 522 we say it is participating in that Flex-Algorithm. 524 Paths computed for a specific Flex-Algorithm MAY be used by various 525 applications, each potentially using its own specific data plane for 526 forwarding the data over such paths. To guarantee the presence of 527 the application specific forwarding state associated with a 528 particular Flex-Algorithm, a router MUST advertise its participation 529 for a particular Flex-Algorithm for each application specifically. 531 8.1. Advertisement of Node Participation for Segment Routing 533 [I-D.ietf-isis-segment-routing-extensions], 534 [I-D.ietf-ospf-segment-routing-extensions] and 535 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] (IGP Segment 536 Routing extensions) describe how SR-Algorithm is used to define how 537 the best path is computed by the IGP. 539 Routers advertise the support for the SR-Algorithm as a node 540 capability as described in the above mentioned IGP Segment Routing 541 extensions. To advertise participation for a particular Flex- 542 Algorithm for Segment Routing, the Flex-Algorithm value MUST be 543 advertised in the SR-Algorithm TLV (OSPF) or sub-TLV (ISIS). 545 Segment Routing Flex-Algorithm participation advertisement is 546 topology independent. When a router advertises participation in an 547 SR-Algorithm, the participation applies to all topologies in which 548 the advertising node participates. 550 8.2. Advertisement of Node Participation for Other Applications 552 This section describes considerations related to how other 553 applications can advertise its participation in a specific Flex- 554 Algorithm. 556 Application specific Flex-Algorithm participation advertisements MAY 557 be topology specific or MAY be topology independent, depending on the 558 application itself. 560 Application specific advertisement for Flex-Algorithm participation 561 MUST be defined for each application and is outside of the scope of 562 this document. 564 9. Advertisement of Link Attributes for Flex-Algorithm 566 Various link include or exclude rules can be part of the Flex- 567 Algorithm definition. These rules use Admin Groups (AG) as defined 568 in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG) 569 as defined in [RFC7308]. 571 To advertise a link affinity in a form of the AG or EAG that is used 572 during Flex-Algorithm calculation, an Application Specific Link 573 Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV 574 of Extended Link TLV as described in 575 [I-D.ietf-ospf-te-link-attr-reuse] MUST be used. The advertisement 576 MUST indicate that it is usable by the Flex-Algorithm application. 578 10. Calculation of Flexible Algorithm Paths 580 A router MUST be configured to participate in a given Flex-Algorithm 581 K before it can compute any path for that Flex-Algorithm. 583 A router which participates in a given Flex Algorithm MUST use the 584 FAD selected based on the rules defined in Section Section 5.3. 586 As described in Section 8, participation for any particular Flex- 587 Algorithm MUST be advertised on a per application basis. Calculation 588 of the paths for any particular Flex-Algorithm MUST be application 589 specific. 591 The way applications handle nodes that do not participate in 592 Flexible-Algorithm is application specific. If the application only 593 wants to consider participating nodes during the Flex-Algorithm 594 calculation, then when computing paths for a given Flex-Algorithm, 595 all nodes that do not advertise participation for that Flex-Algorithm 596 in the application specific advertisements MUST be pruned from the 597 topology. MPLS Segment Routing is an application that MUST use such 598 pruning when computing Flex-Algorithm paths. 600 When computing the path for a give Flex-Algorithm, the metric-type 601 that is part of the Flex-Algorithm definition (Section 5) MUST be 602 used. 604 When computing the path for a given Flex-Algorithm, the calculation- 605 type that is part of the Flex-Algorithm definition (Section 5) MUST 606 be used. 608 Various link include or exclude rules can be part of the Flex- 609 Algorithm definition. To refer to particular bit within an AG or EAG 610 we uses term 'color'. 612 Rules, in the order as specified below, MUST be used to prune link 613 from the topology during the Flex-Algorithm computation. 615 For all links in the topology: 617 1. Check if any exclude rule is part of the Flex-Algorithm 618 definition. If such exclude rule exists, check if any color that 619 is part of the exclude rule is also set on the link. If such a 620 color exist, the link MUST be pruned from the computation. 622 2. Check if any include-any rule is part of the Flex-Algorithm 623 definition. if such include-any rule exists, check if any color 624 that is part of the include-any rule is also set on the link. If 625 such color does not exist, the link MUST be pruned from the 626 computation. 628 3. Check if any include-all rule is part of the Flex-Algorithm 629 definition. If such include-all rule exists, check if all colors 630 that are part of the include-all rule are also set on the link. 631 If not all such colors are set on the link, the link MUST be 632 pruned from the computation. 634 4. If the Flex-Algorithm definition uses other than IGP metric 635 (Section 5), and such metric is not advertised for the particular 636 link in a topology for which the computation is done, such link 637 MUST be pruned from the computation. A metric of value 0 MUST NOT 638 be assumed in such case. 640 Any IGP Shortest Path Tree calculation is limited to a single area. 641 Same applies to Flex-Algorithm calculations. Given that the 642 computing router may not have the visibility to the topology of 643 remote areas, the Flex-Algorithm specific path to an inter-area 644 prefix will only be computed for the local area only. The egress L1/ 645 L2 router (ABR in OSPF) will be selected based on the best path for 646 the given Flex-Algorithm in the local area and such egress L1/L2 (ABR 647 in OSPF) router will be responsible to compute the best Flex- 648 Algorithm specific path over the next area. This may produce an end- 649 to-end path, which is sub-optimal based on Flex-Algorithm 650 constraints. If the best end-to-end path for a given Flex-Algorithm 651 needs to be used for inter-area destinations, paths for such 652 destinations need to be computed by the entity that has the 653 topological information about all areas. 655 11. Flex-Algorithm and Forwarding Plane 657 This section describes how Flex-Algorithm paths are used with 658 forwarding. 660 11.1. Segment Routing MPLS Forwarding for Flex-Algorithm 662 This section describes how Flex-Algorithm paths are used with SR MPLS 663 forwarding. 665 Prefix SID advertisements include an SR-Algorithm value and as such 666 are associated with the specified SR-Algorithm. Prefix-SIDs are also 667 associated with a specific topology which is inherited from the 668 associated prefix reachability advertisement. When the algorithm 669 value advertised is a Flex-Algorithm value, the Prefix SID is 670 associated with paths calculated using that Flex-Algorithm in the 671 associated topology. 673 A Flex-Algorithm path MUST be installed in the MPLS forwarding plane 674 using the MPLS label that corresponds to the Prefix-SID that was 675 advertised for that Flex-algorithm. If the Prefix SID for a given 676 Flex-algorithm is not known, the Flex-Algorithm specific path cannot 677 be installed in the MPLS forwarding plane. 679 Traffic that is supposed to be routed via Flex-Algorithm specific 680 paths, MUST be dropped where there are no such paths available. 682 Loop Free Alternate (LFA) paths for a given Flex-Algorithm MUST be 683 computed using the same constraints as the calculation of the primary 684 paths for that Flex-Algorithm. LFA paths MUST only use Prefix-SIDs 685 advertised specifically for the given algorithm. LFA paths MUST NOT 686 use an Adjacency-SID that belongs to a link that has been pruned from 687 the Flex-Algorithm computation. 689 If LFA protection is being used to protect a given Flex-Algorithm 690 paths, all routers in the area participating in the given Flex- 691 Algorithm SHOULD advertise at least one Flex-Algorithm specific Node- 692 SID. These Node-SIDs are used to enforce traffic over the LFA 693 computed backup path. 695 11.2. Other Applications' Forwarding for Flex-Algorithm 697 Any application that wants to use Flex-Algorithm specific forwarding 698 need to install some form of Flex-Algorithm specific forwarding 699 entries. 701 Application specific forwarding for Flex-Algorithm MUST be defined 702 for each application and is outside of the scope of this document. 704 12. Backward Compatibility 706 This extension brings no new backward compatibility issues. 708 13. Security Considerations 710 This draft adds a two new ways to disrupt the IGP networks: 712 An attacker can hijack a particular Flex-Algorithm by advertising 713 a FAD with a priority of 255 (or any priority higher than that of 714 the legitimate nodes). 716 An attacker could make it look like a router supports a particular 717 Flex-Algorithm when it actually doesn't, or vice versa. 719 Both of these attacks can be addressed by the existing security 720 extensions as described in [RFC5304] and [RFC5310] for ISIS, in 721 [RFC2328] and [RFC7474] for OSPFv2 and in [RFC5340] and [RFC4552] for 722 OSPFv3. 724 14. IANA Considerations 726 14.1. IGP IANA Considerations 728 14.1.1. IGP Algorithm Types Registry 730 This document makes the following registrations in the "IGP Algorithm 731 Types" registry: 733 Type: 128-255. 735 Description: Flexible Algorithms. 737 Reference: This document (Section 4). 739 14.1.2. Flexible Algorithm Definition Metric-Type Registry 741 IANA is requested to set up a registry called "Flexible Algorithm 742 Definition Metric-Type Registry" under a "Interior Gateway Protocol 743 (IGP) Parameters" IANA registries. The registration policy for this 744 registry is "Standards Action" ([RFC8126] and [RFC7120]). 746 Values in this registry come from the range 0-255. 748 This document registers following values in the "Flexible Algorithm 749 Definition Metric-Type Registry": 751 Type: 0 753 Description: IGP metric 755 Reference: This document (Section 5.1) 757 Type: 1 759 Description: Min Unidirectional Link Delay [RFC7810] 761 Reference: This document (Section 5.1) 763 Type: 2 765 Description: TE Default Metric [RFC5305] 767 Reference: This document (Section 5.1) 769 14.2. ISIS IANA Considerations 771 14.2.1. Sub TLVs for Type 242 773 This document makes the following registrations in the "sub-TLVs for 774 TLV 242" registry. 776 Type: TBD (suggested value 26). 778 Description: Flexible Algorithm Definition Sub-TLV. 780 Reference: This document (Section 5.1). 782 14.2.2. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 784 This document creates the following Sub-Sub-TLV Registry: 786 Registry: Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 788 Registration Procedure: Expert review 790 Reference: This document (Section 5.1) 792 This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs 793 for Flexible Algorithm Definition Sub-TLV" registry: 795 Type: 1 796 Description: Flexible Algorithm Exclude Admin Group Sub-TLV 798 Reference: This document (Section 6.1). 800 Type: 2 802 Description: Flexible Algorithm Include-Any Admin Group Sub-TLV 804 Reference: This document (Section 6.2). 806 Type: 3 808 Description: Flexible Algorithm Include-All Admin Group Sub-TLV 810 Reference: This document (Section 6.3). 812 14.3. OSPF IANA Considerations 814 14.3.1. OSPF Router Information (RI) TLVs Registry 816 This specification updates the OSPF Router Information (RI) TLVs 817 Registry with the following value: 819 o TBD (suggested value 16) - Flexible Algorithm Definition TLV 821 14.3.2. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry 823 This document creates the following registry: 825 Registry: OSPF Flexible Algorithm Definition TLV sub-TLV 827 Registration Procedure: Expert review 829 Reference: This document (Section 5.2) 831 The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry will 832 define sub-TLVs at any level of nesting for Flexible Algorithm TLV 833 and should be added to the "Open Shortest Path First (OSPF) 834 Parameters" registries group. New values can be allocated via IETF 835 Review or IESG Approval. 837 This document resisters following Sub-TLVs in the "TLVs for Flexible 838 Algorithm Definition TLV" registry: 840 Type: 1 842 Description: Flexible Algorithm Exclude Admin Group Sub-TLV 843 Reference: This document (Section 7.1). 845 Type: 2 847 Description: Flexible Algorithm Include-Any Admin Group Sub-TLV 849 Reference: This document (Section 7.2). 851 Type: 3 853 Description: Flexible Algorithm Include-All Admin Group Sub-TLV 855 Reference: This document (Section 7.3). 857 Types in the range 32768-33023 are for experimental use; these will 858 not be registered with IANA, and MUST NOT be mentioned by RFCs. 860 Types in the range 33024-65535 are not to be assigned at this time. 861 Before any assignments can be made in the 33024-65535 range, there 862 MUST be an IETF specification that specifies IANA Considerations that 863 covers the range being assigned. 865 15. Contributors 867 This draft, among other things, is also addressing the problem that 868 the [I-D.gulkohegde-routing-planes-using-sr] was trying to solve. 869 All authors of that draft agreed to join this draft. 871 Thanks to Eric Rosen, Les Ginsberg and Tony Przygienda for their 872 detailed review and excellent comments. 874 Thanks to Cengiz Halit for his review and feedback during initial 875 phase of the solution definition. 877 Thanks to Kenji Kumaki for his comments. 879 16. References 881 16.1. Normative References 883 [BCP14] , . 885 [I-D.ietf-isis-segment-routing-extensions] 886 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 887 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 888 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 889 segment-routing-extensions-16 (work in progress), April 890 2018. 892 [I-D.ietf-isis-te-app] 893 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 894 J. Drake, "IS-IS TE Attributes per application", draft- 895 ietf-isis-te-app-04 (work in progress), April 2018. 897 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 898 Psenak, P., Filsfils, C., Previdi, S., Gredler, H., 899 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 900 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 901 segment-routing-extensions-12 (work in progress), April 902 2018. 904 [I-D.ietf-ospf-segment-routing-extensions] 905 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 906 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 907 Extensions for Segment Routing", draft-ietf-ospf-segment- 908 routing-extensions-25 (work in progress), April 2018. 910 [I-D.ietf-ospf-te-link-attr-reuse] 911 Psenak, P., Lindem, A., Ginsberg, L., Henderickx, W., 912 Tantsura, J., Gredler, H., and J. Drake, "OSPFv2 Link 913 Traffic Engineering (TE) Attribute Reuse", draft-ietf- 914 ospf-te-link-attr-reuse-03 (work in progress), January 915 2018. 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 1025 Clarence Filsfils 1026 Cisco Systems, Inc. 1027 Brussels 1028 Belgium 1030 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