draft-ietf-idr-rs-bfd-03.txt   draft-ietf-idr-rs-bfd-04.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: January 4, 2018 J. Scudder Expires: August 18, 2018 J. Scudder
Juniper Networks, Inc. Juniper Networks, Inc.
A. Nipper A. Nipper
T. King C. Dietzel
DE-CIX Management GmbH DE-CIX Management GmbH
July 3, 2017 February 14, 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-03 draft-ietf-idr-rs-bfd-04
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 2, line 4 skipping to change at page 2, line 4
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 January 4, 2018. This Internet-Draft will expire on August 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 (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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Next Hop Validation . . . . . . . . . . . . . . . . . . . . . 5 4. Next Hop Validation . . . . . . . . . . . . . . . . . . . . . 5
4.1. ReachAsk . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. ReachAsk . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. LocReach . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. LocReach . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. ReachTell . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. ReachTell . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. NHIB . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. NHIB . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Advertising NH-Reach state in BGP . . . . . . . . . . . . . . 6 5. Advertising NH-Reach state in BGP . . . . . . . . . . . . . . 6
6. Client Procedures for NH-Reach Changes . . . . . . . . . . . 8 6. Client Procedures for NH-Reach Changes . . . . . . . . . . . 8
7. Recommendations for Using BFD . . . . . . . . . . . . . . . . 9 7. Recommendations for Using BFD . . . . . . . . . . . . . . . . 9
8. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknolwedgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Summary of Document Changes . . . . . . . . . . . . 11 Appendix A. Summary of Document Changes . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Other Forms of Connectity Checks . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 50 skipping to change at page 4, line 4
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
nexthops (host addresses) for which data plane reachability is nexthops (host addresses) for which data plane reachability is
being queried. being 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 9, line 40 skipping to change at page 9, line 40
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.
9. IANA Considerations 9. Acknolwedgments
The authors would like to thanks Thomas King for his contributions
toward this work.
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
this RFC. this RFC.
10. Security Considerations 11. Security Considerations
The mechanism in this document permits a route server client to The mechanism in this document permits a route server client to
influence the contents of the route server's Adj-Ribs-Out through its influence the contents of the route server's Adj-Ribs-Out through its
reports of next hop reachability state using the NH-Reach SAFI. reports of next hop reachability state using the NH-Reach SAFI.
Since this state is per-client, if a route server client is able to Since this state is per-client, if a route server client is able to
inject NH-Reach routes for another route server's BGP session to a inject NH-Reach routes for another route server's BGP session to a
client, it can cause the route server to select different forwarding client, it can cause the route server to select different forwarding
than otherwise expected. This issue may be mitigated using transport than otherwise expected. This issue may be mitigated using transport
security on the BGP sessions between the route server and its security on the BGP sessions between the route server and its
clients. See [RFC4272]. clients. See [RFC4272].
skipping to change at page 10, line 26 skipping to change at page 10, line 33
impose limits on the number of BFD sessions it will create at the impose limits on the number of BFD sessions it will create at the
request of the server. request of the server.
The reachability tests between route server clients themselves may be The reachability tests between route server clients themselves may be
a target for attack. Such attacks may include forcing a BFD session a target for attack. Such attacks may include forcing a BFD session
Down through injecting false BFD state. A less likely attack Down through injecting false BFD state. A less likely attack
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].
11. References 12. References
11.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, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. 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, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4271>. 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, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4760>. 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,
<http://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, DOI 10.17487/RFC5881, June 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5881>. 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, DOI 10.17487/RFC7947, September 2016, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7947>. editor.org/info/rfc7947>.
11.2. Informative References 12.2. Informative References
[I-D.chen-bfd-unsolicited]
Chen, E., Shen, N., and R. Raszuk, "Unsolicited BFD for
Sessionless Applications", draft-chen-bfd-unsolicited-02
(work in progress), January 2018.
[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,
<http://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<https://www.rfc-editor.org/info/rfc7880>.
Appendix A. Summary of Document Changes Appendix A. Summary of Document Changes
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.
Appendix B. Other Forms of Connectity Checks
RFC 5880/5881 BFD is a well-deployed feature. For this reason, it
was chosen as the connectivity check utilized for nexthop
reachability by this document. As other forms of BFD become more
widely deployed, they may also be utilized to provide the
connectivity check functionality.
Examples of other such BFD mechanisms include:
o Seamless BFD [RFC7880]
o Unsolicited BFD for Sessionless Applications
[I-D.chen-bfd-unsolicited]
Implementations MUST support RFC 5880/5881 BFD to be compliant with
this specification. Implementations MAY support other forms of
connectivity check, including those mechanisms listed above, so long
as they provide the ability to fall-back to RFC 5880/5881 BFD.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
US US
Email: randy@psg.com Email: randy@psg.com
skipping to change at page 12, line 4 skipping to change at page 12, line 35
Email: randy@psg.com Email: randy@psg.com
Jeffrey Haas Jeffrey Haas
Juniper Networks, Inc. Juniper Networks, Inc.
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: jhaas@juniper.net Email: jhaas@juniper.net
John G. Scudder John G. Scudder
Juniper Networks, Inc. Juniper Networks, Inc.
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: jgs@juniper.net Email: jgs@juniper.net
Arnold Nipper Arnold Nipper
DE-CIX Management GmbH DE-CIX Management GmbH
Lichtstrasse 43i Lichtstrasse 43i
Cologne 50825 Cologne 50825
Germany Germany
Email: arnold.nipper@de-cix.net Email: arnold.nipper@de-cix.net
Thomas King Christoph Dietzel
DE-CIX Management GmbH DE-CIX Management GmbH
Lichtstrasse 43i Lichtstrasse 43i
Cologne 50825 Cologne 50825
Germany Germany
Email: thomas.king@de-cix.net Email: christoph.dietzel@de-cix.net
 End of changes. 28 change blocks. 
32 lines changed or deleted 69 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/