< draft-acee-idr-lldp-peer-discovery-04.txt   draft-acee-idr-lldp-peer-discovery-05.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: July 3, 2019 Arrcus, Inc Expires: January 9, 2020 Arrcus, Inc
S. Zandi S. Zandi
LinkedIn LinkedIn
J. Haas J. Haas
Juniper Networks, Inc Juniper Networks, Inc
X. Xu X. Xu
Huawei Alibaba
December 30, 2018 July 8, 2019
BGP Logical Link Discovery Protocol (LLDP) Peer Discovery BGP Logical Link Discovery Protocol (LLDP) Peer Discovery
draft-acee-idr-lldp-peer-discovery-04.txt draft-acee-idr-lldp-peer-discovery-05
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 3, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 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. 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
3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 11 3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 11
3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 11 3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 11
3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 11 3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 13 5.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 13
5.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 13 5.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 13
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 [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.
1.1. Requirements Notation 1.1. Requirements Notation
1.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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC-KEYWORDS]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. LLDP Extensions 2. LLDP Extensions
2.1. LLDP Organizationally Specific TLV Format 2.1. LLDP Organizationally Specific TLV Format
The format of the LLDP Basic Organizationally Specific TLV (OS-TLV) The format of the LLDP Basic Organizationally Specific TLV (OS-TLV)
is defined in [LLDP]. It is shown below for completeness. is defined in [LLDP]. It is shown below for completeness.
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
skipping to change at page 3, line 42 skipping to change at page 3, line 46
organization's OUI. For IANA, this is value is organization's OUI. For IANA, this is value is
00-00-5E as specified in [IEEE-802-IANA]. 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 IANA was allocated in section 1.4 of [IEEE-802-IANA]. The OUI for IANA was allocated in section 1.4 of [RFC7042]. This
This document requests creation of a registry for IETF specific sub- document requests creation of a registry for IETF specific sub-types
types for LLDP Organizationally Specific TLVs. for LLDP Organizationally Specific TLVs.
2.2. BGP Config OS-TLV Format 2.2. 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
skipping to change at page 5, line 14 skipping to change at page 5, line 14
2.2.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 addresses used for BGP sessions and the associated address local IP addresses used for BGP sessions and the associated address
families specified by AFI/SAFI tuples. The AFI/SAFI tuple, 0/0, families specified by AFI/SAFI tuples. The AFI/SAFI tuple, 0/0,
indicates to use the associated peering address for all locally indicates to use the associated peering address for all locally
configured address families without an explicit peering address configured address families without an explicit peering address
specification. As always, the address families supported for a given specification. As always, the address families supported for a given
BGP session will be determined during capabilities negotiation BGP session will be determined during capabilities negotiation
[MP-BGP]. It is RECOMMENDED that the wildcard AFI/SAFI be used in [RFC4760]. It is RECOMMENDED that the wildcard AFI/SAFI be used in
deployments with fairly homogenous address family usage. deployments with fairly homogenous address family usage.
The format of the BGP Peering Address Sub-TLV is shown below. The format of the BGP Peering Address 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 (1) | Length | Address Family| IPv4/IPv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv4/IPv6 Peering Address ... ~ ~ IPv4/IPv6 Peering Address ... ~
skipping to change at page 9, line 44 skipping to change at page 9, line 44
Bit 1: This bit indicates 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 [RFC2385]. The TCP
Authentication Option (TCP-AO) is described in [TCP-AO]. The Authentication Option (TCP-AO) is described in [RFC5925]. The
Generalized TTL Security Mechanism (GTSM) is described in [GTSM]. If Generalized TTL Security Mechanism (GTSM) is described in [RFC5082].
both TCP MD5 authentication and TCP-AO authentication are specified If both TCP MD5 authentication and TCP-AO authentication are
and TCP-AO is supported, it will take precedence. specified and TCP-AO is supported, it will take precedence.
2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV 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 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 name for the key chain used for session authentication. Key chains
[YANG-KEY-CHAIN] are a commonly used for protocol authentication and [RFC8177] are a commonly used for protocol authentication and
encryption key specification. Given the limited length of all BGP encryption key specification. Given the limited length of all BGP
configuration information, the key chain name will be limited to 64 configuration information, the key chain name will be limited to 64
characters and will not include a trailing string delimiter. The characters and will not include a trailing string delimiter. The
format of the Session Group-ID Sub-TLV is shown below. 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 (6) |Length (1 - 64)| Key Chain Name | | Type (6) |Length (1 - 64)| Key Chain Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 9 skipping to change at page 11, line 9
Length The Sub-TLV Length will be 1 - 64 octets. Length The Sub-TLV Length will be 1 - 64 octets.
Key Chain Name The name of a key chain to be used for Key Chain Name The name of a key chain to be used for
MD5 or TCP-AO authentication. 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 [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.
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 the BGP-OS TLV. for a link using the BGP Local Address Sub-TLV of the BGP-OS TLV.
This can be an IPv4 or IPv6 local address associated with the LLDP This can be an IPv4 or IPv6 local address associated with the LLDP
skipping to change at page 11, line 37 skipping to change at page 11, line 37
AS number may be included in the Local AS Sub-TLV. The local BGP AS number may be included in the Local AS Sub-TLV. The local BGP
identifier may also be advertised using the BGP Identifier Sub-TLV of identifier may also be advertised using the BGP Identifier Sub-TLV of
the BGP-OS TLV. While not specifically required for session the BGP-OS TLV. While not specifically required for session
establishment, the values may be used for validation, trouble- establishment, the values may be used for validation, trouble-
shooting, and connection collision avoidance. A BGP speaker may also shooting, and connection collision avoidance. A BGP speaker may also
announce a Session Group-ID indicating the class or category of announce a Session Group-ID indicating the class or category of
session(s) supported and/or mapping to a set of session parameters. session(s) supported and/or mapping to a set of session parameters.
Additionally, a BGP speaker MAY also announce relevant capabilities Additionally, a BGP speaker MAY also announce relevant capabilities
using BGP Session Capabilities Sub-TLV of the BGP-OS TLV. using BGP Session Capabilities Sub-TLV of the BGP-OS TLV.
If TCP MD5 authentication [TCP-MD5] or TCP Authentication Option If TCP MD5 authentication [RFC2385] or TCP Authentication Option
(TCP-AO) [TCP-AO] is to be used on the session, the Key Chain Sub-TLV (TCP-AO) [RFC5925] is to be used on the session, the Key Chain Sub-
of the BGP-OS TLV MAY be used to specify the key chain name. TLV 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 BGP sessions using the address in the BGP Local Address establish BGP sessions using the address in the BGP Local Address
Sub-TLV of BGP-OS TLV format. If the peering address is directly Sub-TLV of BGP-OS TLV format. If the peering address is directly
accessible over the link on which the LLDP PDU is received, the BGP accessible over the link on which the LLDP PDU is received, the BGP
speaker 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
skipping to change at page 12, line 12 skipping to change at page 12, line 12
established and the mechanisms for establishing reachability are established and the mechanisms for establishing reachability are
beyond the scope of this specification. If the BGP speaker receives beyond the scope of this specification. If the BGP speaker receives
the same BGP peering address in LLDP PDUs received on multiple links, the same BGP peering address in LLDP PDUs received on multiple links,
it will not establish multiple sessions. Rather, a single 2-hop it will not establish multiple sessions. Rather, a single 2-hop
session will be established. session will be established.
When the deployment of address families is fairly homogenous across When the deployment of address families is fairly homogenous across
the deployment, the wildcard AFI/SAFI can be utilized to simplify the deployment, the wildcard AFI/SAFI can be utilized to simplify
LLDP advertisement. When there is variance in the address families LLDP advertisement. When there is variance in the address families
supported, usage of the wildcard could result in session supported, usage of the wildcard could result in session
establishment delay due to capabilities negotiation [BGP-CAP]. establishment delay due to capabilities negotiation [RFC5492].
A BGP speaker MAY receive a remote neighbor's local AS number(s) in 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 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 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 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- 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 TLV of the BGP-OS TLV. This can be used to avoid connection
collisions by delaying session establishment if the remote BGP collisions by delaying session establishment if the remote BGP
Identifier is greater than the receiving speaker's BGP Identifier. Identifier is greater than the receiving speaker's BGP Identifier.
skipping to change at page 12, line 37 skipping to change at page 12, line 37
Top-of-Rack (ToR) session in a data center deployment and can be used 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 to detect cabling problems when an unexpected Session Group-ID is
received. received.
Additionally, A BGP speaker MAY receive a remote neighbor's Additionally, A BGP speaker MAY receive a remote neighbor's
capabilities in LLDP in the BGP Session Capabilities Sub-TLV of the 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 local neighbor configuration in order to ensure appropriate local neighbor configuration in order to
facilitate session establishment. facilitate session establishment.
If TCP MD5 authentication [TCP-MD5]. or TCP Authentication Option If TCP MD5 authentication [RFC2385]. or TCP Authentication Option
(TCP-AO) [TCP-AO] 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 [YANG-KEY-CHAIN]. MAY be used to identify the correct key chain [RFC8177].
4. Security Considerations 4. Security Considerations
This security considerations for BGP [BGP] apply equally to this This security considerations for BGP [RFC4271] 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 BGP Config [RFC7042]. Assignment is requested for 1 for the BGP Config OS-TLV.
OS-TLV.
+-------------+-----------------------------------+ +-------------+-----------------------------------+
| Range | Assignment Policy | | Range | Assignment Policy |
+-------------+-----------------------------------+ +-------------+-----------------------------------+
| 0 | Reserved (not to be assigned) | | 0 | Reserved (not to be assigned) |
| | | | | |
| 1 | BGP Configuration | | 1 | BGP Configuration |
| | | | | |
| 2-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 2-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]. [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.
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
skipping to change at page 14, line 34 skipping to change at page 14, line 34
| 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 7-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]. [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.
6. Contributors 6. Contributors
Contributors' Addresses Contributors' Addresses
7. References 7. References
7.1. Normative References 7.1. Normative References
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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, Corrections", IEEE 802.1AB-2009/Cor 2-2015,
DOI 10.1109/ieeestd.2015.7056401, March 2015. DOI 10.1109/ieeestd.2015.7056401, March 2015.
[RFC-KEYWORDS] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119,
Requirement Levels", BCP 14, RFC 2119, March 1997. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[BGP-CAP] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
with BGP-4", RFC 5492, February 2009. Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>.
[BGP-DC] Lapukhov, P., Premji, A., and J. Mitchell, "BGP Routing in [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
Data Centers", RFC 7938, August 2016. "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[GTSM] Gill, V., Heasley, J., Savola, P., and C. Pignataro, "The [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Generalized TTL Security Mechanism", RFC 5082, October Pignataro, "The Generalized TTL Security Mechanism
2007. (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[IANA-GUIDE] [RFC5226] 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,
IANA Considerations Section in RFCs", RFC 5226, May 2008. DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[IEEE-802-IANA] [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
Eastlake, D. and J. Abley, "IANA Considerations and IETF with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
Protocol and Documentation Usage for IEEE 802 Parameters", 2009, <https://www.rfc-editor.org/info/rfc5492>.
RFC 7042, October 2013.
[MP-BGP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
"Multiprotocol Extensions for BGP-4", RFC 4760, January Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
2007. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
Authentication Option", RFC 5925, June 2010. IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[TCP-MD5] Heffernan, A., "TCP MD5 Signature Option", RFC 2385, [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
August 1998. BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>.
[YANG-KEY-CHAIN] [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Lindem, A., Qu, Y., Yeung, D., Chen, I., and J. Zhang, Zhang, "YANG Data Model for Key Chains", RFC 8177,
"YANG Data Model for Key Chains", RFC 8177, June 2017. DOI 10.17487/RFC8177, June 2017,
<https://www.rfc-editor.org/info/rfc8177>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Thanks to Sujay Gupta for review and comments. Thanks to Sujay Gupta for review and comments.
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
skipping to change at page 16, line 29 skipping to change at page 17, line 4
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 Jeff Haas
Juniper Networks, Inc Juniper Networks, Inc
1133 Innovation, Inc. 1133 Innovation, Inc.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: jhaas@juniper.net Email: jhaas@juniper.net
Xiaohu Xu Xiaohu Xu
Huawei Alibaba
Email: xuxiaohu@huawei.com Email: xiaohu.xxh@alibaba-inc.com
 End of changes. 39 change blocks. 
67 lines changed or deleted 86 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/