< draft-xu-idr-neighbor-autodiscovery-03.txt		draft-xu-idr-neighbor-autodiscovery-04.txt >
	Network Working Group X. Xu		Network Working Group X. Xu
	Internet-Draft K. Bi		Internet-Draft Alibaba Inc.
	Intended status: Standards Track Huawei		Intended status: Standards Track K. Bi
	Expires: July 6, 2018 J. Tantsura		Expires: October 9, 2018 Huawei
	Individual		J. Tantsura
	January 2, 2018		Nuage Networks
			N. Triantafillis
			Linked-in
			K. Talaulikar
			Cisco
			April 7, 2018
	BGP Neighbor Autodiscovery		BGP Neighbor Autodiscovery
	draft-xu-idr-neighbor-autodiscovery-03		draft-xu-idr-neighbor-autodiscovery-04
	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
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC2119].
	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 https://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 July 6, 2018.		This Internet-Draft will expire on October 9, 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
	(https://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
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	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. HELLO Message Error Handling . . . . . . . . . . . . . . . . 6
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 6		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7		8.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		10.2. Informative References . . . . . . . . . . . . . . . . . 8
			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-idr-bgp-spf]. However, BGP is not good		achieve BGP-SPF [I-D.keyupate-lsvr-bgp-spf]. However, BGP is not
	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. In addition, for those directly connected BGP routers,
	it's usually not ideal to establish BGP sessions over their directly		it's usually not ideal to establish BGP sessions over their directly
	connected interface addresses due to the following reasons: 1) it's		connected interface addresses due to the following reasons: 1) it's
	not convient to do trouble-shooting; 2) the BGP update volume is		not convient to do trouble-shooting; 2) the BGP update volume is
	unnecessarily increased when there are multiple physical links		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
	skipping to change at page 3, line 23 ¶		skipping to change at page 3, line 33 ¶
	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		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
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	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
	To automatically discover directly connected BGP neighbors, a BGP		To automatically discover directly connected BGP neighbors, a BGP
	router periodically sends BGP HELLO messages out those interfaces on		router periodically sends BGP HELLO messages out those interfaces on
	which BGP neighbor autodiscovery are enabled. The BGP HELLO message		which BGP neighbor autodiscovery are enabled. The BGP HELLO message
	is a new BGP message which has the same fixed-size BGP header as the		is a new BGP message which has the same fixed-size BGP header as the
	skipping to change at page 5, line 42 ¶		skipping to change at page 5, line 42 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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 could be used for performing the BGP-SPF algorithm as		which could be used for performing the BGP-SPF algorithm as
	described in [I-D.keyupate-idr-bgp-spf].		described in [I-D.keyupate-lsvr-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
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 35 ¶
	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. 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.
			Meanwhile, the routes towards the BGP neighbor's loopback addresses
			that had been dynamically created due to the BGP Hello adjacency
			SHOULD be deleted accordingly.
	5. HELLO Message Error Handling		5. HELLO Message Error Handling
	TBD		TBD
	6. Acknowledgements		6. Contributors
	The authors would like to thank Enke Chen and Nikos Triantafillis for		Satya Mohanty
	their valuable comments and suggestions on this document.		Cisco
			Email: satyamoh@cisco.com
	7. IANA Considerations		7. Acknowledgements
	7.1. BGP Hello Message		The authors would like to thank Enke Chen for his valuable comments
			and suggestions on this document.
			8. IANA Considerations
			8.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.
	7.2. TLVs of BGP Hello Message		8.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
	8. Security Considerations		9. 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 auto-discovery
	mechanism, it's configurable to enable or disable sending/receiving		mechanism, it's configurable to enable or disable sending/receiving
	BGP hello messages on the per-interface basis and BGP hello messages		BGP hello messages on the per-interface basis and BGP hello messages
	are only exchanged between physically connected peers that are		are only exchanged between physically connected peers that are
	trustworthy. Therefore, the BGP auto-discovery mechanism doesn't		trustworthy. Therefore, the BGP auto-discovery mechanism doesn't
	introduce additional security risks associated with BGP.		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].
	9. References		10. References
	9.1. Normative References
			10.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>.
	9.2. Informative References
	[I-D.keyupate-idr-bgp-spf]
	Patel, K., Lindem, A., Zandi, S., and G. Velde, "Shortest
	Path Routing Extensions for BGP Protocol", draft-keyupate-
	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, <https://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,
	<https://www.rfc-editor.org/info/rfc5082>.		<https://www.rfc-editor.org/info/rfc5082>.
			[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
			Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
			Explicit Replication (BIER)", RFC 8279,
			DOI 10.17487/RFC8279, November 2017,
			<https://www.rfc-editor.org/info/rfc8279>.
			10.2. Informative References
			[I-D.keyupate-lsvr-bgp-spf]
			Patel, K., Lindem, A., Zandi, S., and W. Henderickx,
			"Shortest Path Routing Extensions for BGP Protocol",
			draft-keyupate-lsvr-bgp-spf-00 (work in progress), March
			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
	Huawei		Alibaba Inc.
	Email: xuxh.mail@gmail.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
	Individual		Nuage Networks
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
			Nikos Triantafillis
			Linked-in
			Fax: Nikos Triantafillis<nikos@linkedin.com>
			Ketan Talaulikar
			Cisco
			Email: ketant@cisco.com
End of changes. 24 change blocks.
	45 lines changed or deleted		68 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/