idnits 2.17.1 draft-ietf-rtgwg-cl-requirement-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 25, 2014) is 3744 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-rtgwg-cl-framework-01 == Outdated reference: A later version (-06) exists of draft-ietf-rtgwg-cl-use-cases-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG C. Villamizar, Ed. 3 Internet-Draft OCCNC, LLC 4 Intended status: Informational D. McDysan, Ed. 5 Expires: July 28, 2014 Verizon 6 S. Ning 7 Tata Communications 8 A. Malis 9 Consultant 10 L. Yong 11 Huawei USA 12 January 25, 2014 14 Requirements for Advanced Multipath in MPLS Networks 15 draft-ietf-rtgwg-cl-requirement-14 17 Abstract 19 This document provides a set of requirements for Advanced Multipath 20 in MPLS Networks. 22 Advanced Multipath is a formalization of multipath techniques 23 currently in use in IP and MPLS networks and a set of extensions to 24 existing multipath techniques. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 28, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6 64 3.1. Availability, Stability and Transient Response . . . . . 6 65 3.2. Component Links Provided by Lower Layer Networks . . . . 7 66 3.3. Component Links with Different Characteristics . . . . . 7 67 3.4. Considerations for Bidirectional Client LSP . . . . . . . 8 68 3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 9 69 4. General Requirements for Protocol Solutions . . . . . . . . . 11 70 5. Management Requirements . . . . . . . . . . . . . . . . . . . 12 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 9.2. Informative References . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 There is often a need to provide large aggregates of bandwidth that 82 are best provided using parallel links between routers or carrying 83 traffic over multiple MPLS Label Switched Paths (LSPs). In core 84 networks there is often no alternative since the aggregate capacities 85 of core networks today far exceed the capacity of a single physical 86 link or single packet processing element. 88 The presence of parallel links, with each link potentially comprised 89 of multiple layers has resulted in additional requirements. Certain 90 services may benefit from being restricted to a subset of the 91 component links or a specific component link, where component link 92 characteristics, such as latency, differ. Certain services require 93 that an LSP be treated as atomic and avoid reordering. Other 94 services will continue to require only that reordering not occur 95 within a microflow as is current practice. 97 The purpose of this document is to clearly enumerate a set of 98 requirements related to the protocols and mechanisms that provide 99 MPLS based Advanced Multipath. The intent is to first provide a set 100 of functional requirements that are as independent as possible of 101 protocol specifications in Section 3. A set of general protocol 102 requirements are defined in Section 4. A set of network management 103 requirements are defined in Section 5. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 Any statement which requires the solution to support some new 112 functionality through use of [RFC2119] keywords, SHOULD be 113 interpreted as follows. The implementation either MUST or SHOULD 114 support the new functionality depending on the use of either MUST or 115 SHOULD in the requirements statement. The implementation SHOULD in 116 most or all cases allow any new functionality to be individually 117 enabled or disabled through configuration. A service provider or 118 other deployment MAY choose to enable or disable any feature in their 119 network, subject to implementation limitations on sets of features 120 which can be disabled. 122 2. Definitions 124 Multipath 125 The term multipath includes all techniques in which 127 1. Traffic can take more than one path from one node to a 128 destination. 130 2. Individual packets take one path only. Packets are not 131 subdivided and reassembled at the receiving end. 133 3. Packets are not resequenced at the receiving end. 135 4. The paths may be: 137 a. parallel links between two nodes, or 139 b. may be specific paths across a network to a destination 140 node, or 142 c. may be links or paths to an intermediate node used to 143 reach a common destination. 145 The paths need not have equal capacity. The paths may or may not 146 have equal cost in a routing protocol. 148 Advanced Multipath 149 Advanced Multipath meets the requirements defined in this 150 document. A key capability of advanced multipath is the support 151 of non-homogeneous component links. 153 Composite Link 154 The term Composite Link had been a registered trademark of Avici 155 Systems, but was abandoned in 2007. The term composite link is 156 now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition 157 includes multipath as defined here, plus inverse multiplexing 158 which is explicitly excluded from the definition of multipath. 160 Inverse Multiplexing 161 Inverse multiplexing either transmits whole packets and 162 resequences the packets at the receiving end or subdivides 163 packets and reassembles the packets at the receiving end. 164 Inverse multiplexing requires that all packets be handled by a 165 common egress packet processing element and is therefore not 166 useful for very high bandwidth applications. 168 Component Link 169 The ITU-T definition of composite link in [ITU-T.G.800] and the 170 IETF definition of link bundling in [RFC4201] both refer to an 171 individual link in the composite link or link bundle as a 172 component link. The term component link is applicable to all 173 forms of multipath. The IEEE uses the term member rather than 174 component link in Ethernet Link Aggregation [IEEE-802.1AX]. 176 Client LSP 177 A client LSP is an LSP which has been set up over a server layer. 178 In the context of this discussion, a client LSP is a LSP which 179 has been set up over a multipath as opposed to an LSP 180 representing the multipath itself or any LSP supporting a 181 component links of that multipath. 183 Flow 184 A sequence of packets that should be transferred in order on one 185 component link of a multipath. 187 Flow identification 188 The label stack and other information that uniquely identifies a 189 flow. Other information in flow identification may include an IP 190 header, pseudowire (PW) control word, Ethernet MAC address, etc. 191 Note that a client LSP may contain one or more Flows or a client 192 LSP may be equivalent to a Flow. Flow identification is used to 193 locally select a component link, or a path through the network 194 toward the destination. 196 Load Balance 197 Load split, load balance, or load distribution refers to 198 subdividing traffic over a set of component links such that load 199 is fairly evenly distributed over the set of component links and 200 certain packet ordering requirements are met. Some existing 201 techniques better achieve these objectives than others. 203 Performance Objective 204 Numerical values for performance measures, principally 205 availability, latency, and delay variation. Performance 206 objectives may be related to Service Level Agreements (SLA) as 207 defined in RFC2475 or may be strictly internal. Performance 208 objectives may span links, edge-to-edge, or end-to-end. 209 Performance objectives may span one provider or may span multiple 210 providers. 212 A Component Link may be a point-to-point physical link (where a 213 "physical link" includes one or more link layer plus a physical 214 layer) or a logical link that preserves ordering in the steady state. 215 A component link may have transient out of order events, but such 216 events must not exceed the network's Performance Objectives. For 217 example, a component link may be comprised of any supportable 218 combination of link layers over a physical layer or over logical sub- 219 layers, including those providing physical layer emulation. 221 The ingress and egress of a multipath may be midpoint LSRs with 222 respect to a given client LSP. A midpoint LSR does not participate 223 in the signaling of any clients of the client LSP. Therefore, in 224 general, multipath endpoints cannot determine requirements of clients 225 of a client LSP through participation in the signaling of the clients 226 of the client LSP. 228 The term Advanced Multipath is intended to be used within the context 229 of this document and the related documents, 230 [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and 231 any other related document. Other advanced multipath techniques may 232 in the future arise. If the capabilities defined in this document 233 become commonplace, they would no longer be considered "advanced". 234 Use of the term "advanced multipath" outside this document, if 235 referring to the term as defined here, should indicate Advanced 236 Multipath as defined by this document, citing the current document 237 name. If using another definition of "advanced multipath", documents 238 may optionally clarify that they are not using the term "advanced 239 multipath" as defined by this document if clarification is deemed 240 helpful. 242 3. Functional Requirements 244 The Functional Requirements in this section are grouped in 245 subsections starting with the highest priority. 247 3.1. Availability, Stability and Transient Response 249 Limiting the period of unavailability in response to failures or 250 transient events is extremely important as well as maintaining 251 stability. The transient period between some service disrupting 252 event and the convergence of the routing and/or signaling protocols 253 MUST occur within a time frame specified by Performance Objective 254 values. 256 FR#1 An advanced multipath MAY be announced in conjunction with 257 detailed parameters about its component links, such as bandwidth 258 and latency. The advanced multipath SHALL behave as a single IGP 259 adjacency. 261 FR#2 The solution SHALL provide a means to summarize some routing 262 advertisements regarding the characteristics of an advanced 263 multipath such that the updated protocol mechanisms maintain 264 convergence times within the timeframe needed to meet or not 265 significantly exceed existing Performance Objective for 266 convergence on the same network or convergence on a network with 267 a similar topology. 269 FR#3 The solution SHALL ensure that restoration operations happen 270 within the timeframe needed to meet existing Performance 271 Objective for restoration time on the same network or restoration 272 time on a network with a similar topology. 274 FR#4 The solution shall provide a mechanism to select a set of paths 275 for an LSP across a network in such a way that flows within the 276 LSP are distributed across the set of paths while meeting all of 277 the other requirements stated above. The solution SHOULD work in 278 a manner similar to existing multipath techniques except as 279 necessary to accommodate advanced multipath requirements. 281 FR#5 If extensions to existing protocols are specified and/or new 282 protocols are defined, then the solution SHOULD provide a means 283 for a network operator to migrate an existing deployment in a 284 minimally disruptive manner. 286 FR#6 Any load balancing solutions MUST NOT oscillate. Some change 287 in path MAY occur. The solution MUST ensure that path stability 288 and traffic reordering continue to meet Performance Objective on 289 the same network or on a network with a similar topology. Since 290 oscillation may cause reordering, there MUST be means to control 291 the frequency of changing the component link over which a flow is 292 placed. 294 FR#7 Management and diagnostic protocols MUST be able to operate 295 over advanced multipaths. 297 Existing scaling techniques used in MPLS networks apply to MPLS 298 networks which support Advanced Multipaths. Scalability and 299 stability are covered in more detail in 300 [I-D.ietf-rtgwg-cl-framework]. 302 3.2. Component Links Provided by Lower Layer Networks 304 A component link may be supported by a lower layer network. For 305 example, the lower layer may be a circuit switched network or another 306 MPLS network (e.g., MPLS-TP)). The lower layer network may change 307 the latency (and/or other performance parameters) seen by the client 308 layer. Currently, there is no protocol for the lower layer network 309 to inform the higher layer network of a change in a performance 310 parameter. Communication of the latency performance parameter is a 311 very important requirement. Communication of other performance 312 parameters (e.g., delay variation) is desirable. 314 FR#8 The solution SHALL specify a protocol means to allow a lower 315 layer server network to communicate latency to the higher layer 316 client network. 318 FR#9 The precision of latency reporting SHOULD be configurable. A 319 reasonable default SHOULD be provided. Implementations SHOULD 320 support precision of at least 10% of the one way latencies for 321 latency of 1 msec or more. 323 The intent is to measure the predominant latency in uncongested 324 service provider networks, where geographic delay dominates and is on 325 the order of milliseconds or more. The argument for including 326 queuing delay is that it reflects the delay experienced by 327 applications. The argument against including queuing delay is that 328 if used in routing decisions it can result in routing instability. 329 This tradeoff is discussed in detail in 330 [I-D.ietf-rtgwg-cl-framework]. 332 3.3. Component Links with Different Characteristics 334 As one means to provide high availability, network operators deploy a 335 topology in the MPLS network using lower layer networks that have a 336 certain degree of diversity at the lower layer(s). Many techniques 337 have been developed to balance the distribution of flows across 338 component links that connect the same pair of nodes. When the path 339 for a flow can be chosen from a set of candidate nodes connected via 340 advanced multipaths, other techniques have been developed. Refer to 341 the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of 342 existing techniques and a set of references. 344 FR#10 The solution SHALL provide a means to indicate that a client 345 LSP will traverse a component link with the minimum latency 346 value. This will provide a means by which minimum latency 347 Performance Objectives of flows within the client LSP can be 348 supported. 350 FR#11 The solution SHALL provide a means to indicate that a client 351 LSP will traverse a component link with a maximum acceptable 352 latency value as specified by protocol. This will provide a 353 means by which bounded latency Performance Objectives of flows 354 within the client LSP can be supported. 356 FR#12 The solution SHALL provide a means to indicate that a client 357 LSP will traverse a component link with a maximum acceptable 358 delay variation value as specified by protocol. 360 The above set of requirements apply to component links with different 361 characteristics regardless as to whether those component links are 362 provided by parallel physical links between nodes or provided by sets 363 of paths across a network provided by server layer LSP. 365 Allowing multipath to contain component links with different 366 characteristics can improve the overall load balance and can be 367 accomplished while still accommodating the more strict requirements 368 of a subset of client LSP. 370 3.4. Considerations for Bidirectional Client LSP 372 Some client LSP MAY require a path bound to a specific set of 373 component links. This case is most likely to occur in bidirectional 374 client LSP where time synchronization protocols such as Precision 375 Time Protocol (PTP) or Network Time Protocol (NTP) are carried, or in 376 any other case where symmetric delay is highly desirable. There may 377 be other uses of this capability. 379 Other client LSP may only require that the LSP path serve the same 380 set of nodes in both directions. This is necessary if protocols are 381 carried which make use of the reverse direction of the LSP as a back 382 channel in cases such OAM protocols using IPv4 Time to Live (TTL) or 383 IPv4 Hop Limit to monitor or diagnose the underlying path. There may 384 be other uses of this capability. 386 FR#13 The solution MUST support an optional means for client LSP 387 signaling to bind a client LSP to a particular component link 388 within an advanced multipath. If this option is not exercised, 389 then a client LSP that is bound to an advanced multipath may be 390 bound to any component link matching all other signaled 391 requirements, and different directions of a bidirectional client 392 LSP can be bound to different component links. 394 FR#14 The solution MUST support a means to indicate that both 395 directions of co-routed bidirectional client LSP MUST be bound to 396 the same set of nodes. 398 FR#15 A client LSP which is bound to a specific component link SHOULD 399 NOT exceed the capacity of a single component link. This is 400 inherent in the assumption that a network SHOULD NOT operate in a 401 congested state if congestion is avoidable. 403 For some large bidirectional client LSP it may not be necessary (or 404 possible due to the client LSP capacity) to bind the LSP to a common 405 set of component links but may be necessary or desirable to constrain 406 the path taken by the LSP to the same set of nodes in both 407 directions. Without an entirely new and highly dynamic protocol, it 408 is not feasible to constrain such an bidirectional client LSP to take 409 multiple paths and coordinate load balance on each side to keep both 410 directions of flows within such an LSP on common paths. 412 3.5. Multipath Load Balancing Dynamics 414 Multipath load balancing attempts to keep traffic levels on all 415 component links below congestion levels if possible and preferably 416 well balanced. Load balancing is minimally disruptive (see 417 discussion below this section's list of requirements). The 418 sensitivity to these minimal disruptions of traffic flows within 419 specific client LSP needs to be considered. 421 FR#16 The solution SHALL provide a means that indicates whether any 422 of the LSP within an client LSP MUST NOT be split across multiple 423 component links. 425 FR#17 The solution SHALL provide a means local to a node that 426 automatically distributes flows across the component links in the 427 advanced multipath such that Performance Objectives are met as 428 described in prior requirements in Section 3.3. 430 FR#18 The solution SHALL measure traffic flows or groups of traffic 431 flows and dynamically select the component link on which to place 432 this traffic in order to balance the load so that no component 433 link in the advanced multipath between a pair of nodes is 434 overloaded. 436 FR#19 When a traffic flow is moved from one component link to another 437 in the same advanced multipath between a set of nodes, it MUST be 438 done so in a minimally disruptive manner. 440 FR#20 Load balancing MAY be used during sustained low traffic periods 441 to reduce the number of active component links for the purpose of 442 power reduction. 444 FR#21 The solution SHALL provide a means to identify client LSPs 445 containing traffic flows whose rearrangement frequency needs to 446 be bounded by a specific value and MUST provide a means to bound 447 the rearrangement frequency for traffic flows within these client 448 LSP. 450 FR#22 The solution SHALL provide a means to distribute traffic flows 451 from a single client LSP across multiple component links to 452 handle at least the case where the traffic carried in an client 453 LSP exceeds that of any component link in the advanced multipath. 455 FR#23 The solution SHOULD support the use case where an advanced 456 multipath itself is a component link for a higher order advanced 457 multipath. For example, an advanced multipath comprised of MPLS- 458 TP bi-directional tunnels viewed as logical links could then be 459 used as a component link in yet another advanced multipath that 460 connects MPLS routers. 462 FR#24 If the total demand offered by traffic flows exceeds the 463 capacity of the advanced multipath, the solution SHOULD define a 464 means to cause some client LSP to move to an alternate set of 465 paths that are not congested. These "preempted LSP" may not be 466 restored if there is no uncongested path in the network. 468 A minimally disruptive change implies that as little disruption as is 469 practical occurs. Such a change can be achieved with zero packet 470 loss. A delay discontinuity may occur, which is considered to be a 471 minimally disruptive event for most services if this type of event is 472 sufficiently rare. A delay discontinuity is an example of a 473 minimally disruptive behavior corresponding to current techniques. 475 A delay discontinuity is an isolated event which may greatly exceed 476 the normal delay variation (jitter). A delay discontinuity has the 477 following effect. When a flow is moved from a current link to a 478 target link with lower latency, reordering can occur. When a flow is 479 moved from a current link to a target link with a higher latency, a 480 time gap can occur. Some flows (e.g., timing distribution, PW 481 circuit emulation) are quite sensitive to these effects. A delay 482 discontinuity can also cause a jitter buffer underrun or overrun 483 affecting user experience in real time voice services (causing an 484 audible click). These sensitivities may be specified in a 485 Performance Objective. 487 As with any load balancing change, a change initiated for the purpose 488 of power reduction may be minimally disruptive. Typically the 489 disruption is limited to a change in delay characteristics and the 490 potential for a very brief period with traffic reordering. The 491 network operator when configuring a network for power reduction 492 should weigh the benefit of power reduction against the disadvantage 493 of a minimal disruption. 495 4. General Requirements for Protocol Solutions 497 This section defines requirements for protocol specification used to 498 meet the functional requirements specified in Section 3. 500 GR#1 The solution SHOULD extend existing protocols wherever 501 possible, developing a new protocol only where doing so adds a 502 significant set of capabilities. 504 GR#2 A solution SHOULD extend LDP capabilities to meet functional 505 requirements. This MUST be accomplished without defining LDP 506 Traffic Engineering (TE) methods as decided in [RFC3468]). 508 GR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported 509 on an advanced multipath. Function requirements SHOULD, where 510 possible, be accommodated in a manner that supports LDP signaled 511 LSP, RSVP signaled LSP, and LSP set up using management plane 512 mechanisms. 514 GR#4 When the nodes connected via an advanced multipath are in the 515 same MPLS network topology, the solution MAY define extensions to 516 the IGP. 518 GR#5 When the nodes are connected via an advanced multipath are in 519 different MPLS network topologies, the solution SHALL NOT rely on 520 extensions to the IGP. 522 GR#6 The solution SHOULD support advanced multipath IGP 523 advertisement that results in convergence time better than that 524 of advertising the individual component links. The solution 525 SHALL be designed so that it represents the range of capabilities 526 of the individual component links such that functional 527 requirements are met, and also minimizes the frequency of 528 advertisement updates which may cause IGP convergence to occur. 530 Examples of advertisement update triggering events to be 531 considered include: client LSP establishment/release, changes in 532 component link characteristics (e.g., latency, up/down state), 533 and/or bandwidth utilization. 535 GR#7 When a worst case failure scenario occurs, the number of RSVP- 536 TE client LSPs to be resignaled will cause a period of 537 unavailability as perceived by users. The resignaling time of 538 the solution MUST support protocol mechanisms meeting existing 539 provider Performance Objective for the duration of unavailability 540 without significantly relaxing those existing Performance 541 Objectives for the same network or for networks with similar 542 topology. For example, the processing load due to IGP 543 readvertisement MUST NOT increase significantly and the 544 resignaling time of the solution MUST NOT increase significantly 545 as compared with current methods. 547 5. Management Requirements 549 MR#1 Management Plane MUST support polling of the status and 550 configuration of an advanced multipath and its individual 551 advanced multipath and support notification of status change. 553 MR#2 Management Plane MUST be able to activate or de-activate any 554 component link in an advanced multipath in order to facilitate 555 operation maintenance tasks. The routers at each end of an 556 advanced multipath MUST redistribute traffic to move traffic from 557 a de-activated link to other component links based on the traffic 558 flow TE criteria. 560 MR#3 Management Plane MUST be able to configure a client LSP over an 561 advanced multipath and be able to select a component link for the 562 client LSP. 564 MR#4 Management Plane MUST be able to trace which component link a 565 client LSP is assigned to and monitor individual component link 566 and advanced multipath performance. 568 MR#5 Management Plane MUST be able to verify connectivity over each 569 individual component link within an advanced multipath. 571 MR#6 Component link fault notification MUST be sent to the 572 management plane. 574 MR#7 Advanced multipath fault notification MUST be sent to the 575 management plane and MUST be distributed via link state message 576 in the IGP. 578 MR#8 Management Plane SHOULD provide the means for an operator to 579 initiate an optimization process. 581 MR#9 An operator initiated optimization MUST be performed in a 582 minimally disruptive manner as described in Section 3.5. 584 6. Acknowledgements 586 Frederic Jounay of France Telecom and Yuji Kamite of NTT 587 Communications Corporation co-authored a version of this document. 589 A rewrite of this document occurred after the IETF77 meeting. 590 Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG chairs John 591 Scuder and Alex Zinin, the current WG chair Alia Atlas, and others 592 provided valuable guidance prior to and at the IETF77 RTGWG meeting. 594 Tony Li and John Drake have made numerous valuable comments on the 595 RTGWG mailing list that are reflected in versions following the 596 IETF77 meeting. 598 Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG 599 mailing list after IETF82 that identified a new requirement. 600 Iftekhar Hussain made numerous valuable comments on the RTGWG mailing 601 list that resulted in improvements to document clarity. 603 In the interest of full disclosure of affiliation and in the interest 604 of acknowledging sponsorship, past affiliations of authors are noted. 605 Much of the work done by Ning So occurred while Ning was at Verizon. 606 Much of the work done by Curtis Villamizar occurred while at 607 Infinera. Much of the work done by Andy Malis occurred while Andy 608 was at Verizon. 610 Tom Yu and Francis Dupont provided the SecDir and GenArt reviews 611 respectively. Both reviews provided useful comments. The current 612 wording of the security section is based on suggested wording from 613 Tom Yu. Lou Berger provided the RtgDir review which resulted in the 614 document being renamed and substantial clarification of terminology 615 and document wording, particularly in the Abstract, Introduction, and 616 Definitions sections. 618 7. IANA Considerations 620 This memo includes no request to IANA. 622 8. Security Considerations 624 The security considerations for MPLS/GMPLS and for MPLS-TP are 625 documented in [RFC5920] and [RFC6941]. This document does not impact 626 the security of MPLS, GMPLS, or MPLS-TP. 628 The additional information that this document requires does not 629 provide significant additional value to an attacker beyond the 630 information already typically available from attacking a routing or 631 signaling protocol. If the requirements of this document are met by 632 extending an existing routing or signaling protocol, the security 633 considerations of the protocol being extended apply. If the 634 requirements of this document are met by specifying a new protocol, 635 the security considerations of that new protocol should include an 636 evaluation of what level of protection is required by the additional 637 information specified in this document, such as data origin 638 authentication. 640 9. References 642 9.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, March 1997. 647 9.2. Informative References 649 [I-D.ietf-rtgwg-cl-framework] 650 Ning, S., McDysan, D., Osborne, E., Yong, L., and C. 651 Villamizar, "Composite Link Framework in Multi Protocol 652 Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-01 653 (work in progress), August 2012. 655 [I-D.ietf-rtgwg-cl-use-cases] 656 Ning, S., Malis, A., McDysan, D., Yong, L., and C. 657 Villamizar, "Composite Link Use Cases and Design 658 Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in 659 progress), August 2012. 661 [IEEE-802.1AX] 662 IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE 663 Standard for Local and Metropolitan Area Networks - Link 664 Aggregation", 2006, . 667 [ITU-T.G.800] 668 ITU-T, "Unified functional architecture of transport 669 networks", 2007, . 672 [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label 673 Switching (MPLS) Working Group decision on MPLS signaling 674 protocols", RFC 3468, February 2003. 676 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 677 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 679 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 680 Networks", RFC 5920, July 2010. 682 [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 683 Graveman, "MPLS Transport Profile (MPLS-TP) Security 684 Framework", RFC 6941, April 2013. 686 Authors' Addresses 688 Curtis Villamizar (editor) 689 OCCNC, LLC 691 Email: curtis@occnc.com 693 Dave McDysan (editor) 694 Verizon 695 22001 Loudoun County PKWY 696 Ashburn, VA 20147 697 USA 699 Email: dave.mcdysan@verizon.com 701 So Ning 702 Tata Communications 704 Email: ning.so@tatacommunications.com 706 Andrew Malis 707 Consultant 709 Email: agmalis@gmail.com 710 Lucy Yong 711 Huawei USA 712 5340 Legacy Dr. 713 Plano, TX 75025 714 USA 716 Phone: +1 469-277-5837 717 Email: lucy.yong@huawei.com