Network Working GroupInternet Engineering Task Force (IETF) M. ChenInternet-DraftRequest for Comments: 6829 Huawei Technologies Co., Ltd Updates: 4379(if approved)P. PanIntended status:Category: Standards Track InfineraExpires: May 30, 2013ISSN: 2070-1721 C. Pignataro R. Asati CiscoNovember 26, 2012January 2013 Label Switched Path (LSP) Ping for PseudowireFECsForwarding Equivalence Classes (FECs) Advertised over IPv6draft-ietf-mpls-ipv6-pw-lsp-ping-04AbstractMulti-ProtocolThe Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLSLSPsLSPs, including LSPs used for each direction of an MPLS Pseudowire (PW).TheHowever, the LSP Ping and traceroute elements used forPWs, however,PWs are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that aresetupset up and maintained using IPv6 LDPsessions, andsessions. This document updates RFC 4379.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 May 30, 2013.http://www.rfc-editor.org/info/rfc6829. Copyright Notice Copyright (c)20122013 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 carefully, as they describe your rights and restrictions with respect 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. Pseudowire IPv4 Target FEC Stack Sub-TLVs . . . . . . . . . . . 3 3. Pseudowire IPv6 Target FEC Stack Sub-TLVs . . . . . . . . . . . 4 3.1. FEC 128 Pseudowire . . . . . . . . . . . . . . . . . . . . 4 3.2. FEC 129 Pseudowire . . . . . . . . . . . . . . . . . . . . 5 4. Summary of Changes . . . . . . . . . . . . . . . . . . . . . .67 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81. IntroductionMulti-ProtocolMultiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute are defined in [RFC4379]. These mechanisms can be used to detect data plane failures in all MPLSLabel Switched Paths (LSPs)LSPs, including Pseudowires (PWs).TheHowever, the PW LSP Ping and tracerouteelements, however,elements are not specified for IPv6 address usage. Specifically, the PWFECForwarding Equivalence Class (FEC) sub-TLVs for the Target FEC Stack in the LSP Ping and traceroute mechanism are defined only for IPv4 Provider Edge(PEs) routers,(PE) routers and are not applicable for the case where PEs use IPv6 addresses. ThreePWPW- related TargetForwarding Equivalence Class (FEC)FEC sub-TLVs are currently defined (FEC 128 Pseudowire-Deprecated, FEC 128 Pseudowire-Current, and FEC 129 Pseudowire, see Sections 3.2.8 through 3.2.10 of [RFC4379]). These sub-TLVs contain the source and destination addresses of the LDP session, and currently only an IPv4 LDP session is covered. Despite the fact that the PE IP address family is not explicit in the sub-TLV definition, this can be inferred indirectly by examining the lengths of the Sender's/Remote PE Addressfields,fields or calculating theLengthlength of the sub-TLVs (see Section 3.2 of [RFC4379]). When an IPv6 LDP session is used,thereforethese existing sub-TLVscan notcannot be used since the addresses will not fit. Additionally, all other sub-TLVs are defined in pairs, one for IPv4 and another for IPv6, but not the PW sub-TLVs. This document updates [RFC4379] to explicitly constrain the existing PW FEC sub-TLVs for IPv4 LDPsessions,sessions and extends the PW LSP Ping to IPv6 LDP sessions (i.e., when IPv6 LDP sessions are used to signal the PW, the Sender's and Receiver's IP addresses are IPv6 addresses). This is done by renaming the existing PW sub-TLVs tosay "IPv4",indicate "IPv4" and also by defining two new Target FEC sub-TLVs (FEC 128 Pseudowire IPv6 sub-TLV and FEC 129 Pseudowire IPv6 sub-TLV) to extend the application of PW LSP Ping and traceroute totheIPv6 usage when an IPv6 LDP session[I-D.ietf-mpls-ldp-ipv6][MPLS-LDP] is used to signal the Pseudowire. Note that FEC 128 Pseudowire (Deprecated) is not defined for IPv6 in this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Pseudowire IPv4 Target FEC Stack Sub-TLVs This document updates Section 3.2 and Sections 3.2.8 through 3.2.10 of [RFC4379] as follows and as indicated inSectionSections 4 andSection6. This is done to avoid any potential ambiguity andconfusion,confusion and to clarify that these TLVs carry only IPv4 addresses. Note that the changes are limited to the names of fields; there are no semantic changes. Sections 3.2.8 through 3.2.10 of [RFC4379] list the PW sub-TLVs and state: "FEC 128" Pseudowire (Deprecated) "FEC 128" Pseudowire "FEC 129" Pseudowire These names and titles are now changed to: "FEC 128" Pseudowire - IPv4 (Deprecated) "FEC 128" Pseudowire - IPv4 "FEC 129" Pseudowire - IPv4 Additionally, when referring to the PE addresses,these three sectionsSections 3.2.8 through 3.2.10 of [RFC4379] state: Sender's PE Address Remote PE Address These are now updated to say: Sender's PE IPv4 Address Remote PE IPv4 Address 3. Pseudowire IPv6 Target FEC Stack Sub-TLVs 3.1. FEC 128 Pseudowire The FEC 128 Pseudowire IPv6 sub-TLV hasthe consistenta structure consistent with the FEC 128 Pseudowire sub-TLV as described in Section 3.2.9 of [RFC4379]. The encoding of the FEC 128 Pseudowire IPv6 sub-TLV is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC 128 PW IPv6 Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sender's PE IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Remote PE IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: FEC 128 Pseudowire - IPv6 FEC 128 PW IPv6 Type:TBD1.24. 2 octets. Length: Defines the length in octets of the value field of the sub- TLV and its value is 38. 2 octets. Sender's PE IPv6 Address: The source IP address of the target IPv6 LDP session. 16 octets. Remote PE IPv6 Address: The destination IP address of the target IPv6 LDP session. 16 octets. PW ID: Same as FEC 128 Pseudowire IPv4 [RFC4379]. PW Type: Same as FEC 128 Pseudowire IPv4 [RFC4379]. 3.2. FEC 129 Pseudowire The FEC 129 Pseudowire IPv6 sub-TLV hasthe consistenta structure consistent with the FEC 129 Pseudowire sub-TLV as described in Section 3.2.10 of [RFC4379]. The encoding of FEC 129 Pseudowire IPv6 is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC 129 PW IPv6 Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sender's PE IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Remote PE IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | AGI Type | AGI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | SAII Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (continued) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | TAII Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (continued) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII (cont.) | 0-3 octets of zero padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: FEC 129 Pseudowire - IPv6 FEC 129 PW IPv6 Type:TBD2.25. 2 octets. Length: Defines the length in octets of the value field of the sub- TLV. 2 octets The length of this TLV is 40 + AGI (Attachment Group Identifier) length + SAII (Source Attachment Individual Identifier) length + TAII (Target Attachment Individual Identifier) length. Padding is used to make the total length a multiple of 4; the length of the padding is not included in the Length field. Sender's PE IPv6 Address: The source IP address of the target IPv6 LDP session. 16 octets. Remote PE IPv6 Address: The destination IP address of the target IPv6 LDP session. 16 octets. The other fields are the same as FEC 129 Pseudowire IPv4 [RFC4379]. 4. Summary of Changes Section 3.2 of [RFC4379] tabulates all the sub-TLVs for the Target FEC Stack. Per the change described inSectionSections 2 andSection3, the table would show the following: Sub-Type Length Value Field -------- ------ ----------- ... 9 10 "FEC 128" Pseudowire - IPv4(deprecated)(Deprecated) 10 14 "FEC 128" Pseudowire - IPv4 11 16+ "FEC 129" Pseudowire - IPv4 ...TBD124 38 "FEC 128" Pseudowire - IPv6TBD225 40+ "FEC 129" Pseudowire - IPv6 5. Operation This document does not define any new procedures. The process described in [RFC4379] MUST be used. 6. IANA Considerations IANAis requested to performhas made the following assignments in the"Multi- Protocol"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"registry, "TLVs and sub-TLVs" sub-registry. [RFC Editor: To be REMOVED prior to publication. This registration should take place at <http://www.iana.org/assignments/ mpls-lsp-ping-parameters/ mpls-lsp-ping-parameters.xml#mpls-lsp-ping-parameters-7>]registry. The followingSub-TLVsub-TLV changes, which comprise three updates and two additions, are made for the TLV Type 1 "Target FEC Stack" in theaforementioned"TLVs and sub-TLVs" sub-registry.Update theThe names of the Value fields of these threeSub-TLVs, addingSub-TLVs have been updated to include the "IPv4" qualifier (see Section 2), andupdatethe Reference has been updated toalsopoint to this document: Type Sub-Type Value Field ---- -------- ----------- 1 9 "FEC 128" Pseudowire - IPv4 (Deprecated) 1 10 "FEC 128" Pseudowire - IPv4 1 11 "FEC 129" Pseudowire - IPv4Create twoTwo new entries for the Sub-Type field of the Target FEC TLV (see Section3):3) have been created: Type Sub-Type Value Field ---- -------- ----------- 1TBD124 "FEC 128" Pseudowire - IPv6 1TBD225 "FEC 129" Pseudowire - IPv6 7. Security Considerations Thisdraftdocument does not introduce any new securityissues,issues; the security mechanisms defined in [RFC4379] apply here. 8. Acknowledgements The authors gratefully acknowledge the review and comments of Vanson Lim, Tom Petch, Spike Curtis, Loa Andersson, and Kireeti Kompella. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 9.2. Informative References[I-D.ietf-mpls-ldp-ipv6][MPLS-LDP] Asati, R., Manral, V., Papneja, R., and C. Pignataro, "Updates to LDP for IPv6",draft-ietf-mpls-ldp-ipv6-07 (workWork inprogress),Progress, June 2012. Authors' Addresses Mach(Guoyi) Chen Huawei Technologies Co., Ltd No. 3 Xinxi Road, Shang-di, Hai-dian District Beijing 100085 ChinaEmail:EMail: mach@huawei.com Ping Pan Infinera USEmail:EMail: ppan@infinera.com Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USEmail:EMail: cpignata@cisco.com Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USEmail:EMail: rajiva@cisco.com