< draft-ietf-mpls-bfd-directed-03.txt   draft-ietf-mpls-bfd-directed-04.txt >
MPLS Working Group G. Mirsky MPLS Working Group G. Mirsky
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track J. Tantsura Intended status: Standards Track J. Tantsura
Expires: February 18, 2017 Expires: March 18, 2017 Individual
I. Varlashkin I. Varlashkin
Google Google
M. Chen M. Chen
Huawei Huawei
August 17, 2016 September 14, 2016
Bidirectional Forwarding Detection (BFD) Directed Return Path Bidirectional Forwarding Detection (BFD) Directed Return Path
draft-ietf-mpls-bfd-directed-03 draft-ietf-mpls-bfd-directed-04
Abstract Abstract
Bidirectional Forwarding Detection (BFD) is expected to monitor any Bidirectional Forwarding Detection (BFD) is expected to be able to
kind of paths between systems. When a BFD session monitors an monitor wide variety of encapsulations of paths between systems.
explicitly routed uni-directional path there may be a need to direct When a BFD session monitors an explicitly routed unidirectional path
egress BFD peer to use specific path for the reverse direction of the there may be a need to direct egress BFD peer to use specific path
BFD session. for the reverse direction of the BFD session.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 18, 2017. This Internet-Draft will expire on March 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Direct Reverse BFD Path . . . . . . . . . . . . . . . . . . . 4 3. Direct Reverse BFD Path . . . . . . . . . . . . . . . . . . . 3
3.1. Case of MPLS Data Plane . . . . . . . . . . . . . . . . . 4 3.1. Case of MPLS Data Plane . . . . . . . . . . . . . . . . . 3
3.1.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . 4 3.1.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . 4
3.1.2. Static and RSVP-TE sub-TLVs . . . . . . . . . . . . . 5 3.1.2. Static and RSVP-TE sub-TLVs . . . . . . . . . . . . . 5
3.1.3. Segment Routing: MPLS Data Plane Case . . . . . . . . 5 3.1.3. Segment Routing: MPLS Data Plane Case . . . . . . . . 5
3.2. Bootstrapping BFD session with BFD Reverse Path over 3.2. Bootstrapping BFD session with BFD Reverse Path over
Segment Routed tunnel . . . . . . . . . . . . . . . . . . 6 Segment Routed tunnel . . . . . . . . . . . . . . . . . . 5
3.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 6
4. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 7 4. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
RFC 5880 [RFC5880], RFC 5881 [RFC5881], and RFC 5883 [RFC5883] RFC 5880 [RFC5880], RFC 5881 [RFC5881], and RFC 5883 [RFC5883]
established the BFD protocol for IP networks and RFC 5884 [RFC5884] established the BFD protocol for IP networks and RFC 5884 [RFC5884]
set rules of using BFD asynchronous mode over IP/MPLS LSPs. These set rules of using BFD asynchronous mode over IP/MPLS LSPs. These
four standards implicitly assume that the egress BFD peer will use standards implicitly assume that the egress BFD peer will use the
the shortest path route regardless of route being used to send BFD shortest path route regardless of route being used to send BFD
control packets towards it. control packets towards it.
For the case where an LSP is explicitly routed, if it is desired that For the case where a LSP is explicitly routed it is likely that the
BFD control packets follow the same path in the reverse direction shortest return path to the ingress BFD peer would not follow the
(for support of common fault detection for explicitly routed same path as the LSP in the forward direction. The fact that BFD
bidirectional co-routed LSPs, for example), it is likely that the control packets are not guaranteed to follow the same links and nodes
shortest return path to the ingress BFD peer may not follow the same in both forward and reverse directions is a significant factor in
path as the LSP in the forward direction. The fact that BFD control producing false positive defect notifications, i.e. false alarms, if
packets are not guaranteed to cross the same links and nodes in both used by the ingress BFD peer to deduce the state of the forward
forward and reverse directions is a significant factor in producing direction.
false positive defect notifications, i.e. false alarms, if used by
the ingress BFD peer to deduce the state of the forward direction.
This document defines the BFD Reverse Path TLV as an extension to LSP This document defines the BFD Reverse Path TLV as an extension to LSP
Ping [RFC4379] and proposes that it to be used to instruct the egress Ping [RFC4379] and proposes that it is to be used to instruct the
BFD peer to use explicit path for its BFD control packets associated egress BFD peer to use explicit path for its BFD control packets
with the particular BFD session. The TLV will be allocated from the associated with a particular BFD session. The TLV will be allocated
TLV and sub-TLV registry defined by RFC 4379 [RFC4379]. As a special from the TLV and sub-TLV registry defined by RFC 4379 [RFC4379]. As
case, forward and reverse directions of the BFD session can form a a special case, forward and reverse directions of the BFD session can
bi-directional co-routed associated channel. form a bi-directional co-routed associated channel.
1.1. Conventions used in this document 1.1. Conventions used in this document
1.1.1. Terminology 1.1.1. Requirements Language
BFD: Bidirectional Forwarding Detection
MPLS: Multiprotocol Label Switching
LSP: Label Switching Path
LoC: Loss of Continuity
1.1.2. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Problem Statement 2. Problem Statement
BFD is best suited to monitor bi-directional co-routed paths. In When BFD is used to monitor unidirectional explicitly routed path,
most cases, given stable environments, the forward and reverse e.g. MPLS-TE LSP, BFD control packets in forward direction would be
directions between two nodes are likely to be co-routed. If BFD is in-band using the mechanism defined in [RFC5884] and [RFC5586]. But
used to monitor unidirectional explicitly routed path, e.g. MPLS-TE the reverse direction of the BFD session would follow the shortest
LSP, BFD control packets in forward direction would be in-band using path route and that might lead to the problem in detecting failures
the mechanism defined in [RFC5884] and [RFC5586]. But the reverse on a unidirectional explicit path as described below:
direction of the BFD session would still follow the shortest path
route and that might lead to the following problem in detecting
failures on a unidirectional explicit path:
o a failure detection by ingress node on the reverse path cannot be o a failure detection by ingress node on the reverse path cannot be
interpreted as bi-directional failure with all the certainty and interpreted as bi-directional failure unambiguously and thus
thus trigger, for example, protection switchover of the forward trigger, for example, protection switchover of the forward
direction without possibility of being a false positive defect direction without possibility of being a false positive.
notification.
To address this scenario the egress BFD peer should be instructed to To address this scenario the egress BFD peer would be instructed to
use a specific path for BFD control packets. use a specific path for BFD control packets.
3. Direct Reverse BFD Path 3. Direct Reverse BFD Path
3.1. Case of MPLS Data Plane 3.1. Case of MPLS Data Plane
LSP ping, defined in [RFC4379], uses BFD Discriminator TLV [RFC5884] LSP ping, defined in [RFC4379], uses BFD Discriminator TLV [RFC5884]
to bootstrap a BFD session over an MPLS LSP. This document defines a to bootstrap a BFD session over an MPLS LSP. This document defines a
new TLV, BFD Reverse Path TLV, that MUST contain a single sub-TLV new TLV, BFD Reverse Path TLV, that MUST contain a single sub-TLV
that can be used to carry information about the reverse path for the that can be used to carry information about the reverse path for the
BFD session that is specified by value in BFD Discriminator TLV. BFD session that is specified by value in BFD Discriminator TLV.
3.1.1. BFD Reverse Path TLV 3.1.1. BFD Reverse Path TLV
The BFD Reverse Path TLV is an optional TLV within the LSP ping The BFD Reverse Path TLV is an optional TLV within the LSP ping
protocol. However, if used, the BFD Discriminator TLV MUST be [RFC4379], [RFC6424]. However, if used, the BFD Discriminator TLV
included in an Echo Request message as well. If the BFD MUST be included in an Echo Request message as well. If the BFD
Discriminator TLV is not present when the BFD Reverse Path TLV is Discriminator TLV is not present when the BFD Reverse Path TLV is
included, then it MUST be treated as malformed Echo Request, as included, then it MUST be treated as malformed Echo Request, as
described in [RFC4379]. described in [RFC4379].
The BFD Reverse Path TLV carries information about the path onto The BFD Reverse Path TLV carries information about the path onto
which the egress BFD peer of the BFD session referenced by the BFD which the egress BFD peer of the BFD session referenced by the BFD
Discriminator TLV MUST transmit BFD control packets. The format of Discriminator TLV MUST transmit BFD control packets. The format of
the BFD Reverse Path TLV is as presented in Figure 1. the BFD Reverse Path TLV is as presented in Figure 1.
0 1 2 3 0 1 2 3
skipping to change at page 4, line 45 skipping to change at page 4, line 32
| BFD Reverse Path TLV Type | Length | | BFD Reverse Path TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Path | | Reverse Path |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BFD Reverse Path TLV Figure 1: BFD Reverse Path TLV
BFD Reverse Path TLV Type is 2 octets in length and has a value of BFD Reverse Path TLV Type is 2 octets in length and has a value of
TB1 (to be assigned by IANA as requested in Section 5). TBD1 (to be assigned by IANA as requested in Section 5).
Length field is 2 octets long and defines the length in octets of the Length field is 2 octets long and defines the length in octets of the
Reverse Path field. Reverse Path field.
Reverse Path field contains a sub-TLV. Any Target FEC sub-TLV Reverse Path field contains a sub-TLV. Any Target FEC sub-TLV
(already defined, or to be defined in the future) for TLV Types 1, (already defined, or to be defined in the future) for TLV Types 1,
16, and 21 of MPLS LSP Ping Parameters registry MAY be used in this 16, and 21 of MPLS LSP Ping Parameters registry MAY be used in this
field. Exactly one sub-TLV MUST be included in the Reverse Path TLV. field. Exactly one sub-TLV MUST be included in the Reverse Path TLV.
If more than one sub-TLV is present in the Reverse Path TLV, then, in If more than one sub-TLV is present in the Reverse Path TLV, then, in
order to avoid ambiguity of which of TLVs to use, the egress BFD peer order to avoid ambiguity of which of TLVs to use, the egress BFD peer
skipping to change at page 5, line 46 skipping to change at page 5, line 34
| Label Entry 2 | | Label Entry 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Entry N | | Label Entry N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Segment Routing MPLS Tunnel sub-TLV Figure 2: Segment Routing MPLS Tunnel sub-TLV
The Segment Routing Tunnel sub-TLV Type is two octets in length, and The Segment Routing Tunnel sub-TLV Type is two octets in length, and
has a value of TB2 (to be assigned by IANA as requested in has a value of TBD2 (to be assigned by IANA as requested in
Section 5). Section 5).
The egress LSR MUST use the Value field as label stack for BFD The egress LSR MUST use the Value field as label stack for BFD
control packets for the BFD session identified by the source IP control packets for the BFD session identified by the source IP
address of the MPLS LSP Ping packet and the value in the BFD address of the MPLS LSP Ping packet and the value in the BFD
Discriminator TLV. Label Entries MUST be in network order. Discriminator TLV. Label Entries MUST be in network order.
The Segment Routing Tunnel sub-TLV MAY be used in Reply Path TLV The Segment Routing Tunnel sub-TLV MAY be used in Reply Path TLV
defined in [RFC7110] defined in [RFC7110]
skipping to change at page 7, line 48 skipping to change at page 7, line 36
+----------+----------------------+---------------+ +----------+----------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+----------+----------------------+---------------+ +----------+----------------------+---------------+
| X (TBD1) | BFD Reverse Path TLV | This document | | X (TBD1) | BFD Reverse Path TLV | This document |
+----------+----------------------+---------------+ +----------+----------------------+---------------+
Table 1: New BFD Reverse Type TLV Table 1: New BFD Reverse Type TLV
5.2. Sub-TLV 5.2. Sub-TLV
The IANA is requested to assign new sub-TLV type from "Multiprotocol The IANA is requested to create new sub-registry for sub-TLV types of
Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping TLV TBD. All code points in the ranges 0 through 16383 and 32768
Parameters - TLVs" registry, "Sub-TLVs for TLV Types 1, 16, and 21" through 49161 in this registry shall be allocated according to the
sub-registry. "IETF Review" procedure as specified in [RFC5226] . Code points in
the ranges 16384 through 31743 and 49162 through 64511 in this
registry shall be allocated according to the "First Come First
Served" procedure as specified in [RFC5226]. Values in the range
31744 through 32767 and 64512 through 65534 are for Vendor or Private
Use, and MUST NOT be allocated. This document defines the following
new values of new sub-TLV type:
+----------+-------------------------------------+---------------+ +-------------+-------------------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+----------+-------------------------------------+---------------+ +-------------+-------------------------------------+---------------+
| X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document | | 0 | Reserved | This document |
+----------+-------------------------------------+---------------+ | X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document |
| 2-31743 | Unassigned | |
| 31744-32767 | Reserved for Vendor or Private Use | |
| 32768-64511 | Unassigned | |
| 64512-65534 | Reserved for Vendor or Private Use | |
| 65535 | Reserved | This document |
+-------------+-------------------------------------+---------------+
Table 2: New Segment Routing Tunnel sub-TLV Table 2: New Segment Routing Tunnel sub-TLV
5.3. Return Codes 5.3. Return Codes
The IANA is requested to assign a new Return Code value from the The IANA is requested to assign a new Return Code value from the
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry, "Return Codes" sub-registry, as follows Ping Parameters" registry, "Return Codes" sub-registry, as follows
using a Standards Action value. using a Standards Action value.
skipping to change at page 8, line 39 skipping to change at page 8, line 45
Table 3: New Return Code Table 3: New Return Code
6. Security Considerations 6. Security Considerations
Security considerations discussed in [RFC5880], [RFC5884], and Security considerations discussed in [RFC5880], [RFC5884], and
[RFC4379], apply to this document. [RFC4379], apply to this document.
7. Acknowledgements 7. Acknowledgements
Authors greatly appreciate thorough review and the most helpful Authors greatly appreciate thorough review and the most helpful
comments from Eric Gray. comments from Eric Gray and Carlos Pignataro.
8. Normative References 8. References
8.1. Normative References
[I-D.ietf-mpls-spring-lsp-ping] [I-D.ietf-mpls-spring-lsp-ping]
Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
S., Gredler, H., and M. Chen, "Label Switched Path (LSP) S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
Ping/Trace for Segment Routing Networks Using MPLS Ping/Trace for Segment Routing Networks Using MPLS
Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in
progress), May 2016. progress), May 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 9, line 38 skipping to change at page 9, line 46
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
June 2010, <http://www.rfc-editor.org/info/rfc5883>. June 2010, <http://www.rfc-editor.org/info/rfc5883>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <http://www.rfc-editor.org/info/rfc5884>. June 2010, <http://www.rfc-editor.org/info/rfc5884>.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
Performing Label Switched Path Ping (LSP Ping) over MPLS
Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
<http://www.rfc-editor.org/info/rfc6424>.
[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, DOI 10.17487/RFC7110, January 2014, RFC 7110, DOI 10.17487/RFC7110, January 2014,
<http://www.rfc-editor.org/info/rfc7110>. <http://www.rfc-editor.org/info/rfc7110>.
[RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S.
Aldrin, "Clarifying Procedures for Establishing BFD Aldrin, "Clarifying Procedures for Establishing BFD
Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
DOI 10.17487/RFC7726, January 2016, DOI 10.17487/RFC7726, January 2016,
<http://www.rfc-editor.org/info/rfc7726>. <http://www.rfc-editor.org/info/rfc7726>.
8.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
Ericsson Ericsson
Email: gregory.mirsky@ericsson.com Email: gregimirsky@gmail.com
Jeff Tantsura Jeff Tantsura
Individual
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Ilya Varlashkin Ilya Varlashkin
Google Google
Email: Ilya@nobulus.com Email: Ilya@nobulus.com
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Huawei
 End of changes. 28 change blocks. 
75 lines changed or deleted 86 lines changed or added

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