idnits 2.17.00 (12 Aug 2021) /tmp/idnits34072/draft-ietf-rtgwg-cl-requirement-12.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 (October 9, 2013) is 3146 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: April 12, 2014 Verizon 6 S. Ning 7 Tata Communications 8 A. Malis 9 Verizon 10 L. Yong 11 Huawei USA 12 October 9, 2013 14 Requirements for Advanced Multipath in MPLS Networks 15 draft-ietf-rtgwg-cl-requirement-12 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 April 12, 2014. 43 Copyright Notice 45 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . 8 67 3.4. Considerations for Bidirectional Client LSP . . . . . . . 9 68 3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 10 69 4. General Requirements for Protocol Solutions . . . . . . . . . 11 70 5. Management Requirements . . . . . . . . . . . . . . . . . . . 13 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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 LSP. In core networks there is often no 84 alternative since the aggregate capacities of core networks today far 85 exceed the capacity of a single physical link or single packet 86 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 123 Multipath 124 The term multipath includes all techniques in which 126 1. Traffic can take more than one path from one node to a 127 destination. 129 2. Individual packets take one path only. Packets are not 130 subdivided and reassembled at the receiving end. 132 3. Packets are not resequenced at the receiving end. 134 4. The paths may be: 136 a. parallel links between two nodes, or 138 b. may be specific paths across a network to a destination 139 node, or 141 c. may be links or paths to an intermediate node used to 142 reach a common destination. 144 The paths need not have equal capacity. The paths may or may not 145 have equal cost in a routing protocol. 147 Advanced Multipath 148 Advanced Multipath meets the requirements defined in this 149 document. A key capability of advanced multipath is the support 150 of non-homogeneous component links. 152 Composite Link 153 The term Composite Link had been a registered trademark of Avici 154 Systems, but was abandoned in 2007. The term composite link is 155 now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition 156 includes multipath as defined here, plus inverse multiplexing 157 which is explicitly excluded from the definition of multipath. 159 Inverse Multiplexing 160 Inverse multiplexing either transmits whole packets and 161 resequences the packets at the receiving end or subdivides 162 packets and reassembles the packets at the receiving end. 163 Inverse multiplexing requires that all packets be handled by a 164 common egress packet processing element and is therefore not 165 useful for very high bandwidth applications. 167 Component Link 168 The ITU-T definition of composite link in [ITU-T.G.800] and the 169 IETF definition of link bundling in [RFC4201] both refer to an 170 individual link in the composite link or link bundle as a 171 component link. The term component link is applicable to all 172 forms of multipath. The IEEE uses the term member rather than 173 component link in Ethernet Link Aggregation [IEEE-802.1AX]. 175 Client LSP 176 A client LSP is an LSP which has been set up over a server layer. 177 In the context of this discussion, a client LSP is a LSP which 178 has been set up over a multipath as opposed to an LSP 179 representing the multipath itself or any LSP supporting a 180 component links of that multipath. 182 Flow 183 A sequence of packets that should be transferred in order on one 184 component link of a multipath. 186 Flow identification 187 The label stack and other information that uniquely identifies a 188 flow. Other information in flow identification may include an IP 189 header, pseudowire (PW) control word, Ethernet MAC address, etc. 190 Note that a client LSP may contain one or more Flows or a client 191 LSP may be equivalent to a Flow. Flow identification is used to 192 locally select a component link, or a path through the network 193 toward the destination. 195 Load Balance 196 Load split, load balance, or load distribution refers to 197 subdividing traffic over a set of component links such that load 198 is fairly evenly distributed over the set of component links and 199 certain packet ordering requirements are met. Some existing 200 techniques better achieve these objectives than others. 202 Performance Objective 203 Numerical values for performance measures, principally 204 availability, latency, and delay variation. Performance 205 objectives may be related to Service Level Agreements (SLA) as 206 defined in RFC2475 or may be strictly internal. Performance 207 objectives may span links, edge-to-edge, or end-to-end. 208 Performance objectives may span one provider or may span multiple 209 providers. 211 A Component Link may be a point-to-point physical link (where a 212 "physical link" includes one or more link layer plus a physical 213 layer) or a logical link that preserves ordering in the steady state. 214 A component link may have transient out of order events, but such 215 events must not exceed the network's Performance Objectives. For 216 example, a component link may be comprised of any supportable 217 combination of link layers over a physical layer or over logical sub- 218 layers, including those providing physical layer emulation. 220 The ingress and egress of a multipath may be midpoint LSRs with 221 respect to a given client LSP. A midpoint LSR does not participate 222 in the signaling of any clients of the client LSP. Therefore, in 223 general, multipath endpoints cannot determine requirements of clients 224 of a client LSP through participation in the signaling of the clients 225 of the client LSP. 227 The term Advanced Multipath is intended to be used within the context 228 of this document and the related documents, 229 [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and 230 any other related document. Other advanced multipath techniques may 231 in the future arise. If the capabilities defined in this document 232 become commonplace, they would no longer be considered "advanced". 233 Use of the term "advanced multipath" outside this document, if 234 referring to the term as defined here, should indicate Advanced 235 Multipath as defined by this document, citing the current document 236 name. If using another definition of "advanced multipath", documents 237 may optionally clarify that they are not using the term "advanced 238 multipath" as defined by this document if clarification is deemed 239 helpful. 241 3. Functional Requirements 243 The Functional Requirements in this section are grouped in 244 subsections starting with the highest priority. 246 3.1. Availability, Stability and Transient Response 248 Limiting the period of unavailability in response to failures or 249 transient events is extremely important as well as maintaining 250 stability. The transient period between some service disrupting 251 event and the convergence of the routing and/or signaling protocols 252 MUST occur within a time frame specified by Performance Objective 253 values. 255 FR#1 An advanced multipath MAY be announced in conjunction with 256 detailed parameters about its component links, such as 257 bandwidth and latency. The advanced multipath SHALL behave as 258 a single IGP adjacency. 260 FR#2 The solution SHALL provide a means to summarize some routing 261 advertisements regarding the characteristics of an advanced 262 multipath such that the updated protocol mechanisms maintain 263 convergence times within the timeframe needed to meet or not 264 significantly exceed existing Performance Objective for 265 convergence on the same network or convergence on a network 266 with a similar topology. 268 FR#3 The solution SHALL ensure that restoration operations happen 269 within the timeframe needed to meet existing Performance 270 Objective for restoration time on the same network or 271 restoration time on a network with a similar topology. 273 FR#4 The solution shall provide a mechanism to select a set of paths 274 for an LSP across a network in such a way that flows within the 275 LSP are distributed across the set of paths while meeting all 276 of the other requirements stated above. The solution SHOULD 277 work in a manner similar to existing multipath techniques 278 except as necessary to accommodate advanced multipath 279 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 288 stability and traffic reordering continue to meet Performance 289 Objective on the same network or on a network with a similar 290 topology. Since oscillation may cause reordering, there MUST 291 be means to control the frequency of changing the component 292 link over which a flow is 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 it 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 PTP or NTP 375 are carried, or in any other case where symmetric delay is highly 376 desirable. There may be other uses of this capability. 378 Other client LSP may only require that the LSP path serve the same 379 set of nodes in both directions. This is necessary if protocols are 380 carried which make use of the reverse direction of the LSP as a back 381 channel in cases such OAM protocols using TTL to monitor or diagnose 382 the underlying path. There may be other uses of this capability. 384 FR#13 The solution MUST support an optional means for client LSP 385 signaling to bind a client LSP to a particular component link 386 within an advanced multipath. If this option is not 387 exercised, then a client LSP that is bound to an advanced 388 multipath may be bound to any component link matching all 389 other signaled requirements, and different directions of a 390 bidirectional client LSP can be bound to different component 391 links. 393 FR#14 The solution MUST support a means to indicate that both 394 directions of co-routed bidirectional client LSP MUST be bound 395 to the same set of nodes. 397 A client LSP which is bound to a specific component link SHOULD NOT 398 exceed the capacity of a single component link. 400 For some large bidirectional client LSP it may not be necessary (or 401 possible due to the client LSP capacity) to bind the LSP to a common 402 set of component links but may be necessary or desirable to constrain 403 the path taken by the LSP to the same set of nodes in both 404 directions. Without and entirely new and highly dynamic protocol, it 405 is not feasible to constrain such an bidirectional client LSP to take 406 multiple paths and coordinate load balance on each side to keep both 407 directions of flows within such an LSP on common paths. 409 3.5. Multipath Load Balancing Dynamics 411 Multipath load balancing attempts to keep traffic levels on all 412 component links below congestion levels if possible and preferably 413 well balanced. Load balancing is minimally disruptive (see 414 discussion below this section's list of requirements). The 415 sensitivity to these minimal disruptions of traffic flows within 416 specific client LSP needs to be considered. 418 FR#15 The solution SHALL provide a means that indicates whether any 419 of the flows within an client LSP MUST NOT be split across 420 multiple component links. 422 FR#16 The solution SHALL provide a means local to a node that 423 automatically distributes flows across the component links in 424 the advanced multipath such that Performance Objectives are 425 met as described in prior requirements in Section 3.3. 427 FR#17 The solution SHALL measure traffic flows or groups of traffic 428 flows and dynamically select the component link on which to 429 place this traffic in order to balance the load so that no 430 component link in the advanced multipath between a pair of 431 nodes is overloaded. 433 FR#18 When a traffic flow is moved from one component link to 434 another in the same advanced multipath between a set of nodes, 435 it MUST be done so in a minimally disruptive manner. 437 FR#19 Load balancing MAY be used during sustained low traffic 438 periods to reduce the number of active component links for the 439 purpose of power reduction. 441 FR#20 The solution SHALL provide a means to identify client LSPs 442 containing traffic flows whose rearrangement frequency needs 443 to be bounded by a specific value and MUST provide a means to 444 bound the rearrangement frequency for traffic flows within 445 these client LSP. 447 FR#21 The solution SHALL provide a means to distribute traffic flows 448 from a single client LSP across multiple component links to 449 handle at least the case where the traffic carried in an 450 client LSP exceeds that of any component link in the advanced 451 multipath. 453 FR#22 The solution SHOULD support the use case where an advanced 454 multipath itself is a component link for a higher order 455 advanced multipath. For example, an advanced multipath 456 comprised of MPLS-TP bi-directional tunnels viewed as logical 457 links could then be used as a component link in yet another 458 advanced multipath that connects MPLS routers. 460 FR#23 If the total demand offered by traffic flows exceeds the 461 capacity of the advanced multipath, the solution SHOULD define 462 a means to cause some client LSP to move to an alternate set 463 of paths that are not congested. These "preempted LSP" may 464 not be restored if there is no uncongested path in the 465 network. 467 A minimally disruptive change implies that as little disruption as is 468 practical occurs. Such a change can be achieved with zero packet 469 loss. A delay discontinuity may occur, which is considered to be a 470 minimally disruptive event for most services if this type of event is 471 sufficiently rare. A delay discontinuity is an example of a 472 minimally disruptive behavior corresponding to current techniques. 474 A delay discontinuity is an isolated event which may greatly exceed 475 the normal delay variation (jitter). A delay discontinuity has the 476 following effect. When a flow is moved from a current link to a 477 target link with lower latency, reordering can occur. When a flow is 478 moved from a current link to a target link with a higher latency, a 479 time gap can occur. Some flows (e.g., timing distribution, PW 480 circuit emulation) are quite sensitive to these effects. A delay 481 discontinuity can also cause a jitter buffer underrun or overrun 482 affecting user experience in real time voice services (causing an 483 audible click). These sensitivities may be specified in a 484 Performance Objective. 486 As with any load balancing change, a change initiated for the purpose 487 of power reduction may be minimally disruptive. Typically the 488 disruption is limited to a change in delay characteristics and the 489 potential for a very brief period with traffic reordering. The 490 network operator when configuring a network for power reduction 491 should weigh the benefit of power reduction against the disadvantage 492 of a minimal disruption. 494 4. General Requirements for Protocol Solutions 496 This section defines requirements for protocol specification used to 497 meet the functional requirements specified in Section 3. 499 GR#1 The solution SHOULD extend existing protocols wherever 500 possible, developing a new protocol only where doing so adds a 501 significant set of capabilities. 503 GR#2 A solution SHOULD extend LDP capabilities to meet functional 504 requirements (without using TE methods as decided in 505 [RFC3468]). 507 GR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported 508 on an advanced multipath. Function requirements SHOULD, where 509 possible, be accommodated in a manner that supports LDP 510 signaled LSP, RSVP signaled LSP, and LSP set up using 511 management plane mechanisms. 513 GR#4 When the nodes connected via an advanced multipath are in the 514 same MPLS network topology, the solution MAY define extensions 515 to the IGP. 517 GR#5 When the nodes are connected via an advanced multipath are in 518 different MPLS network topologies, the solution SHALL NOT rely 519 on extensions to the IGP. 521 GR#6 The solution SHOULD support advanced multipath IGP 522 advertisement that results in convergence time better than that 523 of advertising the individual component links. The solution 524 SHALL be designed so that it represents the range of 525 capabilities of the individual component links such that 526 functional requirements are met, and also minimizes the 527 frequency of advertisement updates which may cause IGP 528 convergence to occur. 530 Examples of advertisement update triggering events to be 531 considered include: client LSP establishment/release, changes 532 in component link characteristics (e.g., latency, up/down 533 state), and/or bandwidth utilization. 535 GR#7 When a worst case failure scenario occurs, the number of 536 RSVP-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 540 unavailability without significantly relaxing those existing 541 Performance Objectives for the same network or for networks 542 with similar topology. For example, the processing load due to 543 IGP readvertisement MUST NOT increase significantly and the 544 resignaling time of the solution MUST NOT increase 545 significantly 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 557 from a de-activated link to other component links based on the 558 traffic 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 562 the 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. 609 Tom Yu and Francis Dupont provided the SecDir and GenArt reviews 610 respectively. Both reviews provided useful comments. The current 611 wording of the security section is based on suggested wording from 612 Tom Yu. Lou Berger provided the RtgDir review which resulted in the 613 document being renamed and substantial clarification of terminology 614 and document wording, particularly in the Abstract, Introduction, and 615 Definitions sections. 617 7. IANA Considerations 619 This memo includes no request to IANA. 621 8. Security Considerations 623 The security considerations for MPLS/GMPLS and for MPLS-TP are 624 documented in [RFC5920] and [RFC6941]. This document does not impact 625 the security of MPLS, GMPLS, or MPLS-TP. 627 The additional information that this document requires does not 628 provide significant additional value to an attacker beyond the 629 information already typically available from attacking a routing or 630 signaling protocol. If the requirements of this document are met by 631 extending an existing routing or signaling protocol, the security 632 considerations of the protocol being extended apply. If the 633 requirements of this document are met by specifying a new protocol, 634 the security considerations of that new protocol should include an 635 evaluation of what level of protection is required by the additional 636 information specified in this document, such as data origin 637 authentication. 639 9. References 641 9.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, March 1997. 646 9.2. Informative References 648 [I-D.ietf-rtgwg-cl-framework] 649 Ning, S., McDysan, D., Osborne, E., Yong, L., and C. 650 Villamizar, "Composite Link Framework in Multi Protocol 651 Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-01 652 (work in progress), August 2012. 654 [I-D.ietf-rtgwg-cl-use-cases] 655 Ning, S., Malis, A., McDysan, D., Yong, L., and C. 656 Villamizar, "Composite Link Use Cases and Design 657 Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in 658 progress), August 2012. 660 [IEEE-802.1AX] 661 IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE 662 Standard for Local and Metropolitan Area Networks - Link 663 Aggregation", 2006, . 666 [ITU-T.G.800] 667 ITU-T, "Unified functional architecture of transport 668 networks", 2007, . 671 [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label 672 Switching (MPLS) Working Group decision on MPLS signaling 673 protocols", RFC 3468, February 2003. 675 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 676 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 678 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 679 Networks", RFC 5920, July 2010. 681 [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 682 Graveman, "MPLS Transport Profile (MPLS-TP) Security 683 Framework", RFC 6941, April 2013. 685 Authors' Addresses 687 Curtis Villamizar (editor) 688 OCCNC, LLC 690 Email: curtis@occnc.com 692 Dave McDysan (editor) 693 Verizon 694 22001 Loudoun County PKWY 695 Ashburn, VA 20147 696 USA 698 Email: dave.mcdysan@verizon.com 700 So Ning 701 Tata Communications 703 Email: ning.so@tatacommunications.com 705 Andrew Malis 706 Verizon 707 60 Sylvan Road 708 Waltham, MA 02451 709 USA 711 Phone: +1 781-466-2362 712 Email: andrew.g.malis@verizon.com 714 Lucy Yong 715 Huawei USA 716 5340 Legacy Dr. 717 Plano, TX 75025 718 USA 720 Phone: +1 469-277-5837 721 Email: lucy.yong@huawei.com