< draft-acee-idr-lldp-peer-discovery-00.txt		draft-acee-idr-lldp-peer-discovery-01.txt >
	Network Working Group A. Lindem		Network Working Group A. Lindem
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track K. Patel		Intended status: Standards Track K. Patel
	Expires: September 14, 2017 Arrcus, Inc		Expires: January 4, 2018 Arrcus, Inc
	S. Zandi		S. Zandi
	LinkedIn		LinkedIn
	March 13, 2017		J. Haas
			Juniper Networks, Inc
			X. Xu
			Huawei
			July 3, 2017
	BGP Logical Link Discovery Protocol (LLDP) Peer Discovery		BGP Logical Link Discovery Protocol (LLDP) Peer Discovery
	draft-acee-idr-lldp-peer-discovery-00.txt		draft-acee-idr-lldp-peer-discovery-01.txt
	Abstract		Abstract
	Link Layer Discovery Protocol (LLDP) or IEEE 802.1AB is implemented		Link Layer Discovery Protocol (LLDP) or IEEE 802.1AB is implemented
	in networking equipment from many vendors. It is natural for IETF		in networking equipment from many vendors. It is natural for IETF
	protocols to avail this protocol for simple discovery tasks. This		protocols to avail this protocol for simple discovery tasks. This
	document describes how BGP would use LLDP to discover directly		document describes how BGP would use LLDP to discover directly
	connected and 2-hop peers when peering is based on loopback		connected and 2-hop peers when peering is based on loopback
	addresses.		addresses.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 42 ¶
	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 14, 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
	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 Notation . . . . . . . . . . . . . . . . . . 2		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
	2. LLDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3		2. LLDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. LLDP Organizationally Specific TLV Format . . . . . . . . 3		2.1. LLDP Organizationally Specific TLV Format . . . . . . . . 3
	2.2. Local IP Address OS-TLV Format . . . . . . . . . . . . . 4		2.2. BGP Config OS-TLV Format . . . . . . . . . . . . . . . . 4
	2.3. BGP Config OS-TLV Format . . . . . . . . . . . . . . . . 5		2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV . . . . . 5
	2.3.1. BGP Config OS-TLV - Peering Address Sub-TLV . . . . . 6		2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV . . . . . . 6
	2.3.2. BGP Config OS-TLV - BGP Local AS Sub-TLV . . . . . . 7		2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV . . . . . 7
	2.3.3. BGP Config OS-TLV - BGP Capabilities Sub-TLV . . . . 8		2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV . . . . 8
	3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 9		2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV 9
	3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 9		2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV . . . . . . . . 10
	3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 9		3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 11
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 11
	5.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	5.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 11		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 13
	6.1. Normative References . . . . . . . . . . . . . . . . . . 11		5.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 13
	6.2. Informative References . . . . . . . . . . . . . . . . . 12		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . 14
			7.2. Informative References . . . . . . . . . . . . . . . . . 15
			Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	Link Layer Discovery Protocol (LLDP) [LLDP] or IEEE 802.1AB is		Link Layer Discovery Protocol (LLDP) [LLDP] or IEEE 802.1AB is
	implemented in networking equipment from many vendors. It is natural		implemented in networking equipment from many vendors. It is natural
	for IETF protocols to avail this protocol for simple discovery tasks.		for IETF protocols to avail this protocol for simple discovery tasks.
	This document describes how BGP [BGP] would use LLDP to discover		This document describes how BGP [BGP] would use LLDP to discover
	directly connected and 2-hop peers when peering is based on loopback		directly connected and 2-hop peers when peering is based on loopback
	addresses.		addresses.
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 32 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OUI Continued | Subtype | Value |		| OUI Continued | Subtype | Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... (Up to 507 Octets) |		| ... (Up to 507 Octets) |
	Type Organizationally Specific TLV type value, 127.		Type Organizationally Specific TLV type value, 127.
	Length The length of the remainder of the TLV.		Length The length of the remainder of the TLV.
	OUI Organizationally unique identifier for the		OUI Organizationally unique identifier for the
	organization's OUI. For the IANA, this is value is		organization's OUI. For IANA, this is value is
	00-00-5E as specified in [RFC7042].		00-00-5E as specified in [IEEE-802-IANA].
	Subtype IETF specific subtype		Subtype IETF specific subtype
	Value Value for organizationally specific TLV. The Length of		Value Value for organizationally specific TLV. The Length of
	the value is 4 octets less than the TLV length.		the value is 4 octets less than the TLV length.
	LLDP Organizationally Specific TLV		LLDP Organizationally Specific TLV
	The OUI for the IANA was allocated in section 1.4 of [IEEE-802-IANA].		The OUI for IANA was allocated in section 1.4 of [IEEE-802-IANA].
	This document requests creation of a registry for IETF specific sub-		This document requests creation of a registry for IETF specific sub-
	types for LLDP Organizationally Specific TLVs.		types for LLDP Organizationally Specific TLVs.
	2.2. Local IP Address OS-TLV Format		2.2. BGP Config OS-TLV Format
	The Local IP Address Organizationally Specific TLV will be used to
	advertise IPv4 or IPv6 addresses that are local to the link. A
	network device can advertise multiple Local IP Address OS-TLVs in its
	LLDP PDU and is only constrained by the length of the PDU. Normally
	a network device would only advertise its own local address but
	advertising addresses local to the link for another networking device
	is not specifically disallowed. The format is shown below.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (127) | 8 or 20 | OUI (3 Octets) 00-00-5E |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OUI Continued | 1 | Address Family| IPv4/IPv6 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4/IPv6 Address | IPv6 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Length The length will be 8 for IPv4 addresses or 20 for IPv6
	addresses.
	Subtype IETF specific subtype for a Local IP address for the
	link. The value shall be 1.
	Address IANA Address family (1 for IPv4 or 2 for IPv6)
	Family
	Value Local IPv4 or IPv6 Address.
	2.3. BGP Config OS-TLV Format
	The BGP Config Organizationally Specific TLV (OS-TLV) will be used to		The BGP Config Organizationally Specific TLV (OS-TLV) will be used to
	advertise BGP configuration information. The configuration		advertise BGP configuration information. The configuration
	information will be composed of Sub-TLVs. Since the length is		information will be composed of Sub-TLVs. Since the length is
	limited to 507 octets, multiple BGP Config OS-TLVs could be included		limited to 507 octets, multiple BGP Config OS-TLVs could be included
	in a single LLDP advertisement.		in a single LLDP advertisement.
	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 (127) | Length | OUI (3 Octets) 00-00-5E |		| Type (127) | Length | OUI (3 Octets) 00-00-5E |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|OUI Continued | 2 | BGP Config Sub-TLVs ... |		|OUI Continued | 1 | BGP Config Sub-TLVs ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... (Up to 507 Octets) |		| ... (Up to 507 Octets) |
	Length The length of the BGP TLV.		Length The length of the BGP TLV.
	Subtype IETF specific subtype for BGP Config OS-TLV. The		Subtype IETF specific subtype for BGP Config OS-TLV. The
	value shall be 2.		value shall be 1.
	Value BGP Config Sub-TLVs each with a 1 byte Type and		Value BGP Config Sub-TLVs each with a 1 byte Type and
	Length. The Length will include solely the value		Length. The Length will include solely the value
	portion of the TLV and not the Type and Length		portion of the TLV and not the Type and Length
	fields themselves.		fields themselves.
	2.3.1. BGP Config OS-TLV - Peering Address Sub-TLV		2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV
	The BGP OS-TLV Peering Address Sub-TLV will be used to advertise the		The BGP OS-TLV Peering Address Sub-TLV will be used to advertise the
	local IP address used for BGP sessions and the associated address		local IP addresses used for BGP sessions and the associated address
	families. The format of the BGP Peering Address Sub-TLV is shown		families specified by AFI/SAFI tuples. The AFI/SAFI tuple, 0/0,
	below.		indicates to use the associated peering address for all locally
			configured address families without an explicit peering address
			specification. As always, the address families supported for a given
			BGP session will be determined during capabilities negotiation
			[MP-BGP]. It is RECOMMENDED that the wildcard AFI/SAFI be used in
			deployments with fairly homogenous address family usage.
			The format of the BGP Peering Address Sub-TLV is shown below.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type (1) | Length | Address Family| IPv4/IPv6 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ IPv4/IPv6 Peering Address ... ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| AFI | SAFI | o o o
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type The Sub-TLV Type value shall be 1.
			Length The Sub-TLV length in octets will be 4 for IPv4 or 16
			for IPv6 plus 3 times the number of AFI/SAFI tuples.
			Address IANA Address family (1 for IPv4 or 2 for IPv6)
			Family
			Peering An IPv4 address (4 octets) or an IPv6 address (16 octets)
			Address
			AFI/SAFI One or more AFI/SAFI tuples for BGP session using this
			Pairs peering address. The AFI/SAFI tuple, 0/0, is a wildcard
			indicating to attempt negotiation for all AFI/SAFIs.
			2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV
			The BGP Config OS-TLV Local AS Sub-TLV will be used to advertise the
			4-octet local Autonomous System (AS) number(s). For AS transitions,
			a second local AS number may be specified. The format of the BGP
			Local AS Sub-TLV is shown below.
	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 (1) | Length | Address Family| IPv4/IPv6 |		| Type (2) |Length (4 or 8)| Local AS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ IPv4/IPv6 Peering Address ... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AFI | SAFI | o o o		| Local AS | Optional Second Local AS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Optional Second Local AS |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type The Sub-TLV Type value shall be 1.		Type The Sub-TLV Type value shall be 2.
	Length The Sub-TLV length in octets will be 4 for IPv4 or 16		Length The Sub-TLV Length will be 4 or 8 octets.
	for IPv6 plus 3 times the number of AFI/SAFI pairs.
	Address IANA Address family (1 for IPv4 or 2 for IPv6)		Local AS Local Autonomous System (AS)
	Family
	Peering An IPv4 address (4 octets) or an IPv6 address (16		Second Local AS Local Autonomous System (AS)
	Address octet) peering address.
	AFI/SAFI One or more AFI/SAFI pairs for BGP session using this		2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV
	Pairs peering address.
	2.3.2. BGP Config OS-TLV - BGP Local AS Sub-TLV		The BGP Config OS-TLV BGP Identifier Sub-TLV will be used to
			advertise the 4-octet local BGP Identifier. The BGP Identifier is
			used for debugging purposes and possibly to reduce the likelihood of
			BGP connection collisions. The format of the BGP Identifier Sub-TLV
			is shown below.
	The BGP Config OS-TLV Local AS Sub-TLV will be used to advertise the		0 1 2 3
	4-octet local Autonomous System (AS) number. The format of the BGP		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
	Local AS Sub-TLV is shown below.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type (3) | Length (4) | BGP Identifier |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| BGP Identifier |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type The Sub-TLV Type value shall be f32.
			Length The Sub-TLV Length will be 4 octets.
			BGP Identifier Local BGP Identifier (aka, BGP Router ID)
			2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV
			The BGP Config OS-TLV Session Group-ID Sub-TLV is an opaque 4-octet
			value that is used to represent a category of BGP session that is
			supported on the interface. The format of the Session Group-ID Sub-
			TLV is shown below.
	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 (2) | Length (4) | Local AS |		| Type (4) | Length (4) | Session Group-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local AS |		| Session Group-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type The Sub-TLV Type value shall be 2.		Type The Sub-TLV Type value shall be 4.
	Length The Sub-TLV Length will be 4 octets.		Length The Sub-TLV Length will be 4 octets.
	Local AS Local Autonomous System (AS)		Session Group-ID The session group-id used to indicate a
			class or category of BGP session supported on
			the interface.
	2.3.3. BGP Config OS-TLV - BGP Capabilities Sub-TLV		2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV
	The BGP Config OS-TLV Capabilities Sub-TLV will be used to advertise		The BGP Config OS-TLV Session Capabilities Sub-TLV will be used to
	an 8-octet Capabilities field. The capabilities are represented as		advertise an 8-octet Session Capabilities field. The session
	bit flags identifying the supported BGP capabilities. The format of		capabilities are represented as bit flags identifying the supported
	the BGP Capabilities Sub-TLV is shown below.		BGP session capabilities. The format of the BGP Session Capabilities
			Sub-TLV is shown below.
	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 (3) | Length (8) | Capabilities |		| Type (5) | Length (8) | Session Capabilities |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Capabilities |		| Session Capabilities |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Capabilities |		| Session Capabilities |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type The Sub-TLV Type value shall be 3.		Type The Sub-TLV Type value shall be 5.
	Length The Sub-TLV Length will be 8 octets.		Length The Sub-TLV Length will be 8 octets.
	Capabilities Bit fields identify BGP capabilities		Session Bit fields identify BGP session capabilities
			Capabilities
	The BGP Capabilities is an 8-octet bit field. The most significant		The BGP Session Capabilities is an 8-octet bit field. The most
	bit is the first bit (Bit 1) of the Capabilities. The following bits		significant bit is the first bit (Bit 1) of the Session Capabilities.
	are defined:		The following bits are defined:
	Bit 1: This bit indicates that support for TCP MD5		Bit 1: This bit indicates support for TCP MD5
	authentication [TCP-MD5].		authentication [TCP-MD5].
	Bit 2: This bit indicates support for TCP-AO		Bit 2: This bit indicates support for TCP-AO
	authentication [TCP-AO].		authentication [TCP-AO].
	Bit 3: This bit indicates support for Generalized TTL		Bit 3: This bit indicates support for Generalized TTL
	Security Mechanism (GTSM) [GTSM] with a		Security Mechanism (GTSM) [GTSM] with a
	configured TTL range of 254-255.		configured TTL range of 254-255.
	TCP MD5 authentication is described in [TCP-MD5]. The TCP		TCP MD5 authentication is described in [TCP-MD5]. The TCP
	Authentication Option (TCP-AO) is described in [TCP-AO]. The		Authentication Option (TCP-AO) is described in [TCP-AO]. The
	Generalized TTL Security Mechanism (GTSM) is described in [GTSM]. If		Generalized TTL Security Mechanism (GTSM) is described in [GTSM]. If
	both TCP MD5 authentication and TCP-AO authentication are specified		both TCP MD5 authentication and TCP-AO authentication are specified
	and TCP-AO is supported, it will take precedence.		and TCP-AO is supported, it will take precedence.
			2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV
			The BGP Config OS-TLV Key Chain Sub-TLV is a string specifying the
			name for the key chain used for session authentication. Key chains
			[YANG-KEY-CHAIN] are a commonly used for protocol authentication and
			encryption key specification. Given the limited length of all BGP
			configuration information, the key chain name will be limited to 64
			characters and will not include a trailing string delimiter. The
			format of the Session Group-ID Sub-TLV is shown below.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type (6) |Length (1 - 64)| Key Chain Name |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Key Chain Name (Up to 64 Octets) |
			O
			O
			O
			| Key Chain Name |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type The Sub-TLV Type value shall be 6.
			Length The Sub-TLV Length will be 1 - 64 octets.
			Key Chain Name The name of a key chain to be used for
			MD5 or TCP-AO authentication.
	3. BGP LLDP Peer Discovery Operations		3. BGP LLDP Peer Discovery Operations
	The simple use case is to just use the peer address advertised in the		The simple use case is to just use the peer address advertised in the
	LLDP Packet Data Unit (PDU) to establish a 1-hop BGP peer session.		LLDP Packet Data Unit (PDU) to establish a 1-hop BGP peer session.
	This can be used in data centers using BGP as described in [BGP-DC].		This can be used in data centers using BGP as described in [BGP-DC].
	The more complex use case is when a loopback address in advertised as		The use case where a loopback address or other local address is
	the peering address in the LLDP PDU.		advertised as the peering address is also supported. However,
			reachabiliy to a peering address other than the interface address is
			beyond the scope of this document.
	3.1. Advertising BGP Speaker		3.1. Advertising BGP Speaker
	A BGP speaker MAY advertise its BGP peering address in an LLDP PDU		A BGP speaker MAY advertise its BGP peering address in an LLDP PDU
	for a link using the BGP Local Address Sub-TLV of BGP-OS TLV Format.		for a link using the BGP Local Address Sub-TLV of the BGP-OS TLV.
	This can be an IPv4 or IPv6 address local to the link for 1-hop		This can be an IPv4 or IPv6 local address associated with the LLDP
	peering or a loopback address for 2-hop peering.		link for 1-hop peering. For 2-hop peering, it could be a loopback
			address or any other address that is local to the node but not the
			LLDP link. As noted above, reachability to the loopback address is
			beyond the scope of this document.
	Additionally, a BGP speaker MAY advertise one or more local addresses		A BGP speaker MAY advertise its local AS number using the BGP Local
	IPv4 and IPv6 addresses. In the case of 2-hop peering, a local		AS Sub-TLV of the BGP-OS TLV. During AS transitions, a second local
	address on the link can be used as a next-hop for the peering		AS number may be included in the Local AS Sub-TLV. The local BGP
	address. In this manner both the peering address and reachability		identifier may also be advertised using the BGP Identifier Sub-TLV of
	can be discovered.		the BGP-OS TLV. While not specifically required for session
			establishment, the values may be used for validation, trouble-
			shooting, and connection collision avoidance. A BGP speaker may also
			announce a Session Group-ID indicating the class or category of
			session(s) supported and/or mapping to a set of session parameters.
			Additionally, a BGP speaker MAY also announce relevant capabilities
			using BGP Session Capabilities Sub-TLV of the BGP-OS TLV.
	A BGP speaker MAY advertise its local AS number using BGP AS Sub-TLV		If TCP MD5 authentication [TCP-MD5] or TCP Authentication Option
	of BGP-OS TLV format. It may also announce relevant capabilities		(TCP-AO) [TCP-AO] is to be used on the session, the Key Chain Sub-TLV
	using BGP Capabilities Sub-TLV of BGP-OS TLV format.		of the BGP-OS TLV MAY be used to specify the key chain name.
	3.2. Receiving BGP Speaker		3.2. Receiving BGP Speaker
	A BGP speaker configured for LLDP peer discovery will attempt to		A BGP speaker configured for LLDP peer discovery WILL attempt to
	establish peers using the address in the BGP Local Address Sub-TLV of		establish BGP sessions using the address in the BGP Local Address
	BGP-OS TLV format. If the peering address is directly accessible		Sub-TLV of BGP-OS TLV format. If the peering address is directly
	over the link on which the LLDP PDU was received, the BGP speaker		accessible over the link on which the LLDP PDU is received, the BGP
	will attempt to establish a 1-hop BGP session with the peer.		speaker will attempt to establish a 1-hop BGP session with the peer.
	If the received BGP Peering Address is not directly accessible over		If the received BGP Peering Address is not directly accessible over
	the link, the BGP speaker may add a route to the access the BGP peer.		the link, the peer must be reachable for the session to be
	The next-hop for the route MAY be one of the addresses the BGP		established and the mechanisms for establishing reachability are
	speaker has advertised in the Local IP Address OS-TLV. If the BGP		beyond the scope of this specification. If the BGP speaker receives
	speaker receives the same BGP peering address in LLDP PDU on multiple		the same BGP peering address in LLDP PDUs received on multiple links,
	links, it will not establish multiple sessions. Rather a single		it will not establish multiple sessions. Rather, a single 2-hop
	2-hop session will be established. Optionally, ECMP routes are added		session will be established.
	to the BGP peering session over each link on which an LLDP PDU
	containing the same Peering Address is received.
	A BGP speaker MAY receive remote neighbor's local AS number in LLDP		When the deployment of address families is fairly homogenous across
	in BGP AS Sub-TLV of the BGP-OS TLV. A BGP speaker MAY use the		the deployment, the wildcard AFI/SAFI can be utilized to simplify
	received local AS number to perform validation check of AS received		LLDP advertisement. When there is variance in the address families
	in the OPEN message. Furthermore, A BGP speaker MAY receive remote		supported, usage of the wildcard could result in session
	neighbor's capabilities in LLDP in BGP Capabilities Sub-TLV of the		establishment delay due to capabilities negotiation [BGP-CAP].
			A BGP speaker MAY receive a remote neighbor's local AS number(s) in
			an LLDP PDU in the BGP Local AS Sub-TLV of the BGP-OS TLV. A BGP
			speaker MAY use the received local AS number(s) to perform validation
			checking of the AS received in the OPEN message. A BGP speaker MAY
			receive a remote neighbor's BGP Identifier in the BGP Identifier Sub-
			TLV of the BGP-OS TLV. This can be used to avoid connection
			collisions by delaying session establishment if the remote BGP
			Identifier is greater than the receiving speaker's BGP Identifier.
			A BGP speaker MAY receive a Session Group-ID Sub-TLV in the LLDP BGP-
			OS TLV. This Session Group-ID may be used for validation and/or
			mapping the session to a particular set of session parameters. For
			example, the Session Group-ID could be mapped to a spine, leaf, or
			Top-of-Rack (ToR) session in a data center deployment and can be used
			to detect cabling problems when an unexpected Session Group-ID is
			received.
			Additionally, A BGP speaker MAY receive a remote neighbor's
			capabilities in LLDP in the BGP Session Capabilities Sub-TLV of the
	BGP-OS TLV. A BGP speaker MAY use the received capabilities to		BGP-OS TLV. A BGP speaker MAY use the received capabilities to
	ensure appropriate neighbor based configuration is done locally so as		ensure appropriate local neighbor configuration in order to
	to facilitate the session establishment.		facilitate session establishment.
			If TCP MD5 authentication [TCP-MD5]. or TCP Authentication Option
			(TCP-AO) [TCP-AO] is to be used on the session as determined either
			via the Session Capabilities Sub-TLV, Session Group-ID, or local
			policy, the key chain name in the Key Chain Sub-TLV of the BGP-OS TLV
			MAY be used to identify the correct key chain [YANG-KEY-CHAIN].
	4. Security Considerations		4. Security Considerations
	This security considerations for BGP [BGP] apply equally to this		This security considerations for BGP [BGP] apply equally to this
	extension.		extension.
	Additionally, BGP peering address discovery should only be done on		Additionally, BGP peering address discovery should only be done on
	trusted links (e.g., in a data center network) since LLDP packets are		trusted links (e.g., in a data center network) since LLDP packets are
	not authenticated or encrypted [LLDP].		not authenticated or encrypted [LLDP].
	5. IANA Considerations		5. IANA Considerations
	5.1. IANA Assigned LLDP Subtype		5.1. IANA Assigned LLDP Subtype
	IANA is requested to create a registry for IANA assigned subtypes in		IANA is requested to create a registry for IANA assigned subtypes in
	the Organizationally Specific TLV assigned to IANA (OUI of 000-00-53		the Organizationally Specific TLV assigned to IANA (OUI of 000-00-53
	[IEEE-802-IANA]. Assignment is requested for 1 for the Local IP		[IEEE-802-IANA]. Assignment is requested for 1 for the BGP Config
	Address OS-TLV. Assignment is also requested for 2 for the BGP		OS-TLV.
	Config OS-TLV.
	+-------------+-----------------------------------+		+-------------+-----------------------------------+
	| Range | Assignment Policy |		| Range | Assignment Policy |
	+-------------+-----------------------------------+		+-------------+-----------------------------------+
	| 0 | Reserved (not to be assigned) |		| 0 | Reserved (not to be assigned) |
	| | |		| | |
	| 1 | Local IP Address |		| 1 | BGP Configuration |
	| | |
	| 2 | BGP Configuration |
	| | |		| | |
	| 3-127 | Unassigned (IETF Review) |		| 2-127 | Unassigned (IETF Review) |
	| | |		| | |
	| 128-254 | Reserved (Not to be assigned now) |		| 128-254 | Reserved (Not to be assigned now) |
	| | |		| | |
	| 255 | Reserved (not to be assigned) |		| 255 | Reserved (not to be assigned) |
	+-------------+-----------------------------------+		+-------------+-----------------------------------+
	IANA LLDP Organizationally Specific TLV Sub-Types		IANA LLDP Organizationally Specific TLV Sub-Types
	o Types in the range 3-127 are to be assigned subject to IETF		o Types in the range 2-127 are to be assigned subject to IETF
	Review. New values are assigned only through RFCs that have been		Review. New values are assigned only through RFCs that have been
	shepherded through the IESG as AD-Sponsored or IETF WG Documents		shepherded through the IESG as AD-Sponsored or IETF WG Documents
	[IANA-GUIDE].		[IANA-GUIDE].
	o Types in the range 128-254 are reserved and not to be assigned at		o Types in the range 128-254 are reserved and not to be assigned at
	this time. Before any assignments can be made in this range,		this time. Before any assignments can be made in this range,
	there MUST be a Standards Track RFC that specifies IANA		there MUST be a Standards Track RFC that specifies IANA
	Considerations that covers the range being assigned.		Considerations that covers the range being assigned.
	5.2. BGP Config LLDP OS-TLV Sub-TLVs		5.2. BGP Config LLDP OS-TLV Sub-TLVs
	IANA is requested to create a registry for Sub-TLVs of the BGP Config		IANA is requested to create a registry for Sub-TLVs of the BGP Config
	LLDP OS-TLV. Assignment is requested for 1 for the BGP Peering		LLDP OS-TLV. Assignment is requested for 1 for the BGP Peering
	Address Sub-TLV. Assignment is also requested for 2 for the Local AS		Address Sub-TLV. Assignment is also requested for 2 for the Local AS
	Sub-TLV. Additionally, assignment is requested for 3 for the		Sub-TLV. Additionally, assignment is requested for 3 for the BGP
	Capabilities Sub-TLV.		Identifier Sub-TLV, 4 for the BGP Session Group-ID, 5 for the Session
			Capabilities Sub-TLV, and 6 for the Key Chain Name.
	+-------------+-----------------------------------+		+-------------+-----------------------------------+
	| Range | Assignment Policy |		| Range | Assignment Policy |
	+-------------+-----------------------------------+		+-------------+-----------------------------------+
	| 0 | Reserved (not to be assigned) |		| 0 | Reserved (not to be assigned) |
	| | |		| | |
	| 1 | Peering Address |		| 1 | Peering Address |
	| | |		| | |
	| 2 | Local AS |		| 2 | Local AS |
	| | |		| | |
	| 3 | Capabilities |		| 3 | BGP Identifier |
	| | |		| | |
	| 4-127 | Unassigned (IETF Review) |		| 4 | Session Group-ID |
			| | |
			| 5 | Session Capabilities |
			| | |
			| 6 | Key Chain Name |
			| | |
			| 7-127 | Unassigned (IETF Review) |
	| | |		| | |
	| 128-254 | Reserved (Not to be assigned now) |		| 128-254 | Reserved (Not to be assigned now) |
	| | |		| | |
	| 255 | Reserved (not to be assigned) |		| 255 | Reserved (not to be assigned) |
	+-------------+-----------------------------------+		+-------------+-----------------------------------+
	LLDP BGP Config OS-TLV Types		LLDP BGP Config OS-TLV Types
	o Types in the range 4-127 are to be assigned subject to IETF		o Types in the range 7-127 are to be assigned subject to IETF
	Review. New values are assigned only through RFCs that have been		Review. New values are assigned only through RFCs that have been
	shepherded through the IESG as AD-Sponsored or IETF WG Documents		shepherded through the IESG as AD-Sponsored or IETF WG Documents
	[IANA-GUIDE].		[IANA-GUIDE].
	o Types in the range 128-254 are reserved and not to be assigned at		o Types in the range 128-254 are reserved and not to be assigned at
	this time. Before any assignments can be made in this range,		this time. Before any assignments can be made in this range,
	there MUST be a Standards Track RFC that specifies IANA		there MUST be a Standards Track RFC that specifies IANA
	Considerations that covers the range being assigned.		Considerations that covers the range being assigned.
	6. References		6. Contributors
	6.1. Normative References		Contributors' Addresses
			7. References
			7.1. Normative References
	[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[BGP-DC] Lapukhov, P., Premji, A., and J. Mitchell, "BGP Routing in
	Data Centers", RFC 7938, August 2016.
	[LLDP] IEEE, "IEEE Standard for Local and metropolitan area		[LLDP] IEEE, "IEEE Standard for Local and metropolitan area
	networks-- Station and Media Access Control Connectivity		networks-- Station and Media Access Control Connectivity
	Discovery Corrigendum 2: Technical and Editorial		Discovery Corrigendum 2: Technical and Editorial
	Corrections", IEEE 802.1AB-2009/Cor 2-2015, DOI 10.1109/		Corrections", IEEE 802.1AB-2009/Cor 2-2015,
	ieeestd.2015.7056401, March 2015.		DOI 10.1109/ieeestd.2015.7056401, March 2015.
	[RFC-KEYWORDS]		[RFC-KEYWORDS]
	Bradner, S., "Key words for use in RFC's to Indicate		Bradner, S., "Key words for use in RFC's to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	6.2. Informative References		7.2. Informative References
			[BGP-CAP] Scudder, J. and R. Chandra, "Capabilities Advertisement
			with BGP-4", RFC 5492, February 2009.
			[BGP-DC] Lapukhov, P., Premji, A., and J. Mitchell, "BGP Routing in
			Data Centers", RFC 7938, August 2016.
	[GTSM] Gill, V., Heasley, J., Savola, P., and C. Pignataro, "The		[GTSM] Gill, V., Heasley, J., Savola, P., and C. Pignataro, "The
	Generalized TTL Security Mechanism", RFC 5082, October		Generalized TTL Security Mechanism", RFC 5082, October
	2007.		2007.
	[IANA-GUIDE]		[IANA-GUIDE]
	Narten, T. and H. Alvestrand, "Guidelines for Writing an		Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226, May 2008.		IANA Considerations Section in RFCs", RFC 5226, May 2008.
	[IEEE-802-IANA]		[IEEE-802-IANA]
	Eastlake, D. and J. Abley, "IANA Considerations and IETF		Eastlake, D. and J. Abley, "IANA Considerations and IETF
	Protocol and Documentation Usage for IEEE 802 Parameters",		Protocol and Documentation Usage for IEEE 802 Parameters",
	RFC 7042, October 2013.		RFC 7042, October 2013.
			[MP-BGP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
			"Multiprotocol Extensions for BGP-4", RFC 4760, January
			2007.
	[TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP		[TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, June 2010.		Authentication Option", RFC 5925, June 2010.
	[TCP-MD5] Heffernan, A., "TCP MD5 Signature Option", RFC 2385,		[TCP-MD5] Heffernan, A., "TCP MD5 Signature Option", RFC 2385,
	August 1998.		August 1998.
			[YANG-KEY-CHAIN]
			Lindem, A., Qu, Y., Yeung, D., Chen, I., and J. Zhang,
			"YANG Data Model for Key Chains", RFC 8177, June 2017.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The RFC text was produced using Marshall Rose's xml2rfc tool.		The RFC text was produced using Marshall Rose's xml2rfc tool.
	Authors' Addresses		Authors' Addresses
	Acee Lindem		Acee Lindem
	Cisco Systems		Cisco Systems
	301 Midenhall Way		301 Midenhall Way
	Cary, NC 27513		Cary, NC 27513
	skipping to change at page 13, line 4 ¶		skipping to change at page 16, line 14 ¶
	Authors' Addresses		Authors' Addresses
	Acee Lindem		Acee Lindem
	Cisco Systems		Cisco Systems
	301 Midenhall Way		301 Midenhall Way
	Cary, NC 27513		Cary, NC 27513
	USA		USA
	Email: acee@cisco.com		Email: acee@cisco.com
	Keyur Patel		Keyur Patel
	Arrcus, Inc		Arrcus, Inc
	Email: keyur@arrcus.com		Email: keyur@arrcus.com
	Shawn Zandi		Shawn Zandi
	LinkedIn		LinkedIn
	222 2nd Street		222 2nd Street
	San Francisco, CA 94105		San Francisco, CA 94105
	USA		USA
	Email: szandi@linkedin.com		Email: szandi@linkedin.com
			Jeff Haas
			Juniper Networks, Inc
			1133 Innovation, Inc.
			Sunnyvale, CA 94089
			USA
			Email: jhaas@juniper.net
			Xiaohu Xu
			Huawei
			Email: xuxiaohu@huawei.com
End of changes. 63 change blocks.
	159 lines changed or deleted		273 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/