draft-ietf-idr-rs-bfd-04.txt   draft-ietf-idr-rs-bfd-05.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: Standards Track J. Haas Intended status: Standards Track J. Haas
Expires: August 18, 2018 J. Scudder Expires: October 13, 2018 J. Scudder
Juniper Networks, Inc. Juniper Networks, Inc.
A. Nipper A. Nipper
C. Dietzel C. Dietzel
DE-CIX Management GmbH DE-CIX
February 14, 2018 April 11, 2018
Making Route Servers Aware of Data Link Failures at IXPs Making Route Servers Aware of Data Link Failures at IXPs
draft-ietf-idr-rs-bfd-04 draft-ietf-idr-rs-bfd-05
Abstract Abstract
When BGP route servers are used, the data plane is not congruent with When BGP route servers are used, the data plane is not congruent with
the control plane. Therefore, peers at an Internet exchange can lose the control plane. Therefore, peers at an Internet exchange can lose
data connectivity without the control plane being aware of it, and data connectivity without the control plane being aware of it, and
packets are lost. This document proposes the use of a newly defined packets are lost. This document proposes the use of a newly defined
BGP Subsequent Address Family Identifier (SAFI) both to allow the BGP Subsequent Address Family Identifier (SAFI) both to allow the
route server to request its clients use BFD to track data plane route server to request its clients use BFD to track data plane
connectivity to their peers' addresses, and for the clients to signal connectivity to their peers' addresses, and for the clients to signal
skipping to change at page 1, line 43 skipping to change at page 1, line 43
words, without normative meaning. words, without normative meaning.
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 https://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 August 18, 2018. This Internet-Draft will expire on October 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Next Hop Validation . . . . . . . . . . . . . . . . . . . . . 5 4. Next Hop Validation . . . . . . . . . . . . . . . . . . . . . 5
4.1. ReachAsk . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. ReachAsk . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. LocReach . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. LocReach . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. ReachTell . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. ReachTell . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. NHIB . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. NHIB . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Advertising NH-Reach state in BGP . . . . . . . . . . . . . . 6 5. Advertising NH-Reach state in BGP . . . . . . . . . . . . . . 7
6. Client Procedures for NH-Reach Changes . . . . . . . . . . . 8 6. Client Procedures for NH-Reach Changes . . . . . . . . . . . 9
7. Recommendations for Using BFD . . . . . . . . . . . . . . . . 9 7. Recommendations for Using BFD . . . . . . . . . . . . . . . . 9
8. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 10
9. Acknolwedgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknolwedgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Summary of Document Changes . . . . . . . . . . . . 11 Appendix A. Summary of Document Changes . . . . . . . . . . . . 12
Appendix B. Other Forms of Connectity Checks . . . . . . . . . . 11 Appendix B. Other Forms of Connectity Checks . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
In configurations (typically Internet Exchange Points (IXPs)) where In configurations (typically Internet Exchange Points (IXPs)) where
EBGP routing information is exchanged between client routers through EBGP routing information is exchanged between client routers through
the agency of a route server (RS) [RFC7947], but traffic is exchanged the agency of a route server (RS) [RFC7947], but traffic is exchanged
directly, operational issues can arise when partial data plane directly, operational issues can arise when partial data plane
connectivity exists among the route server client routers. Since the connectivity exists among the route server client routers. Since the
data plane is not congruent with the control plane, the client data plane is not congruent with the control plane, the client
routers on the IXP can lose data connectivity without the control routers on the IXP can lose data connectivity without the control
skipping to change at page 3, line 36 skipping to change at page 3, line 36
the procedures for signaling reachability back to the route server the procedures for signaling reachability back to the route server
may not. may not.
Throughout this document, we refer to the "route server", "RS" or Throughout this document, we refer to the "route server", "RS" or
just "server" and the "client" to describe the two BGP routers just "server" and the "client" to describe the two BGP routers
engaging in the exchange of information. We observe that there could engaging in the exchange of information. We observe that there could
be other applications for this extension. Our use of terminology is be other applications for this extension. Our use of terminology is
intended for clarity of description, and not to limit the future intended for clarity of description, and not to limit the future
applicability of the proposal. applicability of the proposal.
[I-D.ietf-idr-bgp-bestpath-selection-criteria] discusses enhancement
of the route resolvability condition of section 9.1.2.1 of [RFC4271]
to include next hop reachability and path availability checks. This
specification represents in part an instance of such, implemented
using BFD as the OAM mechanism.
2. Definitions 2. Definitions
o Indirect peer: If a route server is configured such that routes o Indirect peer: If a route server is configured such that routes
from a given client might be sent to some other client, or vice- from a given client might be sent to some other client, or vice-
versa, those two clients are considered to be indirect peers. versa, those two clients are considered to be indirect peers.
o Indirect Peer's Address, IPA, next hop: We refer frequently to a
next hop. It should generally be clear from context what is
intended, almost always an address associated with an indirect
peer (the exception, when an indirect peer sends a third party
next hop, is discussed in Section 3). In Section 5 we discuss the
MP-BGP [RFC4760] Next Hop field; this is distinguished by its
capitalization and should also be clear from context. Later in
that section we define the Indirect Peer's Address field of the
NLRI, also called "IPA". It will be clear to the reader that this
refers to the "next hops" discussed elsewhere in the document, but
we don't use the name "next hop" for this field to avoid confusion
with the pre-existing next hop path attribute of [RFC4271] and
attribute field of [RFC4760].
o RS: Route Server. See [RFC7947]. o RS: Route Server. See [RFC7947].
3. Overview 3. Overview
As with the base BGP protocol, we model the function of this As with the base BGP protocol, we model the function of this
extension as the interaction between a conceptual set of databases: extension as the interaction between a conceptual set of databases:
o ReachAsk: The reachability request database. A database of o ReachAsk: The reachability request database. A database of next
nexthops (host addresses) for which data plane reachability is hops (host addresses) for which data plane reachability is being
being queried. queried.
o ReachAsk-Out: A set of queries sent to the client. o ReachAsk-Out: A set of queries sent to the client.
o ReachAsk-In: A set of queries received from the route server. o ReachAsk-In: A set of queries received from the route server.
o ReachTell: The reachability response database. A database of o ReachTell: The reachability response database. A database of
responses to ReachAsk queries, indicating what is known about data responses to ReachAsk queries, indicating what is known about data
plane reachability. plane reachability.
o ReachTell-Out: The responses being sent to the route server. o ReachTell-Out: The responses being sent to the route server.
o ReachTell-In: The response received from the client. o ReachTell-In: The response received from the client.
o LocReach: The local reachability database. o LocReach: The local reachability database.
o NHIB: Next Hop Information Base. Stores what is known about the o NHIB: Next Hop Information Base. Stores what is known about the
client's reachability to its next hops. client's reachability to its next hops.
skipping to change at page 5, line 8 skipping to change at page 5, line 47
tracks connectivity using BFD and reports its connectivity status to tracks connectivity using BFD and reports its connectivity status to
the RS using ReachTell "routes". Connectivity status may be that the the RS using ReachTell "routes". Connectivity status may be that the
next hop is reachable, unreachable, or unknown. Once the RS has been next hop is reachable, unreachable, or unknown. Once the RS has been
informed by the client of its connectivity, it uses this information informed by the client of its connectivity, it uses this information
to influence the route selection the RS performs on behalf of the to influence the route selection the RS performs on behalf of the
client. Details are elaborated in the following sections. client. Details are elaborated in the following sections.
4. Next Hop Validation 4. Next Hop Validation
Below, we detail procedures where a route server tells its client Below, we detail procedures where a route server tells its client
router about other client nexthops by sending it ReachAsk routes and router about other client next hops by sending it ReachAsk routes and
the client router verifies connectivity to those other client routers the client router verifies connectivity to those other client routers
and communicates its findings back to the RS using ReachTell routes. and communicates its findings back to the RS using ReachTell routes.
The RS uses the received ReachTell routes as input to the NHIB and The RS uses the received ReachTell routes as input to the NHIB and
hence the route selection process it performs on behalf of the hence the route selection process it performs on behalf of the
client. client.
4.1. ReachAsk 4.1. ReachAsk
The route server maintains a ReachAsk database for each client that The route server maintains a ReachAsk database for each client that
supports this proposal, that is, for each client that has advertised supports this proposal, that is, for each client that has advertised
skipping to change at page 7, line 31 skipping to change at page 8, line 18
not asked for, but this is permissible in any case. Again, since the not asked for, but this is permissible in any case. Again, since the
contents of ReachAsk are simply a set of host routes to be tested, contents of ReachAsk are simply a set of host routes to be tested,
route selection over a combined ReachAsk MAY be omitted. route selection over a combined ReachAsk MAY be omitted.
ReachAsk and ReachTell entries are exchanged using the NH-Reach NLRI ReachAsk and ReachTell entries are exchanged using the NH-Reach NLRI
encoding: encoding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|Reserved |Sta| next hop (4 or 16 octets) | |T|Reserved |Sta| Indirect Peer's Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ... next hop (4 or 16 octets) ... . . ... Indirect Peer's Address (4 or 16 octets) ... .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NH-Reach NLRI Format NH-Reach NLRI Format
o T: Type is a one-bit field that can take the value 0, meaning the o T: Type is a one-bit field that can take the value 0, meaning the
NLRI is a ReachAsk entry, or 1, meaning it is a ReachTell entry. NLRI is a ReachAsk entry, or 1, meaning it is a ReachTell entry.
o Reserved: These five bits are reserved. They MUST be sent as zero o Reserved: These five bits are reserved. They MUST be sent as zero
and MUST be disregarded on receipt. and MUST be disregarded on receipt.
o Sta: State is a two-bit field used to signal the LocReach o Sta: State is a two-bit field used to signal the LocReach
(Section 4.2) state: (Section 4.2) state:
* 0 or 3: Unknown. * 0 or 3: Unknown.
* 1: Up. * 1: Up.
* 2: Down. * 2: Down.
Although either 0 or 3 is to be interpreted as "Unknown", the Although either 0 or 3 is to be interpreted as "Unknown", the
value 0 MUST be used on transmission. The value 3 MUST be value 0 MUST be used on transmission. The value 3 MUST be
accepted as an alias for 0 on receipt. accepted as an alias for 0 on receipt.
o The Indirect Peer's Address ("IPA") field is an IPv4 or IPv6 host
o The next hop field is an IPv4 or IPv6 host route, depending on route, depending on whether the AFI is IPv4 or IPv6.
whether the AFI is IPv4 or IPv6.
ReachAsk and ReachTell entries MUST NOT be propagated from one BGP ReachAsk and ReachTell entries MUST NOT be propagated from one BGP
peering session to another; the routes are not transitive. peering session to another; the routes are not transitive.
The next hop field is the key for the NH-Reach NLRI type; the The IPA field is the key for the NH-Reach NLRI type; the information
information encoded in the top octet is non-key information. It is encoded in the top octet is non-key information. It is possible in
possible in principle (although unlikely) for two NLRI to be validly principle (although unlikely) for two NLRI to be validly present in
present in an UPDATE message with identical next hop fields but an UPDATE message with identical IPA fields but different types.
different types. However, two NLRI with the same next hop field and However, two NLRI with the same IPA field and different State fields
different State fields MUST NOT be encoded in the same UPDATE MUST NOT be encoded in the same UPDATE message. If such is
message. If such is encountered, the receiver MUST behave as though encountered, the receiver MUST behave as though the state "Unknown"
the state "Unknown" was received for the next hop in question. was received for the IPA in question.
6. Client Procedures for NH-Reach Changes 6. Client Procedures for NH-Reach Changes
When an entry is added to a route server client's ReachAsk-In for a When an entry is added to a route server client's ReachAsk-In for a
route server peering session, the client will then attempt to verify route server peering session, the client will then attempt to verify
connectivity to the host depicted by that entry. The procedure connectivity to the host depicted by that entry. The procedure
described in this specification utilizes BFD. described in this specification utilizes BFD.
If no existing BFD session exists to this nexthop, a BFD session is If no existing BFD session exists to this next hop, a BFD session is
provisioned to that IP address and the LocReach reachability state provisioned to that IP address and the LocReach reachability state
(Section 4.2) is set to Unknown. (Section 4.2) is set to Unknown.
If the client cannot establish a BFD session with an entry in its If the client cannot establish a BFD session with an entry in its
ReachAsk-In, the nexthop remains in LocReach with its Reachable state ReachAsk-In, the next hop remains in LocReach with its Reachable
Unknown. state Unknown.
Once the BFD session moves to the Up state, the LocReach reachability Once the BFD session moves to the Up state, the LocReach reachability
state is set to Up. state is set to Up.
When the BFD session transitions out of the Up state to the Down When the BFD session transitions out of the Up state to the Down
state, the LocReach reachability state is set to Down. state, the LocReach reachability state is set to Down.
If the BFD session transitions out of the Up state to the AdminDown If the BFD session transitions out of the Up state to the AdminDown
state, the LocReach reachability state is set to Unknown. state, the LocReach reachability state is set to Unknown.
skipping to change at page 9, line 40 skipping to change at page 10, line 24
For purposes of routing stability, implementations may wish to apply For purposes of routing stability, implementations may wish to apply
hysteresis ("holddown") to next hops that have transitioned from hysteresis ("holddown") to next hops that have transitioned from
reachable to unreachable and back. reachable to unreachable and back.
Implementations MAY restrict the range of addresses with which they Implementations MAY restrict the range of addresses with which they
will attempt to form BFD relationships. For example, an will attempt to form BFD relationships. For example, an
implementation might by default only allow BFD relationships with implementation might by default only allow BFD relationships with
peers that share a subnetwork with the route server. An peers that share a subnetwork with the route server. An
implementation MAY apply such restrictions by default. implementation MAY apply such restrictions by default.
In a route-server environment, use of this feature SHOULD be
restricted to consider only routes that are advertised from within
the IXP network. This might include checks on AS_PATH length.
9. Acknolwedgments 9. Acknolwedgments
The authors would like to thanks Thomas King for his contributions The authors would like to thanks Thomas King for his contributions
toward this work. toward this work.
10. IANA Considerations 10. IANA Considerations
IANA is requested to allocate a value from the Subsequent Address IANA is requested to allocate a value from the Subsequent Address
Family Identifiers (SAFI) Parameters registry for this proposal. Its Family Identifiers (SAFI) Parameters registry for this proposal. Its
Description in that registry shall be NH-Reach with a Reference of Description in that registry shall be NH-Reach with a Reference of
skipping to change at page 10, line 39 skipping to change at page 11, line 27
includes forcing a BFD session to stay Up when its real state is includes forcing a BFD session to stay Up when its real state is
Down. These attacks may be mitigated using the BFD security Down. These attacks may be mitigated using the BFD security
mechanisms defined in [RFC5880]. mechanisms defined in [RFC5880].
12. References 12. References
12.1. Normative References 12.1. Normative References
[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,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, <https://www.rfc- DOI 10.17487/RFC4271, January 2006,
editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, <https://www.rfc- DOI 10.17487/RFC4760, January 2007,
editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010, <https://www.rfc- DOI 10.17487/RFC5881, June 2010,
editor.org/info/rfc5881>. <https://www.rfc-editor.org/info/rfc5881>.
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
"Internet Exchange BGP Route Server", RFC 7947, "Internet Exchange BGP Route Server", RFC 7947,
DOI 10.17487/RFC7947, September 2016, <https://www.rfc- DOI 10.17487/RFC7947, September 2016,
editor.org/info/rfc7947>. <https://www.rfc-editor.org/info/rfc7947>.
12.2. Informative References 12.2. Informative References
[I-D.chen-bfd-unsolicited] [I-D.chen-bfd-unsolicited]
Chen, E., Shen, N., and R. Raszuk, "Unsolicited BFD for Chen, E., Shen, N., and R. Raszuk, "Unsolicited BFD for
Sessionless Applications", draft-chen-bfd-unsolicited-02 Sessionless Applications", draft-chen-bfd-unsolicited-02
(work in progress), January 2018. (work in progress), January 2018.
[I-D.ietf-idr-bgp-bestpath-selection-criteria]
Asati, R., "BGP Bestpath Selection Criteria Enhancement",
draft-ietf-idr-bgp-bestpath-selection-criteria-08 (work in
progress), October 2017.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<https://www.rfc-editor.org/info/rfc7880>. <https://www.rfc-editor.org/info/rfc7880>.
Appendix A. Summary of Document Changes Appendix A. Summary of Document Changes
idr-04 to idr-05: Added reference to "BGP Bestpath Selection
Criteria Enhancement" draft. Rename "next hop" field of NLRI to
"Indirect Peer's Address". Add suggestion about AS_PATH length
checks.
idr-03 to idr-04: Note other forms of connectivity checks. idr-03 to idr-04: Note other forms of connectivity checks.
idr-02 to idr-03: Substantial rewrite. Introduce NLRI format that idr-02 to idr-03: Substantial rewrite. Introduce NLRI format that
embeds state. embeds state.
idr-01 to idr-02: Move from BGP-LS to NH-Reach SAFI. Lots of idr-01 to idr-02: Move from BGP-LS to NH-Reach SAFI. Lots of
editorial changes. editorial changes.
idr-00 to idr-01: Add BGP Capability. Move from NH-Cost to BGP-LS. idr-00 to idr-01: Add BGP Capability. Move from NH-Cost to BGP-LS.
ymbk-01 to idr-00: No technical changes; adopted by IDR. ymbk-01 to idr-00: No technical changes; adopted by IDR.
ymbk-00 to ymbk-01: Clarifications to BFD procedures. Use BFD state ymbk-00 to ymbk-01: Clarifications to BFD procedures. Use BFD state
as an input to BGP route selection. as an input to BGP route selection.
 End of changes. 29 change blocks. 
54 lines changed or deleted 84 lines changed or added

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