idnits 2.17.1 draft-ietf-rtgwg-cl-requirement-13.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 (November 13, 2013) is 3789 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: May 17, 2014 Verizon 6 S. Ning 7 Tata Communications 8 A. Malis 9 Consultant 10 L. Yong 11 Huawei USA 12 November 13, 2013 14 Requirements for Advanced Multipath in MPLS Networks 15 draft-ietf-rtgwg-cl-requirement-13 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 May 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 13 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 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 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 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 exercised, 387 then a client LSP that is bound to an advanced multipath may be 388 bound to any component link matching all other signaled 389 requirements, and different directions of a bidirectional client 390 LSP can be bound to different component links. 392 FR#14 The solution MUST support a means to indicate that both 393 directions of co-routed bidirectional client LSP MUST be bound to 394 the same set of nodes. 396 A client LSP which is bound to a specific component link SHOULD NOT 397 exceed the capacity of a single component link. 399 For some large bidirectional client LSP it may not be necessary (or 400 possible due to the client LSP capacity) to bind the LSP to a common 401 set of component links but may be necessary or desirable to constrain 402 the path taken by the LSP to the same set of nodes in both 403 directions. Without and entirely new and highly dynamic protocol, it 404 is not feasible to constrain such an bidirectional client LSP to take 405 multiple paths and coordinate load balance on each side to keep both 406 directions of flows within such an LSP on common paths. 408 3.5. Multipath Load Balancing Dynamics 410 Multipath load balancing attempts to keep traffic levels on all 411 component links below congestion levels if possible and preferably 412 well balanced. Load balancing is minimally disruptive (see 413 discussion below this section's list of requirements). The 414 sensitivity to these minimal disruptions of traffic flows within 415 specific client LSP needs to be considered. 417 FR#15 The solution SHALL provide a means that indicates whether any 418 of the flows within an client LSP MUST NOT be split across 419 multiple component links. 421 FR#16 The solution SHALL provide a means local to a node that 422 automatically distributes flows across the component links in the 423 advanced multipath such that Performance Objectives are met as 424 described in prior requirements in Section 3.3. 426 FR#17 The solution SHALL measure traffic flows or groups of traffic 427 flows and dynamically select the component link on which to place 428 this traffic in order to balance the load so that no component 429 link in the advanced multipath between a pair of nodes is 430 overloaded. 432 FR#18 When a traffic flow is moved from one component link to another 433 in the same advanced multipath between a set of nodes, it MUST be 434 done so in a minimally disruptive manner. 436 FR#19 Load balancing MAY be used during sustained low traffic periods 437 to reduce the number of active component links for the purpose of 438 power reduction. 440 FR#20 The solution SHALL provide a means to identify client LSPs 441 containing traffic flows whose rearrangement frequency needs to 442 be bounded by a specific value and MUST provide a means to bound 443 the rearrangement frequency for traffic flows within these client 444 LSP. 446 FR#21 The solution SHALL provide a means to distribute traffic flows 447 from a single client LSP across multiple component links to 448 handle at least the case where the traffic carried in an client 449 LSP exceeds that of any component link in the advanced multipath. 451 FR#22 The solution SHOULD support the use case where an advanced 452 multipath itself is a component link for a higher order advanced 453 multipath. For example, an advanced multipath comprised of MPLS- 454 TP bi-directional tunnels viewed as logical links could then be 455 used as a component link in yet another advanced multipath that 456 connects MPLS routers. 458 FR#23 If the total demand offered by traffic flows exceeds the 459 capacity of the advanced multipath, the solution SHOULD define a 460 means to cause some client LSP to move to an alternate set of 461 paths that are not congested. These "preempted LSP" may not be 462 restored if there is no uncongested path in the network. 464 A minimally disruptive change implies that as little disruption as is 465 practical occurs. Such a change can be achieved with zero packet 466 loss. A delay discontinuity may occur, which is considered to be a 467 minimally disruptive event for most services if this type of event is 468 sufficiently rare. A delay discontinuity is an example of a 469 minimally disruptive behavior corresponding to current techniques. 471 A delay discontinuity is an isolated event which may greatly exceed 472 the normal delay variation (jitter). A delay discontinuity has the 473 following effect. When a flow is moved from a current link to a 474 target link with lower latency, reordering can occur. When a flow is 475 moved from a current link to a target link with a higher latency, a 476 time gap can occur. Some flows (e.g., timing distribution, PW 477 circuit emulation) are quite sensitive to these effects. A delay 478 discontinuity can also cause a jitter buffer underrun or overrun 479 affecting user experience in real time voice services (causing an 480 audible click). These sensitivities may be specified in a 481 Performance Objective. 483 As with any load balancing change, a change initiated for the purpose 484 of power reduction may be minimally disruptive. Typically the 485 disruption is limited to a change in delay characteristics and the 486 potential for a very brief period with traffic reordering. The 487 network operator when configuring a network for power reduction 488 should weigh the benefit of power reduction against the disadvantage 489 of a minimal disruption. 491 4. General Requirements for Protocol Solutions 493 This section defines requirements for protocol specification used to 494 meet the functional requirements specified in Section 3. 496 GR#1 The solution SHOULD extend existing protocols wherever 497 possible, developing a new protocol only where doing so adds a 498 significant set of capabilities. 500 GR#2 A solution SHOULD extend LDP capabilities to meet functional 501 requirements (without using TE methods as decided in [RFC3468]). 503 GR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported 504 on an advanced multipath. Function requirements SHOULD, where 505 possible, be accommodated in a manner that supports LDP signaled 506 LSP, RSVP signaled LSP, and LSP set up using management plane 507 mechanisms. 509 GR#4 When the nodes connected via an advanced multipath are in the 510 same MPLS network topology, the solution MAY define extensions to 511 the IGP. 513 GR#5 When the nodes are connected via an advanced multipath are in 514 different MPLS network topologies, the solution SHALL NOT rely on 515 extensions to the IGP. 517 GR#6 The solution SHOULD support advanced multipath IGP 518 advertisement that results in convergence time better than that 519 of advertising the individual component links. The solution 520 SHALL be designed so that it represents the range of capabilities 521 of the individual component links such that functional 522 requirements are met, and also minimizes the frequency of 523 advertisement updates which may cause IGP convergence to occur. 525 Examples of advertisement update triggering events to be 526 considered include: client LSP establishment/release, changes in 527 component link characteristics (e.g., latency, up/down state), 528 and/or bandwidth utilization. 530 GR#7 When a worst case failure scenario occurs, the number of RSVP- 531 TE client LSPs to be resignaled will cause a period of 532 unavailability as perceived by users. The resignaling time of 533 the solution MUST support protocol mechanisms meeting existing 534 provider Performance Objective for the duration of unavailability 535 without significantly relaxing those existing Performance 536 Objectives for the same network or for networks with similar 537 topology. For example, the processing load due to IGP 538 readvertisement MUST NOT increase significantly and the 539 resignaling time of the solution MUST NOT increase significantly 540 as compared with current methods. 542 5. Management Requirements 544 MR#1 Management Plane MUST support polling of the status and 545 configuration of an advanced multipath and its individual 546 advanced multipath and support notification of status change. 548 MR#2 Management Plane MUST be able to activate or de-activate any 549 component link in an advanced multipath in order to facilitate 550 operation maintenance tasks. The routers at each end of an 551 advanced multipath MUST redistribute traffic to move traffic from 552 a de-activated link to other component links based on the traffic 553 flow TE criteria. 555 MR#3 Management Plane MUST be able to configure a client LSP over an 556 advanced multipath and be able to select a component link for the 557 client LSP. 559 MR#4 Management Plane MUST be able to trace which component link a 560 client LSP is assigned to and monitor individual component link 561 and advanced multipath performance. 563 MR#5 Management Plane MUST be able to verify connectivity over each 564 individual component link within an advanced multipath. 566 MR#6 Component link fault notification MUST be sent to the 567 management plane. 569 MR#7 Advanced multipath fault notification MUST be sent to the 570 management plane and MUST be distributed via link state message 571 in the IGP. 573 MR#8 Management Plane SHOULD provide the means for an operator to 574 initiate an optimization process. 576 MR#9 An operator initiated optimization MUST be performed in a 577 minimally disruptive manner as described in Section 3.5. 579 6. Acknowledgements 581 Frederic Jounay of France Telecom and Yuji Kamite of NTT 582 Communications Corporation co-authored a version of this document. 584 A rewrite of this document occurred after the IETF77 meeting. 585 Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG chairs John 586 Scuder and Alex Zinin, the current WG chair Alia Atlas, and others 587 provided valuable guidance prior to and at the IETF77 RTGWG meeting. 589 Tony Li and John Drake have made numerous valuable comments on the 590 RTGWG mailing list that are reflected in versions following the 591 IETF77 meeting. 593 Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG 594 mailing list after IETF82 that identified a new requirement. 595 Iftekhar Hussain made numerous valuable comments on the RTGWG mailing 596 list that resulted in improvements to document clarity. 598 In the interest of full disclosure of affiliation and in the interest 599 of acknowledging sponsorship, past affiliations of authors are noted. 600 Much of the work done by Ning So occurred while Ning was at Verizon. 601 Much of the work done by Curtis Villamizar occurred while at 602 Infinera. Much of the work done by Andy Malis occurred while Andy 603 was at Verizon. 605 Tom Yu and Francis Dupont provided the SecDir and GenArt reviews 606 respectively. Both reviews provided useful comments. The current 607 wording of the security section is based on suggested wording from 608 Tom Yu. Lou Berger provided the RtgDir review which resulted in the 609 document being renamed and substantial clarification of terminology 610 and document wording, particularly in the Abstract, Introduction, and 611 Definitions sections. 613 7. IANA Considerations 615 This memo includes no request to IANA. 617 8. Security Considerations 618 The security considerations for MPLS/GMPLS and for MPLS-TP are 619 documented in [RFC5920] and [RFC6941]. This document does not impact 620 the security of MPLS, GMPLS, or MPLS-TP. 622 The additional information that this document requires does not 623 provide significant additional value to an attacker beyond the 624 information already typically available from attacking a routing or 625 signaling protocol. If the requirements of this document are met by 626 extending an existing routing or signaling protocol, the security 627 considerations of the protocol being extended apply. If the 628 requirements of this document are met by specifying a new protocol, 629 the security considerations of that new protocol should include an 630 evaluation of what level of protection is required by the additional 631 information specified in this document, such as data origin 632 authentication. 634 9. References 636 9.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, March 1997. 641 9.2. Informative References 643 [I-D.ietf-rtgwg-cl-framework] 644 Ning, S., McDysan, D., Osborne, E., Yong, L., and C. 645 Villamizar, "Composite Link Framework in Multi Protocol 646 Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-01 647 (work in progress), August 2012. 649 [I-D.ietf-rtgwg-cl-use-cases] 650 Ning, S., Malis, A., McDysan, D., Yong, L., and C. 651 Villamizar, "Composite Link Use Cases and Design 652 Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in 653 progress), August 2012. 655 [IEEE-802.1AX] 656 IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE 657 Standard for Local and Metropolitan Area Networks - Link 658 Aggregation", 2006, . 661 [ITU-T.G.800] 662 ITU-T, "Unified functional architecture of transport 663 networks", 2007, . 666 [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label 667 Switching (MPLS) Working Group decision on MPLS signaling 668 protocols", RFC 3468, February 2003. 670 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 671 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 673 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 674 Networks", RFC 5920, July 2010. 676 [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 677 Graveman, "MPLS Transport Profile (MPLS-TP) Security 678 Framework", RFC 6941, April 2013. 680 Authors' Addresses 682 Curtis Villamizar (editor) 683 OCCNC, LLC 685 Email: curtis@occnc.com 687 Dave McDysan (editor) 688 Verizon 689 22001 Loudoun County PKWY 690 Ashburn, VA 20147 691 USA 693 Email: dave.mcdysan@verizon.com 695 So Ning 696 Tata Communications 698 Email: ning.so@tatacommunications.com 700 Andrew Malis 701 Consultant 703 Email: agmalis@gmail.com 704 Lucy Yong 705 Huawei USA 706 5340 Legacy Dr. 707 Plano, TX 75025 708 USA 710 Phone: +1 469-277-5837 711 Email: lucy.yong@huawei.com