idnits 2.17.1 draft-zhang-pce-resource-sharing-07.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 == Line 26 has weird spacing: '... months and ...' == Line 27 has weird spacing: '... at any time...' == Line 28 has weird spacing: '...ference mate...' == Line 475 has weird spacing: '...nd such reque...' -- The document date (September 3, 2018) is 2062 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Stateful-PCE' is mentioned on line 101, but not defined == Missing Reference: 'RFC3209' is mentioned on line 141, but not defined == Missing Reference: 'TBD2' is mentioned on line 376, but not defined == Unused Reference: 'RFC8231' is defined on line 536, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Xian Zhang 2 Internet Draft Haomian Zheng 3 Category: Standards track Huawei Technologies 4 Oscar Gonzales de Dios 5 Victor Lopez 6 Telefonica I+D 8 Expires: March 3, 2019 September 3, 2018 10 Extensions to Path Computation Element Protocol (PCEP) to Support 11 Resource Sharing-based Path Computation 13 draft-zhang-pce-resource-sharing-07.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 3, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Requirements Language 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 Abstract 62 Resource sharing in a network means two or more Label Switched Paths 63 (LSPs) use common piece(s) of resource along their paths. This can 64 help save network resource and is useful in scenarios such as LSP 65 recovery or when two LSPs do not need to be active at the same time. 66 A Path Computation Element (PCE) is responsible for path computation 67 with such requirement. Given this feature and its access to the 68 network resource information and possibly active LSPs information, 69 it can be used to support resource-sharing-based path computation 70 with better efficiency. 72 This document extends the Path Computation Element Protocol (PCEP) 73 in order to support resource sharing-based path computation. 75 Table of Contents 77 1. Introduction and Motivation.................................. 3 78 2. Motivation .................................................. 4 79 2.1. Single PCE Use Case..................................... 4 80 2.2. Multiple PCEs Use Case.................................. 6 81 3. Extensions to PCEP .......................................... 8 82 3.1. Association group and type.............................. 8 83 3.2. Resource Sharing TLV.................................... 8 84 3.3. Processing Rules....................................... 10 85 4. Security Considerations..................................... 11 86 5. IANA Considerations ........................................ 11 87 5.1. Association Object Type Indicators .................... 11 88 6. References ................................................. 12 89 6.1. Normative References................................... 12 90 6.2. Informative References................................. 13 91 7. Authors' Addresses ......................................... 13 93 1. Introduction and Motivation 95 A Path Computation Element (PCE) provides an alternative way for 96 providing path computation function, and it is especially useful in 97 the scenarios where complex constraints and/or a demanding amount of 98 computation resource are required [RFC4655]. The development of PCE 99 standardization has evolved from stateless to stateful. A stateful 100 PCE has access to the LSP database information of the network(s) it 101 serves as a computation engine [Stateful-PCE]. Unless specified, 102 this document assumes a PCE mentioned is a stateful PCE (either 103 passive or active). 105 Resource sharing denotes that two or more Label Switched Paths 106 (LSPs) share common piece(s) of resource, (such as a common time 107 slot of a link in an Optical Transport Network (OTN)). This is 108 usually useful in the scenario where only one LSP is active and the 109 benefit herein is to save network resources. A simple example of 110 this is dynamically calculating a LSP for an existing LSP undergoing 111 a link failure. Note that the resource sharing can be worked out 112 using a statelss PCE, but the mechanism may be complex and is out 113 the scope of this draft. 115 This document considers the following requirement: new LSP may 116 request for resource sharing with one or multiple existing LSPs. 117 Furthermore, if there is resource sharing between new LSP and 118 existing LSP, the two LSPs cannot exist simultaneously, the new LSP 119 will replace the existing LSP(s). 121 In a single domain, this is a common requirement in the recovery 122 cases especially in order to increase traffic resilience against 123 failure while reducing the amount of network resource used for 124 recovery purpose [RFC4428]. 126 The current protocol supporting the communication between a PCE and 127 a Path Computation Client (PCC), i.e. PCE Protocol (PCEP), allows 128 for re-optimization of an existing LSP [RFC5440]. This is achieved 129 by setting R bit in the Request Parameter (RP) object, together with 130 some additional information if applicable, in the Path Computation 131 Request (PCReq) message sent from a PCC to the PCE. To support this 132 type of resource sharing, a PCC needs to ask a PCE to compute a new 133 path with the constraints of sharing resource with one or multiple 134 existing LSPs. It is worth noting the "resource sharing" in this 135 draft not only means one LSP re-using the same link(s) of another 136 LSP, but also the same slice of bandwidth. This may occur when an 137 LSP is required for re-routing, or online re-optimization. Current 138 PCEP specifications do not provide such function. More specifically, 139 this draft describes the resource sharing issue during the procedure 140 when a new LSP is required to replace an existing LSP, which can be 141 used together with Make-before-break (MBB) described in [RFC3209]. 142 There are a few objects which indicate the resource sharing/disjoint 143 relationships, such as SRLG and ASSOCIATE. However, these objects 144 are used to describe the relationship with two simultaneous LSPs, 145 instead of a new one and an old one, which is different with the 146 object proposed in this draft. 148 As mentioned in [stateful-PCE], the PLSP-ID is unique during a PCEP 149 session between PCC and PCE. Such identification is helpful in 150 supporting the above resource sharing requirement for 151 standardization of stateful PCEs. With a unique identifier, the 152 configuration of PCCs is greatly simplified. Instead of determining 153 all the resources to be shared, the PCC could request resource 154 sharing directly from PCE. 156 The resource sharing can also be required in an inter-layer PCEP 157 session. This is similar to the previous requirement. However, it is 158 more complex and therefore deserves a more detailed explanation 159 here. 161 In a multi-layer network, Label Switched Paths (LSPs) in a lower 162 layer are used to carry higher-layer LSPs across the lower-layer 163 network [RFC5623]. Therefore, the resource sharing constraints in 164 the higher layer might actually relate to the resource sharing in 165 the lower layer. Thus, it is useful to consider how this can be 166 achieved and whether additional extensions are needed using the 167 models defined in [RFC5623]. 169 In the next sections, use cases are provided to show what 170 information needs to be exchanged to fulfill these requirements. 171 This memo then provides extensions to PCEP to enable this function. 173 2. Motivation 175 2.1. Single PCE Use Case 177 Figure 1 shows a single domain network with a stateful PCE. Assume a 178 working LSP (N1-N2-N3) exists in the network, when there is failure 179 on the link N2-N3, it is desired to set up a restoration path for 180 this working LSP. Suppose N1 serves as the PCC and sends a request 181 to the stateful PCE for such an LSP. Before sending the request, N1 182 may need to check what policy should be applied for the path re- 183 computation. For example, it might value resource sharing and prefer 184 to share as much resource with the working LSP as possible and 185 specify this policy in the PCReq message. If resources are shared 186 between the old and new LSPs, there will be some 'interruption' when 187 the traffic is switched from the old LSP to the new LSP. Here the 188 resources to be shared mean the LSP information, which includes the 189 node, link and corresponding SRLG information, etc. 191 On the other hand, in some scenarios there are different policies, 192 for example the LSP should be restored without any interruption with 193 best effort. An example can be found in Fig. 1 without failure on 194 N2-N3 link, instead, an online re-optimization is needed for the 195 working LSP (N1-N2-N3) from the stateful PCE. In such cases, the 196 best choice is to set up a backup LSP for the working LSP with 197 totally separate routing (for example N1-N5-N4-N3), and move the 198 traffic to that backup LSP. After that the working LSP can be torn 199 down, which will not result in any interruption during the 200 optimization procedure. This can actually be implemented with 201 existing PCEP mechanism. However, if there is no such separate path, 202 existing PCEP will reply error. A secondary option for this case is 203 to set up an LSP and complete such re-optimization with resource 204 sharing, even if some interruption introduced. Given the resource 205 from the LSP to be interrupted, there may be some solutions instead 206 of Path Compute error due to the lack of resource. 208 A simple illustration is provided below: 210 +--------------+ 211 | | 212 | Stateful PCE | 213 | | 214 +--------------+ 216 +------+ +------+ +------+ 217 | N1 +----------+ N2 +-----X----+ N3 | 218 +--+---+ +---+--+ +---+--+ 219 | | | 220 | +---------+ | 221 | | | 222 | +------+ +------+ | 223 +-----+ N5 +----------+ N4 +-----+ 224 +------+ +------+ 226 Figure 1: A Single Domain Example 228 Available recovery paths computed by the stateful PCE: 230 LSP1: N1-N2-N4-N3 231 LSP2: N1-N5-N4-N3 233 If resource sharing is preferred, the stateful PCE will reply with 234 LSP1 information. Instead, if PCC prefer to have less interruption, 235 PCE will reply with LSP2 information. 237 Another piece of information that needs to be conveyed to the PCE is 238 the information about the working path LSP. Note this simple use 239 case assumes end-to-end recovery. But in order to be applicable to 240 use cases such as shared mesh protection purpose, where the head-end 241 or tail-end nodes may be different, this information is necessary in 242 the message exchange between PCCs and PCEs, so that the stateful PCE 243 knows which LSP the path computation request wants to share the 244 resource. 246 Besides, parameter changes during the resource sharing computation 247 also need to be considered. For example, the bandwidth of the 248 request LSP may be different with the existing LSP, while resource 249 sharing is still preferred by the PCC. PCE should consider the 250 sharing request together with the policy and available resource(s) 251 in the network. Details can be found in Section 3.3. 253 2.2. Multiple PCEs Use Case 255 Figure 2 shows a two-layer network example, with each layer managed 256 by a PCE. As Discussed in Section 3 of [RFC5623], there are three 257 models for inter-layer path computation. They are single PCE 258 computation, multiple PCE with inter-PCE communication and multiple 259 PCE without inter-PCE communication, respectively. For the single 260 PCE computation, the process would be similar to that of the use 261 case in Section 2.1. Thus, this model is not discussed further. 263 ----- 264 .................................| LSR | 265 .: | H5 | 266 .: /----- 267 .: / | 268 ----- -----.: ----- -----/ | 269 | LSR |--| LSR |.......................| LSR |--| LSR | / 270 | H1 | | H2 | | H3 | | H4 | / 271 ----- -----\ /----- ----- / 272 \ / / 273 \ / / 274 \ / / 275 \ / / 276 \----- -----/ / 277 | LSR |-| LSR | / 278 | L1 | | L2 | / 279 ----- -----\ / 280 | \ / 281 | \ / 282 | \ / 283 ----- \-----/ 284 | LSR |-----------| LSR | 285 | L3 | | L4 | 286 ----- ----- 287 Figure 2: A Two-layer Network Example 289 An inter-layer path computation example is shown in Fig. 2, assume a 290 LSP (LSP1: H2-H3) has been established already, visible as H2-H3 291 from view of higher-layer PCE and H2-L1-L2-H3 from the global view 292 (or from the view of lower-layer PCE). A new request comes at H2 to 293 establish a new LSP (LSP2: from H2 to H5), given the constraint it 294 can share resource with LSP1. This requirement is possible if only 295 one of the LSPs needs to be active and resource sharing is the 296 target. 298 If multiple PCE with inter-PCE communication model is employed, the 299 path computation request sent by H2 to higher-layer PCE will be 300 forwarded to lower-layer PCE since there is no resource readily 301 available in the higher layer. So it leaves the lower-layer PCE to 302 compute a path in the lower layer in order to support the higher 303 layer request. In this case, lower-layer PCE is required to compute 304 a path between H2 and H5 under the constraint that it can share the 305 resource with that of the LSP1. At this moment the lower-layer PCE 306 has the knowledge on the explicit routing that LSP1 go through (H2- 307 L1-L2-H3), and therefore can map the lower layer LSP with the 308 higher-layer one. So when lower-layer PCE computes the path for 309 LSP2, it can consider the resource used by LSP1 as available with 310 higher priority. For example, lower-layer PCE may choose H2-L1-L2- 311 L4-H5 as the computation result. On the other hand, if the path 312 computation policy is to have a separate path with LSP1, the lower- 313 layer PCE may choose H2-L1-L3-L4-H5. 315 During this procedure higher-layer PCE can only use LSP1 information 316 (such as its five-tuple LSP information) as the information, an 317 issue to solve is how lower-layer PCE can resolve this information 318 to the actual resource usage in its own layer, i.e. lower layer. 319 This could be solved by edge LSR L1 reporting this higher-lower 320 layer LSP correlation to the lower-layer PCE as part of the LSP 321 information during the LSP state synchronization process. If needed, 322 it can be later updated when there is a change in this information. 323 Alternatively, the lower-layer PCE can get this information from 324 other sources, such as network management system, where this 325 information should be stored. 327 If multiple PCE without inter-PCE communication model is employed, 328 the path computation request in the lower layer will be initiated 329 the border LSR node, i.e., L1. The process would be similar to that 330 of the previous scenario. A point worth noting is that the border 331 LSR node may be able to resolve the higher layer LSP information 332 itself, such as mapping it to the corresponding LSP in the lower 333 layer, in this way lower-layer PCE does not need to perform this 334 function. Otherwise, the mapping method mentioned above can still be 335 used. 337 3. Extensions to PCEP 339 This section provides PCEP extensions. Currently the text focuses 340 only on passive stateful PCE and corresponding PCReq. But if active 341 stateful PCE delegation is used, we would like to convey the same 342 information in PCRpt. In the passive stateful PCE architecture, a 343 PCC is allowed to specify resource sharing when sending a PCReq 344 message. It also details the processing rule and error codes needed. 346 3.1. Association group and type 348 According to the definition in [ietf-pce-association-group], the 349 association group is used to associate multiple LSPs into one group 350 for further path computation considerations, such as disjointness 351 and resource sharing. An association ID will be used to identify the 352 resource sharing group. An association type that described 353 disjointness has been defined in [ietf-pce-association-diversity]. 354 In this draft, a new association type is defined as: 356 Association type = TBD1 ("Sharing Association Type"). 358 A sharing group should have multiple LSPs. The number of LSPs and 359 the criteria for how LSPs share among each other are implementation 360 dependent. Local path computation policies apply to different PCE 361 and PCC, some examples can be found in section 2. 363 3.2. Resource Sharing TLV 365 The PCEP Resource Sharing group MUST carry the following TLV. It MAY 366 be carried within a PCReq message from the network element (or other 367 PCCs) so as to indicate the desired resource sharing requirements to 368 be applied by the stateful PCE during path computation. 370 0 1 2 3 372 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Type = [TBD2] | Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Flags |S|N|L| 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Optional TLVs | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Currently the following flags have been defined: 390 * L (Link share) bit: when set, this flag indicates that the PCE 391 should prioritize the links that shared by existing LSPs within the 392 sharing group for path computation. 394 * N (Node share) bit: when set, this flag indicates that the PCE 395 should prioritize the nodes that shared by existing LSPs within the 396 sharing group for path computation. 398 * S (SRLG share) bit: bit: when set, this flag indicates that the 399 PCE should set the SRLG (Shared Risk Link Group) of the computed LSP 400 to the same as existing LSPs within the sharing group for path 401 computation. 403 Optional TLVs may be needed to indicate the LSP(s) with which the 404 resource is shared. If multiple LSPs are required, the PCE may need 405 to consider different sharing policies, which is implementation 406 dependent and may result in a different computing result. The 407 selection policy among multiple computation result is out of the 408 scope of this draft. 410 3.3. Processing Rules 412 To request a path allowing sharing resource with one or multiple 413 existing LSPs, a PCC includes a Resource Sharing TLV in the 414 association group object in the PCReq message. 416 On receipt of a PCReq message with a Resource Sharing TLV, a 417 stateful PCE MUST proceed as follows: 419 - If the Resource Sharing TLV is unknown/unsupported, the PCE will 420 follow procedures defined in [RFC5440]. That is, the PCE sends a 421 PCErr message with error type 3 or 4 (Unknown / Not supported 422 object) and error value 1 or 2 (unknown / unsupported object class 423 / object type), and the related path computation request is 424 discarded. 426 - If Resource Sharing TLV are unknown/unsupported and the P bit is 427 set, the PCE MUST send a PCErr message with error type 3 or 4 428 (Unknown / Not supported object) and error value 4 429 (Unrecognized/Unsupported parameter), and the related path 430 computation request MUST be discarded as defined in [RFC5440]. 432 - If the resource sharing TLV is extracted correctly, the PCE MUST 433 apply the requested resource sharing requirement. 435 The procedure of setting flags follows the rules defined in Section 436 3.1. The RSO flags may be locally configured on the requesting nodes 437 via external entities, such as a network management system or the 438 entity that impose the resource sharing requirement. 440 It is worth noting that the Resource Sharing TLV can be used 441 together with other path indication objects like IRO/XRO, with 442 difference objectives. The first difference is, the use of Resource 443 Sharing TLV is to setup an alternative path, instead a new path. It 444 is also dependent on the knowledge of PCC, e.g., if the PCC have a 445 full knowledge of the path information and have strong preference on 446 the route, it may send the PCReq with IRO message to specify the 447 route. On the other hand, if the PCC does not know how the path 448 should go but just want to set up a new LSP to replace the old one, 449 it may use the Resource Sharing TLV instead of IRO. The second 450 difference is, resource Sharing TLV is a loose requirement. For 451 example, if the constraint specified in IRO/XRO in an A-Z path 452 computation request cannot be satisfied, the PCRep from PCE to PCC 453 would be unsuccessful. However it is still possible to have a path 454 from the A-Z. If the target node/link/SRLG is set in Resource 455 Sharing TLV rather than IRO, the PCE may feedback a path that from 456 A-Z that not sharing the target specified in Resource Sharing TLV. 458 4. Security Considerations 460 Security of PCEP is discussed in [RFC5440] and [RFC6952]. The 461 extensions in this document do not change the fundamentals of 462 security for PCEP. 464 However, the introduction of the Resource Sharing TLV in association 465 group object provides a vector that may be used to probe for 466 information from a network. For example, a PCC that wants to 467 discover the path of an LSP with which it is not involved can issue 468 a PCReq with a Resource sharing TLV and may be able to get back 469 quite a lot of information about the path of the LSP through issuing 470 multiple such requests for different endpoints and analyzing the 471 received results. To protect against this, a PCE should be 472 configured with access and authorization controls such that only 473 authorized PCCs (for example, those within the network) can make 474 computation requests, only specifically authorized PCCs can make 475 requests for resource sharing, and such requests relating to 476 specific LSPs are further limited to a select few PCCs. How such 477 access controls and authorization is managed is outside the scope of 478 this document, but it will at the least include Access Control 479 Lists. 481 Furthermore, a PCC must be aware that setting up an LSP that share 482 resources with another LSP may be a way of attacking the other LSP, 483 for example by depriving it of the resources it needs to operate 484 correctly. Thus it is important that, both in PCEP and the 485 associated signaling protocols, only authorized resource sharing is 486 allowed. 488 5. IANA Considerations 490 5.1. Association Object Type Indicators 492 This document defines a new association type, with the following 493 information: 495 Object Name Object Reference 496 Class Type 497 ------------------------------------------------------------ 499 TBA1 Sharing-group Association Type [this document] 501 5.2 PCEP TLV Definitions 502 This document defines the following TLVs to support the resource 503 sharing scenario: 505 Value Name Reference 506 ------------------------------------------------------------ 508 TBA2 Resource-sharing TLV [this document] 510 IANA is requested to allocate the following bit numbers in the flag 511 spaces of Resource-sharing TLV: 513 Bit Flag name Reference 515 0 Link Share [this document] 517 1 Node Share [this document] 519 2 SRLG Share [this document] 521 6. References 523 6.1. Normative References 525 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 526 requirements levels", RFC 2119, March 1997. 528 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 529 Computation Element (PCE)-Based Architecture", RFC 4655, 530 August 2006. 532 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 533 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 534 March 2009. 536 [RFC8231] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 537 Extensions for Stateful PCE", RFC8231, June 2017. 539 [ietf-pce-association-group] Minei, I., Crabbe E., Sivabalan S., 540 Ananthakrishnan H., Dhody D., Tanaka Y., "PCEP Extensions 541 for Establishing Relationships Between Sets of LSPs", work 542 in Progress. 544 [ietf-pce-association-diversity] Litkowski, S., Sivabalan, S., 545 Barth, C., Dhody, D., "Path Computation Element 546 communication Protocol extension for signaling LSP 547 diversity constraint", Work in Progress. 549 6.2. Informative References 551 [RFC4428] Papadimitriou, D., Mannie., E., "Analysis of Generalized 552 Multi-Protocol Label Switching (GMPLS)-based Recovery 553 Mechanisms (including Protection and Restoration)", 554 RFC4428, March 2006. 556 [RFC5623] Oki., E., Takeda, T., Le Roux, JL., Farrel, A., "Framework 557 for PCE-Based Inter-Layer MPLS and GMPLS Traffic 558 Engineering", RFC5623, September 2009. 560 [RFC6952] Jethanandani, M., Patel, K., Zheng, L., "Analysis of BGP, 561 LDP, PCEP, and MSDP Issues According to the Keying and 562 Authentication for Routing Protocols (KARP) Design Guide", 563 RFC6952, May 2013. 565 7. Authors' Addresses 567 Xian Zhang 568 Huawei Technologies 570 Email: zhang.xian@huawei.com 572 Haomian Zheng 573 Huawei Technologies 575 Email: zhenghaomian@huawei.com 577 Oscar Gonzalez de Dios 578 Telefonica I+D 579 Don Ramon de la Cruz 82-84 580 Madrid 28045 581 Spain 582 EMail: ogondio@tid.es 584 Victor Lopez 585 Telefonica I+D 586 Don Ramon de la Cruz 82-84 587 Madrid 28045 588 Spain 589 EMail: vlopez@tid.es 591 Contributor's Address : 593 Dhruv Dhody 594 Huawei Technologies 595 Email: dhruv.dhody@huawei.com 597 Igor Bryskin 598 Huawei Technologies 599 Email: Igor.Bryskin@huawei.com