< draft-xu-idr-neighbor-autodiscovery-04.txt   draft-xu-idr-neighbor-autodiscovery-05.txt >
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Alibaba Inc. Internet-Draft Alibaba Inc
Intended status: Standards Track K. Bi Intended status: Standards Track K. Bi
Expires: October 9, 2018 Huawei Expires: October 9, 2018 Huawei
J. Tantsura J. Tantsura
Nuage Networks Nuage Networks
N. Triantafillis N. Triantafillis
Linked-in LinkedIn
K. Talaulikar K. Talaulikar
Cisco Cisco
April 7, 2018 April 7, 2018
BGP Neighbor Autodiscovery BGP Neighbor Autodiscovery
draft-xu-idr-neighbor-autodiscovery-04 draft-xu-idr-neighbor-autodiscovery-05
Abstract Abstract
BGP has been used as the underlay routing protocol in many hyper- BGP has been used as the underlay routing protocol in many hyper-
scale data centers. This document proposes a BGP neighbor scale data centers. This document proposes a BGP neighbor
autodiscovery mechanism that greatly simplifies BGP deployments. autodiscovery mechanism that greatly simplifies BGP deployments.
This mechanism is very useful for those hyper-scale data centers This mechanism is very useful for those hyper-scale data centers
where BGP is used as the underlay routing protocol. where BGP is used as the underlay routing protocol.
Requirements Language Requirements Language
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BGP Hello Message Format . . . . . . . . . . . . . . . . . . 3 3. BGP Hello Message Format . . . . . . . . . . . . . . . . . . 3
4. Hello Message Procedure . . . . . . . . . . . . . . . . . . . 5 4. Hello Message Procedure . . . . . . . . . . . . . . . . . . . 5
5. HELLO Message Error Handling . . . . . . . . . . . . . . . . 6 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 7
8.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 7 7.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7
8.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
BGP has been used as the underlay routing protocol instead of IGP in BGP has been used as the underlay routing protocol instead of IGP in
many hyper-scale data centers [RFC7938]. Furthermore, there is an many hyper-scale data centers [RFC7938]. Furthermore, there is an
ongoing effort to leverage BGP link-state distribution mechanism to ongoing effort to leverage BGP link-state distribution mechanism to
achieve BGP-SPF [I-D.keyupate-lsvr-bgp-spf]. However, BGP is not achieve BGP-SPF [I-D.keyupate-lsvr-bgp-spf]. However, BGP is not
good as an IGP from the perspective of deployment automation and good as an IGP from the perspective of deployment automation and
simplicity. For instance, the IP address and the Autonomous System simplicity. For instance, the IP address and the Autonomous System
Number (ASN) of each and every BGP neighbor have to be manually Number (ASN) of each and every BGP neighbor have to be manually
configured on BGP routers although these BGP peers are directly configured on BGP routers although these BGP peers are directly
connected. In addition, for those directly connected BGP routers, connected. Furthermore, for those BGP routers with multiple physical
it's usually not ideal to establish BGP sessions over their directly links being connected, it's usually not ideal to establish BGP
connected interface addresses due to the following reasons: 1) it's sessions over their directly connected interface addresses because
not convient to do trouble-shooting; 2) the BGP update volume is the BGP update volume would be unnecessarily increased, meanwhile, it
unnecessarily increased when there are multiple physical links may not be suitable to configure those links as a Link Aggregation
between them and those links couldn't be configured as a Link Group (LAG) due to some reasons. As a result, it's more common that
Aggregtion Group (LAG) due to whatever reason (e.g., diffferent link loopback interface addresses of those directly connected BGP peers
type or speed). As a result, it's more common that loopback are used for BGP session establishment purpose. To make those
interface addresses of those directly connected BGP peers are used loopback addresses of directly connected BGP peers reachable from one
for BGP session establishment. To make those loopback addresses of another, either static routes have to be configured or some kind of
directly connected BGP peers reachable from one another, either IGP has to be enabled. The former is not good from the network
static routes have to be configured or some kind of IGP has to be automation perspective while the latter is not good from the network
enabled. The former is not good from the automation perspective simplification perspective (i.e., running less routing protocols).
while the latter is in conflict with the original intention of using
BGP as an IGP.
This draft specifies a BGP neighbor autodiscovery mechanism by This draft specifies a BGP neighbor autodiscovery mechanism by
borrowing some ideas from the Label Distribution Protocol (LDP) borrowing some ideas from the Label Distribution Protocol (LDP)
[RFC5036] . More specifically, directly connected BGP routers could [RFC5036] . More specifically, directly connected BGP routers could
automatically discovery the loopback address and the ASN of one other automatically discovery the loopback address and the ASN of one other
through the exchange of the to-be-defined BGP messages. The BGP through the exchange of the to-be-defined BGP messages. The BGP
session establishment process as defined in [RFC4271] could be session establishment process as defined in [RFC4271] could be
triggered once directly connected BGP neighbors are discovered from triggered once directly connected BGP neighbors are discovered from
one another. Note that the BGP session should be established over one another. Note that the BGP session should be established over
the discovered loopback address of the BGP neighbor. In addition, to the discovered loopback address of the BGP neighbor. In addition, to
elimnate the need of configuring static routes or enabling IGP for eliminate the need of configuring static routes or enabling IGP for
the loopback addresses, a certain type of routes towards the BGP the loopback addresses, a certain type of routes towards the BGP
neighbor's loopback addresses are dynatically instantiated once the neighbor's loopback addresses are dynamically instantiated once the
BGP neighbor has been discovered. The administritive distance of BGP neighbor has been discovered. The administrative distance of
such type of routes MUST be smaller than their equivalents that are such type of routes MUST be smaller than their equivalents that are
learnt by the regular BGP update messages . Otherwise, circular learnt by the regular BGP update messages . Otherwise, circular
dependency would occur once these loopback addresses are advertised dependency would occur once these loopback addresses are advertised
via the regular BGP updates. via the regular BGP updates.
2. Terminology 2. Terminology
This memo makes use of the terms defined in [RFC4271]. This memo makes use of the terms defined in [RFC4271].
3. BGP Hello Message Format 3. BGP Hello Message Format
skipping to change at page 4, line 29 skipping to change at page 4, line 29
Hold Time: Hello hold timer in seconds. Hello Hold Time specifies Hold Time: Hello hold timer in seconds. Hello Hold Time specifies
the time the sending BGP peer will maintain its record of Hellos the time the sending BGP peer will maintain its record of Hellos
from the receiving BGP peer without receipt of another Hello. A from the receiving BGP peer without receipt of another Hello. A
pair of BGP peers negotiates the hold times they use for Hellos pair of BGP peers negotiates the hold times they use for Hellos
from each other. Each proposes a hold time. The hold time used from each other. Each proposes a hold time. The hold time used
is the minimum of the hold times proposed in their Hellos. A is the minimum of the hold times proposed in their Hellos. A
value of 0 means use the default 15 seconds. value of 0 means use the default 15 seconds.
Message Length: This 2-octet unsigned integer specifies the length Message Length: This 2-octet unsigned integer specifies the length
in octects of the Connection Address TLV and other TLVs. in octets of the TLVs field.
AS number: AS Number of the Hello message sender. AS number: AS Number of the Hello message sender.
TLVs: This field contains Connection Address TLV and other TLVs. TLVs: This field contains one or more TLVs as described below.
The Accepted ASN List TLV format is shown as follows: The Accepted ASN List TLV format is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD1 | Length | | Type=TBD1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accepted ASN List(variable) | | Accepted ASN List(variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 14 skipping to change at page 6, line 14
We recommend that the interval between Hello transmissions be at most We recommend that the interval between Hello transmissions be at most
one third of the Hello hold time. one third of the Hello hold time.
A BGP session with a peer has one or more Hello adjacencies. A BGP session with a peer has one or more Hello adjacencies.
A BGP session has multiple Hello adjacencies when a pair of BGP peers A BGP session has multiple Hello adjacencies when a pair of BGP peers
is connected by multiple links that have the same connection address is connected by multiple links that have the same connection address
(e.g., multiple PPP links between a pair of routers). In this (e.g., multiple PPP links between a pair of routers). In this
situation, the Hellos a BGP peer sends on each such link carry the situation, the Hellos a BGP peer sends on each such link carry the
same Connection Address. In addition, to elimnate the need of same Connection Address. In addition, to eliminate the need of
configuring static routes or enabling IGP for advertising the configuring static routes or enabling IGP for advertising the
loopback addresses, a certain type of routes towards the BGP loopback addresses, a certain type of routes towards the BGP
neighbor's loopback addresses (e.g., carried in the Connection neighbor's loopback addresses (e.g., carried in the Connection
Address TLV) could be dymatically created once the BGP neighbor has Address TLV) could be dynamically created once the BGP neighbor has
been discovered. The administritive distance of such type of routes been discovered. The administrative distance of such type of routes
MUST be smaller than their equivalents which are learnt via the MUST be smaller than their equivalents which are learnt via the
normal BGP update messages. Otherwise, circular dependency problem normal BGP update messages. Otherwise, circular dependency problem
would occur once these loopback addresses are advertised via the would occur once these loopback addresses are advertised via the
normal BGP update messages as well. normal BGP update messages as well.
BGP uses the regular receipt of BGP Hellos to indicate a peer's BGP uses the regular receipt of BGP Hellos to indicate a peer's
intent to keep BGP session identified by the Hello. A BGP peer intent to keep BGP session identified by the Hello. A BGP peer
maintains a hold timer with each Hello adjacency that it restarts maintains a hold timer with each Hello adjacency that it restarts
when it receives a Hello that matches the adjacency. If the timer when it receives a Hello that matches the adjacency. If the timer
expires without receipt of a matching Hello from the peer, BGP expires without receipt of a matching Hello from the peer, BGP
concludes that the peer no longer wishes to keep BGP session for that concludes that the peer no longer wishes to keep BGP session for that
link or that the peer has failed. The BGP peer then deletes the link or that the peer has failed. The BGP peer then deletes the
Hello adjacency. When the last Hello adjacency for an BGP session is Hello adjacency. The route towards the BGP neighbor's loopback
deleted, the BGP peer terminates the BGP session by sending a address that had been dynamically created due to that BGP Hello
Notification message and closing the transport connection. adjacency SHOULD be deleted accordingly. When the last Hello
Meanwhile, the routes towards the BGP neighbor's loopback addresses adjacency for an BGP session is deleted, the BGP peer terminates the
that had been dynamically created due to the BGP Hello adjacency BGP session and closing the transport connection.
SHOULD be deleted accordingly.
5. HELLO Message Error Handling
TBD
6. Contributors 5. Contributors
Satya Mohanty Satya Mohanty
Cisco Cisco
Email: satyamoh@cisco.com Email: satyamoh@cisco.com
7. Acknowledgements 6. Acknowledgements
The authors would like to thank Enke Chen for his valuable comments The authors would like to thank Enke Chen for his valuable comments
and suggestions on this document. and suggestions on this document.
8. IANA Considerations 7. IANA Considerations
8.1. BGP Hello Message 7.1. BGP Hello Message
This document requests IANA to allocate a new UDP port for BGP Hello This document requests IANA to allocate a new UDP port for BGP Hello
message. message.
Value TLV Name Reference Value TLV Name Reference
----- ------------------------------------ ------------- ----- ------------------------------------ -------------
Service Name: BGP-HELLO Service Name: BGP-HELLO
Transport Protocol(s): UDP Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>. Contact: IETF Chair <chair@ietf.org>.
Description: BGP Hello Message. Description: BGP Hello Message.
Reference: This document -- draft-xu-idr-neighbor-autodiscovery. Reference: This document -- draft-xu-idr-neighbor-autodiscovery.
Port Number: TBD1 (179 is the suggested value) -- To be assigned by IANA. Port Number: TBD1 (179 is the suggested value) -- To be assigned by IANA.
8.2. TLVs of BGP Hello Message 7.2. TLVs of BGP Hello Message
This document requests IANA to create a new registry "TLVs of BGP This document requests IANA to create a new registry "TLVs of BGP
Hello Message" with the following registration procedure: Hello Message" with the following registration procedure:
Registry Name: TLVs of BGP Hello Message. Registry Name: TLVs of BGP Hello Message.
Value TLV Name Reference Value TLV Name Reference
------- ------------------------------------------ ------------- ------- ------------------------------------------ -------------
0 Reserved This document 0 Reserved This document
1 Accepted ASN List This document 1 Accepted ASN List This document
2 Connection Address This document 2 Connection Address This document
3 Router ID This document 3 Router ID This document
4-65500 Unassigned 4-65500 Unassigned
65501-65534 Experimental This document 65501-65534 Experimental This document
65535 Reserved This document 65535 Reserved This document
9. Security Considerations 8. Security Considerations
For security purposes, BGP speakers usually only accept TCP For security purposes, BGP speakers usually only accept TCP
connection attempts to port 179 from the specified BGP peers or those connection attempts to port 179 from the specified BGP peers or those
within the configured address range. With the BGP auto-discovery within the configured address range. With the BGP neighbor auto-
mechanism, it's configurable to enable or disable sending/receiving discovery mechanism, it's configurable to enable or disable sending/
BGP hello messages on the per-interface basis and BGP hello messages receiving BGP hello messages on the per-interface basis and BGP hello
are only exchanged between physically connected peers that are messages are only exchanged between physically connected peers that
trustworthy. Therefore, the BGP auto-discovery mechanism doesn't are trustworthy. Therefore, the BGP neighbor auto-discovery
introduce additional security risks associated with BGP. mechanism doesn't introduce additional security risks associated with
BGP.
In addition, for the BGP sessions with the automatically discovered In addition, for the BGP sessions with the automatically discovered
peers via the BGP hello messages, the TTL of the TCP/BGP messages peers via the BGP hello messages, the TTL of the TCP/BGP messages
(dest port=179) MUST be set to 255. Any received TCP/BGP message (dest port=179) MUST be set to 255. Any received TCP/BGP message
with TTL being less than 254 MUST be dropped according to [RFC5082]. with TTL being less than 254 MUST be dropped according to [RFC5082].
10. References 9. References
10.1. Normative References 9.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-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, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 8, line 41 skipping to change at page 8, line 36
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>. <https://www.rfc-editor.org/info/rfc5082>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
10.2. Informative References 9.2. Informative References
[I-D.keyupate-lsvr-bgp-spf] [I-D.keyupate-lsvr-bgp-spf]
Patel, K., Lindem, A., Zandi, S., and W. Henderickx, Patel, K., Lindem, A., Zandi, S., and W. Henderickx,
"Shortest Path Routing Extensions for BGP Protocol", "Shortest Path Routing Extensions for BGP Protocol",
draft-keyupate-lsvr-bgp-spf-00 (work in progress), March draft-keyupate-lsvr-bgp-spf-00 (work in progress), March
2018. 2018.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938, BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016, DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>. <https://www.rfc-editor.org/info/rfc7938>.
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
Alibaba Inc. Alibaba Inc
Email: xiaohu.xxh@alibaba-inc.com Email: xiaohu.xxh@alibaba-inc.com
Kunyang Bi Kunyang Bi
Huawei Huawei
Email: bikunyang@huawei.com Email: bikunyang@huawei.com
Jeff Tantsura Jeff Tantsura
Nuage Networks Nuage Networks
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Nikos Triantafillis Nikos Triantafillis
Linked-in LinkedIn
Fax: Nikos Triantafillis<nikos@linkedin.com> Email: nikos@linkedin.com
Ketan Talaulikar Ketan Talaulikar
Cisco Cisco
Email: ketant@cisco.com Email: ketant@cisco.com
 End of changes. 25 change blocks. 
64 lines changed or deleted 57 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/