< draft-acee-idr-lldp-peer-discovery-09.txt		draft-acee-idr-lldp-peer-discovery-10.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: December 3, 2021 Arrcus, Inc		Expires: February 9, 2022 Arrcus, Inc
	S. Zandi		S. Zandi
	LinkedIn		LinkedIn
	J. Haas		J. Haas
	Juniper Networks, Inc		Juniper Networks, Inc
	X. Xu		X. Xu
	Capitalonline		Capitalonline
	June 1, 2021		August 8, 2021
	BGP Logical Link Discovery Protocol (LLDP) Peer Discovery		BGP Logical Link Discovery Protocol (LLDP) Peer Discovery
	draft-acee-idr-lldp-peer-discovery-09		draft-acee-idr-lldp-peer-discovery-10
	Abstract		Abstract
	Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is		Link Layer Discovery Protocol (LLDP) or IEEE Std 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 would use LLDP to discover directly		This 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 42 ¶		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 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 December 3, 2021.		This Internet-Draft will expire on February 9, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	2. LLDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3		2. LLDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. LLDP IETF Organizationally Specific TLV Format . . . . . 3		2.1. LLDP IETF Organizationally Specific TLV Format . . . . . 3
	2.2. BGP Config OS-TLV Format . . . . . . . . . . . . . . . . 4		2.2. BGP Config OS-TLV Format . . . . . . . . . . . . . . . . 4
	2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV . . . . . 5		2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV . . . . . 5
	2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV . . . . . . 6		2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV . . . . . . 6
	2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV . . . . . 7		2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV . . . . . 7
	2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV . . . . 8		2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV . . . . 8
	2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV 9		2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV 9
	2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV . . . . . . . . 10		2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV . . . . . . . . 10
	2.2.7. BGP Config OS-TLV - Local Address Sub-TLV . . . . . . 11		2.2.7. BGP Config OS-TLV - Local Address Sub-TLV . . . . . . 11
	3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 12		2.2.8. BGP Config OS-TLV - BGP State Version Sub-TLV . . . . 12
	3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 12		3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 13
	3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 12		3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 13
	4. LLDP Authentication/Encryption . . . . . . . . . . . . . . . 13		3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 13
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		4. LLDP Authentication/Encryption . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 15		6.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 15
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16		6.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . 16		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 16		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17		8.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Link Layer Discovery Protocol (LLDP) [LLDP] or IEEE Std 802.1AB is		Link Layer Discovery Protocol (LLDP) [LLDP] or IEEE Std 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 [RFC4271] would use LLDP to discover		This document describes how BGP [RFC4271] 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 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	Length The Sub-TLV length in octets will be 4 for IPv4 or 16		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.		for IPv6 plus 3 times the number of AFI/SAFI tuples.
	Address IANA Address family (1 for IPv4 or 2 for IPv6)		Address IANA Address family (1 for IPv4 or 2 for IPv6)
	Family		Family
	Local An IPv4 address (4 octets) or an IPv6 address (16 octets)		Local An IPv4 address (4 octets) or an IPv6 address (16 octets)
	Address		Address
			2.2.8. BGP Config OS-TLV - BGP State Version Sub-TLV
			The BGP OS-TLV Version Sub-TLV will be used to advertise a
			monotonically increasing version. This version will indicate if any
			local BGP state that may impact BGP session establishment has
			changed. Changes can range from anything as obvious a change in
			local peering address to more indirect changes such as the
			modification of the key-chain being advertised.
			The format of the BGP State Version 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 (3) | Length (4) | BGP State Version |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| BGP State Version |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type The Sub-TLV Type value shall be 8.
			Length The Sub-TLV Length will be 4 octets.
			BGP State Version BGP State Version - Monotonically increasing
			version number indicating if any local state
			that may effect BGP session establishment has
			changed.
	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 [RFC7938].		This can be used in data centers using BGP as described in [RFC7938].
	The use case where a loopback address or other local address is		The use case where a loopback address or other local address is
	advertised as the peering address is also supported. However,		advertised as the peering address is also supported. However,
	reachabiliy to a peering address other than the interface address is		reachabiliy to a peering address other than the interface address is
	beyond the scope of this document.		beyond the scope of this document.
	skipping to change at page 13, line 43 ¶		skipping to change at page 14, line 43 ¶
	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 local neighbor configuration in order to		ensure appropriate local neighbor configuration in order to
	facilitate session establishment.		facilitate session establishment.
	If TCP MD5 authentication [RFC2385]. or TCP Authentication Option		If TCP MD5 authentication [RFC2385]. or TCP Authentication Option
	(TCP-AO) [RFC5925] is to be used on the session as determined either		(TCP-AO) [RFC5925] is to be used on the session as determined either
	via the Session Capabilities Sub-TLV, Session Group-ID, or local		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		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 [RFC8177].		MAY be used to identify the correct key chain [RFC8177].
			The BGP State Version associated with the LLDP peer SHOULD be
			retained to determine whether anything impacting BGP session
			establishment has changed. When session establishment fails, this
			can be used to avoid back-off on attempting to establish a BGP
			session when nothing has changed on the peer or locally.
	4. LLDP Authentication/Encryption		4. LLDP Authentication/Encryption
	The IEEE 802.1AE [MACsec] standard can be used for encryption and/or		The IEEE 802.1AE [MACsec] standard can be used for encryption and/or
	authentication to provide privacy and integrity. MACsec utilizes the		authentication to provide privacy and integrity. MACsec utilizes the
	Galois/Counter Mode Advanced Encryption Standard (AES-GCM) for		Galois/Counter Mode Advanced Encryption Standard (AES-GCM) for
	authenticated encryption and Galois Message Authentication Code		authenticated encryption and Galois Message Authentication Code
	(GMAC) if only authentication, but not encryption is required.		(GMAC) if only authentication, but not encryption is required.
	The MACsec Key Agreement (MKA) is included as part of the IEEE		The MACsec Key Agreement (MKA) is included as part of the IEEE
	802.1X-20200 Port-Based Network Access Control Standard [MKA]. The		802.1X-20200 Port-Based Network Access Control Standard [MKA]. The
	skipping to change at page 15, line 38 ¶		skipping to change at page 17, line 24 ¶
	| 3 | BGP Identifier |		| 3 | BGP Identifier |
	| | |		| | |
	| 4 | Session Group-ID |		| 4 | Session Group-ID |
	| | |		| | |
	| 5 | Session Capabilities |		| 5 | Session Capabilities |
	| | |		| | |
	| 6 | Key Chain Name |		| 6 | Key Chain Name |
	| | |		| | |
	| 7 | Local Address |		| 7 | Local Address |
	| | |		| | |
	| 8-127 | Unassigned (IETF Review) |		| 8 | BGP State Version |
			| | |
			| 9-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 8-127 are to be assigned subject to IETF		o Types in the range 9-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
	[RFC5226].		[RFC5226].
	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.
	7. Contributors		7. Contributors
End of changes. 9 change blocks.
	20 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/