idnits 2.17.1 draft-chen-mpls-source-label-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For inter-AS scenario, BGP extension is a naturally choice and can be used to convey SI mapping information from one AS to other ASes. The BGP extension draft is work in progress. For BGP based SI distribution, it requires that SIs MUST not be sent out of a SIAD. The similar sending and receiving restriction as defined in Section 6.2.1 is also needed. -- The document date (October 13, 2014) is 3476 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) -- Looks like a reference, but probably isn't: '16' on line 164 -- Looks like a reference, but probably isn't: '65535' on line 164 == Unused Reference: 'RFC5420' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC4761' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC5065' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC6790' is defined on line 559, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Chen 3 Internet-Draft X. Xu 4 Intended status: Standards Track Z. Li 5 Expires: April 16, 2015 Huawei 6 L. Fang 7 Microsoft 8 G. Mirsky 9 Ericsson 10 October 13, 2014 12 MultiProtocol Label Switching (MPLS) Source Label 13 draft-chen-mpls-source-label-06 15 Abstract 17 A MultiProtocol Label Switching (MPLS) label was originally defined 18 to identify a Forwarding Equivalence Class (FEC). A packet is 19 assigned to a specific FEC based on its network layer destination 20 address, and optionally Class of Service. It's difficult or even 21 impossible to derive the source identity information from the label. 22 For some applications, source identification is a critical 23 requirement. For example, performance monitoring, where the 24 monitoring node needs to identify where a packet was sent from. 26 This document introduces the concept of Source Identifier (SI) that 27 identifies the ingress Label Switching Router (LSR) of a Label 28 Switched Path (LSP). A SI is unique within a domain that is referred 29 to as Source Identifier Administrative Domain (SIAD). 31 This document also introduces the concept of Source Label (SL) that 32 is carried in the label stack and carries the SI of the ingress LSR 33 of an LSP. Source Label is preceded by a Source Label Indicator 34 (SLI) when included the label stack and is not used for forwarding. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on April 16, 2015. 59 Copyright Notice 61 Copyright (c) 2014 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Problem Statement and Introduction . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Source Label . . . . . . . . . . . . . . . . . . . . . . . . 4 79 4. Performance Measurement Use Case . . . . . . . . . . . . . . 5 80 5. Data Plane Processing . . . . . . . . . . . . . . . . . . . . 5 81 5.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 5 82 5.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 6 83 5.3. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . 6 84 5.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 6 85 6. Source Label Capability Signaling . . . . . . . . . . . . . . 6 86 6.1. LDP Extensions . . . . . . . . . . . . . . . . . . . . . 6 87 6.2. BGP Extensions . . . . . . . . . . . . . . . . . . . . . 7 88 6.2.1. Sending/Receiving Restriction . . . . . . . . . . . . 8 89 6.3. IGP Extensions . . . . . . . . . . . . . . . . . . . . . 9 90 7. Source Identifier Distribution . . . . . . . . . . . . . . . 9 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 92 8.1. Source Label Indication . . . . . . . . . . . . . . . . . 9 93 8.2. LDP Source Label Capability TLV . . . . . . . . . . . . . 10 94 8.3. BGP Source Label Capability Attribute . . . . . . . . . . 10 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 98 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 99 11.2. Informative References . . . . . . . . . . . . . . . . . 11 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 102 1. Problem Statement and Introduction 104 A MultiProtocol Label Switching (MPLS) label [RFC3031] was originally 105 defined for packet forwarding and assumes the forwarding/destination 106 address semantics. As no source identity information is carried in 107 the label stack, in many cases there is no way to directly derive the 108 source identity information from the label or label stack. 110 MPLS LSPs can be categorized into four different types: 112 o Point-to-Point (P2P) 114 o Point-to-Multipoint (P2MP) 116 o Multipoint-to-Point (MP2P) 118 o Multipoint-to-Multipoint (MP2MP) 120 For P2P and P2MP LSPs (e.g., the Resource Reservation Protocol 121 Traffic Engineering (RSVP-TE) [RFC3209] based and statically 122 configured P2P and P2MP LSPs), the source identity may be implicitly 123 derived by the egress LSR from the label when Penultimate Hop Popping 124 (PHP) is disabled and the correlation between ingress LSR and the LSP 125 is explicitly signaled through the control plane. Such LSP may be 126 characterized as MPLS-TP LSP [RFC5960]. 128 However, for MP2P and MP2MP LSPs (e.g., the Label Distribution 129 Protocol (LDP) based LSPs [RFC5036] [RFC6388], and Layer 3 Private 130 Network (L3VPN) [RFC4364] LSPs), ingress LSRs of those LSPs cannot be 131 identified by egress LSRs. 133 Comparing to the pure IP forwarding where both source and destination 134 addresses are encoded in the IP packet header, the essential issue of 135 the MPLS encoding is that the label stack does not explicitly include 136 any source identity information. For some applications, source 137 identification is a critical requirement. For example, performance 138 monitoring, the monitoring nodes need to identify where packets were 139 sent from and then can count the packets according to some 140 constraints. 142 This document introduces the concept of Source Label (SL). An SL is 143 carried in the label stack and carries the identifier of the ingress 144 LSR that originated the MPLS frame. 146 2. Terminology 148 SI - Source Identifier 150 SIAD - Source Identifier Administrative Domain 152 SL - Source Label 154 SLC - Source Label Capability 156 SLI - Source Label Indicator 158 3. Source Label 160 A Source Label is defined to carry an identifier (Source Identifier) 161 of a node that is (one of) the ingress LSR(s) to specific LSP. 162 Source Label SHOULD NOT be used for forwarding and is not signaled. 164 A Source Identifier (SI) is a number in the range of [16, 65535]. 165 Each node in a domain MUST be allocated one or more unique SIs, the 166 domain is referred as a "Source Identifier Administrative Domain" 167 (SIAD). For most of the use cases, one SI per LSR would be 168 sufficient. But for some cases, there may be need for more than one 169 SIs. For example, in the L3VPN scenario, it may be necessary to 170 allocate a dedicated SI to identify each VPN instance. 172 In order to indicate whether a label is a Source Label, a Source 173 Label Indicator (SLI) is introduced. The SLI is a special purpose 174 label [RFC7274] that is placed immediately before the source label in 175 the label stack, which is used to indicate that the next label in the 176 label stack is the Source Label. The value of SLI is TBD1. The SL 177 is an example of context label [RFC5331], the SLI is the context. 179 To prevent the Source Label from leaking to unintended domains, two 180 aspects need to be considered: 182 o In the control plane, the Source Label MUST NOT be distributed 183 outside the SIAD where it is used. Since the ingress LSR is based 184 on the Source Label Capability signaled by the egress LSR to 185 determine whether to insert the Source Label, the SLC signaling 186 MUST make sure that the SLC will not be signaled to the LSRs that 187 reside in other SIADs. 189 o In the data plane, the domain boundary nodes (e.g., the ASBR) 190 SHOULD have the capability to filter out the packets that carry 191 the SL/SLI and are received from other SIADs. For example, some 192 policies (e.g., using ACL) could be deployed at the ASBR to filter 193 out the packets that carry SL/SLI and are from other SIADs. 195 4. Performance Measurement Use Case 197 There are two general types of performance measurement: one is active 198 performance measurement, and the other is passive performance 199 measurement. 201 In active performance measurement the receiver measures the injected 202 packets to evaluate the performance of a path. The active 203 measurement measures the performance of the extra injected packets. 204 The IP Performance Metrics (IPPM) working group has defined 205 specifications [RFC4656][RFC5357] for active performance measurement. 207 In passive performance measurement, no additional traffic is injected 208 into the flow and measurements are taken to record the performance 209 metrics of the data traffic. The MPLS performance measurement 210 protocol [RFC6374] for packet loss is an example of passive 211 performance measurement, but currently it can only be measured for 212 MPLS-TE LSPs. For a specific receiver, in order to count the 213 received packets of a flow, the system doing the measurement (e.g., 214 egress router) needs to know which target flow a received packet 215 belongs to. Source identification is therefore necessary. Source 216 identification may be achieved by including appropriate MEP-ID 217 [RFC6428]. 219 As discussed in the previous section, the existing MPLS label or 220 label stack does not carry the source information. So, for an LSP, 221 the ingress LSR can put its SI in the Source Label, and then the 222 egress LSR can use the SI to identify the packet's source, in order 223 to facilitate accounting. 225 5. Data Plane Processing 227 5.1. Ingress LSR 229 For an LSP, the ingress LSR MUST make sure that the egress LSR is 230 able to process the Source Label before inserting the SLI/SL 231 combination into the label stack. Therefore, an egress LSR SHOULD 232 signal (see Section 6) to the ingress LSR whether it is able to 233 process the Source Label. Once the ingress LSR knows that the egress 234 LSR can process Source Label, it can choose whether or not to insert 235 the SL and SLI into the label stack. 237 When an SL to be included in a label stack, the steps are as follows: 239 1. Push the SL, the TTL of the SL MUST be set to 1, the BoS bit for 240 the SL depends on whether the SL is the bottom label. Setting 241 and interpretation of TC field of the SL is for further study; 243 2. Push the SLI, the TTL and TC fields for the SLI MUST be set to 244 the same values as for the LSP Label (L); 246 3. Push the LSP Label (L). 248 Then the label stack looks like: <...L, SLI, SL [,...]>. There MAY 249 be multiple combinations of SLI and SL inserted into the label stack, 250 each combination is related to an LSP. For the given LSP, only one 251 combination of SLI and SL MUST be inserted. 253 5.2. Transit LSR 255 There is no change in forwarding behavior for transit LSRs. If a 256 transit LSR can recognize the SLI, it can use the SL to collect 257 traffic throughput and/or measure the performance of the LSP. 259 5.3. Egress LSR 261 When an egress LSR receives a packet with a SLI/SL combination, if 262 the egress LSR is able to process the SL; it pops the LSP label (if 263 any), SLI and SL; then processes remaining packet header as normal. 264 If the egress LSR is not able to process the SLI, the packet SHOULD 265 be dropped as specified for the handling of any unknown label 266 according to [RFC3031]. 268 5.4. Penultimate Hop LSR 270 There is no change in forwarding behavior for the penultimate hop 271 LSR. 273 6. Source Label Capability Signaling 275 Before inserting a Source Label in the label stack, an ingress LSR 276 SHOULD know whether the egress LSR is able to process the SLI and SL. 277 Therefore, an egress LSR SHOULD signal to the ingress LSRs its 278 ability to process the SLI and SL. This is called Source Label 279 Capability (SLC), it is very similar to the "Entropy Label Capability 280 (ELC)"[RFC6790]. 282 6.1. LDP Extensions 284 A new LDP TLV [RFC5036], SLC TLV, is defined to signal an egress's 285 ability to process Source Label. The SLC TLV MAY appear as an 286 Optional Parameter of the Label Mapping Message. The presence of the 287 SLC TLV in a Label Mapping Message indicates to ingress LSRs that the 288 egress LSR can process Source Labels for the associated LSP. 290 The structure of the SLC TLV is shown below. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |U|F| Type (TBD2) | Length (0) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 1: Source Label Capability TLV 300 This U bit MUST be set to 1. If the SLC TLV is not understood by the 301 receiver, then it MUST be ignored. 303 This F bit MUST be set to 1. Since the SLC TLV is going to be 304 propagated hop-by-hop, it should be forwarded even by nodes that may 305 not understand it. 307 Type: TBD2. 309 Length field: This field specifies the total length in octets of the 310 SLC TLV and is defined to be 0. 312 An LSR that receives a Label Mapping with the SLC TLV but does not 313 understand it MUST propagate it intact to its neighbors and MUST NOT 314 send a notification to the sender (following the meaning of the U- 315 and F-bits). If the LSR has no other neighbors and does not 316 understand the SLC TLV, means it is the ingress LSR, it could just 317 ignore it. An LSR X may receive multiple Label Mappings for a given 318 FEC F from its neighbors. In its turn, X may advertise a Label 319 Mapping for F to its neighbors. If X understands the SLC TLV, and if 320 any of the advertisements it received for FEC F does not include the 321 SLC TLV, X MUST NOT include the SLC TLV in its own advertisements of 322 F. If all the advertised Mappings for F include the SLC TLV, then X 323 MUST advertise its Mapping for F with the SLC TLV. If any of X's 324 neighbors resends its Mapping, sends a new Mapping or sends a Label 325 Withdraw for a previously advertised Mapping for F, X MUST re- 326 evaluate the status of SLC for FEC F, and, if there is a change, X 327 MUST re-advertise its Mapping for F with the updated status of SLC. 329 LDP is normally running within an AS, technically, it can be deployed 330 across ASes. An implementation supports the SLC MUST support a per- 331 session/per-interface configuration item to enable/disable the SLC. 332 For the session/interface that connects to other SLADs, the SLC MUST 333 be disabled. 335 6.2. BGP Extensions 337 When Border Gateway Protocol (BGP) [RFC4271] is used for distributing 338 Network Layer Reachability Information (NLRI) as described in, for 339 example, [RFC3107], [RFC4364], the BGP UPDATE message may include the 340 SLC attribute as part of the Path Attributes. This is an optional, 341 non-transitive BGP attribute of value TBD3. The inclusion of this 342 attribute with an NLRI indicates that the advertising BGP router can 343 process Source Labels as an egress LSR for all routes in that NLRI. 345 A BGP speaker S that originates an UPDATE should include the SLC 346 attribute only if both of the following are true: 348 A1: S sets the BGP NEXT_HOP attribute to itself AND 350 A2: S can process source labels. 352 Suppose a BGP speaker T receives an UPDATE U with the SLC attribute. 353 T has two choices. T can simply re-advertise U with the SLC 354 attribute if either of the following is true: 356 B1: T does not change the NEXT_HOP attribute OR 358 B2: T simply swaps labels without popping the entire label stack and 359 processing the payload below. 361 An example of the use of B1 is Route Reflectors. However, if T 362 changes the NEXT_HOP attribute for U and in the data plane pops the 363 entire label stack to process the payload, T MAY include an SLC 364 attribute for UPDATE U' if both of the following are true: 366 C1: T sets the NEXT_HOP attribute of U' to itself AND 368 C2: T can process source labels. Otherwise, T MUST remove the SLC 369 attribute. 371 6.2.1. Sending/Receiving Restriction 373 An implementation that supports the SLC MUST support per-session 374 configuration item, SL_SESSION, that indicates whether the SLC is 375 enabled or disabled for use on that session. 377 - The default value of SL_SESSION, for EBGP sessions, MUST be 378 "disabled". 380 - The default value of SL_SESSION, for IBGP and confederation-EBGP 381 [RFC5065]sessions, SHOULD be "enabled." 383 The SLC attribute MUST NOT be sent on any BGP session for which 384 SL_SESSION is disabled. 386 If an SLC attribute is received on a BGP session for which SL_SESSION 387 is disabled, the attribute MUST be treated exactly as if it were an 388 unrecognized non-transitive attribute. That is, "it MUST be quietly 389 ignored and not passed along to other BGP peers" (see [RFC4271], 390 section 5). 392 6.3. IGP Extensions 394 IGP based SLC applies to the scenarios where IGP is used for label 395 mapping (e.g., Segment Routing). IGP SLC signaling is defined in 396 [I-D.chen-isis-source-identifier-distribution] and 397 [I-D.chen-ospf-source-identifier-distribution], the presence of a 398 Source Identifier TLV/sub-TLV MUST be interpreted as support of SLC 399 by the LSR. That means the SLC is implicitly indicated by receiving 400 a SI distribution from an LSR. 402 7. Source Identifier Distribution 404 Based on the Source Identifier, an egress or intermediate LSR can 405 identify from where an MPLS packet is sent. To achieve this, the 406 egress and/or intermediate LSRs have to know which ingress LSR is 407 related to which Source Identifier before using the Source Identifier 408 to derive the source information. Therefore, there needs to be a 409 mechanism to distribute the mapping information between an ingress 410 LSR and its SI(s). 412 IGP based SI distribution documents, 413 [I-D.chen-isis-source-identifier-distribution], 414 [I-D.chen-ospf-source-identifier-distribution], define extensions to 415 corresponding IGP protocols necessary for intra-AS scenario. 417 For inter-AS scenario, BGP extension is a naturally choice and can be 418 used to convey SI mapping information from one AS to other ASes. The 419 BGP extension draft is work in progress. For BGP based SI 420 distribution, it requires that SIs MUST not be sent out of a SIAD. 421 The similar sending and receiving restriction as defined in 422 Section 6.2.1 is also needed. 424 8. IANA Considerations 426 8.1. Source Label Indication 428 IANA is required to allocate a special purpose label (TBD1) for the 429 Source Label Indicator (SLI) from the "Multiprotocol Label Switching 430 Architecture (MPLS) Label Values" Registry. 432 8.2. LDP Source Label Capability TLV 434 IANA is requested to allocate a value of TBD2 from the IETF Consensus 435 range (0x0001-0x07FF) in the "TLV Type Name Space" registry as the 436 "Source Label Capability TLV". 438 8.3. BGP Source Label Capability Attribute 440 IANA is requested to allocate a Path Attribute Type Code TBD3 from 441 the "BGP Path Attributes" registry as the "BGP Source Label 442 Capability Attribute". 444 9. Security Considerations 446 This document introduces the SIAD that is the scope of a SL. The SLC 447 and SI MUST NOT be signaled and distributed outside one SIAD. BGP 448 based SLC and SI distribution is controlled by SL_SESSION 449 configuration. Improper configuration on both ends of an EBGP 450 connection could result in the SLC and SI being passed from one SIAD 451 to another. This would likely result in potential SI conflicts. 453 To prevent packets carrying SL/SLI from leaking from one SIAD to 454 another, the SIAD boundary nodes SHOULD deploy some policies (e.g., 455 ACL) to filter out the packets. Specifically, in the sending end, 456 the SIAD boundary node SHOULD filter out the packets that carry the 457 SLI and are sent to other SIADs; in the receiving end, the SIAD 458 boundary node SHOULD drop the packets that carry the SLI and are from 459 other SIADs. 461 10. Acknowledgements 463 The process of "Source Label Capability Signaling" is largely 464 referred to the process of "ELC signaling"[RFC6790]. 466 The authors would like to thank Carlos Pignataro, Loa Andersson , 467 Curtis Villamizar, Eric Osborne, Eric Rosen, Yimin Shen, Lizhong Jin, 468 Ross Callon and Yakov Rekhter for their review, suggestion and 469 comments to this document. 471 11. References 473 11.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 479 Label Switching Architecture", RFC 3031, January 2001. 481 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 482 BGP-4", RFC 3107, May 2001. 484 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 485 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 486 Tunnels", RFC 3209, December 2001. 488 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 489 Specification", RFC 5036, October 2007. 491 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 492 Ayyangarps, "Encoding of Attributes for MPLS LSP 493 Establishment Using Resource Reservation Protocol Traffic 494 Engineering (RSVP-TE)", RFC 5420, February 2009. 496 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 497 Measurement for MPLS Networks", RFC 6374, September 2011. 499 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 500 and Retiring Special-Purpose MPLS Labels", RFC 7274, June 501 2014. 503 11.2. Informative References 505 [I-D.chen-isis-source-identifier-distribution] 506 Chen, M. and G. Mirsky, "Extensions to ISIS for Source 507 Identifier Distribution", draft-chen-isis-source- 508 identifier-distribution-00 (work in progress), October 509 2014. 511 [I-D.chen-ospf-source-identifier-distribution] 512 Chen, M. and G. Mirsky, "Extensions to OSPF for Source 513 Identifier Distribution", draft-chen-ospf-source- 514 identifier-distribution-00 (work in progress), October 515 2014. 517 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 518 Defeating Denial of Service Attacks which employ IP Source 519 Address Spoofing", BCP 38, RFC 2827, May 2000. 521 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 522 Protocol 4 (BGP-4)", RFC 4271, January 2006. 524 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 525 Networks (VPNs)", RFC 4364, February 2006. 527 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 528 Zekauskas, "A One-way Active Measurement Protocol 529 (OWAMP)", RFC 4656, September 2006. 531 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 532 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 533 4761, January 2007. 535 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 536 System Confederations for BGP", RFC 5065, August 2007. 538 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 539 Label Assignment and Context-Specific Label Space", RFC 540 5331, August 2008. 542 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 543 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 544 RFC 5357, October 2008. 546 [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport 547 Profile Data Plane Architecture", RFC 5960, August 2010. 549 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 550 "Label Distribution Protocol Extensions for Point-to- 551 Multipoint and Multipoint-to-Multipoint Label Switched 552 Paths", RFC 6388, November 2011. 554 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 555 Connectivity Verification, Continuity Check, and Remote 556 Defect Indication for the MPLS Transport Profile", RFC 557 6428, November 2011. 559 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 560 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 561 RFC 6790, November 2012. 563 Authors' Addresses 565 Mach(Guoyi) Chen 566 Huawei 568 Email: mach.chen@huawei.com 570 Xiaohu Xu 571 Huawei 573 Email: xuxiaohu@huawei.com 574 Zhenbin Li 575 Huawei 577 Email: lizhenbin@huawei.com 579 Luyuan Fang 580 Microsoft 582 Email: lufang@microsoft.com 584 Greg Mirsky 585 Ericsson 587 Email: Gregory.mirsky@ericsson.com