draft-ietf-mpls-lsp-ping-reply-mode-simple-01.txt   draft-ietf-mpls-lsp-ping-reply-mode-simple-02.txt 
Internet Engineering Task Force N. Akiya Internet Engineering Task Force N. Akiya
Internet-Draft G. Swallow Internet-Draft Big Switch Networks
Updates: 4379,7110 (if approved) C. Pignataro Updates: 7110 (if approved) G. Swallow
Intended status: Standards Track Cisco Systems Intended status: Standards Track C. Pignataro
Expires: July 9, 2015 L. Andersson Expires: October 15, 2015 Cisco Systems
L. Andersson
M. Chen M. Chen
Huawei Huawei
January 5, 2015 April 13, 2015
Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification 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 Abstract
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
Ping and Traceroute use the Reply Mode field to signal the method to 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 be used in the MPLS echo reply. This document updates the "Reply via
Specified Path (5)" Reply Mode value to easily indicate the reverse Specified Path (5)" Reply Mode value to easily indicate the reverse
LSP. This document also adds an optional TLV which can carry ordered LSP. This document also adds an optional TLV which can carry ordered
list of Reply Mode values. list of Reply Mode values.
This document updates RFC4379 and RFC7110. This document updates RFC7110.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Reply via Specified Path Update . . . . . . . . . . . . . 5 3.1. Reply via Specified Path Update . . . . . . . . . . . . . 5
3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 6 3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 6
4. Relations to Other LSP Ping/Trace Features . . . . . . . . . 7 4. Relations to Other LSP Ping/Trace Features . . . . . . . . . 7
4.1. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 7 4.1. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Example 1: Reply Mode Order TLV Usage with Reply Path 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 4.1.2. Example 2: Reply Mode Order TLV Usage with Reply Path
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 9 6.1. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 9 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Reply Mode Order TLV Beneficial Scenarios . . . . . 10 Appendix A. Reply Mode Order TLV Beneficial Scenarios . . . . . 11
A.1. Incorrect Forwarding Scenario . . . . . . . . . . . . . . 10 A.1. Incorrect Forwarding Scenario . . . . . . . . . . . . . . 11
A.2. Non-Co-Routed Bidirectional LSP Scenario . . . . . . . . 11 A.2. Non-Co-Routed Bidirectional LSP Scenario . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The MPLS LSP Ping, described in [RFC4379], allows an initiator LSR to The MPLS LSP Ping, described in [RFC4379], allows an initiator LSR to
encode instructions (Reply Mode) on how a responder LSR should send encode instructions (Reply Mode) on how a responder LSR should send
the response back to the initiator LSR. [RFC7110] also allows the the response back to the initiator LSR. [RFC7110] also allows the
initiator LSR to encode a TLV (Reply Path TLV) which can instruct 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 responder LSR to use specific LSP to send the response back to the
initiator LSR. Both approaches are powerful as they provide the initiator LSR. Both approaches are powerful as they provide the
ability for the initiator LSR to control the return path. ability for the initiator LSR to control the return path.
skipping to change at page 3, line 32 skipping to change at page 3, line 39
o In Section 2, further description of the problems; o In Section 2, further description of the problems;
o In Section 3, a solution to minimize false failures while o In Section 3, a solution to minimize false failures while
accommodating operator preferences; accommodating operator preferences;
o In Section 4, relationships to other LSP Ping/Traceroute features; o In Section 4, relationships to other LSP Ping/Traceroute features;
o In Appendix A, examples of scenarios where the mechanism described o In Appendix A, examples of scenarios where the mechanism described
in this document provides benefits. 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 2. Problem Statements
It is becoming increasingly difficult for implementations to It is becoming increasingly difficult for implementations to
automatically supply a workable return path encoding for all MPLS LSP automatically supply a workable return path encoding for all MPLS LSP
Ping and Traceroute operations across all LSP types. There are Ping and Traceroute operations across all LSP types. There are
several factors which are contributing to this complication. several factors which are contributing to this complication.
o Some LSPs have a control-channel, and some do not. Some LSPs have 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 a reverse LSP, and some do not. Some LSPs have IP reachability in
the reverse direction, and some do not. the reverse direction, and some do not.
skipping to change at page 6, line 17 skipping to change at page 6, line 22
0:0:0:0:0:FFFF:7F00/104 for IPv6. 0:0:0:0:0:FFFF:7F00/104 for IPv6.
3.2. Reply Mode Order TLV 3.2. Reply Mode Order TLV
This document also introduces a new optional TLV to describe list of 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 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 value(s) in preferred order. The first Reply Mode value is the most
preferred and the last Reply Mode value is the least preferred. preferred and the last Reply Mode value is the least preferred.
Following rules apply when using Reply Mode Order TLV. 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 3. The Reply Mode field of an MPLS echo request MUST be set to a
value when supplying Reply Mode Order TLV in transmitting MPLS valid value even when supplying the Reply Mode Order TLV. The
echo request. The initiator LSR SHOULD set Reply Mode field of initiator LSR SHOULD set the Reply Mode field of MPLS echo
MPLS echo request to a value that corresponds to a return path request to a value that corresponds to a return path which most
which most likely to be available, in case the responder LSR does likely to be available, in case the responder LSR does not
not understand the Reply Mode Order TLV. understand the Reply Mode Order TLV.
4. If a responder LSR understands the Reply Mode Order TLV and the 4. If a responder LSR understands the Reply Mode Order TLV but the
TLV is valid, then the responder LSR MUST consider Reply Mode 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 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. 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, 6. Reply Mode Order TLV MUST contain at least one Reply Mode value,
and SHOULD contain at least two Reply Mode values. 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. multiple times) in the Reply Mode Order TLV.
8. Reply Mode value 1 (Do not reply) SHOULD NOT be used in the Reply 8. The Reply Mode value 5 (Reply via Specified Path) MAY be included
Mode Order TLV. 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 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the
this TLV. Reply Mode value corresponding to selected return path 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 MUST be set in Reply Mode field of MPLS echo reply to communicate
back to the initiator LSR which return path was chosen. back to the initiator LSR which return path was chosen.
The format of the TLV is as follows: The format of the TLV is as follows:
0 1 2 3 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 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 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 Figure 1 Reply Mode Order TLV
This is a variable length optional TLV. Each Reply Mode field is 1 This is a variable length optional TLV. Each Reply Mode field is 1
octet. octet.
4. Relations to Other LSP Ping/Trace Features 4. Relations to Other LSP Ping/Trace Features
4.1. Reply Path TLV 4.1. Reply Path TLV
[RFC7110] has defined that the "Reply Path TLV" can include Sub-TLVs [RFC7110] has defined that the "Reply Path TLV" can include Sub-TLVs
describing multiple FECs, from which the responder LSR can chose the describing multiple FECs, from which the responder LSR can choose the
FEC to send the MPLS echo reply message on. [RFC7110] has also FEC to send the MPLS echo reply message. [RFC7110] has also defined
defined that Sub-TLVs, within the "Reply Path TLV", describing FECs that Sub-TLVs, within the "Reply Path TLV", describing FECs for
for return paths SHOULD be ignored when the B bit is set in the Flags 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 field. Therefore, when the initiator LSR wants to use the Reply Mode
Order TLV to describe the reverse LSP and other FECs for return Order TLV to describe the reverse LSP and other FECs for return
paths, then the initiator SHOULD include two "Reply via Specified paths, then the initiator SHOULD include two "Reply via Specified
Path (5)" Reply Mode values and two "Reply Path TLV" objects (one Path (5)" Reply Mode values and two "Reply Path TLV" objects (one
"Reply Path TLV" corresponding to each "Reply via Specified Path "Reply Path TLV" corresponding to each "Reply via Specified Path
(5)"). (5)").
o The reverse LSP is described by the "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 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 bit set in the Flags field. In this "Reply Path TLV", no Sub-TLVs
skipping to change at page 8, line 46 skipping to change at page 9, line 19
o One Reply Path TLV carrying {FEC X, FEC Y} o One Reply Path TLV carrying {FEC X, FEC Y}
Described encoding of the Reply Mode Order TLV and the Reply Path TLV 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 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 prefer the reverse LSP, followed by "Reply via an IPv4/IPv6 UDP
packet (2)", FEC X and then FEC Y. packet (2)", FEC X and then FEC Y.
4.2. Proxy LSP Ping 4.2. Proxy LSP Ping
The mechanism defined in this document will work with 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 defined by [I-D.ietf-mpls-proxy-lsp-ping]. The MPLS proxy ping
can carry a Reply Mode value and the Reply Mode Order TLV with list request message can carry a Reply Mode value in the header and one or
of Reply Mode values. Proxy LSR MUST copy both Reply Mode value and more Reply Mode values in the Reply Mode Order TLV. It is
the Reply Mode Order TLV into MPLS echo request. Proxy LSR, upon RECOMMENDED that the Reply Mode 2 (Reply via an IPv4/IPv6 UDP packet)
receiving MPLS echo reply, MUST copy Reply Mode value into MPLS proxy be used in the Reply Mode field of the MPLS proxy ping request
ping reply. With these procedures, Reply Mode used by the MPLS echo message.
reply sender is propagated in the Reply Mode field to the sender of
MPLS proxy ping request. 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 5. Security Considerations
Beyond those specified in [RFC4379], there are no further security Beyond those specified in [RFC4379] and [RFC7110], there are no
measures required. further security measures required.
6. IANA Considerations 6. IANA Considerations
6.1. New Reply Mode Order TLV 6.1. New Reply Mode Order TLV
IANA is requested to assign a new TLV type value from the "TLVs" sub- IANA is requested to assign a new TLV type value from the "TLVs" sub-
registry within the "Multiprotocol Label Switching Architecture registry within the "Multiprotocol Label Switching Architecture
(MPLS)" registry, for the "Reply Mode Order TLV". (MPLS)" registry, for the "Reply Mode Order TLV".
The new TLV Type value should be assigned from the range The new TLV Type value should be assigned from the range
skipping to change at page 9, line 33 skipping to change at page 10, line 26
Type Meaning Reference Type Meaning Reference
---- ------- --------- ---- ------- ---------
TBD1 Reply Mode Order TLV this document TBD1 Reply Mode Order TLV this document
7. Acknowledgements 7. Acknowledgements
Authors would like to thank Santiago Alvarez and Faisal Iqbal for Authors would like to thank Santiago Alvarez and Faisal Iqbal for
discussions which motivated creation of this document. Authors would discussions which motivated creation of this document. Authors would
also like to thank Sam Aldrin, Curtis Villamizar, Ross Callon, also like to thank Sam Aldrin, Curtis Villamizar, Ross Callon,
Jeffrey Zhang, Jeremy Whittaker and Mustapha Alissaoui for providing Jeffrey Zhang, Jeremy Whittaker, Mustapha Alissaoui, Qin Wu, Jie Dong
valuable comments to influence the contents of the draft. and Adrian Farrel for providing valuable comments to influence the
contents of the draft.
8. Contributing Authors 8. Contributing Authors
Shaleen Saxena Shaleen Saxena
Brocade Brocade
Email: ssaxena@brocade.com Email: ssaxena@brocade.com
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 10, line 13 skipping to change at page 11, line 9
February 2006. February 2006.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping", "Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, January 2014. RFC 7110, January 2014.
9.2. Informative References 9.2. Informative References
[I-D.ietf-mpls-proxy-lsp-ping] [I-D.ietf-mpls-proxy-lsp-ping]
Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo
Request", draft-ietf-mpls-proxy-lsp-ping-02 (work in Request", draft-ietf-mpls-proxy-lsp-ping-05 (work in
progress), July 2014. progress), March 2015.
Appendix A. Reply Mode Order TLV Beneficial Scenarios Appendix A. Reply Mode Order TLV Beneficial Scenarios
This section lists examples of how the Reply Mode Order TLV can This section lists examples of how the Reply Mode Order TLV can
benefit. benefit.
A.1. Incorrect Forwarding Scenario A.1. Incorrect Forwarding Scenario
A network has a following LSP, and the LSP has a control channel. A network has a following LSP, and the LSP has a control channel.
skipping to change at page 12, line 20 skipping to change at page 13, line 15
Success (Reply Mode: 5) Success (Reply Mode: 5)
Success (Reply Mode: 2) Success (Reply Mode: 2)
Success (Reply Mode: 2) Success (Reply Mode: 2)
Success (Reply Mode: 5) Success (Reply Mode: 5)
Success (Reply Mode: 5) Success (Reply Mode: 5)
Complete Complete
Authors' Addresses Authors' Addresses
Nobo Akiya Nobo Akiya
Cisco Systems Big Switch Networks
Email: nobo@cisco.com Email: nobo.akiya.dev@gmail.com
George Swallow George Swallow
Cisco Systems Cisco Systems
Email: swallow@cisco.com Email: swallow@cisco.com
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
Email: cpignata@cisco.com Email: cpignata@cisco.com
 End of changes. 27 change blocks. 
63 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/