--- 1/draft-george-mpls-ipv6-only-gap-04.txt 2014-03-24 10:14:35.103673657 -0700 +++ 2/draft-george-mpls-ipv6-only-gap-05.txt 2014-03-24 10:14:35.151674823 -0700 @@ -1,19 +1,19 @@ Internet Engineering Task Force W. George, Ed. Internet-Draft Time Warner Cable Intended status: Informational C. Pignataro, Ed. -Expires: August 14, 2014 Cisco Systems - February 10, 2014 +Expires: September 25, 2014 Cisco + March 24, 2014 Gap Analysis for Operating IPv6-only MPLS Networks - draft-george-mpls-ipv6-only-gap-04 + draft-george-mpls-ipv6-only-gap-05 Abstract This document reviews the MPLS protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS- related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 14, 2014. + This Internet-Draft will expire on September 25, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -48,21 +48,21 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 4 3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 5 3.2.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Multipoint LDP . . . . . . . . . . . . . . . . . . . 5 3.2.3. RSVP- TE . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3.2. RSVP-TE-P2MP . . . . . . . . . . . . . . . . . . 7 3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 7 3.2.4. Controller, PCE . . . . . . . . . . . . . . . . . . . 7 3.2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.6. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 8 @@ -73,30 +73,29 @@ 3.3.2.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 10 3.3.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 10 3.3.2.3. BGP Encapsulation SAFI . . . . . . . . . . . . . 10 3.3.2.4. NG-MVPN . . . . . . . . . . . . . . . . . . . . . 10 3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 12 3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 13 3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 14 - 3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 14 + 3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 15 3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 9. Informative References . . . . . . . . . . . . . . . . . . . 19 - Appendix A. Assignments . . . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. Informative References . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction IPv6 is an integral part of modern network deployments. At the time when this document was written, the majority of these IPv6 deployments were using dual-stack implementations, where IPv4 and IPv6 are supported equally on many or all of the network nodes, and single-stack primarily referred to IPv4-only devices. Dual-stack deployments provide a useful margin for protocols and features that are not currently capable of operating solely over IPv6, because they @@ -114,90 +113,88 @@ complete function, this document reviews the Multi-Protocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. 2. Use Case - From a purely theoretical perspective, ensuring that MPLS is fully IP - version-agnostic is the right thing to do. However, it is sometimes - helpful to understand the underlying drivers that make this work - necessary to undertake, especially at a time when IPv6-only - networking is still fairly uncommon. This section will discuss some - drivers. It is not intended to be a comprehensive discussion of all - potential use cases, but rather a discussion of at least one use case - to demonstrate that this document is not discussing a purely - theoretical problem. + This section discusses some drivers for ensuring that MPLS completely + supports IPv6-only operation. It is not intended to be a + comprehensive discussion of all potential use cases, but rather a + discussion of at least one use case to provide context and + justification to undertake such a gap analysis. IP convergence is continuing to drive new classes of devices to begin communicating via IP. Examples of such devices could include set top boxes for IP Video distribution, cell tower electronics (macro or micro cells), infrastructure Wi-Fi Access Points, and devices for machine to machine (M2M) or Internet of Things applications. In some cases, these classes of devices represent a very large deployment base, on the order of thousands or even millions of devices network- wide. The scale of these networks, coupled with the increasingly overlapping use of RFC 1918 [RFC1918] address space within the average network, and the lack of globally-routable IPv4 space available for long-term growth begins to drive the need for many of the endpoints in this network to be managed solely via IPv6. Even if these devices are carrying some IPv4 user data, it is often encapsulated in another protocol such that the communication between the endpoint and its upstream devices can be IPv6-only without - impacting support for IPv4 on user data. Depending on the MPLS - features required, it is plausible to assume that the (existing) MPLS - network may need to be extended to these devices. + impacting support for IPv4 on user data. As the number of devices to + manage increases, the operator is compelled to move to IPv6. + Depending on the MPLS features required, it is plausible to assume + that the (existing) MPLS network will need to be extended to these + IPv6-only devices. Additionally, as the impact of IPv4 exhaustion becomes more acute, more and more aggressive IPv4 address reclamation measures will be - justified. Measures that were previously seen as too complex or as - netting too few addresses for the work required may become more - realistic as the cost for obtaining new IPv4 addresses increases. - More and more networks are likely to adopt the general stance that - IPv4 addresses need to be preserved for revenue-generating customers - so that legacy support for IPv4 can be maintained as long as - possible. As a result, it may be appropriate for some or all of the - network infrastructure, including MPLS LSRs and LERs, to have its - IPv4 addresses reclaimed and transition toward IPv6-only operation. + justified. Many networks are likely to focus on preserving their + remaining IPv4 addresses for revenue-generating customers so that + legacy support for IPv4 can be maintained as long as possible. As a + result, it may be appropriate for some or all of the network + infrastructure, including MPLS LSRs and LERs, to have its IPv4 + addresses reclaimed and transition toward IPv6-only operation. 3. Gap Analysis This gap analysis aims to answer the question, "what breaks when one attempts to use MPLS features on a network of IPv6-only devices?" The baseline assumption for this analysis is that some endpoints as well as Label Switch Routers (PE and P routers) only have IPv6 transport available, and need to support the full suite of MPLS features defined as of the time of this document's writing at parity with the support on an IPv4 network. This is necessary whether they are enabled via Label Distribution Protocol (LDP) RFC 5036 [RFC5036], Resource Reservation Protocol Extensions for MPLS Traffic Engineering - (RSVP-TE) RFC 5420 [RFC5420], or Border Gateway Protocol (BGP) RFC + (RSVP-TE) RFC 3209 [RFC3209], or Border Gateway Protocol (BGP) RFC 3107 [RFC3107], and whether they are encapsulated in MPLS RFC 3032 [RFC3032], IP RFC 4023 [RFC4023], Generic Routing Encapsulation (GRE) RFC 4023 [RFC4023], or Layer 2 Tunneling Protocol Version 3 (L2TPv3) RFC 4817 [RFC4817]. It is important when evaluating these gaps to distinguish between user data and control plane data, because while this document is focused on IPv6-only operation, it is quite likely that some amount of the user payload data being carried in the IPv6-only MPLS network will still be IPv4. 3.1. MPLS Data Plane MPLS labeled packets can be transmitted over a variety of data links RFC 3032 [RFC3032], and MPLS labeled packets can also be encapsulated over IP. The encapsulations of MPLS in IP and GRE as well as MPLS over L2TPv3 support IPv6. See Section 3 of RFC 4023 [RFC4023] and Section 2 of RFC 4817 [RFC4817] respectively. + In the case where an IPv4 prefix is resolved over an IPv6 LSP, an + IPv6 Explicit Null label cannot immediately preceed an IPv4 packet. + Gap: None. 3.2. MPLS Control Plane 3.2.1. LDP Label Distribution Protocol (LDP) RFC 5036 [RFC5036] defines a set of procedures for distribution of labels between label switch routers that can use the labels for forwarding traffic. While LDP was designed to use an IPv4 or dual-stack IP network, it has a number of @@ -226,22 +223,23 @@ 2. Multipoint (MP) FEC Root address: mLDP defines its own MP FECs and rules, different from LDP, to map MP LSPs. mLDP MP FEC contains a Root Address field which is an IP address in IP networks. The current specification allows specifying Root address according to AFI and hence covers both IPv4 or IPv6 root addresses, requiring no extension to support IPv6-only MP LSPs. The root address is used by each LSR participating in an MP LSP setup such that root address reachability is resolved by doing a table lookup against root address to find corresponding upstream - neighbor(s). This will pose a problem when an MP LSP traverses - islands of IPv4 and IPv4 clouds on the way to the root node. + neighbor(s). This will pose a problem if an MP LSP traverses + IPv4-only and IPv6-only nodes in a dual-stack network on the way + to the root node. For example, consider following setup, where R1/R6 are IPv4-only, R3/ R4 are IPv6-only, and R2/R5 are dual-stack LSRs: ( IPv4-only ) ( IPv6-only ) ( IPv4-only ) R1 -- R2 -- R3 -- R4 -- R5 -- R6 Leaf Root Assume R1 to be a leaf node for an P2MP LSP rooted at R6 (root node). R1 uses R6's IPv4 address as the Root address in MP FEC. As the MP @@ -340,21 +338,27 @@ Gap: None. 3.2.6. GMPLS RFC4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with capability for both IPv4 and IPv6. RFC4990 [RFC4990] clarifies the use of IPv6 addresses in GMPLS networks including handling in the MIB modules. - Gap: None. + Section 5.3, second paragraph of RFC6370 [RFC6370] describes the + mapping from an MPLS-TP LSP_ID to RSVP-TE with an assumption that + Node_IDs are derived from valid IPv4 addresses. This assumption + fails in an IPv6-only network, given that there wouldn't be any IPv4 + addresses. + + Gap: Minor; Section 5.3. of RFC6370 needs to be updated. 3.3. MPLS Applications 3.3.1. L2VPN L2VPN RFC 4664 [RFC4664] specifies two fundamentally different kinds of Layer 2 VPN services that a service provider could offer to a customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify the LDP protocol changes to instantiate VPWS and VPLS services @@ -373,20 +377,23 @@ can run directly over IPv6 core infrastructure, as well as IPv6 edge devices. RFC 6074 [RFC6074] is the only RFC that appears to have a gap for IPv6-only operation. In its discovery procedures (section 3.2.2 and section 6), it suggests encoding PE IP address in the VSI- ID, which is encoded in NLRI, and should not exceed 12 bytes (to differentiate its AFI/SAFI encoding from RFC4761). This means that PE IP address can NOT be an IPv6 address. Also, in its signaling procedures (section 3.2.3), it suggests encoding PE_addr in SAII and TAII, which are limited to 32-bit (AII Type=1) at the moment. + RFC 6073 [RFC6073] defines the new LDP PW Switching Point PE TLV, + which supports IPv4 and IPv6. + Gap: Minor. RFC6074 needs to be updated. 3.3.1.1. EVPN EVPN [I-D.ietf-l2vpn-evpn] is still a work in progress. As such, it is out of scope for this gap analysis. Instead, the authors of that draft need to ensure that it supports IPv6-only operation, or if it cannot, identify dependencies on underlying gaps in MPLS protocol(s) that must be resolved before it can support IPv6-only operation. @@ -395,25 +402,26 @@ RFC 4364 [RFC4364] defines a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. The following use cases arise in the context of this gap analysis: 1. Connecting IPv6 islands over IPv6-only MPLS network 2. Connecting IPv4 islands over IPv6-only MPLS network Both use cases require mapping an IP packet to an IPv6-signaled LSP. - RFC4364 defines as VPN-IPv4 address type, but not a VPN-IPv6 address - type. RFC 4659 [RFC4659] corrects this oversight. Also, Section 5 + RFC4364 defines a VPN-IPv4 address family, but not a VPN-IPv6 address + family. RFC 4659 [RFC4659] corrects this oversight. Also, Section 5 of RFC 4364 [RFC4364] assumes that the BGP next-hop contains exactly 32 bits. This text should be generalized to include 128 bit next- - hops as well. + hops as well. Section 3.2.1.1 of RFC 4659 [RFC4659] does actually + specifies a 128-bit BGP next-hop. The authors do not believe that there are any additional issues encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as transport on an IPv6-only network. Gap: Major. RFC4364 must be updated, and RFC4659 may need to be updated to explicitly cover use case #2. (Discussed in further detail below) 3.3.2.1. 6PE/4PE @@ -421,44 +429,44 @@ RFC 4798 [RFC4798] defines 6PE, which defines how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. However, use case 2 is doing the opposite, and thus could also be referred to as 4PE. The method to support this use case is not defined explicitly. To support it, IPv4 edge devices need to be able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, the core switches may not understand IPv4 at all, but in some cases they may need to be able to exchange Labeled IPv4 routes from one AS to a neighboring AS. - Gap: Major. RFC4659 needs to be updated to explicitly cover use case - #2. + Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is + currently not specified in an RFC. 3.3.2.2. 6VPE/4VPE RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. It allows the core network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1 above. RFC4364 should work as defined for use case 2 above, which could also be referred to as 4VPE, but the RFC does not explicitly discuss this use. Gap: Minor. RFC4659 may need to be updated to explicitly cover use case #2 3.3.2.3. BGP Encapsulation SAFI RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP - Tunnel Encapsulation Attribute, which can be used to signal - tunnelling over an single-Address Family IP core. This mechanism - supports transport of MPLS (and other protocols) over Tunnels in an - IP core (including an IPv6-only core). In this context, load- - balancing can be provided as specified in RFC 5640 [RFC5640]. + Tunnel Encapsulation Attribute, which can be used to signal tunneling + over a single-Address Family IP core. This mechanism supports + transport of MPLS (and other protocols) over Tunnels in an IP core + (including an IPv6-only core). In this context, load-balancing can + be provided as specified in RFC 5640 [RFC5640]. Gap: None. 3.3.2.4. NG-MVPN RFC 6513 [RFC6513] defines the procedure to provide multicast service over MPLS VPN backbone for the customers. The procedure involves the below set of protocols: 3.3.2.4.1. PE-CE Multicast Routing Protocol @@ -637,20 +645,23 @@ Gap: None. 3.4.4. Pseudowire OAM The OAM specifications for MPLS Pseudowires define usage for both IPv4 and IPv6. Specifically, VCCV RFC 5085 [RFC5085] can carry IPv4 or IPv6 OAM packets (see Section 5.1.1 and 5.2.1 of RFC 5085), and VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation (see Section 3.2 of RFC 5885). + Additionally, for LSP Ping for Pseudowires, the Pseudowire FECs are + specified for IPv6 in RFC 6829 [RFC6829]. + Gap: None. 3.4.5. MPLS-TP OAM As with MPLS-TP, MPLS-TP OAM RFC 6371 [RFC6371] is not dependent on IP or existing MPLS OAM functions, and should not be affected by operation on an IPv6-only network. Therefore, this is out of scope for this document. Gap: None. @@ -687,20 +698,23 @@ +---------+--------------------------+------------------------------+ | Item | Gap | Addressed in | +---------+--------------------------+------------------------------+ | LDP | LSP mapping, LDP | LDP-IPv6 | | S.3.2.1 | identifiers, LDP | [I-D.ietf-mpls-ldp-ipv6] | | | discovery, LDP session | | | | establishment, next hop | | | | address and LDP TTL | | | | security | | +---------+--------------------------+------------------------------+ + | GMPLS | RFC6370 [RFC6370] Node | TBD | + | S.3.2.6 | ID derivation | | + +---------+--------------------------+------------------------------+ | L2VPN | RFC 6074 [RFC6074] | TBD | | S.3.3.1 | discovery, signaling | | +---------+--------------------------+------------------------------+ | L3VPN | RFC 4364 [RFC4364] BGP | TBD | | S.3.3.2 | next-hop, define method | | | | for 4PE/4VPE | | +---------+--------------------------+------------------------------+ | OAM | RFC 4379 [RFC4379] no | TBD | | S.3.4 | IPv6 multipath support, | | | | possible dropped | | @@ -708,106 +722,80 @@ | | mismatch | | +---------+--------------------------+------------------------------+ | MIBs | RFC 3811 [RFC3811] no | 3811bis | | S.3.5 | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] | +---------+--------------------------+------------------------------+ Table 1: IPv6-only MPLS Gaps 5. Acknowledgements - The authors wish to thank Andrew Yourtchenko and Loa Andersson for a - detailed review, as well as Brian Haberman, Joel Jaeggli, and Adrian + The authors wish to thank Andrew Yourtchenko, Loa Andersson, David + Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka for their + detailed reviews, as well as Brian Haberman, Joel Jaeggli, and Adrian Farrell for their comments. 6. Contributing Authors The following people have contributed text to this draft: Rajiv Asati - Cisco Systems - 7025 Kit Creek Road - Research Triangle Park, NC 27709 US Email: rajiva@cisco.com Kamran Raza - Cisco Systems - 2000 Innovation Drive - Ottawa, ON K2K-3E8 - CA Email: skraza@cisco.com Ronald Bonica - Juniper Networks - 2251 Corporate Park Drive - Herndon, VA 20171 - US Email: rbonica@juniper.net Rajiv Papneja - Huawei Technologies - 2330 Central Expressway - Santa Clara, CA 95050 - US Email: rajiv.papneja@huawei.com - Dhruv Dhody + Dhruv Dhody Huawei Technologies - Leela Palace - Bangalore, Karnataka 560008 - IN Email: dhruv.ietf@gmail.com Vishwas Manral - Hewlett-Packard, Inc. - 19111 Pruneridge Ave. - Cupertino, CA 95014 - US - Email: vishwas.manral@hp.com Nagendra Kumar - Cisco Systems, Inc. - 7200 Kit Creek Road - Research Triangle Park, NC 27709 - US Email: naikumar@cisco.com 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations @@ -811,23 +799,23 @@ 8. Security Considerations Changing the address family used for MPLS network operation does not fundamentally alter the security considerations currently extant in any of the specifics of the protocol or its features. 9. Informative References [I-D.ietf-l2vpn-evpn] - Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F., - Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", - draft-ietf-l2vpn-evpn-04 (work in progress), July 2013. + Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. + Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- + evpn-06 (work in progress), March 2014. [I-D.ietf-l3vpn-mvpn-mldp-nlri] Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf- l3vpn-mvpn-mldp-nlri-04 (work in progress), December 2013. [I-D.ietf-l3vpn-mvpn-pe-ce] Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE- CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-00 (work in progress), October 2013. @@ -987,25 +975,20 @@ [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008. - [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. - Ayyangarps, "Encoding of Attributes for MPLS LSP - Establishment Using Resource Reservation Protocol Traffic - Engineering (RSVP-TE)", RFC 5420, February 2009. - [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009. [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation @@ -1037,28 +1020,34 @@ [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010. + [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. + Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. + [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, February 2011. + [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport + Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. + [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011. [RFC6445] Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol @@ -1087,46 +1076,29 @@ [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, August 2012. [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013. -Appendix A. Assignments - - *RFC EDITOR PLEASE REMOVE BEFORE PUBLISHING* - - This will track which author volunteered for which section(s): - - OAM - Ron Bonica, Carlos Pignataro - - LDP/mLDP (multicast) - Kamran Raza - - L2VPN - Rajiv Asati, Vishwas Manral, Rajiv Papneja - - L3VPN - Rajiv Asati, Vishwas Manral, Rajiv Papneja - - PCE - Dhruv Dhody, Rajiv Papneja - - Editors- Wes George(primary), Vishwas Manral, Rajiv Asati - Authors' Addresses Wesley George (editor) Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20111 US Phone: +1-703-561-2540 Email: wesley.george@twcable.com Carlos Pignataro (editor) - Cisco Systems + Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US + Phone: +1-919-392-7428 Email: cpignata@cisco.com