idnits 2.17.1 draft-ietf-ospf-node-admin-tag-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2328]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2014) is 3475 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) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-lfa-manageability-04 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP S. Hegde 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track H. Raghuveer 5 Expires: April 23, 2015 6 H. Gredler 7 Juniper Networks, Inc. 8 R. Shakir 9 British Telecom 10 A. Smirnov 11 Cisco Systems, Inc. 12 Z. Li 13 Huawei Technologies 14 B. Decraene 15 Orange 16 October 20, 2014 18 Advertising per-node administrative tags in OSPF 19 draft-ietf-ospf-node-admin-tag-00 21 Abstract 23 This document describes an extension to OSPF protocol [RFC2328] to 24 add an optional operational capability, that allows tagging and 25 grouping of the nodes in an OSPF domain. This allows 26 simplification,ease of management and control over route and path 27 selection based on configured policies. 29 This document describes the protocol extensions to disseminate per- 30 node administrative-tags to the OSPFv2 and OSPFv3 protocol. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 23, 2015. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Administrative Tag TLV . . . . . . . . . . . . . . . . . . . 3 75 4. OSPF per-node administrative tag TLV . . . . . . . . . . . . 3 76 4.1. TLV format . . . . . . . . . . . . . . . . . . . . . . . 3 77 4.2. Elements of procedure . . . . . . . . . . . . . . . . . . 4 78 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 5 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 9.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 This document provides mechanisms to advertise per-node 90 administrative tags in the OSPF Router Information LSA [RFC4970]. In 91 certain path-selection applications like for example in traffic- 92 engineering or Loop Free Alternate (LFA) backup selection there is a 93 need to tag the nodes based on their roles in the network and have 94 policies to prefer or prune a certain group of nodes. 96 2. Applicability 98 For the purpose of advertising per-node administrative tags within 99 OSPF a new TLV is proposed. Because path selection is a functional 100 set which applies both to TE and non-TE applications, this new TLV is 101 carried in the Router Information LSA (RI LSA) [RFC4970] 103 3. Administrative Tag TLV 105 An administrative Tag is a 32-bit integer value that can be used to 106 identify a group of nodes in the OSPF domain. 108 The new TLV defined will be carried within an RI LSA for OSPFV2 and 109 OSPFV3. Router information LSA [RFC4970] can have link,area or AS 110 level flooding scope. Choosing the flooding scope to flood the group 111 tags are defined by the policies and is a local matter. 113 The TLV specifies one or more administrative tag values. An OSPF 114 node advertises the set of groups it is part of in the OSPF domain. 115 (for example, all PE-nodes are configured with certain tag value, all 116 P-nodes are configured with a different tag value in a domain). The 117 total number of admin tags that a given router can advertise in one 118 TLV is restricted to 64. If more tags are needed, multiple TLVs can 119 be added in same RI-LSA or in different instance of the RI LSA as 120 defined in [I-D.acee-ospf-rfc4970bis]. 122 4. OSPF per-node administrative tag TLV 124 4.1. TLV format 126 As per [RFC4970], the format of the TLVs within the body of an RI LSA 127 is the same as the format used by the Traffic Engineering Extensions 128 to OSPF [RFC3630]. 130 The LSA payload consists of one or more nested Type/Length/Value 131 (TLV) triplets. The format of each TLV is: 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Type | Length | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Administrative Tag #1 | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Administrative Tag #2 | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 // // 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Administrative Tag #N | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 1: OSPF per-node Administrative Tag TLV 149 Type : TBA 151 Length: A 16-bit field that indicates the length of the value portion 152 in octets and will be a multiple of 4 octets dependent on the number 153 of tags advertised. 155 Value: A sequence of multiple 4 octets defining the administrative 156 tags. The number of tags carried in this TLV is restricted to 64. 157 atleast one tag MUST be carried if this TLV is included in the RI- 158 LSA. 160 4.2. Elements of procedure 162 Meaning of the Node administrative tags is generally opaque to OSPF. 163 Router advertising the per-node administrative tag (or tags) may be 164 configured to do so without knowing (or even explicitly supporting) 165 functionality implied by the tag. 167 Interpretation of tag values is specific to the administrative domain 168 of a particular network operator. The meaning of a per-node 169 administrative tag is defined by the network local policy and is 170 controlled via the configuration. If a receiving node does not 171 understand the tag value, it ignores the specific tag and floods the 172 RI LSA without any change as defined in [RFC4970]. 174 The semantics of the tag order has no meaning. That is, there is no 175 implied meaning to the ordering of the tags that indicates a certain 176 operation or set of operations that need to be performed based on the 177 ordering. 179 Each tag SHOULD be treated as an independent identifier that MAY be 180 used in policy to perform a policy action. Tags carried by the 181 administrative tag TLV SHOULD be used to indicate independent 182 characteristics of a node. The TLV SHOULD be considered an unordered 183 list. Whilst policies may be implemented based on the presence of 184 multiple tags (e.g., if tag A AND tag B are present), they MUST NOT 185 be reliant upon the order of the tags (i.e., all policies should be 186 considered commutative operations, such that tag A preceding or 187 following tag B does not change their outcome). 189 To avoid incomplete or inconsistent interpretations of the per-node 190 administrative tags the same tag value MUST NOT be advertised by a 191 router in RI LSAs of different scopes. The same tag MAY be 192 advertised in multiple RI LSAs of the same scope, for example, OSPF 193 Area Border Router (ABR) may advertise the same tag in area-scope RI 194 LSAs in multiple areas connected to the ABR. 196 The per-node administrative tags are not meant to be extended by the 197 future OSPF standards. The new OSPF extensions MUST NOT require use 198 of per-node administrative tags or define well-known tag values. 199 Node administrative tags are for generic use and do not require IANA 200 registry. The future OSPF extensions requiring well known values MAY 201 define their own data signaling tailored to the needs of the feature 202 or MAY use capability TLV as defined in [RFC4970]. 204 Being part of the RI LSA, the per-node administrative tag TLV must be 205 reasonably small and stable. In particular, but not limited to, 206 implementations supporting the per-node administrative tags MUST NOT 207 tie advertised tags to changes in the network topology (both within 208 and outside the OSPF domain) or reachability of routes. 210 5. Applications 212 This section lists several examples of how implementations might use 213 the Node administrative tags. These examples are given only to 214 demonstrate generic usefulness of the router tagging mechanism. 215 Implementation supporting this specification is not required to 216 implement any of the use cases. It is also worth noting that in some 217 described use cases routers configured to advertise tags help other 218 routers in their calculations but do not themselves implement the 219 same functionality. 221 1. Service auto-discovery 223 Router tagging may be used to automatically discover group of 224 routers sharing a particular service. 226 For example, service provider might desire to establish full mesh 227 of MPLS TE tunnels between all PE routers in the area of MPLS VPN 228 network. Marking all PE routers with a tag and configuring 229 devices with a policy to create MPLS TE tunnels to all other 230 devices advertising this tag will automate maintenance of the 231 full mesh. When new PE router is added to the area, all other PE 232 devices will open TE tunnels to it without the need of 233 reconfiguring them. 235 2. Fast-Rerouting policy 237 Increased deployment of Loop Free Alternates (LFA) as defined in 238 [RFC5286] poses operation and management challenges. 239 [I-D.ietf-rtgwg-lfa-manageability] proposes policies which, when 240 implemented, will ease LFA operation concerns. 242 One of the proposed refinements is to be able to group the nodes 243 in IGP domain with administrative tags and engineer the LFA based 244 on configured policies. 246 (a) Administrative limitation of LFA scope 248 Service provider access infrastructure is frequently designed 249 in layered approach with each layer of devices serving 250 different purposes and thus having different hardware 251 capabilities and configured software features. When LFA 252 repair paths are being computed, it may be desirable to 253 exclude devices from being considered as LFA candidates based 254 on their layer. 256 For example, if the access infrastructure is divided into the 257 Access, Distribution and Core layers it may be desirable for 258 a Distribution device to compute LFA only via Distribution or 259 Core devices but not via Access devices. This may be due to 260 features enabled on Access routers; due to capacity 261 limitations or due to the security requirements. Managing 262 such a policy via configuration of the router computing LFA 263 is cumbersome and error prone. 265 With the Node administrative tags it is possible to assign a 266 tag to each layer and implement LFA policy of computing LFA 267 repair paths only via neighbors which advertise the Core or 268 Distribution tag. This requires minimal per-node 269 configuration and network automatically adapts when new links 270 or routers are added. 272 (b) LFA calculation optimization 273 Calculation of LFA paths may require significant resources of 274 the router. One execution of Dijkstra algorithm is required 275 for each neighbor eligible to become next hop of repair 276 paths. Thus a router with a few hundreds of neighbors may 277 need to execute the algorithm hundreds of times before the 278 best (or even valid) repair path is found. Manually 279 excluding from the calculation neighbors which are known to 280 provide no valid LFA (such as single-connected routers) may 281 significantly reduce number of Dijkstra algorithm runs. 283 LFA calculation policy may be configured so that routers 284 advertising certain tag value are excluded from LFA 285 calculation even if they are otherwise suitable. 287 3. Controlling Remote LFA tunnel termination 289 [I-D.ietf-rtgwg-remote-lfa] proposed method of tunneling traffic 290 after connected link failure to extend the basic LFA coverage and 291 algorithm to find tunnel tail-end routers fitting LFA 292 requirement. In most cases proposed algorithm finds more than 293 one candidate tail-end router. In real life network it may be 294 desirable to exclude some nodes from the list of candidates based 295 on the local policy. This may be either due to known limitations 296 of the node (the router does not accept targeted LDP sessions 297 required to implement Remote LFA tunneling) or due to 298 administrative requirements (for example, it may be desirable to 299 choose tail-end router among co-located devices). 301 The Node administrative tag delivers simple and scalable 302 solution. Remote LFA can be configured with a policy to accept 303 during the tail-end router calculation as candidates only routers 304 advertising certain tag. Tagging routers allows to both exclude 305 nodes not capable of serving as Remote LFA tunnel tail-ends and 306 to define a region from which tail-end router must be selected. 308 4. Mobile backhaul network service deployment 310 The topology of mobile backhaul network usually adopts ring 311 topology to save fiber resource and it is divided into the 312 aggregate network and the access network. Cell Site 313 Gateways(CSGs) connects the eNodeBs and RNC(Radio Network 314 Controller) Site Gateways(RSGs)connects the RNCs. The mobile 315 traffic is transported from CSGs to RSGs. The network takes a 316 typical aggregate traffic model that more than one access rings 317 will attach to one pair of aggregate site gateways(ASGs) and more 318 than one aggregate rings will attach to one pair of RSGs. 320 ---------------- 321 / \ 322 / \ 323 / \ 324 +------+ +----+ Access +----+ 325 |eNodeB|---|CSG1| Ring 1 |ASG1|------------- 326 +------+ +----+ +----+ \ 327 \ / \ 328 \ / +----+ +---+ 329 \ +----+ |RSG1|----|RNC| 330 -------------| | Aggregate +----+ +---+ 331 |ASG2| Ring | 332 -------------| | +----+ +---+ 333 / +----+ |RSG2|----|RNC| 334 / \ +----+ +---+ 335 / \ / 336 +------+ +----+ Access +----+ / 337 |eNodeB|---|CSG2| Ring 2 |ASG3|------------ 338 +------+ +----+ +----+ 339 \ / 340 \ / 341 \ / 342 ----------------- 344 Figure 2: Mobile Backhaul Network 346 A typical mobile backhaul network with access rings and aggregate 347 links is show in figure above. The mobile backhaul networks 348 deploy traffic engineering due to the strict Service Level 349 Agreements(SLA). The TE paths may have additional constraints to 350 avoid passing via different access rings or to get completely 351 disjoint backup TE paths. The mobile backhaul networks towards 352 the access side change frequently due to the growing mobile 353 traffic and addition of new eNodeBs. It's complex to satisfy the 354 requirements using cost, link color or explicit path 355 configurations. The node administrative tag defined in this 356 document can be effectively used to solve the problem for mobile 357 backhaul networks. The nodes in different rings can be assigned 358 with specific tags. TE path computation can be enhanced to 359 consider additional constraints based on node administrative 360 tags. 362 5. Explicit routing policy 364 Partially meshed network provides multiple paths between any two 365 nodes in the network. In a data center environment, the topology 366 is usually highly symmetric with many/all paths having equal 367 cost. In a long distance network, this is usually less the case 368 for a variety of reasons (e.g. historic, fiber availability 369 constraints, different distances between transit nodes, different 370 roles ...). Hence between a given source and destination, a path 371 is typically preferred over the others, while between the same 372 source and another destination, a different path may be 373 preferred. 375 +--------------------+ 376 | | 377 | +----------+ | 378 | | | | 379 T-10-T | | 380 /| /| | | 381 / | / | | | 382 --+ | | | | | 383 / +--+-+ 100 | | 384 / / | | | | 385 / / R-18-R | | 386 / / /\ /\ | | 387 / | / \ / \ | | 388 / | / x \ | | 389 A-25-A 10 10 \ \ | | 390 / / 10 10 | | 391 / / \ \ | | 392 A-25-A A-25-A | | 393 \ \ / / | | 394 201 201 201 201 | | 395 \ \ / / | | 396 \ x / | | 397 \ / \ / | | 398 \/ \/ | | 399 I-24-I 100 100 400 | | | | 401 | +-----------+ | 402 | | 403 +---------------------+ 405 Figure 3: Explicit Routing topology 407 In the above topology, operator may want to enforce the following 408 high level explicitly routed policies: - Traffic from A nodes to 409 A nodes must not go through I nodes - Traffic from A nodes to I 410 nodes must not go through R and T nodes With node admin tag, tag 411 A can be configured on all A nodes, (similarly I, R, T), and then 412 configure this single CSPF policy on all A nodes to avoid I nodes 413 for path calculation. 415 6. Security Considerations 417 This document does not introduce any further security issues other 418 than those discussed in [RFC2328] and [RFC5340]. 420 7. IANA Considerations 422 This specification updates one OSPF registry: OSPF Router Information 423 (RI) TLVs Registry 425 i) TBD - Node Admin tag TLV 427 8. Acknowledgments 429 Thanks to Bharath R, Pushpasis Sarakar and Dhruv Dhody for useful 430 inputs. Thanks to Chris Bowers for providing useful inputs to remove 431 ambiguity related to tag-ordering. 433 9. References 435 9.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997. 440 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 442 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 443 (TE) Extensions to OSPF Version 2", RFC 3630, September 444 2003. 446 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 447 Shaffer, "Extensions to OSPF for Advertising Optional 448 Router Capabilities", RFC 4970, July 2007. 450 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 451 for IPv6", RFC 5340, July 2008. 453 9.2. Informative References 455 [I-D.acee-ospf-rfc4970bis] 456 Lindem, A., Shen, N., Vasseur, J., Aggarwal, R., and S. 457 Shaffer, "Extensions to OSPF for Advertising Optional 458 Router Capabilities", draft-acee-ospf-rfc4970bis-00 (work 459 in progress), July 2014. 461 [I-D.ietf-rtgwg-lfa-manageability] 462 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 463 Horneffer, M., and p. psarkar@juniper.net, "Operational 464 management of Loop Free Alternates", draft-ietf-rtgwg-lfa- 465 manageability-04 (work in progress), August 2014. 467 [I-D.ietf-rtgwg-remote-lfa] 468 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 469 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02 470 (work in progress), May 2013. 472 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 473 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 475 Authors' Addresses 477 Shraddha Hegde 478 Juniper Networks, Inc. 479 Embassy Business Park 480 Bangalore, KA 560093 481 India 483 Email: shraddha@juniper.net 485 Harish Raghuveer 487 Email: harish.r.prabhu@gmail.com 489 Hannes Gredler 490 Juniper Networks, Inc. 491 1194 N. Mathilda Ave. 492 Sunnyvale, CA 94089 493 US 495 Email: hannes@juniper.net 497 Rob Shakir 498 British Telecom 500 Email: rob.shakir@bt.com 501 Anton Smirnov 502 Cisco Systems, Inc. 503 De Kleetlaan 6a 504 Diegem 1831 505 Belgium 507 Email: as@cisco.com 509 Li zhenbin 510 Huawei Technologies 511 Huawei Bld. No.156 Beiqing Rd 512 Beijing 100095 513 China 515 Email: lizhenbin@huawei.com 517 Bruno Decraene 518 Orange 520 Email: bruno.decraene@orange.com