< draft-xu-idr-neighbor-autodiscovery-01.txt		draft-xu-idr-neighbor-autodiscovery-02.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: September 13, 2017 J. Tantsura		Expires: January 4, 2018 J. Tantsura
	Individual		Individual
	March 12, 2017		July 3, 2017
	BGP Neighbor Autodiscovery		BGP Neighbor Autodiscovery
	draft-xu-idr-neighbor-autodiscovery-01		draft-xu-idr-neighbor-autodiscovery-02
	Abstract		Abstract
	BGP has been used as the routing protocol in many hyper-scale data		BGP has been used as the routing protocol in many hyper-scale data
	centers. This document proposes a BGP neighbor autodiscovery		centers. This document proposes a BGP neighbor autodiscovery
	mechanism which can be used to simplify the BGP deployment greatly.		mechanism that greatly simplifies BGP deployments. This mechanism is
	This mechanism is very useful for those hyper-scale data centers		very useful for those hyper-scale data centers where BGP is used as
	where BGP is used as the routing protocol.		the 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 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 September 13, 2017.		This Internet-Draft will expire on January 4, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . 7		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 routing protocol instead of IGP in many
	hyper-scale data centers [RFC7938]. Furthermore, there is an attempt		hyper-scale data centers [RFC7938]. Furthermore, there is an ongoing
	to leverages BGP Link-State distribution and the Shortest Path First		effort to leverages BGP Link-State distribution and the Shortest Path
	algorithm similar to Internal Gateway Protocols (IGPs) such as OSPF		First algorithm similar to Internal Gateway Protocols (IGPs) such as
	[I-D.keyupate-idr-bgp-spf]. In a word, there is a strong motivation		OSPF [I-D.keyupate-idr-bgp-spf]. In a word, there is a strong
	to replace IGP by BGP in hyper-scale data centers.		motivation to replace IGP's by BGP in hyper-scale data centers.
	However, BGP is not good as IGP from the perspective of deployment		However, BGP is not good as an IGP from the perspective of deployment
	automation and simplicity. For instance, the IP address and		automation and simplicity. For instance, the IP address and the
	Autonomous System Number (ASN) of each BGP neighbor have to be		Autonomous System Number (ASN) of each and every BGP neighbor have to
	manually configured on BGP routers although these BGP peers are		be manually configured on BGP routers although these BGP peers are
	directly connected. In addition, for those directly connected BGP		directly connected. In addition, for those directly connected BGP
	routers, it's usually not ideal to establish BGP sessions over their		routers, it's usually not ideal to establish BGP sessions over their
	directly connected interface addresses due to the following reasons:		directly connected interface addresses due to the following reasons:
	1) it's not convient to do trouble-shooting; 2) the BGP update volume		1) it's not convient to do trouble-shooting; 2) the BGP update volume
	is unnecessarily increased when there are multiple physical links		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 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 HELLO messages. The		through the exchange of the to-be-defined BGP messages. The BGP
	BGP session establishment process as defined in [RFC4271] is		session establishment process as defined in [RFC4271] is triggered
	triggered once directly connected BGP neighbors are discovered from		once directly connected BGP neighbors are discovered from one
	one another. Note that the BGP session should be established over		another. Note that the BGP session should be established over the
	the discovered loopback address of the BGP neighbor. In addition, to		discovered loopback address of the BGP neighbor. In addition, to
	elimnate the need of configing static routes or enabling IGP for the		elimnate the need of configuring static routes or enabling IGP for
	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 dymatically created once the BGP		neighbor's loopback addresses are dynatically instantiated once the
	neighbor has been discovered. The administritive distance of such		BGP neighbor has been discovered. The administritive distance of
	type of routes MUST be smaller than their equivalents which are		such type of routes MUST be smaller than their equivalents that are
	learnt via the normal BGP update messages . Otherwise, circular		learnt by the regular BGP update messages . Otherwise, circular
	dependency problem would occur once these loopback addresses are		dependency would occur once these loopback addresses are advertised
	advertised via the normal BGP update messages as well.		via the regular BGP updates.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		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].
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	exiting BGP messages. However, the HELLO message MUST sent as UDP		exiting BGP messages. However, the HELLO message MUST sent as UDP
	packets addressed to the to-be-assigned BGP discovery port (179 is		packets addressed to the to-be-assigned BGP discovery port (179 is
	the suggested port value) for the "all routers on this subnet" group		the suggested port value) for the "all routers on this subnet" group
	multicast address (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in		multicast address (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in
	the IPv6 case). The IP source address is set to the address of the		the IPv6 case). The IP source address is set to the address of the
	interface over which the message is sent out.		interface over which the message is sent out.
	In addition to the fixed-size BGP header, the HELLO message contains		In addition to the fixed-size BGP header, the HELLO message contains
	the following fields:		the following fields:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version | Hold Time | Message Length |		| Version | Hold Time | Message Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLVs |		| AS number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: BGP Hello Message		| TLVs |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 1: BGP Hello Message
	Version: This 1-octet unsigned integer indicates the protocol		Version: This 1-octet unsigned integer indicates the protocol
	version number of the message. The current BGP version number is		version number of the message. The current BGP version number is
	4.		4.
	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 ASN TLV, Connection Address TLV and other TLVs.		in octects of the Connection Address TLV and other TLVs.
	TLVs: This field contains ASN TLV, Connection Address TLV and		AS number: AS Number of the Hello message sender.
	other TLVs.
	The ASN TLV format is show as follows:		TLVs: This field contains Connection Address TLV and other TLVs.
			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=TBD2 | Length |		| Type=TBD1 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AS Number (2-octet or 4-octet) |		| Accepted ASN List(variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: ASN TLV		Figure 2: Accepted ASN List TLV
	Type: TBD2.		Type: TBD1
	Length: Specifies the length of the Value field in octets.		Length:Specifies the length of the Value field in octets.
	AS Number: This variable-length field indicates the 2-octet or		Accepted ASN-List: This variable-length field contains one or more
	4-octet ASN of the sender.		accepted 4-octet ASNs.
	The Connection Address TLV format is shown as follows:		The Connection Address 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=TBD3 | Length |		| Type=TBD2 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Connection Address (4-octet or 16-octet) |		| Connection Address (4-octet or 16-octet) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Connection Address TLV		Figure 3: Connection Address TLV
	Type: TBD3		Type: TBD2
	Length:Specifies the length of the Value field in octets.		Length:Specifies the length of the Value field in octets.
	Connection Address: This variable-length field indicates the IPv4		Connection Address: This variable-length field indicates the IPv4
	or IPv6 loopback address which is used for establishing BGP		or IPv6 loopback address which is used for establishing BGP
	sessions.		sessions.
	The Router ID TLV format is shown as follows:		The Router ID 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=TBD4 | Length |		| Type=TBD3 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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.
	skipping to change at page 6, line 39 ¶		skipping to change at page 6, line 42 ¶
	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
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank		The authors would like to thank Enke Chen and Nikos Triantafillis for
			their valuable comments and suggestions on this document.
	7. IANA Considerations		7. IANA Considerations
	7.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
	----- ------------------------------------ -------------		----- ------------------------------------ -------------
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 25 ¶
	7.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 ASN 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		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 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.
	9. References		In addition, for the BGP sessions with the automatically discovered
			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
			with TTL being less than 254 MUST be dropped according to [RFC5082].
			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>.		<http://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>.		<http://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-02 (work in progress), December 2016.		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, <http://www.rfc-editor.org/info/rfc5036>.
			[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
			Pignataro, "The Generalized TTL Security Mechanism
			(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
			<http://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>.		<http://www.rfc-editor.org/info/rfc7938>.
	Authors' Addresses		Authors' Addresses
	Xiaohu Xu		Xiaohu Xu
	Huawei		Huawei
	skipping to change at page 8, line 37 ¶		skipping to change at page 9, line 4 ¶
	Xiaohu Xu		Xiaohu Xu
	Huawei		Huawei
	Email: xuxiaohu@huawei.com		Email: xuxiaohu@huawei.com
	Kunyang Bi		Kunyang Bi
	Huawei		Huawei
	Email: bikunyang@huawei.com		Email: bikunyang@huawei.com
	Jeff Tantsura		Jeff Tantsura
	Individual		Individual
	Email: jefftant@gmail.com		Email: jefftant.ietf@gmail.com
End of changes. 31 change blocks.
	58 lines changed or deleted		70 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/