--- 1/draft-ietf-mpls-lsp-ping-reply-mode-simple-01.txt 2015-04-16 00:43:58.202890837 -0700 +++ 2/draft-ietf-mpls-lsp-ping-reply-mode-simple-02.txt 2015-04-16 00:43:58.690902663 -0700 @@ -1,33 +1,34 @@ Internet Engineering Task Force N. Akiya -Internet-Draft G. Swallow -Updates: 4379,7110 (if approved) C. Pignataro -Intended status: Standards Track Cisco Systems -Expires: July 9, 2015 L. Andersson +Internet-Draft Big Switch Networks +Updates: 7110 (if approved) G. Swallow +Intended status: Standards Track C. Pignataro +Expires: October 15, 2015 Cisco Systems + L. Andersson M. Chen Huawei - January 5, 2015 + April 13, 2015 Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification - draft-ietf-mpls-lsp-ping-reply-mode-simple-01 + draft-ietf-mpls-lsp-ping-reply-mode-simple-02 Abstract The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the "Reply via Specified Path (5)" Reply Mode value to easily indicate the reverse LSP. This document also adds an optional TLV which can carry ordered list of Reply Mode values. - This document updates RFC4379 and RFC7110. + This document updates RFC7110. 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 of This Memo This Internet-Draft is submitted in full conformance with the @@ -36,63 +37,65 @@ 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 July 9, 2015. + This Internet-Draft will expire on October 15, 2015. Copyright Notice Copyright (c) 2015 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 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Reply via Specified Path Update . . . . . . . . . . . . . 5 3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 6 4. Relations to Other LSP Ping/Trace Features . . . . . . . . . 7 4.1. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Example 1: Reply Mode Order TLV Usage with Reply Path - TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7 + TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. Example 2: Reply Mode Order TLV Usage with Reply Path TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.2. Proxy LSP Ping . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. Proxy LSP Ping . . . . . . . . . . . . . . . . . . . . . 9 + 4.2.1. Proxy LSR Sending an MPLS Echo Request . . . . . . . 9 + 4.2.2. Proxy LSR Sending an MPLS Proxy Ping Reply . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 6.1. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 9 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 9 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 - 9.2. Informative References . . . . . . . . . . . . . . . . . 10 - Appendix A. Reply Mode Order TLV Beneficial Scenarios . . . . . 10 - A.1. Incorrect Forwarding Scenario . . . . . . . . . . . . . . 10 - A.2. Non-Co-Routed Bidirectional LSP Scenario . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 10 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 10 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 9.2. Informative References . . . . . . . . . . . . . . . . . 11 + Appendix A. Reply Mode Order TLV Beneficial Scenarios . . . . . 11 + A.1. Incorrect Forwarding Scenario . . . . . . . . . . . . . . 11 + A.2. Non-Co-Routed Bidirectional LSP Scenario . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The MPLS LSP Ping, described in [RFC4379], allows an initiator LSR to encode instructions (Reply Mode) on how a responder LSR should send the response back to the initiator LSR. [RFC7110] also allows the initiator LSR to encode a TLV (Reply Path TLV) which can instruct the responder LSR to use specific LSP to send the response back to the initiator LSR. Both approaches are powerful as they provide the ability for the initiator LSR to control the return path. @@ -114,20 +117,24 @@ o In Section 2, further description of the problems; o In Section 3, a solution to minimize false failures while accommodating operator preferences; o In Section 4, relationships to other LSP Ping/Traceroute features; o In Appendix A, examples of scenarios where the mechanism described in this document provides benefits. + This documents updates [RFC7110] by allowing the usage of the Reply + Mode value 5 (Reply via Specified Path) without including the Reply + Path TLV. + 2. Problem Statements It is becoming increasingly difficult for implementations to automatically supply a workable return path encoding for all MPLS LSP Ping and Traceroute operations across all LSP types. There are several factors which are contributing to this complication. o Some LSPs have a control-channel, and some do not. Some LSPs have a reverse LSP, and some do not. Some LSPs have IP reachability in the reverse direction, and some do not. @@ -239,78 +246,93 @@ 0:0:0:0:0:FFFF:7F00/104 for IPv6. 3.2. Reply Mode Order TLV This document also introduces a new optional TLV to describe list of Reply Mode values. The new TLV will contain one or more Reply Mode value(s) in preferred order. The first Reply Mode value is the most preferred and the last Reply Mode value is the least preferred. Following rules apply when using Reply Mode Order TLV. - 1. Reply Mode Order TLV MAY be included in MPLS echo request. + 1. The Reply Mode Order TLV MAY be included in MPLS echo request. - 2. Reply Mode Order TLV MUST NOT be included in MPLS echo reply. + 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. - 3. Reply Mode field of MPLS echo request MUST be set to a valid - value when supplying Reply Mode Order TLV in transmitting MPLS - echo request. The initiator LSR SHOULD set Reply Mode field of - MPLS echo request to a value that corresponds to a return path - which most likely to be available, in case the responder LSR does - not understand the Reply Mode Order TLV. + 3. The Reply Mode field of an MPLS echo request MUST be set to a + valid value even when supplying the Reply Mode Order TLV. The + initiator LSR SHOULD set the Reply Mode field of MPLS echo + request to a value that corresponds to a return path which most + likely to be available, in case the responder LSR does not + understand the Reply Mode Order TLV. - 4. If a responder LSR understands the Reply Mode Order TLV and the - TLV is valid, then the responder LSR MUST consider Reply Mode + 4. If a responder LSR understands the Reply Mode Order TLV but the + TLV is not valid (due to conditions described in the items 6, 8 + and 9 immediately below), then the responder LSR MUST only use + the value described in the Reply Mode field of received MPLS echo + request. + + 5. If a responder LSR understands the Reply Mode Order TLV and the + TLV is valid, then the responder LSR MUST consider the Reply Mode values described in the TLV and MUST NOT use the value described + in the Reply Mode field of received MPLS echo request. In other + words, a valid Reply Mode Order TLV overrides the value specified in the Reply Mode field of received MPLS echo request. - 5. If a responder LSR understands the Reply Mode Order TLV but the - TLV is not valid (due to conditions listed below), then the - responder LSR MUST only use the value described in the Reply Mode - field of received MPLS echo request. - 6. Reply Mode Order TLV MUST contain at least one Reply Mode value, and SHOULD contain at least two Reply Mode values. - 7. A Reply Mode value MUST NOT be repeated (i.e. MUST NOT appear + 7. A Reply Mode value, except for Reply Mode value 5 (Reply via + Specified Path), MUST NOT be repeated (i.e., MUST NOT appear multiple times) in the Reply Mode Order TLV. - 8. Reply Mode value 1 (Do not reply) SHOULD NOT be used in the Reply - Mode Order TLV. + 8. The Reply Mode value 5 (Reply via Specified Path) MAY be included + more than once in the Reply Mode Order TLV. However, in such + case a Reply Path TLV MUST be included for all instances of the + Reply Mode value 5 included in the Reply Mode Order TLV. In + other words, 3 instances of the Reply Mode value 5 in the Reply + Mode Order TLV will require 3 instances of the Reply Path TLVs. - The responding node is to select the first available return path in - this TLV. Reply Mode value corresponding to selected return path + 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the + Reply Mode Order TLV. + + If a responder LSR receives a Reply Mode Order TLV which does not + comply to the rules described above, then the responder LSR MUST + ignore the Reply Mode Order TLV. + + The responder LSR is to select the first available return path in + this TLV. Reply Mode value corresponding to the selected return path MUST be set in Reply Mode field of MPLS echo reply to communicate back to the initiator LSR which return path was chosen. The format of the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Mode Order TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reply mode 1 | Reply mode 2 | Reply mode 3 | Reply mode 4 | + ~ Reply mode 1 | Reply mode 2 | Reply mode 3 | Reply mode 4 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Reply Mode Order TLV This is a variable length optional TLV. Each Reply Mode field is 1 octet. 4. Relations to Other LSP Ping/Trace Features 4.1. Reply Path TLV [RFC7110] has defined that the "Reply Path TLV" can include Sub-TLVs - describing multiple FECs, from which the responder LSR can chose the - FEC to send the MPLS echo reply message on. [RFC7110] has also - defined that Sub-TLVs, within the "Reply Path TLV", describing FECs - for return paths SHOULD be ignored when the B bit is set in the Flags + describing multiple FECs, from which the responder LSR can choose the + FEC to send the MPLS echo reply message. [RFC7110] has also defined + that Sub-TLVs, within the "Reply Path TLV", describing FECs for + return paths SHOULD be ignored when the B bit is set in the Flags field. Therefore, when the initiator LSR wants to use the Reply Mode Order TLV to describe the reverse LSP and other FECs for return paths, then the initiator SHOULD include two "Reply via Specified Path (5)" Reply Mode values and two "Reply Path TLV" objects (one "Reply Path TLV" corresponding to each "Reply via Specified Path (5)"). o The reverse LSP is described by the "Reply via Specified Path (5)" Reply Mode value and the corresponding "Reply Path TLV" with the B bit set in the Flags field. In this "Reply Path TLV", no Sub-TLVs @@ -366,33 +389,50 @@ o One Reply Path TLV carrying {FEC X, FEC Y} Described encoding of the Reply Mode Order TLV and the Reply Path TLV in the MPLS echo request message will result in the responder LSR to prefer the reverse LSP, followed by "Reply via an IPv4/IPv6 UDP packet (2)", FEC X and then FEC Y. 4.2. Proxy LSP Ping The mechanism defined in this document will work with Proxy LSP Ping - defined by [I-D.ietf-mpls-proxy-lsp-ping]. MPLS proxy ping request - can carry a Reply Mode value and the Reply Mode Order TLV with list - of Reply Mode values. Proxy LSR MUST copy both Reply Mode value and - the Reply Mode Order TLV into MPLS echo request. Proxy LSR, upon - receiving MPLS echo reply, MUST copy Reply Mode value into MPLS proxy - ping reply. With these procedures, Reply Mode used by the MPLS echo - reply sender is propagated in the Reply Mode field to the sender of - MPLS proxy ping request. + defined by [I-D.ietf-mpls-proxy-lsp-ping]. The MPLS proxy ping + request message can carry a Reply Mode value in the header and one or + more Reply Mode values in the Reply Mode Order TLV. It is + RECOMMENDED that the Reply Mode 2 (Reply via an IPv4/IPv6 UDP packet) + be used in the Reply Mode field of the MPLS proxy ping request + message. + +4.2.1. Proxy LSR Sending an MPLS Echo Request + + If the proxy LSR is sending an MPLS echo request, then the proxy LSR + MUST copy following elements from the MPLS proxy ping request message + to the MPLS echo request message. + + o The Reply Mode field. + + o The Reply Mode Order TLV. + + o The Reply Path TLV(s). If there are more than one Reply Path + TLVs, then then order of them MUST be preserved when copying. + +4.2.2. Proxy LSR Sending an MPLS Proxy Ping Reply + + If the proxy LSR is sending an MPLS proxy ping reply, then it is + RECOMMENDED that the Reply Mode Order TLV be ignored and the Reply + Mode field in the MPLS proxy ping request message be used. 5. Security Considerations - Beyond those specified in [RFC4379], there are no further security - measures required. + Beyond those specified in [RFC4379] and [RFC7110], there are no + further security measures required. 6. IANA Considerations 6.1. New Reply Mode Order TLV IANA is requested to assign a new TLV type value from the "TLVs" sub- registry within the "Multiprotocol Label Switching Architecture (MPLS)" registry, for the "Reply Mode Order TLV". The new TLV Type value should be assigned from the range @@ -401,22 +441,23 @@ Type Meaning Reference ---- ------- --------- TBD1 Reply Mode Order TLV this document 7. Acknowledgements Authors would like to thank Santiago Alvarez and Faisal Iqbal for discussions which motivated creation of this document. Authors would also like to thank Sam Aldrin, Curtis Villamizar, Ross Callon, - Jeffrey Zhang, Jeremy Whittaker and Mustapha Alissaoui for providing - valuable comments to influence the contents of the draft. + Jeffrey Zhang, Jeremy Whittaker, Mustapha Alissaoui, Qin Wu, Jie Dong + and Adrian Farrel for providing valuable comments to influence the + contents of the draft. 8. Contributing Authors Shaleen Saxena Brocade Email: ssaxena@brocade.com 9. References 9.1. Normative References @@ -429,22 +470,22 @@ February 2006. [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, January 2014. 9.2. Informative References [I-D.ietf-mpls-proxy-lsp-ping] Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo - Request", draft-ietf-mpls-proxy-lsp-ping-02 (work in - progress), July 2014. + Request", draft-ietf-mpls-proxy-lsp-ping-05 (work in + progress), March 2015. Appendix A. Reply Mode Order TLV Beneficial Scenarios This section lists examples of how the Reply Mode Order TLV can benefit. A.1. Incorrect Forwarding Scenario A network has a following LSP, and the LSP has a control channel. @@ -531,23 +572,23 @@ Success (Reply Mode: 5) Success (Reply Mode: 2) Success (Reply Mode: 2) Success (Reply Mode: 5) Success (Reply Mode: 5) Complete Authors' Addresses Nobo Akiya - Cisco Systems + Big Switch Networks - Email: nobo@cisco.com + Email: nobo.akiya.dev@gmail.com George Swallow Cisco Systems Email: swallow@cisco.com Carlos Pignataro Cisco Systems Email: cpignata@cisco.com