Internet Engineering Task Force (IETF) Category: Standards Track. R. Asati Cisco January 2013

Similar documents
Internet Engineering Task Force (IETF) Cisco Systems, Inc. April 2015

Internet Engineering Task Force (IETF) Request for Comments: 7537 Updates: 4379, L. Andersson S. Aldrin Huawei Technologies May 2015

Internet Engineering Task Force (IETF) Request for Comments: July 2012

Internet Engineering Task Force (IETF) Request for Comments: 7189 Category: Standards Track March 2014 ISSN:

Internet Engineering Task Force (IETF) Request for Comments: Tata Communications F. Jounay Orange CH S. Delord January 2014

Internet Engineering Task Force (IETF) Category: Standards Track. S. Aldrin Google Inc. March 2018

Internet Engineering Task Force (IETF) Obsoletes: 4379, 6424, 6829, 7537

Internet Engineering Task Force (IETF) Category: Standards Track April 2013 ISSN: Formally Deprecating Some ICMPv4 Message Types

Internet Engineering Task Force

Internet Engineering Task Force (IETF) Huawei Technologies Co., Ltd.

Internet Engineering Task Force (IETF) Request for Comments: 7881 Category: Standards Track. Big Switch Networks July 2016

Internet Engineering Task Force

Expires: April 19, 2019 October 16, 2018

Internet Engineering Task Force (IETF) Request for Comments: 7140 Category: Standards Track

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track. Cisco B. Wen Comcast J. Rabadan Nokia June 2018

Internet Engineering Task Force (IETF) Updates: 5885 Category: Standards Track July 2016 ISSN:

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track May 2011 ISSN:

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track. Cisco May 2012

Internet Engineering Task Force

Internet Engineering Task Force (IETF) Request for Comments: 6440 Category: Standards Track. Huawei December 2011

Internet Engineering Task Force (IETF) Category: Standards Track

Expires: April 19, 2019 October 16, 2018

Internet Engineering Task Force (IETF) Request for Comments: November 2015

Internet Engineering Task Force (IETF)

Internet Engineering Task Force (IETF) Updates: 5451 March 2012 Category: Standards Track ISSN:

Internet Engineering Task Force (IETF) Updates: 5036, 6720 Category: Standards Track. Ionos Networks R. Papneja Huawei June 2015

Internet Engineering Task Force. Intended status: Standards Track. June 7, 2014

Internet Engineering Task Force (IETF) ISSN: A. Malis Huawei Technologies S. Aldrin Google November 2016

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track. January 2010

Internet Engineering Task Force (IETF) Category: Standards Track ISSN: E. Gray Ericsson September 2011

Internet Engineering Task Force (IETF) Deutsche Telekom January 2015

Internet Engineering Task Force (IETF) Request for Comments: AT&T N. Leymann Deutsche Telekom February 2012

Internet Engineering Task Force (IETF) Request for Comments: 6769 Category: Informational. A. Lo Arista L. Zhang UCLA X. Xu Huawei October 2012

Internet Engineering Task Force (IETF) Request for Comments: Alcatel-Lucent W. Luo January 2011

Internet Engineering Task Force (IETF) Category: Standards Track. Enterprise Architects February 2012

Internet Engineering Task Force (IETF) Request for Comments: 7213 Category: Standards Track. M. Bocci Alcatel-Lucent June 2014

Internet Engineering Task Force (IETF) Request for Comments: ISSN: April 2011

Internet Engineering Task Force. Updates: 4379,6790 (if approved) Intended status: Standards Track Expires: April 24, 2014 October 21, 2013

Internet Engineering Task Force (IETF) Request for Comments: Category: Experimental February 2014 ISSN:

Internet Engineering Task Force (IETF) June Network Time Protocol (NTP) Server Option for DHCPv6

Internet Engineering Task Force (IETF) Request for Comments: 6178

February Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

Internet Engineering Task Force (IETF) Request for Comments: 8237 Category: Standards Track ISSN: E. Bellagamba Ericsson October 2017

Internet Engineering Task Force (IETF) Category: Standards Track. S. Aldrin Google, Inc. L. Ginsberg Cisco Systems November 2018

Updates: 4448 (if approved) Intended status: Standards Track Expires: January 3, 2019 July 02, 2018

Internet Engineering Task Force (IETF) Category: Informational August 2012 ISSN:

Internet Engineering Task Force (IETF) Request for Comments: 6441 BCP: 171 November 2011 Category: Best Current Practice ISSN:

Internet Engineering Task Force (IETF) Request for Comments: 7125 Category: Informational. February 2014

Cisco Systems June 2009

Internet Engineering Task Force (IETF) M. Vigoureux, Ed. Alcatel-Lucent X. Dai, Ed. ZTE Corporation November 2011

Internet Engineering Task Force (IETF) Huawei Technologies Co., Ltd July Rebind Capability in DHCPv6 Reconfigure Messages

Internet Engineering Task Force (IETF) Request for Comments: 8184 Category: Informational

Internet Engineering Task Force (IETF) Request for Comments: ISSN: March 2018

Internet Engineering Task Force (IETF) Request for Comments: ISSN: October 2011

Internet Engineering Task Force (IETF) Request for Comments: ISSN: March 2018

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track ISSN: February 2012

Internet Engineering Task Force (IETF) Category: Standards Track ISSN: S. Previdi. Cisco Systems

Internet Engineering Task Force (IETF) Category: Informational. May IEEE Information Element for the IETF

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track ISSN: February 2016

Internet Engineering Task Force (IETF) Request for Comments: 7319 BCP: 191 July 2014 Category: Best Current Practice ISSN:

Internet Engineering Task Force (IETF) Request for Comments: 8186 Category: Standards Track. June 2017

Internet Engineering Task Force (IETF) Category: Informational. Consulintel March 2011

Internet Engineering Task Force (IETF) Request for Comments: ISSN: March 2016

Internet Engineering Task Force (IETF) Request for Comments: Category: Informational. R. White. D. McPherson Verisign, Inc.

Internet Engineering Task Force (IETF) Request for Comments: Juniper Networks, Inc. J. Tantsura Ericsson Q. Zhao Huawei Technology January 2016

Internet Engineering Task Force (IETF) Request for Comments: 7504 June 2015 Updates: 1846, 5321 Category: Standards Track ISSN:

Internet Engineering Task Force (IETF) Category: Standards Track. February 2012

Internet Engineering Task Force (IETF) Nokia P. Pillay-Esnault Huawei USA January 2019

Internet Engineering Task Force (IETF) Request for Comments: 5994 Category: Informational

Internet Engineering Task Force (IETF) Category: Standards Track ISSN: January 2011

Internet Engineering Task Force (IETF) Request for Comments: 7330 Category: Standards Track. Cisco Systems August 2014

Internet Engineering Task Force (IETF) Category: Standards Track. T. Morin France Telecom - Orange Y. Rekhter. Juniper Networks.

Internet Engineering Task Force (IETF) Request for Comments: 8142 Category: Standards Track April 2017 ISSN:

Internet Engineering Task Force. Intended status: Standards Track. February 23, 2015

Internet Engineering Task Force (IETF) Request for Comments: 8035 Updates: 5761 November 2016 Category: Standards Track ISSN:

Internet Engineering Task Force (IETF) Category: Standards Track. S. Krishnan Ericsson October 2015

Internet Engineering Task Force (IETF) Request for Comments: March 2012

Internet Engineering Task Force (IETF) Request for Comments: 6379 Obsoletes: 4869 Category: Informational October 2011 ISSN:

Internet Engineering Task Force (IETF) Request for Comments: 6425

Internet Engineering Task Force (IETF) Request for Comments: 6658 Category: Standards Track. A. Malis Verizon Communications July 2012

Internet Engineering Task Force (IETF) Request for Comments: 8372 ISSN: M. Chen Z. Li. Huawei. G. Mirsky ZTE Corp.

Request for Comments: 6592 Category: Informational 1 April 2012 ISSN:

Internet Engineering Task Force (IETF) Category: Standards Track. March 2017

Internet Engineering Task Force (IETF) Category: Standards Track ISSN: Huawei J. Tantsura Apstra, Inc. C. Filsfils. Cisco Systems, Inc.

Internet Engineering Task Force (IETF) Updates: 4326 June 2014 Category: Standards Track ISSN:

Internet Engineering Task Force (IETF) Request for Comments: 7725 Category: Standards Track February 2016 ISSN:

Internet Engineering Task Force (IETF) Request for Comments: 7078 Category: Standards Track. University of Southampton January 2014

Internet Engineering Task Force (IETF) Request for Comments: 6028 Category: Experimental ISSN: October 2010

Internet Engineering Task Force (IETF) ISSN: April 2014

Internet Engineering Task Force (IETF) Request for Comments: Alcatel-Lucent January 2016

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track ISSN: July 2014

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track. July 2014

Internet Engineering Task Force (IETF) Category: Standards Track. Cisco Systems, Inc. J. Scudder Juniper Networks September 2016

OSPF-TE Extensions for General Network Element Constraints

Internet Engineering Task Force (IETF) Request for Comments: 6923 Category: Standards Track

Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status.

Category: Standards Track Cisco Systems D. Tappan Consultant October 2009

Internet Engineering Task Force (IETF) Updates: 6811 September 2018 Category: Standards Track ISSN:

Internet Engineering Task Force (IETF) Category: Standards Track ISSN: July 2012

Internet Engineering Task Force (IETF) Request for Comments: 6034 Category: Standards Track October 2010 ISSN:

Transcription:

Internet Engineering Task Force (IETF) Request for Comments: 6829 Updates: 4379 Category: Standards Track ISSN: 2070-1721 M. Chen Huawei Technologies Co., Ltd P. Pan Infinera C. Pignataro R. Asati Cisco January 2013 Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 Abstract The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for 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 are set up and maintained using IPv6 LDP sessions. This document updates RFC 4379. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6829. Chen, et al. Standards Track [Page 1]

Copyright Notice Copyright (c) 2013 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......................... 2 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...................... 6 5. Operation........................... 6 6. IANA Considerations...................... 6 7. Security Considerations.................... 7 8. Acknowledgements....................... 7 9. References.......................... 7 9.1. Normative References................... 7 9.2. Informative References.................. 7 1. Introduction Multiprotocol 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 MPLS LSPs, including Pseudowires (PWs). However, the PW LSP Ping and traceroute elements are not specified for IPv6 address usage. Specifically, the PW Forwarding Equivalence Class (FEC) sub-tlvs for the Target FEC Stack in the LSP Ping and traceroute mechanism are defined only for IPv4 Provider Edge (PE) routers and are not applicable for the case where PEs use IPv6 addresses. Three PWrelated Target 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 Chen, et al. Standards Track [Page 2]

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 Address fields or calculating the length of the sub-tlvs (see Section 3.2 of [RFC4379]). When an IPv6 LDP session is used, these existing sub-tlvs cannot 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 LDP 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 to 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 to IPv6 usage when an IPv6 LDP session [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 in Sections 4 and 6. This is done to avoid any potential ambiguity and 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 Chen, et al. Standards Track [Page 3]

Additionally, when referring to the PE addresses, Sections 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 has a 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: 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. Chen, et al. Standards Track [Page 4]

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 has a 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: 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. Chen, et al. Standards Track [Page 5]

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 in Sections 2 and 3, the table would show the following: Sub-Type Length Value Field -------- ------ -----------... 9 10 "FEC 128" Pseudowire - IPv4 (Deprecated) 10 14 "FEC 128" Pseudowire - IPv4 11 16+ "FEC 129" Pseudowire - IPv4... 24 38 "FEC 128" Pseudowire - IPv6 25 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 IANA has made the following assignments in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. The following sub-tlv changes, which comprise three updates and two additions, are made for the TLV Type 1 "Target FEC Stack" in the "TLVs and sub-tlvs" sub-registry. The names of the Value fields of these three Sub-TLVs have been updated to include the "IPv4" qualifier (see Section 2), and the Reference has been updated to point 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 - IPv4 Chen, et al. Standards Track [Page 6]

Two new entries for the Sub-Type field of the Target FEC TLV (see Section 3) have been created: Type Sub-Type Value Field ---- -------- ----------- 1 24 "FEC 128" Pseudowire - IPv6 1 25 "FEC 129" Pseudowire - IPv6 7. Security Considerations This document does not introduce any new security 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] [RFC4379] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 9.2. Informative References [MPLS-LDP] Asati, R., Manral, V., Papneja, R., and C. Pignataro, "Updates to LDP for IPv6", Work in Progress, June 2012. Chen, et al. Standards Track [Page 7]

Authors Addresses Mach(Guoyi) Chen Huawei Technologies Co., Ltd No. 3 Xinxi Road, Shang-di, Hai-dian District Beijing 100085 China EMail: mach@huawei.com Ping Pan Infinera US EMail: ppan@infinera.com Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US EMail: cpignata@cisco.com Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 US EMail: rajiva@cisco.com Chen, et al. Standards Track [Page 8]