< draft-xu-idr-neighbor-autodiscovery-02.txt		draft-xu-idr-neighbor-autodiscovery-03.txt >
	Network Working Group X. Xu		Network Working Group X. Xu
	Internet-Draft K. Bi		Internet-Draft K. Bi
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: January 4, 2018 J. Tantsura		Expires: July 6, 2018 J. Tantsura
	Individual		Individual
	July 3, 2017		January 2, 2018
	BGP Neighbor Autodiscovery		BGP Neighbor Autodiscovery
	draft-xu-idr-neighbor-autodiscovery-02		draft-xu-idr-neighbor-autodiscovery-03
	Abstract		Abstract
	BGP has been used as the routing protocol in many hyper-scale data		BGP has been used as the underlay routing protocol in many hyper-
	centers. This document proposes a BGP neighbor autodiscovery		scale data centers. This document proposes a BGP neighbor
	mechanism that greatly simplifies BGP deployments. This mechanism is		autodiscovery mechanism that greatly simplifies BGP deployments.
	very useful for those hyper-scale data centers where BGP is used as		This mechanism is very useful for those hyper-scale data centers
	the routing protocol.		where BGP is used as the underlay routing protocol.
	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 January 4, 2018.		This Internet-Draft will expire on July 6, 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		(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
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	7.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 6		7.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 6
	7.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7		7.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	BGP has been used as the routing protocol instead of IGP in many		BGP has been used as the underlay routing protocol instead of IGP in
	hyper-scale data centers [RFC7938]. Furthermore, there is an ongoing		many hyper-scale data centers [RFC7938]. Furthermore, there is an
	effort to leverages BGP Link-State distribution and the Shortest Path		ongoing effort to leverage BGP link-state distribution mechanism to
	First algorithm similar to Internal Gateway Protocols (IGPs) such as		achieve BGP-SPF [I-D.keyupate-idr-bgp-spf]. However, BGP is not good
	OSPF [I-D.keyupate-idr-bgp-spf]. In a word, there is a strong		as an IGP from the perspective of deployment automation and
	motivation to replace IGP's by BGP in hyper-scale data centers.		simplicity. For instance, the IP address and the Autonomous System
			Number (ASN) of each and every BGP neighbor have to be manually
	However, BGP is not good as an IGP from the perspective of deployment		configured on BGP routers although these BGP peers are directly
	automation and simplicity. For instance, the IP address and the		connected. In addition, for those directly connected BGP routers,
	Autonomous System Number (ASN) of each and every BGP neighbor have to		it's usually not ideal to establish BGP sessions over their directly
	be manually configured on BGP routers although these BGP peers are		connected interface addresses due to the following reasons: 1) it's
	directly connected. In addition, for those directly connected BGP		not convient to do trouble-shooting; 2) the BGP update volume is
	routers, it's usually not ideal to establish BGP sessions over their		unnecessarily increased when there are multiple physical links
	directly connected interface addresses due to the following reasons:
	1) it's not convient to do trouble-shooting; 2) the BGP update volume
	is unnecessarily increased when there are multiple physical links
	between them and those links couldn't be configured as a Link		between them and those links couldn't be configured as a Link
	Aggregtion Group (LAG) due to whatever reason (e.g., diffferent link		Aggregtion Group (LAG) due to whatever reason (e.g., diffferent link
	type or speed). As a result, it's more common that loopback		type or speed). As a result, it's more common that loopback
	interface addresses of those directly connected BGP peers are used		interface addresses of those directly connected BGP peers are used
	for BGP session establishment. To make those loopback addresses of		for BGP session establishment. To make those loopback addresses of
	directly connected BGP peers reachable from one another, either		directly connected BGP peers reachable from one another, either
	static routes have to be configured or some kind of IGP has to be		static routes have to be configured or some kind of IGP has to be
	enabled. The former is not good from the automation perspective		enabled. The former is not good from the automation perspective
	while the latter is in conflict with the original intention of using		while the latter is in conflict with the original intention of using
	BGP as an IGP.		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] is triggered		session establishment process as defined in [RFC4271] could be
	once directly connected BGP neighbors are discovered from one		triggered once directly connected BGP neighbors are discovered from
	another. Note that the BGP session should be established over the		one another. Note that the BGP session should be established over
	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		elimnate 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 dynatically instantiated once the
	BGP neighbor has been discovered. The administritive distance of		BGP neighbor has been discovered. The administritive 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.
	1.1. Requirements Language		1.1. Requirements Language
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 41 ¶
	| Router ID (4-octet or 16-octet) |		| Router ID (4-octet or 16-octet) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Router ID TLV		Figure 4: Router ID TLV
	Type: TBD3		Type: TBD3
	Length:Specifies the length of the Value field in octets and it's		Length:Specifies the length of the Value field in octets and it's
	set to 4 for the IPv4-address-formatted BGP Router ID.		set to 4 for the IPv4-address-formatted BGP Router ID.
	Router ID: This variable-length field indicates the BGP router ID		Router ID: This variable-length field indicates the BGP router ID
	which is used for performing the BGP-SPF algorithm as described in		which could be used for performing the BGP-SPF algorithm as
	[I-D.keyupate-idr-bgp-spf].		described in [I-D.keyupate-idr-bgp-spf].
	4. Hello Message Procedure		4. Hello Message Procedure
	A BGP peer receiving Hellos from another peer maintains a Hello		A BGP peer receiving Hellos from another peer maintains a Hello
	adjacency corresponding to the Hellos. The peer maintains a hold		adjacency corresponding to the Hellos. The peer maintains a hold
	timer with the Hello adjacency, which it restarts whenever it		timer with the Hello adjacency, which it restarts whenever it
	receives a Hello that matches the Hello adjacency. If the hold timer		receives a Hello that matches the Hello adjacency. If the hold timer
	for a Hello adjacency expires the peer discards the Hello adjacency.		for a Hello adjacency expires the peer discards the Hello adjacency.
	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
	for example, 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 elimnate the need of
	configing static routes or enabling IGP for the loopback addresses, a		configuring static routes or enabling IGP for advertising the
	certain type of routes towards the BGP neighbor's loopback addresses		loopback addresses, a certain type of routes towards the BGP
	(e.g., carried in the Connection Address TLV) are dymatically created		neighbor's loopback addresses (e.g., carried in the Connection
	once the BGP neighbor has been discovered. The administritive		Address TLV) could be dymatically created once the BGP neighbor has
	distance of such type of routes MUST be smaller than their		been discovered. The administritive distance of such type of routes
	equivalents which are learnt via the normal BGP update messages.		MUST be smaller than their equivalents which are learnt via the
	Otherwise, circular dependency problem would occur once these		normal BGP update messages. Otherwise, circular dependency problem
	loopback addresses are advertised via the normal BGP update messages		would occur once these loopback addresses are advertised via the
	as well.		normal BGP update messages as well.
	BGP uses the regular receipt of BGP Discovery Hellos to indicate a		BGP uses the regular receipt of BGP Hellos to indicate a peer's
	peer's intent to keep BGP session identified by the Hello. A BGP		intent to keep BGP session identified by the Hello. A BGP peer
	peer maintains a hold timer with each Hello adjacency that it		maintains a hold timer with each Hello adjacency that it restarts
	restarts when it receives a Hello that matches the adjacency. If the		when it receives a Hello that matches the adjacency. If the timer
	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. When the last Hello adjacency for an BGP session is
	deleted, the BGP peer terminates the BGP session by sending a		deleted, the BGP peer terminates the BGP session by sending a
	Notification message and closing the transport connection.		Notification message and closing the transport connection.
	5. HELLO Message Error Handling		5. HELLO Message Error Handling
	TBD		TBD
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 9 ¶
	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].
	9. References		9. References
	9.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,
	<http://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,
	<http://www.rfc-editor.org/info/rfc4271>.		<https://www.rfc-editor.org/info/rfc4271>.
	9.2. Informative References		9.2. Informative References
	[I-D.keyupate-idr-bgp-spf]		[I-D.keyupate-idr-bgp-spf]
	Patel, K., Lindem, A., Zandi, S., and G. Velde, "Shortest		Patel, K., Lindem, A., Zandi, S., and G. Velde, "Shortest
	Path Routing Extensions for BGP Protocol", draft-keyupate-		Path Routing Extensions for BGP Protocol", draft-keyupate-
	idr-bgp-spf-03 (work in progress), June 2017.		idr-bgp-spf-03 (work in progress), June 2017.
	[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,		"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
	October 2007, <http://www.rfc-editor.org/info/rfc5036>.		October 2007, <https://www.rfc-editor.org/info/rfc5036>.
	[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.		[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
	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,
	<http://www.rfc-editor.org/info/rfc5082>.		<https://www.rfc-editor.org/info/rfc5082>.
	[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,
	<http://www.rfc-editor.org/info/rfc7938>.		<https://www.rfc-editor.org/info/rfc7938>.
	Authors' Addresses		Authors' Addresses
	Xiaohu Xu		Xiaohu Xu
	Huawei		Huawei
	Email: xuxiaohu@huawei.com		Email: xuxh.mail@gmail.com
	Kunyang Bi		Kunyang Bi
	Huawei		Huawei
	Email: bikunyang@huawei.com		Email: bikunyang@huawei.com
	Jeff Tantsura		Jeff Tantsura
	Individual		Individual
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
End of changes. 20 change blocks.
	56 lines changed or deleted		53 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/