< draft-xu-idr-neighbor-autodiscovery-09.txt   draft-xu-idr-neighbor-autodiscovery-10.txt >
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Alibaba Inc Internet-Draft Alibaba Inc
Intended status: Standards Track K. Talaulikar Intended status: Standards Track K. Talaulikar
Expires: January 17, 2019 Cisco Systems Expires: April 25, 2019 Cisco Systems
K. Bi K. Bi
Huawei Huawei
J. Tantsura J. Tantsura
Nuage Networks
N. Triantafillis N. Triantafillis
July 16, 2018 Apstra
October 22, 2018
BGP Neighbor Auto-Discovery BGP Neighbor Discovery
draft-xu-idr-neighbor-autodiscovery-09 draft-xu-idr-neighbor-autodiscovery-10
Abstract Abstract
BGP is being used as the underlay routing protocol in some large- BGP is being used as the underlay routing protocol in some large-
scaled data centers (DCs). Most popular design followed is to do scaled data centers (DCs). Most popular design followed is to do
hop-by-hop external BGP (eBGP) session configurations between hop-by-hop external BGP (EBGP) session configurations between
neighboring routers on a per link basis. The provisioning of BGP neighboring routers on a per link basis. The provisioning of BGP
neighbors in routers across such a DC brings its own operational neighbors in routers across such a DC brings its own operational
complexity. complexity.
This document introduces a BGP neighbor discovery mechanism that This document introduces a BGP neighbor discovery mechanism that
greatly simplifies BGP operations in such DC and other networks by greatly simplifies BGP operations in such DC and other networks by
automatic setup of BGP sessions between neighbor routers using this automatic setup of BGP sessions between neighbor routers using this
mechanism. mechanism.
Requirements Language Requirements Language
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 January 17, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
4. UDP Message Header . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Hello Message Format . . . . . . . . . . . . . . . . . . . . 6 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Hello Message TLVs . . . . . . . . . . . . . . . . . . . . . 8 6. UDP Message Header . . . . . . . . . . . . . . . . . . . . . 7
6.1. Accepted ASN List TLV . . . . . . . . . . . . . . . . . . 8 7. Hello Message Format . . . . . . . . . . . . . . . . . . . . 8
6.2. Peering Address TLV . . . . . . . . . . . . . . . . . . . 9 8. Hello Message TLVs . . . . . . . . . . . . . . . . . . . . . 10
6.3. Local Prefix TLV . . . . . . . . . . . . . . . . . . . . 10 8.1. Accepted ASN List TLV . . . . . . . . . . . . . . . . . . 10
6.4. Link Attributes TLV . . . . . . . . . . . . . . . . . . . 12 8.2. Peering Address TLV . . . . . . . . . . . . . . . . . . . 11
6.5. Neighbor TLV . . . . . . . . . . . . . . . . . . . . . . 14 8.3. Local Prefix TLV . . . . . . . . . . . . . . . . . . . . 13
6.6. Cryptographic Authentication TLV . . . . . . . . . . . . 15 8.4. Link Attributes TLV . . . . . . . . . . . . . . . . . . . 14
7. Neighbor Discovery Procedure . . . . . . . . . . . . . . . . 17 8.5. Neighbor TLV . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Interface State . . . . . . . . . . . . . . . . . . . . . 17 8.6. Cryptographic Authentication TLV . . . . . . . . . . . . 18
7.2. Adjacency State Machine . . . . . . . . . . . . . . . . . 18 9. Neighbor Discovery Procedure . . . . . . . . . . . . . . . . 20
7.3. Peering Route . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Interface Procedures . . . . . . . . . . . . . . . . . . 20
8. Interactions with Base BGP Protocol . . . . . . . . . . . . . 20 9.2. Adjacency State Machine . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9.2.1. Down State . . . . . . . . . . . . . . . . . . . . . 21
10. Manageability Considerations . . . . . . . . . . . . . . . . 22 9.2.2. Initial State . . . . . . . . . . . . . . . . . . . . 22
10.1. Operational Considerations . . . . . . . . . . . . . . . 22 9.2.3. 1-Way State . . . . . . . . . . . . . . . . . . . . . 22
10.2. Management Considerations . . . . . . . . . . . . . . . 23 9.2.4. 2-Way State . . . . . . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.2.5. Adj-Reject State . . . . . . . . . . . . . . . . . . 23
11.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . 24 9.2.6. Adj-OK State . . . . . . . . . . . . . . . . . . . . 24
11.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . 24 9.2.7. Accepted State . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 9.3. Adjacency Route . . . . . . . . . . . . . . . . . . . . . 25
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Interactions with Base BGP Protocol . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 25 12. Manageability Considerations . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . 26 12.1. Operational Considerations . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 12.2. Management Considerations . . . . . . . . . . . . . . . 29
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
13.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . 29
13.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
16.1. Normative References . . . . . . . . . . . . . . . . . . 31
16.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
BGP is being used as the underlay routing protocol instead of link- BGP is being used as the underlay routing protocol instead of link-
state routing protocols like IS-IS and OSPF in some large-scale data state routing protocols like IS-IS and OSPF in some large-scale data
centers (DCs). [RFC7938] describes the design, configuration and centers (DCs). [RFC7938] describes the design, configuration and
operational aspects of using BGP in such networks. The most popular operational aspects of using BGP in such networks. The most popular
design scheme involves the setup of external BGP (eBGP) sessions over design scheme involves the setup of external BGP (EBGP) sessions over
individual links between directly connected routers using their individual links between directly connected routers using their
interface addresses. Such BGP neighbor provisioning requires interface addresses. Such BGP neighbor provisioning requires
provisioning of the neighbor IP address and Autonomous System (AS) configuration of the neighbor IP address and Autonomous System (AS)
Number (ASN) for each and every BGP neighbor on every link address. Number (ASN) for BGP neighbor on each and every link of every BGP
As a DC fabric comprising of topology described in [RFC7938] grows router. As a DC fabric comprising of topology described in [RFC7938]
with addition of new leafs, spines and links between them, the BGP grows with addition of new leafs, spines, and links between them, the
provisioning needs to be carefully setup. Unlike with the link-state BGP provisioning needs to be carefully updated. Unlike with the
protocols, there is no automatic discovery of neighbors simply by link-state protocols, in the case of BGP, there is no automatic
adding links and nodes in the fabric and route exchange over them discovery of neighbors and route exchange between them by simply
getting enabled seamlessly in the case of BGP. adding links and nodes of the fabric into the routing protocol
operation.
In some DC designs with BGP, multiple links are added between a leaf In some DC designs with BGP, multiple links are added between a leaf
and spine to add additional bandwidth. Use of link-aggregation at and spine to add additional bandwidth. Use of link-aggregation at
Layer 2 level may not be desirable in such cases due to the risk of Layer 2 level may not be always desirable in such cases due to the
flow polarization on account of a mix of ECMP at Layer 2 and Layer 3 risk of flow polarization on account of a mix of ECMP at Layer 2 and
levels. In such cases, one option is for a eBGP sessions to be setup Layer 3 levels. In such cases, one option is for EBGP sessions to be
between two BGP neighbors over each of the links between them. In setup between two BGP neighbors over each of the links between them.
such a case, the BGP session scale and the resultant increase in In such a case, the BGP session scale and the resultant increase in
update processing may pose scalability challenges. A second option update processing may pose scalability challenges. A second option
is for a single eBGP session to be setup between the loopback IP is for a single EBGP session to be setup between the loopback IP
addresses between the neighbor and then configure some static routes addresses between the neighbor and then configure some static routes
for it pointing over the underlying links as ECMP. In this option for loopback reachability over the underlying links. This option
there is an additional provisioning task introduced in the form of introduces an additional provisioning task for the static routes.
static routing.
Furthermore, there is also a need for BGP to be able to describe its Furthermore, there is also a need for BGP to be able to describe its
links and its neighbors on its directly connected links and export links and its neighbors on its directly connected links and export
this information via BGP-LS [RFC7752] to provide a detail link-level this information via BGP-LS [RFC7752] to provide a detail link-level
topology view using a standards based mechanism of a data center topology view of a data center running BGP. The ability of BGP in
running only BGP. The ability of BGP in discovering its neighbors discovering its neighbors over its links, monitoring their liveliness
over its links, monitoring their liveliness and learning the link and learning the link attributes (such as addresses) is required for
attributes (such as addresses) is required for the conveying the the conveying the link-state topology in such a BGP network. This
link-state topology in a BGP network. This information can be information can be leveraged by the BGP-SPF proposal
leveraged by the BGP-SPF proposal [I-D.ietf-lsvr-bgp-spf] which [I-D.ietf-lsvr-bgp-spf] which introduces link-state routing
introduces link-state routing capabilities in BGP. This information capabilities in BGP. This information can also be leveraged to
can also be leveraged to convey the link-state topology in a network convey the link-state topology in a network running traditional BGP
running traditional BGP routing using BGP-LS as described in routing using BGP-LS as described in
[I-D.ketant-idr-bgp-ls-bgp-only-fabric] and to enabled end to end [I-D.ketant-idr-bgp-ls-bgp-only-fabric] and to enabled end to end
traffic engineering use-cases spanning across DCs and the core/access traffic engineering use-cases spanning across DCs and the core/access
networks. networks.
2. Terminology 2. Terminology
This memo makes use of the terms defined in [RFC4271] and [RFC7938] . This document makes use of the terms defined in [RFC4271] and
[RFC7938] .
3. Overview 3. Applicability
The applicability of the BGP Neighbor Discovery mechanism described
in this document is limited to deployments where BGP is used as
routing protocol between directly connected routers and when there is
a requirement for automatic setup of BGP peering between them.
o In DC networks where BGP is used as a hop-by-hop routing protocol
[RFC7938].
o In metro networks where access aggregation topologies are
architected as a CLOS topology (or similar other networks) and BGP
is used as a hop-by-hop routing protocol.
While this document uses EBGP examples, the mechanism is equally
applicable in designs that use IBGP similarly for hop-by-hop routing.
The applicability of the BGP Neighbor Discovery mechanism to any
other BGP protocol deployment is outside the scope of this document.
4. Requirements
This section describe the requirements for the BGP hop-by-hop routing
deployments that were considered for the definition of the BGP
Neighbor Discovery extensions proposed in this document..
Following are the key requirements related for the BGP neighbor
discovery process:
1. It should perform discovery of directly connected BGP routers.
Mechanism should support either IPv4 or IPv6 or a dual stack
design and it should be generic for any link-layer.
2. It should include exchange of BGP peering addresses (IPv4 or IPv6
or both) that routers can use to automatically setup BGP TCP
peering between themselves. The mechanism should leverage the
existing capability negotiation process performed as part of the
BGP TCP session establishment.
3. When BGP peering is desired to be performed over loopback
addresses of the routers, then the mechanism should automatically
setup reachability to the loopback over one or more underlying
directly connected links between them. In this scenario, the
mechanism should also provide resolution for the BGP next-hop
address (i.e. the loopback address) for the BGP routes exchanged
over these sessions between the loopback addresses.
4. Mechanism should enable exchange of link-level information such
as IP addresses and link attributes between the directly
connected BGP routers. It should be extensible to include other
information in the future.
5. Mechanism should be limited to link scope for security and use
link-local addressing only. Cryptographic mechanisms should be
also provided for additional security.
6. Mechanism should support capabilities for performing optional
validation of parameters to detect misconfiguration (e.g. link
address subnet mismatch, peering between incorrect AS, etc.) in
an extensible manner before going on to use the link and the
setup of the BGP TCP peering session over it.
7. The mechanism should not affect or change the BGP TCP session
establishment procedures and the BGP routing exchange over the
TCP session other than the interactions for triggering the setup/
removal of peer session that is based on discovery mechanism.
8. The mechanism should leverage existing fast-detection techniques
for failures that are used currently for EBGP sessions over
directly connected links like fast-external-failover and BFD.
9. The mechanism should focus on the discovery process and exchange
of status as a control plane procedure and be sufficiently
loosely coupled with the base BGP operations to enable
implementations to ensure scalability of BGP operations when
using the discovery procedures.
5. Overview
At a high level, this specification introduces the use of UDP based At a high level, this specification introduces the use of UDP based
BGP Hello messages to be exchanged between directly connected BGP BGP Hello messages to be exchanged between directly connected BGP
routers for neighbor discovery. routers for neighbor discovery.
1. Information is exchanged between BGP routers on a per link basis 1. Information is exchanged between BGP routers on a per link basis
leading to discovery of each others peering address and other leading to discovery of each others peering address and other
information. information.
2. The TCP session establishment for the BGP protocol operation and 2. The TCP session establishment for the BGP protocol operation and
skipping to change at page 4, line 37 skipping to change at page 6, line 29
3. As part of the neighbor information exchange the route to a 3. As part of the neighbor information exchange the route to a
neighbor's peering address is also automatically setup pointing neighbor's peering address is also automatically setup pointing
over the links over which the neighbor is discovered. over the links over which the neighbor is discovered.
4. This route is used for both the BGP TCP session establishment as 4. This route is used for both the BGP TCP session establishment as
well as for resolution of the BGP next-hop (NH) for the routes well as for resolution of the BGP next-hop (NH) for the routes
learnt via the neighbor instead of an underlying IGP or static learnt via the neighbor instead of an underlying IGP or static
route. route.
Auto-discovery of BGP neighbors and their liveness detection may be This document prefers the use of an extension to BGP protocol since
performed via different mechanisms. This document prefers the use of the deployments and use-cases targeted (i.e. large-scale DCs) are
an extension to BGP protocol since the deployments and use-cases already running BGP as their routing protocol. Extending BGP with
targeted (i.e. large-scale DCs) are already running BGP as their neighbor discovery capabilities is operationally and implementation
routing protocol. Extending BGP with neighbor discovery capabilities wise a simpler approach than requiring a new or an additional
is operationally and implementation wise a simpler approach than protocol to be first extended to do this functionality (to exchange
requiring a new or an additional protocol to be first extended to do BGP-specific parameters) and then also integrated its operations with
this functionality (to exchange BGP-specific parameters) and then BGP protocol operations.
also integrated its operations with BGP protocol operations.
Following are the key objectives and goals of the BGP neighbor
discovery mechanism proposed in this document:
o Existing BGP update processing is unchanged
o Minimal changes for integration of the neighbor discovery state
machine with the existing BGP Peer state machine for auto-
discovered neighbors only
o Auto-discovery mechanism is restricted to directly connected BGP
speakers only and uses link-local multicast addresses only for the
hello messaging
o Liveness detection is used for monitoring the BGP adjacency status The BGP Neighbor discovery mechanism is a control plane mechanism
for directly connected BGP routers over individual links and is intended to discovery and maintain the BGP router's adjacencies with
BGP specific. It is not intended to replace the functionality for its neighbors over directly connected links. Maintaining an
existing generic mechanisms like BFD and LLDP. adjacency also involves detecting any changes in parameters using
periodic messages and triggering corresponding actions based on the
change. Such actions also include removal of the BGP TCP peering for
an auto discovered peering session based on the neighbor discovery.
However, the mechanism is not intended for a fast liveness detection
of neighbor and existing mechanisms for this purpose such as BFD
[RFC5880] may be leveraged.
o Hello processing is separate from the core BGP protocol operations The BGP Neighbor discovery mechanism is scoped to a link and works
such that BGP route processing scale and performance is not using link-local addressing. In a BGP DC network that is using IPv6
impacted in the fabric underlay, it is possible that no IPv6 global addresses
are assigned to the interfaces between the nodes and the IPv6 Global
address(es) are assigned only to the loopback interfaces of these
nodes. The Neighbor discovery mechanism enables the setup of BGP
peering using the IPv6 Global addresses on the loopback interfaces
and hop by hop routing with just IPv6 link-local addresses on the
interfaces. Such a design eases introduction of nodes in the fabric
and links between them from a provisioning aspect. In a deployment
with IPv4 addressing, IP unnumbered could be similarly used for all
the links between the nodes using the IPv4 address assigned to the
loopback interfaces on those nodes.
The BGP neighbor discovery mechanism defined in this document borrows The BGP neighbor discovery mechanism defined in this document borrows
ideas from the Label Distribution Protocol (LDP) [RFC5036]. However, ideas from the Label Distribution Protocol (LDP) [RFC5036]. However,
most importantly, only the concept of link-local signaling based most importantly, only the concept of link-local signaling based
neighbor discovery is borrow while the discovery aspect for targeted neighbor discovery is borrowed while the discovery aspect for
LDP sessions does not apply to this BGP neighbor discovery mechanism. targeted LDP sessions does not apply to this BGP neighbor discovery
mechanism.
The further sections in this document first describe the newly The further sections in this document first describe the newly
introduced message formats and TLVs and then go on to describe the introduced message formats and TLVs and then go on to describe the
procedures of the BGP neighbor discovery mechanism and its procedures of BGP neighbor discovery and its integration with the
integration with the base BGP protocol mechanism as specified in base BGP protocol mechanism as specified in [RFC4271].
[RFC4271].
The operational and management aspects of the BGP neighbor discovery The operational and management aspects of the BGP neighbor discovery
mechanism are described in Section 10. mechanism are described in Section 12.
4. UDP Message Header 6. UDP Message Header
The BGP neighbor discovery mechanism will operate using UDP messages. The BGP neighbor discovery mechanism will operate using UDP messages.
The UDP port of TBD (179 is the preferred port number to be assigned The UDP port of TBD (179 is the preferred port number to be assigned
as specified in Section 11) is used which is same as the TCP port 179 as specified in Section 13) is used which is same as the TCP port 179
used by BGP. The BGP UDP message common header format is specified used by BGP. The BGP UDP message common header format is specified
as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Message Length | | Version | Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS number | | AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 34 skipping to change at page 8, line 18
in octets of the entire BGP UDP message including the header. in octets of the entire BGP UDP message including the header.
AS number: AS Number of the UDP message sender. AS number: AS Number of the UDP message sender.
BGP Identifier: BGP Identifier of the UDP message sender. BGP Identifier: BGP Identifier of the UDP message sender.
BGP UDP messages can be sent using either IPv4 or IPv6 depending on BGP UDP messages can be sent using either IPv4 or IPv6 depending on
the address used for session establishment and provisioned on the the address used for session establishment and provisioned on the
interfaces over which these messages are sent. interfaces over which these messages are sent.
5. Hello Message Format 7. Hello Message Format
A BGP router uses UDP based Hello messages to automatically discover A BGP router uses UDP based Hello messages to discover directly
directly connected BGP neighbors and to check their liveliness. The connected BGP neighbors over those interfaces enabled for Neighbor
Hello messages and the BGP neighbor discovery mechanism operates only Discovery. The BGP Hello messages for the Neighbor Discovery
on those interfaces where it is specifically enabled on. The BGP procedure are used for link-locally signaling and hence MUST be
neighbor discovery mechanism is intend for link-local signaling addressed to the "all routers on this subnet" group multicast address
between directly connected BGP nodes and hence the BGP Hello messages (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in the IPv6 case) and
MUST be addressed to the "all routers on this subnet" group multicast the TTL for the IP packets SHOULD be set to 1. The IP source address
address (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in the IPv6 MUST be set to the address of the interface over which the message is
case) and the TTL for the IP packets SHOULD be set to 1. The IP sent out which would be the primary interface address or unnumbered
source address MUST be set to the address of the interface over which address in the IPv4 case and the IPv6 link-local address on the
the message is sent out which would be the primary interface address interface in the IPv6 case.
or unnumbered address in the IPv4 case and the IPv6 link-local
address on the interface in the IPv6 case.
The Hello message format is as follows: The Hello message format is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Message Length | | Version | Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS number | | AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier | | BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacency Hold Time | Reserved | | Adjacency Hold Time | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | | TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: BGP Hello Message Figure 2: 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.
Type: The type of BGP message (Hello - TBD value from BGP Message Type: The type of BGP message (Hello - TBD value from BGP Message
Types Registry) Types Registry)
Message Length: This 2-octet unsigned integer specifies the length Message Length: This 2-octet unsigned integer specifies the length
in octets of the TLVs field. in octets of the TLVs field.
AS number: AS Number of the Hello message sender. AS number: AS Number of the BGP router sending the Hello message.
BGP Identifier: BGP Identifier of the Hello message sender. BGP Identifier: BGP Identifier of the BGP router sending the Hello
message.
Adjacency Hold Time: Hello adjacency hold timer in seconds. Adjacency Hold Time: Hello adjacency hold timer in seconds.
Adjacency Hold Time specifies the time the receiving BGP neighbor Adjacency Hold Time specifies the time, for which the receiving
router SHOULD maintain its neighbor adjacency state without BGP neighbor router SHOULD maintain adjacency state for it,
receipt of another Hello. A value of 0 means that the receiving without receipt of another Hello. A value of 0 means that the
BGP peer should immediately mark that the sender is going down. receiving BGP peer should immediately mark that the adjacency to
the sender is going down.
Flags : Current defined bits are as follows. All other bits
SHOULD be cleared by sender and MUST be ignored by receiver.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| |
+-+-+-+-+-+-+-+-+
where:
S bit - indicates that this is a State Change Hello message
when SET and normal periodic Hello message when CLEAR
Reserved: SHOULD be set to 0 by sender and MUST be ignored by Reserved: SHOULD be set to 0 by sender and MUST be ignored by
receiver. receiver.
TLVs: This field contains one or more TLVs as described below. TLVs: This field contains one or more TLVs as described below.
BGP HELLO messages can be sent using either IPv4 or IPv6 addresses BGP HELLO messages can be sent using either IPv4 or IPv6 addresses
depending on the addressing used for session establishment and depending on the addressing used for session establishment and
provisioned on the interfaces over which these messages are sent. provisioned on the interfaces over which these messages are sent.
Either IPv4 or IPv6 address (but never both on the same link) are When both IPv4 and IPv6 is enabled on the interface, then IPv6
used for the BGP Hello message exchange and the neighbor discovery address SHOULD be used. Implementations MAY provide an option to
mechanism based on the local configuration policy. override the choice of address family to be used. The choice of
address family to be used MUST be consistent on all BGP routers on a
given link for neighbor discovery.
In a BGP DC network that is using IPv6 only in the fabric underlay, Based on the setting of the S flag, there are two variants of the
it is possible that no IPv6 global addresses are assigned to the Hello message:
interfaces between the nodes and the IPv6 Global address(es) are
assigned only to the loopback interfaces of these nodes. Such a 1. State Change Hello Message : these Hello messages include TLVs
design could ease introducing of nodes in the fabric and links which convey the state and parameters of the local interface and
between them from a provisioning aspect. The BGP neighbor discovery adjacency to other routers on the link. They are generated only
mechanism described in this document works on links between routers when there is a change in state of the adjacency or some
having only IPv6 link-local addresses and setting up BGP sessions parameter at the interface level.
between them using their loopback IPv6 Global addresses in an
automatic manner. 2. Periodic Hello Message : these are the normal periodic Hello
messages which do not include TLVs and are used to maintain the
adjacency on the link during steady state conditions.
These Hello message variants are intended to limit the exchange of
information and state via TLVs to only those periods where necessary
while using lightweight Hello messages during steady state. This
simplifies the Hello message processing and improves scalability of
the discovery mechanism.
The neighbor discovery procedure using the Hello message is described The neighbor discovery procedure using the Hello message is described
in Section 7 and its relation with the BGP Keepalives and Hold Timer in Section 9 and its relation with the BGP Keepalives and Hold Timer
for the TCP session is described in Section 8. for the TCP session is described in Section 10.
6. Hello Message TLVs 8. Hello Message TLVs
The BGP Hello message carries TLVs as described in this section that The BGP Hello message carries TLVs as described in this section that
enable exchange of information on a per interface basis between enable exchange of information on a per interface basis between
directly connected BGP neighbors. These messages enable the neighbor directly connected BGP neighbors. These messages enable the neighbor
discovery process. discovery process.
6.1. Accepted ASN List TLV 8.1. Accepted ASN List TLV
The Accepted ASN List TLV is an optional TLV that is used to signal The Accepted ASN List TLV is an optional TLV that is used to signal
the AS numbers from which the BGP router would accept BGP sessions. an unordered list of AS numbers from which the BGP router would
When not signaled, it indicates that the router will accept BGP accept BGP sessions. When not signaled, it indicates that the router
peering from any ASN from its neighbors. Indicating the list of ASNs will accept BGP peering from any ASN from its neighbors. Indicating
from which a router will accept BGP sessions helps avoid the neighbor the list of ASNs, helps avoid the neighbor discovery process getting
discovery process getting stuck in a 1-way state where one side keeps stuck in a 1-way state where one side keeps attempting to setup
attempting to setup adjacency while the other does not accept it due adjacency while the other does not accept it due to incorrect ASN.
to incorrect ASN.
The operational and management aspects of this ASN based policy The operational and management aspects of this ASN based policy
control for BGP neighbor discovery are described further in control for BGP neighbor discovery are described further in
Section 10. Section 12.
Only a single instance of this TLV is included and its format is This TLV SHOULD NOT be included in a Hello message with the S bit
shown below. CLEAR. More than a single instance of this TLV MUST NOT be included
in a Hello message. If a router receives multiple instances of this
TLV then it should only consider the first instance in the sequence
and ignore the rest.
The format of this 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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accepted ASN List(variable) | | Accepted ASN List(variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Accepted ASN List TLV Figure 3: Accepted ASN List TLV
Type: TBD1 Type: TBD1
Length:Specifies the length of the Value field in octets (in Length: Specifies the length of the Value field in octets (in
multiple of 4) multiple of 4)
Accepted ASN-List: This variable-length field contains one or more Accepted ASN-List: This variable-length field contains one or more
accepted 4-octet ASNs. accepted 4-octet ASNs.
6.2. Peering Address TLV 8.2. Peering Address TLV
The Peering Address TLV is used to indicate to the neighbor the The Peering Address TLV is used to indicate to the neighbor the
address to which they should establish the BGP TCP session. For each address to be used for setting up the BGP TCP session. Along with
peering address, the router can specify its supported AFI/SAFI(s). the peering address, the router can specify its supported AFI/
When the AFI/SAFI values are specified as 0/0, then it indicates that SAFI(s). When the AFI/SAFI values are specified as 0/0, then it
the neighbor can attempt for negotiation of any AFI/SAFIs. The indicates that the neighbor can attempt for negotiation of any AFI/
indication of AFI/SAFI(s) in the Peering Address TLV is not intended SAFIs. The indication of AFI/SAFI(s) in the Peering Address TLV is
as an alternative for the MP capabilities negotiation mechanism done not intended as an alternative for the MP capabilities negotiation
as part of the BGP TCP session establishment. mechanism done as part of the BGP TCP session establishment.
This is a mandatory TLV and at least one instance of this TLV MUST be Multiple instances of this TLV MAY be included in the Hello message,
present. Multiple instances of this TLV MAY be present one for each one for each peering address (e.g. IPv4 and IPv6 or multiple IPv4
peering address (e.g. IPv4 and IPv6 or multiple IPv4 addresses for addresses for different AFI/SAFI sessions). When multiple peering
different AFI/SAFI sessions). addresses are provisioned, then the indication helps the router
select the appropriate peer address of the neighbor based on its
local peering address profile by matching the supported AFI/SAFIs.
This TLV is essential for the setting up of the TCP peering between
BGP neighbors using the neighbor discovery mechanism. When a BGP
router stops including a Peer Address in its State Change Hello
messages, then it is no longer accepting TCP peering sessions to that
address and the neighbor SHOULD clean up any peering session that was
setup to that address via the discovery mechanism.
Implementations SHOULD support the signaling of an interface IP
address in the Peering Address TLV and perform the BGP TCP session
establishment using interface addresses (i.e. the neighbor discovery
mechanism is not limited to the use of loopback addresses for the
peering session establishment). Implementations MAY support the
signaling of IPv6 Link Local addresses using the Peering Address TLV
and using the same for the BGP TCP session setup.
This TLV SHOULD NOT be included in a Hello message with the S bit
CLEAR.
The Peering Address TLV format is shown below. The Peering Address TLV format 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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | No. AFI/SAFI | Reserved | | Flags | No. AFI/SAFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 27 skipping to change at page 12, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs ... | sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Peering Address TLV Figure 4: Peering Address TLV
Type: TBD2 Type: TBD2
Length:Specifies the length of the Value field in octets. Length: Specifies the length of the Value field in octets.
Flags : Current defined bits are as follows. All other bits Flags : Current defined bits are as follows. All other bits
SHOULD be cleared by sender and MUST be ignored by receiver. SHOULD be cleared by sender and MUST be ignored by receiver.
Bit 0x1 - address is IPv6 when set and IPv4 when clear 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|A| |
+-+-+-+-+-+-+-+-+
where:
A bit - address is IPv6 when SET and IPv4 when CLEAR
Number of AFI/SAFI: indicates the number of AFI/SAFI pairs that Number of AFI/SAFI: indicates the number of AFI/SAFI pairs that
the router supports on the given peering address. the router supports on the given peering address.
Reserved: sender SHOULD set to 0 and receiver MUST ignore. Reserved: sender SHOULD set to 0 and receiver MUST ignore.
Address: This 4 or 16 octet field indicates the IPv4 or IPv6 Address: This 4 or 16 octet field indicates the IPv4 or IPv6
address which is used for establishing BGP sessions. address which is used for establishing BGP sessions.
AFI/SAFI : one or more pairs of these values that indicate the AFI/SAFI : one or more pairs of these values that indicate the
supported capabilities on the peering address. supported capabilities on the peering address.
Sub-TLVs : currently none defined Sub-TLVs : optional and currently none defined
6.3. Local Prefix TLV 8.3. Local Prefix TLV
When the Peering Address to be used for the BGP TCP session BGP neighbor discovery mechanism, in certain scenarios, requires a
establishment is not the directly connected interface address (e.g. BGP router to program a route in its local routing table for a prefix
when using loopback address) then local prefix(es) that cover its belonging to its neighbor router. On such scenario is when the BGP
peering address(es) MUST be signaled by a BGP router to its neighbor TCP peering is to be setup between the loopback addresses on the
as part of the Hello message. This allows the neighbor to learn neighboring routers. This requires that the routers have
these local prefix(es) and to program routes for them over the reachability to their each other's loopback addresses before the TCP
directly connected interfaces over which they are being signaled. session can be brought up.
The Local Prefix TLV is this an optional TLV and it MUST be used to
only signal prefixes that are locally configured on the router. The The Local Prefix TLV is an optional TLV which enables a BGP router to
procedure for resolving the peering address signaled via the Peering explicitly signal its local prefix to its neighbor for setting up of
Address TLV over the local prefixes signaled is described in such a local routing entry pointing over the underlying link over
Section 7.3. which it is being signaled. This enables the BGP router to have
control over the specific links over which its neighbor that may
reach it for the specific local prefix. The details of the procedure
for programming of the route corresponding to the prefix signaled
using the Local Prefix TLV is described in Section 9.3..
Multiple instances of the Local Prefix TLV MAY be included in the
Hello message with each carrying a specific prefix in it. This TLV
SHOULD NOT be included in a Hello message with the S bit CLEAR.
The Local Prefix TLV format is as shown below. The Local Prefix TLV format is as 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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of IPv4 Prefixes | No. of IPv6 Prefixes | | Flags | Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Mask | ...
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Mask | ... | Prefix Address (4-octet or 16-octet) |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs ... | sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Local Prefix TLV Figure 5: Local Prefix TLV
Type: TBD3 Type: TBD3
Length: Specifies the length of the Value field in octets Length: Specifies the length of the Value field in octets
No. of IPv4 Prefixes : specifies the number of IPv4 prefixes. Flags : Current defined bits are as follows. All other bits
When value is 0, then it indicates no IPv4 Prefixes are present. SHOULD be cleared by sender and MUST be ignored by receiver.
No. of IPv6 Prefixes : specifies the number of IPv6 prefixes. 0 1 2 3 4 5 6 7
When value is 0, then it indicates no IPv6 Prefixes are present. +-+-+-+-+-+-+-+-+
|A| |
+-+-+-+-+-+-+-+-+
IPv4 Prefix Address & Prefix Mask: Zero or more pairs of IPv4 where:
prefix address and their mask.
IPv6 Prefix Address & Prefix Mask: Zero or more pairs of IPv6 A bit - address is IPv6 when SET and IPv4 when CLEAR
prefix address and their mask.
Sub-TLVs : currently none defined Prefix Length: specifies the Prefix length
6.4. Link Attributes TLV Reserved: sender SHOULD set to 0 and receiver MUST ignore.
The Link Attributes TLV is a mandatory TLV that signals to the Prefix Address: This 4 or 16 octet field indicates the IPv4 or
neighbor the link attributes of the interface on the local router. A IPv6 prefix address.
single instance of this TLV MUST be present in the message. This TLV
enables a BGP router to learn all its neighbors IP addresses on the
specific link as well as its link identifiers. All the IPv4
addresses configured on the interface are signaled to the neighbor.
When the interface has IPv4 unnumbered address then that is not
included in this TLV. Only the IPv6 global addresses configured on
the interface are signaled to the neighbor. In case of an interface
running dual stack, both IPv4 and IPv6 addresses are signaled in a
single TLV irrespective of which one is used for UDP message
exchange.
More sub-TLVs may be defined in the future to exchange other link Sub-TLVs : optional and currently none defined
attributes between BGP neighbors.
8.4. Link Attributes TLV
The Link Attributes TLV is a mandatory TLV in a State Change Hello
message that signals to the neighbor the link attributes of the
interface on the local router. One and only one instance of this TLV
MUST be included in the State Change Hello message. A State Change
Hello message without this TLV included MUST be discarded and an
error logged for the same.
This TLV enables a BGP router to learn all its neighbors IP addresses
on the specific link as well as it's link identifier. When the
interface is IPv4 enabled, all the IPv4 addresses configured on it
are included in this TLV. IPv4 unnumbered address is not included in
this TLV and no IPv4 address would be included for the interface in
such cases. When the interface is IPv6 enabled, all the IPv6 global
addresses configured on the interface are included in this TLV. IPv6
link-local addresses are not included in this TLV. In case of an
interface running dual stack, both IPv4 and IPv6 addresses are
included in this TLV irrespective of the address family that is used
for UDP message exchange.
Additional sub-TLVs may be defined in the future to exchange other
link attributes between BGP neighbors. This TLV SHOULD NOT be
included in a Hello message with the S bit CLEAR.
The Link Attributes TLV format is as shown below. The Link Attributes TLV format is as 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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID | Flags | Reserved | | Local Interface ID | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 37 skipping to change at page 15, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs ... | sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Link Attributes TLV Figure 6: Link Attributes TLV
Type: TBD4 Type: TBD4
Length: Specifies the length of the Value field in octets Length: Specifies the length of the Value field in octets
Local Interface ID : the local interface ID of the interface (e.g. Local Interface ID : the local interface ID of the interface
the MIB-2 ifIndex). This helps uniquely identify the link even (refer unnumbered link section of [RFC2104] e.g. the MIB-2
when there are multiple links between two neighbors using IPv4 ifIndex). This helps uniquely identify the link even when there
unnumbered address or only having IPv6 link-local addresses. are multiple links between two neighbors using IPv4 unnumbered
address or only having IPv6 link-local addresses.
Flags : Currently defined bits are as follows. Other bits SHOULD Flags : Currently defined bits are as follows. Other bits SHOULD
be cleared by sender and MUST be ignored by receiver. be cleared by sender and MUST be ignored by receiver.
Bit 0x1 - indicates link is enabled for IPv4 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|V|B| |
+-+-+-+-+-+-+-+-+
Bit 0x2 - indicates link is enabled for IPv6 where:
I bit - indicates link is enabled for IPv4
V bit - indicates link is enabled for IPv6
B bit - indicates support for BFD monitoring [RFC5880] over the
link
Reserved: SHOULD be set to 0 by sender and MUST be ignored by Reserved: SHOULD be set to 0 by sender and MUST be ignored by
receiver. receiver.
No. of IPv4 Addresses : specifies the number of IPv4 addresses on No. of IPv4 Addresses : specifies the number of IPv4 addresses on
the interface. When value is 0, then it indicates no IPv4 the interface. When value is 0, then it indicates no IPv4
Prefixes are present or the interface is IPv4 unnumbered if it is Prefixes are present or the interface is IPv4 unnumbered if it is
enabled for IPv4 enabled for IPv4
No. of IPv6 Addresses : specifies the number of IPv6 global No. of IPv6 Addresses : specifies the number of IPv6 global
skipping to change at page 14, line 22 skipping to change at page 16, line 39
IPv6 Global Prefixes are present and the interface is only IPv6 Global Prefixes are present and the interface is only
configured with IPv6 link-local addresses if it is enabled for configured with IPv6 link-local addresses if it is enabled for
IPv6. IPv6.
IPv4 Address & Mask: Zero or more pairs of IPv4 address and their IPv4 Address & Mask: Zero or more pairs of IPv4 address and their
mask. mask.
IPv6 Address & Mask: Zero or more pairs of IPv6 address and their IPv6 Address & Mask: Zero or more pairs of IPv6 address and their
mask. mask.
Sub-TLVs : currently none defined Sub-TLVs : optional and currently none defined
6.5. Neighbor TLV 8.5. Neighbor TLV
The Neighbor TLV is used by a BGP router to indicate its hello The Neighbor TLV is used by a BGP router to indicate its Hello
adjacency status with its neighboring router(s) on the specific link. adjacency state with its neighboring router(s) on the specific link.
The neighbor is identified by its Peering Address which has been The neighbor is identified by its AS Number and BGP Identifier. The
accepted. The BGP TCP session establishment process begins when the router MUST include the Neighbor TLV for each of its discovered
hello adjacency is formed between the two neighbors over at least one neighbors on that link irrespective of its status.
directly connected link between them. Multiple instances of this TLV
MAY be present in a Hello message - one for each peering address of The usage of the Neighbor TLV is described in detail in Section 9.
each of its neighbor on that particular interface. This TLV SHOULD NOT be included in a Hello message with the S bit
CLEAR.
The Neighbor TLV format is as shown below. The Neighbor TLV format is as 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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Status | Reserved | | Flags | State | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Peering Address (4-octet or 16-octet) | | Neighbor AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs ... | sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Neighbor TLV Figure 7: Neighbor TLV
Type: TBD5 Type: TBD5
Length: Specifies the length of the Value field in octets Length: Specifies the length of the Value field in octets
Flags : Currently defined 0x1 bit is clear when Peering Address is Flags : Current defined bits are as follows. All other bits
IPv4 and set when IPv6. Other bits SHOULD be clear by sender and SHOULD be cleared by sender and MUST be ignored by receiver.
MUST be ignored by receiver.
Status : Indicates the status code of the peering for the 0 1 2 3 4 5 6 7
particular session over this link. The following codes are +-+-+-+-+-+-+-+-+
currently defined |B| |
+-+-+-+-+-+-+-+-+
0 - Indicates 1-way detection of the peer where:
1 - Indicates rejection of the peer due to local policy reasons B bit - When SET with the adjacency state not in Accepted state
(i.e. local router would not be initiating or accepting session indicates that the adjacency is not accepted due to BFD down.
to this neighbor).
2 - Indicates 2-way detection of the peering by both neighbors State : Indicates the state code of the adjacency state machine
(refer to Section 9.2 for details) for the neighbor over this
link. The following codes are currently defined
3 - Indicates that the BGP TCP peering session has been 0 - Down (not to be used as state in this TLV
established between the neighbors
1 - Initial (not to be used as state in this TLV)
2 - 1-way
3 - 2-way
4 - Adj-Reject
5 - Adj-OK
6 - Accepted
Reserved: SHOULD be set to 0 by sender and MUST be ignored by Reserved: SHOULD be set to 0 by sender and MUST be ignored by
receiver. receiver.
Neighbor Peering Address: This 4 or 16 octet field indicates the Neighbor AS number: AS Number of the neighbor BGP router as
IPv4 or IPv6 peering address of the neighbor for which peering signaled in its Hello message.
status is being reported.
Neighbor BGP Identifier: BGP Identifier of the neighbor BGP router
as signaled in its Hello message.
Sub-TLVs : currently none defined Sub-TLVs : currently none defined
6.6. Cryptographic Authentication TLV 8.6. Cryptographic Authentication TLV
The Cryptographic Authentication TLV is an optional TLV that is used The Cryptographic Authentication TLV is an optional TLV that is used
to introduce an authentication mechanism for BGP Hello message by as part of an authentication mechanism for BGP Hello message by
securing against spoofing attacks. It also introduces a securing against spoofing attacks. It also introduces a
cryptographic sequence number carried in the Hello messages that can cryptographic sequence number carried in the Hello messages that can
be used to protect against replay attacks. Using this Cryptographic be used to protect against replay attacks. Using this Cryptographic
Authentication TLV, one or more secret keys (with corresponding Authentication TLV, one or more secret keys (with corresponding
Security Association (SA) IDs) are configured on each BGP router. Security Association (SA) IDs) are configured on each BGP router.
For each BGP Hello message, the key is used to generate and verify an For each BGP Hello message, the key is used to generate and verify an
HMAC Hash that is stored in the BGP Hello message. For the HMAC Hash that is stored in the Cryptographic Authentication TLV.
cryptographic hash function, this document proposes to use SHA-1, For the cryptographic hash function, this document proposes to use
SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard SHA-1, SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash
(SHS) [FIPS-180-4]. The HMAC authentication mode defined in Standard (SHS) [FIPS-180-4]. The HMAC authentication mode defined in
[RFC2104] is used. Of the above, implementations MUST include [RFC2104] is used. Of the above, implementations MUST include
support for at least HMAC-SHA-256, SHOULD include support for HMAC- support for at least HMAC-SHA-256, SHOULD include support for HMAC-
SHA-1, and MAY include support for HMAC-SHA-384 and HMAC-SHA-512. SHA-1, and MAY include support for HMAC-SHA-384 and HMAC-SHA-512.
Further details for ensuring the security of the BGP Hello UDP Further details for ensuring the security of the BGP Hello UDP
messages are described in Section 9. messages are described in Section 11.
The Cryptographic Authentication TLV format is as shown below. The Cryptographic Authentication TLV format is as 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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID | | Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 13 skipping to change at page 20, line 5
use, which is shown below: use, which is shown below:
HMAC-SHA1 20 bytes HMAC-SHA1 20 bytes
HMAC-SHA-256 32 bytes HMAC-SHA-256 32 bytes
HMAC-SHA-384 48 bytes HMAC-SHA-384 48 bytes
HMAC-SHA-512 64 bytes HMAC-SHA-512 64 bytes
7. Neighbor Discovery Procedure 9. Neighbor Discovery Procedure
The neighbor discovery mechanism in BGP is implemented with the The neighbor discovery mechanism in BGP is implemented with the
introduction of an Interface state in BGP and an Adjacency Finite introduction of an Interface state in BGP and an Adjacency Finite
State Machine (FSM). This section describes the states, FSM and State Machine (FSM). This section describes the states, FSM and
procedures involved. procedures involved.
7.1. Interface State 9.1. Interface Procedures
In order to perform neighbor discovery over its connected interfaces, In order to perform neighbor discovery, BGP needs to maintain state
BGP needs to maintain state for all its connected interfaces over for the subset of its connected interfaces over which neighbor
which neighbor discovery is enabled. Once the neighbor discovery is discovery is enabled. For these interfaces, BGP sends its Hello
enabled and the link is UP, then BGP starts sending its Hello messages, including the TLVs described in Section 8, as long as its
messages with the TLVs listed in Section 6. The Neighbor TLV link is UP. The Neighbor TLV described in Section 8.5 is, included
described in Section 6.5 is, however, not included until after a once a neighbor is discovered as described in Section 9.2 .
neighbor is learnt as part of the discovery process described in
further sections.
These Hello messages are originated periodically at an interval which The Hello messages MUST be originated periodically at an interval
is less than or equal to one third of the Adjacency Hold Time which is less than or equal to one third of the Adjacency Hold Time
specified in the message. The RECOMMENDED default value for the indicated by the router in its Hello message. The RECOMMENDED
Adjacency Hold Time is 45 seconds and this makes the hello message default value for the Adjacency Hold Time is 45 seconds which makes
interval to be 15 seconds. A Hello message SHOULD also be generated the hello message interval to be 15 seconds. Period Hello messages
in a triggered manner during the neighbor discovery process as a ensure robustness of the neighbor discovery mechanism against
change in the router's own or neighbor's Hello message is detected transient loss of hello messages that are sent over unreliable UDP
which results in change in adjacency state or parameters. messaging channel and also enable detection of neighbor down events
over specific links. Periodic Hello messages that do not convey any
change in state SHOULD exclude TLVs that signal the local interface
or adjacency state and have the S bit CLEAR as specified in
Section 7.
A State Change Hello message MUST be triggered, without waiting for
the periodic timer expiry, whenever there is a change in the router's
Hello TLVs' content that needs to be signaled to its neighbor over
the specific link. A State Change Hello message MUST also be
triggered when a new neighbor's Hello message is first received or
change is detected in the neighbor's Hello TLV's that results in
change in it's adjacency state. Once a State Change Hello message is
triggered on a specific interface, the router MUST continue to
generate State Change Hello messages on it with the necessary TLVs
included at periodic hello message intervals for a period of time
that is at least equal to the Adjacency Hold Time. This ensures that
messages carrying the updated information and local state changes are
not lost. The router can switch back to Periodic Hello messages
after it has transmitted State Change Hello messages with the latest
TLV contents for the Adjacency Hold Time period.
When a router receives a Hello message from its neighbor, it MUST
restart the Adjacency Hold timer that it is maintaining for the
neighbor adjacency using the value indicated in the Hello message.
When the message is of type State Change (i.e. with S bit SET), it
additionally needs to process all the TLVs included and verify the
signaled state against what was conveyed in the previous State Change
Hello message from the same neighbor. Any changed identified would
trigger the adjacency FSM change as described in Section 9.2.
When a router does not receive a Hello message from its neighbor for When a router does not receive a Hello message from its neighbor for
a period equal to Adjacency Hold Time, then it MUST clean up its a period equal to Adjacency Hold Time, then it MUST treat this as an
adjacency to this neighbor. The relationship of the Adjacency Hold adjacency down event and clean up its adjacency state to this
Timer with the BGP Hold Timer at the TCP session level is described neighbor as described in Section 9.2.
further in Section 8.
Before the interface is shut or the neighbor discovery is disabled on Before the interface is shut or the neighbor discovery mechanism is
it, the router SHOULD attempt to send out triggered Hello messages disabled on it, the router SHOULD attempt to send out immediate Hello
with Adjacency Hold Time set to 0 and without including any Neighbor messages, with the S bit CLEAR (i.e. not including state related
TLV in it to indicate that the neighbor discovery is being turned OFF TLVs) and with Adjacency Hold Time set to 0, to trigger the adjacency
on that router's interface. A router receiving a Hello message with down event on its neighbors. It MUST then clean up its own adjacency
Adjacency Hold Time set to 0 MUST clean up its adjacency to the states on that specific link.
originating router.
7.2. Adjacency State Machine When either the BGP Identifier or the AS number are modified, then
the router MUST send out a triggered Hello message, with the S bit
CLEAR and with Adjacency Hold Time set to 0 using the old BGP
Identifier and AS number values, over all the links enabled for BGP
neighbor discovery.
A router receiving a Hello message with Adjacency Hold Time set to 0
MUST treat this event as if the adjacency hold timer has expired for
the specific neighbor and proceed to bring down the adjacency.
An interface going down (e.g. due to link failure or loss of signal)
MUST immediately trigger the adjacency down event for all adjacencies
over it as if the adjacency hold timer expired for all neighbors on
that link.
9.2. Adjacency State Machine
On a per interface basis, BGP needs to maintain an adjacency state On a per interface basis, BGP needs to maintain an adjacency state
for each neighbor that it discovers. The adjacency state is for each neighbor that it discovers. The adjacency state is
maintained as a FSM and it has the following states: maintained as a FSM and it has states as described in the following
sections.
1. Init : This is the initial state that is setup when the router 9.2.1. Down State
detects a hello message from a new neighbor that it has not seen
previously. This is also the state to which the adjacency
transitions to when the router no longer sees itself in a
Neighbor TLV in the hello message from a neighbor.
2. 1-way : This is the state immediately after the Init when the This is the transient terminal state after which an adjacency is
router sends its Hello message with inclusion of the neighbor's deleted.
Peering Address in a Neighbor TLV with the status set to 1-way.
3. Reject : This is the state (generally after Init) when the router When transitioning to the Down state from Accepted, the router
detects that the neighbor cannot be accepted due to subnet removes the path corresponding to this adjacency from any Adjacency
mismatch on the addresses on either end of the link or a Route that it had setup to the neighbor's prefixes. If no other
discrepancy in its Accepted ASN List TLV or due to some other adjacency exists in Accepted state to the neighbor, then it also
local policy. The router then sends its Hello message with deletes the BGP TCP peering session(s) setup to the neighbor based on
inclusion of this neighbor's Peering Address in a Neighbor TLV the neighbor discovery mechanism.
with the status set to rejection.
4. 2-way : This is the state after 1-way when the router detects its 9.2.2. Initial State
own Peering Address in a Neighbor TLV in the neighbor's hello
message with the status set to 1-way or 2-way. It then updates
the neighbor's status to 2-way in the Neighbor TLV in its own
Hello message and sends it out. At this stage, both neighbors
have accepted each other. On transition to this state, the
router also installs peering route(s) in its own routing table
corresponding to the prefix(es) received from the neighbor in its
Local Prefix TLV so that reachability is established for the TCP
session formation. Next the TCP session formation can be
initialized via the BGP Peer FSM. If there is already a peering
route to the same address on another interfaces, then this new
interface is added as an ECMP path to it. If the BGP TCP session
is already initialized (established or connection in progress)
towards the same peering address then no further action is
required on this BGP Peer FSM.
5. Established : This is the state after 2-way when the router has This is the transient initial state from which an adjacency starts,
successfully setup its BGP TCP session with the neighbor's when the router detects a hello message from a new neighbor on the
Peering Address. It then updates the neighbor's status to link, and immediately transitions to the 1-way state.
established in the Neighbor TLV in its own Hello message and
sends it out.
Any downward transition from Established or 2-way state to a lower 9.2.3. 1-Way State
state results in removal of that interface from the peering route(s)
for that neighbor and the deletion of the route itself when the last
path is deleted. The deletion of the route may bring down the BGP
TCP session.
A BGP TCP session with an auto-discovered neighbor may have one or While in the 1-way state (or when entering it), the adjacency
more Hello adjacencies corresponding to it - one over each transitions from 1-way to 2-way state when the router detects a
interconnecting link between them. Neighbor TLV corresponding to itself in the neighbor's Hello message.
If the state does not immediately transition on to 2-way after
entering 1-way, the the router MUST immediately trigger a State
Change Hello message with the inclusion of the neighbor in a Neighbor
TLV with the state set to 1-way.
7.3. Peering Route When transitioning to the 1-way state from Accepted, the router
removes the path corresponding to this adjacency from any Adjacency
Route that it had setup to the neighbor's prefixes. If no other
adjacency exists in Accepted state to the neighbor, then it also
deletes the BGP TCP peering session(s) setup to the neighbor based on
the neighbor discovery mechanism.
BGP auto-discovered neighbors MAY setup their BGP TCP session over a Adjacency transitions to Down state for any of the following events:
loopback address instead of using the directly connected interface
address between them. When this is desired, the neighbors also
advertise the loopback address host prefix (or optionally a prefix
which covers more than a single loopback address when multiple are
used for different peering sessions) in their Local Prefix TLV.
Before the TCP session can be established, the reachability needs to
be setup in both direction by each neighbor by programming their
local prefixes in their forwarding plane. These routes that are
programmed by BGP automatically using the prefixes advertised via the
Local Prefix TLV are called Peering Routes.
Peering Routes serve two purposes. First, they enable reachability o Link goes down operationally or is administratively shut
between the Peering Addresses (generally loopbacks) of the two
neighbors so that the BGP TCP session may come up between them. o Adjacency Hold Timer expires
Second, for the BGP routes learnt over the TCP session, where the
next-hop is the neighbor, they also provide the BGP NH resolution. o Router receives a Hello message from its neighbor with Adjacency
Hold Time value set to 0
o Neighbor discovery is disabled on the link
o Change in BGP Identifier or AS number on the local router
9.2.4. 2-Way State
Upon transitioning into this state, the router triggers a State
Change Hello message with the neighbor's status set to 2-way in the
Neighbor TLV. At this stage, both neighbors have received each
other's Hello messages and thus discovered each other.
When the router, in this adjacency state, detects that the neighbor's
state for itself is 2-way or higher, then it performs the validation
checks based on local policy and information exchanged in the Hello
TLVs. Following are some of the validation checks that may be
performed on the adjacency:
o Verify subnet matching between the local and remote interface
addresses.
o Verify AS numbers based on local policy as well as against the
Allowed ASN TLV when one is being exchanged.
o Verify that BFD monitoring (when enabled) is indicating UP state.
When the adjacency passes the validation checks, it transitions to
the Adj-OK state and transitions to the Adj-Reject state otherwise.
The adjacency transitions to Down state for any of the adjacency down
events described in Section 9.2.3 .
The adjacency transitions to 1-way state when the router stops seeing
itself in a Neighbor TLV of its Neighbor's State Change Hello
messages.
9.2.5. Adj-Reject State
Upon transitioning into this state, the router triggers a State
Change Hello message with the neighbor's status set to Adj-Reject in
the Neighbor TLV.
The adjacency remains in the Adj-Reject state as long as the
parameters being exchanged via the State Change Hello messages do not
pass validation checks. The neighbors continue to include each other
in their respective State Change Hello messages.
The adjacency transitions to the Adj-OK state once the validation
checks pass (e.g. due to update in any parameters or local policy).
The adjacency transitions to Down state for any of the adjacency down
events described in Section 9.2.3 .
The adjacency transitions to 1-way state when the router stops seeing
itself in a Neighbor TLV of its Neighbor's State Change Hello
messages.
When transitioning to an Adj-Reject state from Accepted state, the
router removes the path corresponding to this adjacency from any
Adjacency Route that it had setup to the neighbor's prefixes. If no
other adjacency exists in Accepted state to the neighbor, then it
also deletes the BGP TCP peering session(s) setup to the neighbor
based on the neighbor discovery mechanism.
9.2.6. Adj-OK State
Upon transitioning into this state, the router triggers a State
Change Hello message with the neighbor's status set to Adj-OK in the
Neighbor TLV.
The adjacency transition to Adj-OK state indicates that the router
has accepted its neighbor. However, it is possible that the neighbor
has not accept it and is signaling Adj-Reject state for the adjacency
from it's end.
The adjacency transitions to the Accepted state from Adj-OK once it
detects that its neighbor is also signaling the Adj-OK or Accepted
state for it.
The adjacency transitions to Down state for any of the adjacency down
events described in Section 9.2.3 .
The adjacency transitions to 1-way state when the router stops seeing
itself in a Neighbor TLV of its Neighbor's State Change Hello
messages.
The adjacency transitions to Adj-Reject state when any of the
validation checks listed in Section 9.2.4 fail.
When transitioning to an Adj-OK state from Accepted state, the router
removes the path corresponding to this adjacency from any Adjacency
Route that it had setup to the neighbor's prefixes. If no other
adjacency exists in Accepted state to the neighbor, then it also
deletes the BGP TCP peering session(s) setup to the neighbor based on
the neighbor discovery mechanism.
9.2.7. Accepted State
The adjacency transition to Accepted state indicates that both the
neighboring routers have accepted the adjacency to each other.
On this transition, the router triggers a State Change Hello message
with the neighbor's status set to Accepted in the Neighbor TLV. It
then installs the Adjacency Route(s) for the Prefix(es) signaled by
the neighbor via the Local Prefix TLV via this adjacency link using
the neighbor's address on that link. If this is the first Accepted
adjacency to the neighbor then the Adjacency Route gets added to the
local routing table, otherwise an additional path corresponding to
this adjacency link and neighbor address on it gets added to the
existing Adjacency Route. The details are described in Section 9.3.
When this is the first Accepted adjacency to the neighbor, then the
setup of the BGP TCP session to the Peering Address(es) signaled by
the neighbor is also triggered.
The adjacency transitions to Down state for any of the adjacency down
events described in Section 9.2.3.
The adjacency transitions to 1-way state when the router stops seeing
itself in a Neighbor TLV of its Neighbor's State Change Hello
messages.
The adjacency transitions to Adj-Reject state when any of the
validation checks listed in Section 9.2.4 fail.
9.3. Adjacency Route
The Adjacency Route programming is an optional part of the BGP
Neighbor Discovery mechanism for setting up reachability for the
neighbor's prefixes signaled via the Local Prefix TLV corresponding
to adjacencies in Accepted state.
Adjacency Routes establish reachability between local prefixes on
directly connected BGP routers. They enable reachability between the
Peering Addresses (generally loopbacks) of the two neighbors so that
the BGP TCP session may come up between them. Then, for the BGP
routes learnt over the TCP session, where the next-hop is the
neighbor, they also provide the BGP NH resolution.
Unlike other BGP routes, these are not recursive routes as in they Unlike other BGP routes, these are not recursive routes as in they
point to the neighbor's interface and IP address. These routes that point to the neighbor's interface and IP address. These routes that
are setup as part of the neighbor discovery procedure are hence are setup as part of the neighbor discovery procedure are hence
different from the regular iBGP and eBGP routes. These routes also different from the regular IBGP and EBGP routes. These routes also
MUST have a better administrative distance as compared to the iBGP MUST have a better administrative distance as compared to the IBGP
and eBGP routes to ensure that they do not get displaced from the and EBGP routes to ensure that they do not get displaced from the
forwarding by BGP routes learnt over the same session that was forwarding by BGP routes learnt over the very session(s) established
established over these peering routes. using these peering routes.
The Adjacency Routes SHOULD NOT be stored in any of BGP RIBs
[RFC4271] since they are not computed based on the BGP decision
process. It is RECOMMENDED that these routes be managed in a
separate routing table within the BGP Neighbor Discovery function to
ensure that none of the processing and validation for BGP RIB affects
them and in turn they do not influence the BGP decision process and
route calculation.
When there are multiple interconnecting links between two BGP When there are multiple interconnecting links between two BGP
neighbors, a single BGP TCP session may be setup between them over neighbors, a single BGP TCP session may be setup between them over
which routes are then exchanged. However, in the forwarding, the which routes are then exchanged. However, in the forwarding, the
peering route will have multiple paths - one for each of these Adjacency route will have multiple paths - one for each of these
interconnecting links. So the BGP routes learnt over the session interconnecting links. So the BGP routes learnt over the session
actually end up getting resolved over the peering route and in turn actually end up getting resolved over this Adjacency route and in
get the ECMP load balancing even with a single BGP session. turn gets the ECMP load balancing even with a single BGP session.
8. Interactions with Base BGP Protocol 10. Interactions with Base BGP Protocol
The BGP Finite State Machine (FSM) as specified in [RFC4271] is The BGP Finite State Machine (FSM) as specified in [RFC4271] is
unchanged and the BGP TCP session establishment, route updates and unchanged and the BGP TCP session establishment, route updates and
processing continues to follow the BGP protocol specifications. processing continues to follow the BGP protocol specifications.
BGP peering addresses along with their respective ASNs have BGP peering addresses along with their respective ASNs have
traditionally been explicitly provisioned on both the BGP neighbors. traditionally been explicitly provisioned on both BGP neighbors. The
The difference that neighbor discovery mechanism brings about is in difference that neighbor discovery mechanism brings about is in
elimination of this configuration as these parameters are learnt via elimination of this configuration as these parameters are learnt via
the neighbor discovery procedure. Once BGP router learns its the neighbor discovery procedure. Once BGP router learns its
neighbor's peering address and ASN and has accepted it for peering neighbor's peering address and ASN, then its initializes the BGP Peer
based on its local policy configuration, then its initializes the BGP FSM for this neighbor in the Idle State - just as if this neighbor
Peer FSM for this neighbor in the Idle State - just as if this was configured. From thereon, the BGP Peer FSM actions follows.
neighbor was configured. From thereon, the BGP Peer FSM actions
follows.
The BGP Keepalives and Hold Timer for the session over TCP apply The BGP Keepalives and Hold Timer for the session over TCP apply
unchanged and they govern the operations of the BGP TCP session and unchanged and they govern the operations of the BGP TCP session.
when it is brought down. While the BGP Keepalive works at the TCP While the BGP Keepalive works at the TCP session level, the BGP
session level, the BGP Adjacency Hold Timer monitors the liveliness Adjacency Hold Timer monitors one or more underlying interconnecting
on one or more underlying interconnecting link between the neighbors. link adjacencies between the neighbors. The reachability for the BGP
The reachability for the BGP TCP session may be over more than one TCP session may also be over the some BGP routes learnt via routing
adjacency. The loss of BGP Hello messages on the UDP transport or updates over the sessions setup via neighbor discovery. It is likely
some link failure can result in the expiry of the Adjacency Hold that even after all the underlying interconnecting link adjacencies
Timer. However, this does not result in bringing down of the BGP TCP between two neighbors are down that the neighbor's peering address is
session for an auto-discovered BGP neighbor by default. An reachable via BGP routing over some other path in the network. In
implementation MAY provide an option to bring a BGP TCP session down order to avoid this, it is RECOMMENDED that the BGP TCP sessions
when the Adjacency Hold Timer expiry brings down the last adjacency setup via neighbor discovery mechanism use TTL set to 1 to ensure
between neighbors very similar to how BFD down brings the session they are setup only over directly attached links to the neighbors.
down.
When the BGP Peer FSM for an auto-discovered neighbor (i.e. one that Since the BGP TCP session setup via neighbor discovery was meant for
is not provisioned explicitly), is in the Idle or Connect state then hop-by-hop routing, it would be necessary to bring down the session
the adjacency state for that neighbor needs to be monitored to check even while its BGP Hold Timer has not expired for faster convergence.
if its BGP TCP session context needs to be cleaned-up. When there is Therefore, when all the underlying link adjacencies between two BGP
no adjacency state for an auto-discovered neighbor in 2-way or neighbors move out of the Accepted state (or go down), then the BGP
Established state, then the BGP TCP session FSM state for such a TCP peering session that was setup using BGP Neighbor Discovery
neighbor MUST be cleaned-up when in Idle or Connect state. This is mechanism between these two neighbors is also deleted as if it was
similar to when the configuration for a provisioned BGP neighbor is un-configured.
deleted from a BGP router.
Since the BGP neighbor discovery mechanism runs over a UDP socket, it Since the BGP neighbor discovery mechanism runs over a UDP socket, it
is isolated from the core BGP protocol working which is TCP based. is isolated from the core BGP protocol working which is TCP based.
Implementations SHOULD ensure that the hello processing does not Implementations SHOULD ensure that the hello processing does not
affect the base BGP operations and scalability. One option may be to affect the base BGP operations and scalability. One option may be to
run the BGP neighbor discovery mechanism in a separate thread from run the BGP neighbor discovery mechanism in a separate thread from
the rest of BGP processing. These implementation details, however, the rest of BGP processing. These implementation details, however,
are outside the scope of this document. are outside the scope of this document.
It is not generally expected that BGP sessions are explicitly It is not generally expected that BGP sessions are explicitly
provisioned along with the neighbor discovery mechanism. However, in provisioned along with the neighbor discovery mechanism. However, in
such an event, the neighbor discovery mechanism MUST NOT affect or such an event, the neighbor discovery mechanism MUST NOT affect or
result in any changes to provisioned BGP neighbors and their result in any changes to provisioned BGP neighbors and their
operations. Specifically, BGP peering to auto-discovered neighbors operations. Specifically, BGP peering to auto-discovered neighbors
MUST NOT be instantiated using the procedures described in this MUST NOT be instantiated using the procedures described in this
document when the same BGP neighbor is already provisioned. The document when the same BGP neighbor is already provisioned. The
configured BGP neighbor parameters take precedence and the auto- configured BGP neighbor parameters take precedence and the auto-
discovered values and parameters are not used for such configured BGP discovered values and parameters are not used for such configured BGP
sessions. sessions.
Mechanisms like BFD monitoring and Fast External Failover that are 11. Security Considerations
currently used for eBGP sessions may still continue to be used where
necessary and are not affected by the neighbor discovery mechanism.
9. Security Considerations
BGP routers accept TCP connection attempts to port 179 only from the BGP routers accept TCP connection attempts to port 179 only from the
provisioned BGP neighbors or, in some implementations, those from provisioned BGP neighbors or, in some implementations, those from
within a configured address range. With the BGP neighbor auto- within a configured address range. With the BGP neighbor auto-
discovery mechanism, it is now possible for BGP to automatically discovery mechanism, it is now possible for BGP to automatically
learn neighbors and initiate/receive TCP connections from them. This learn neighbors and initiate/receive TCP connections from them. This
introduces the need for specific considerations to be taken care of introduces the need for specific considerations to be taken care of
to ensure security of the BGP protocol operations. to ensure security of the BGP protocol operations.
This document introduces UDP messages in BGP for the neighbor This document introduces UDP messages in BGP for the neighbor
skipping to change at page 21, line 45 skipping to change at page 27, line 45
interfaces specifically enabled for neighbor discovery. Hello interfaces specifically enabled for neighbor discovery. Hello
messages MUST NOT be accepted on other than the 224.0.0.2 or FF02::2 messages MUST NOT be accepted on other than the 224.0.0.2 or FF02::2
addresses. Optionally, implementations MAY set TTL to 255 when addresses. Optionally, implementations MAY set TTL to 255 when
originating the Hello messages and receivers check specifically for originating the Hello messages and receivers check specifically for
the TLV to be 254 and discard the packet when this is not the case. the TLV to be 254 and discard the packet when this is not the case.
This ensures that the Hello packets signaling happens between This ensures that the Hello packets signaling happens between
directly connected BGP routers only. directly connected BGP routers only.
The BGP neighbor discovery mechanism is expected to be run typically The BGP neighbor discovery mechanism is expected to be run typically
in DCs and between physically connected routers that are trustworthy. in DCs and between physically connected routers that are trustworthy.
The Cryptographic Authentication TLV (as described in Section 6.6) The Cryptographic Authentication TLV (as described in Section 8.6)
SHOULD be used in deployments where this assumption of SHOULD be used in deployments where this assumption of
trustworthiness is not valid. This mechanism is similar to one trustworthiness is not valid. This mechanism is similar to one
defined for LDP Hello messages that are also UDP based as specified defined for LDP Hello messages that are also UDP based as specified
in [RFC7349]. An updated future version of this document will in [RFC7349]. An updated future version of this document will
describe similar procedures for BGP hello in more details. describe similar procedures for BGP hello in more details.
Once the BGP hello messages and the neighbor discovery mechanism is Once the BGP hello messages and the neighbor discovery mechanism is
secured, then the security considerations for BGP protocol operations secured, then the security considerations for BGP protocol operations
apply for the auto-discovered neighbor sessions. Specifically, for apply for the auto-discovered neighbor sessions.
the BGP TCP sessions with the automatically discovered directly
connected neighbors, the TTL of the BGP TCP messages (dest port=179)
MUST be set to 255. Any received BGP TCP message with TTL being less
than 254 MUST be dropped according to [RFC5082].
10. Manageability Considerations 12. Manageability Considerations
This section is structured as recommended in [RFC5706]. This section is structured as recommended in [RFC5706].
10.1. Operational Considerations 12.1. Operational Considerations
The BGP neighbor discovery mechanism introduced by this document is The BGP neighbor discovery mechanism introduced by this document is
not applicable to general BGP deployments and is specifically meant not applicable to general BGP deployments as discussed in Section 3.
for DC networks where BGP is used as a hop-by-hop routing protocol as The mechanism is specifically meant for networks where BGP is used as
described in [RFC7938]. The neighbor discovery mechanism hence a hop-by-hop routing protocol E.g. as described in [RFC7938]. The
SHOULD NOT be enabled by default in BGP. neighbor discovery mechanism hence SHOULD NOT be enabled by default
in BGP.
Implementations SHOULD provide configuration methods that allow Implementations SHOULD provide configuration methods that allow
enablement of BGP neighbor discovery on specific local interfaces. enablement of BGP neighbor discovery on specific local interfaces.
In a DC network, it is expected that the operator selects the In a DC network, it is expected that the operator selects the
appropriate links on which to enable this e.g. on a Tier 2 node it is appropriate links on which to enable this e.g. on a Tier 2 node it is
enabled on all links towards the Tier 1 and Tier 3 nodes while on a enabled on all links towards the Tier 1 and Tier 3 nodes while on a
Tier 3 node, it may be only enabled on the links towards the Tier 2 Tier 1 node, it may be only enabled on the links towards the Tier 2
node. The details of this enablement are outside the scope of this node. The details of this enablement are outside the scope of this
document since it varies based on the DC design and may be document since it varies based on the DC design and may be
implementation specific. implementation specific.
Implementations SHOULD provide configuration methods that enable the Implementations SHOULD provide configuration methods that enable the
setup of BGP neighbor templates that enables operator to setup BGP setup of BGP neighbor templates that enables operator to setup BGP
neighbor discovery parameters on the BGP router. Some of the aspects neighbor discovery parameters on the BGP router. Some of the aspects
to be considered in such a template are: to be considered in such a template are:
o Local address to be used for the BGP TCP session peering along o Local address to be used for the BGP TCP session peering along
skipping to change at page 23, line 31 skipping to change at page 29, line 28
operations of the auto-discovered BGP TCP peering sessions similar to operations of the auto-discovered BGP TCP peering sessions similar to
the provisioned BGP neighbors. the provisioned BGP neighbors.
Implementations SHOULD support logging of events like discovery of an Implementations SHOULD support logging of events like discovery of an
adjacency using neighbor discovery including peering route updates adjacency using neighbor discovery including peering route updates
and events like triggering of BGP TCP session establishment for them. and events like triggering of BGP TCP session establishment for them.
Errors and alarms related to loss of adjacencies and tear down of BGP Errors and alarms related to loss of adjacencies and tear down of BGP
TCP peering sessions SHOULD also be generated so they could be TCP peering sessions SHOULD also be generated so they could be
monitored. monitored.
10.2. Management Considerations 12.2. Management Considerations
This document introduces UDP based messaging in BGP protocol and This document introduces UDP based messaging in BGP protocol and
therefore the necessary fault management mechanisms are required to therefore the necessary fault management mechanisms are required to
be implemented for the same. Implementations MUST discard be implemented for the same. Implementations MUST discard
unsupported message types or version types other than 4 received over unsupported message types or version types other than 4 received over
a UDP session. Such messages MUST NOT affect the neighbor discovery a UDP session. Such messages MUST NOT affect the neighbor discovery
mechanism in operation using the Hello messages. Unknown TLVs mechanism in operation using the Hello messages. Unknown TLVs
received via the Hello messages MUST be ignored and the rest of the received via the Hello messages MUST be ignored and the rest of the
Hello message MUST be processed. Implementations SHOULD discard Hello message MUST be processed. Implementations SHOULD discard
Hello messages with malformed TLVs and this should be logged as an Hello messages with malformed TLVs and this should be logged as an
error. error.
11. IANA Considerations 13. IANA Considerations
This documents requests IANA for updates to the BGP Parameters This documents requests IANA for updates to the BGP Parameters
registry as described in this section. registry as described in this section.
11.1. BGP Hello Message 13.1. BGP Hello Message
This document requests IANA to allocate a new UDP port (179 is the This document requests IANA to allocate a new UDP port (179 is the
preferred number ) and a BGP message type code for BGP Hello message. preferred number ) and a BGP message type code for BGP Hello message.
Value TLV Name Reference Value TLV Name Reference
----- ------------------------------------ ------------- ----- ------------------------------------ -------------
Service Name: BGP-HELLO Service Name: BGP-HELLO
Transport Protocol(s): UDP Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>. Contact: IETF Chair <chair@ietf.org>.
Description: BGP Hello Message. Description: BGP Hello Message.
Reference: This document -- draft-xu-idr-neighbor-autodiscovery. Reference: This document -- draft-xu-idr-neighbor-autodiscovery.
Port Number: 179 (preferred value) -- To be assigned by IANA. Port Number: 179 (preferred value) -- To be assigned by IANA.
11.2. TLVs of BGP Hello Message 13.2. TLVs of BGP Hello Message
This document requests IANA to create a new registry "TLVs of BGP This document requests IANA to create a new registry "TLVs of BGP
Hello Message" with the following registration procedure: Hello Message" with the following registration procedure:
Registry Name: TLVs of BGP Hello Message. Registry Name: TLVs of BGP Hello Message.
Value TLV Name Reference Value TLV Name Reference
------- ---------------------------------- ------------- ------- ---------------------------------- -------------
0 Reserved This document 0 Reserved This document
1 Accepted ASN List This document 1 Accepted ASN List This document
2 Peering Address This document 2 Peering Address This document
3 Local Prefix This document 3 Local Prefix This document
4 Link Attributes This document 4 Link Attributes This document
5 Neighbor This document 5 Neighbor This document
6 Cryptographic Authentication This document 6 Cryptographic Authentication This document
7-65500 Unassigned 7-65500 Unassigned
65501-65534 Experimental This document 65501-65534 Experimental This document
65535 Reserved This document 65535 Reserved This document
12. Acknowledgements 14. Acknowledgements
The authors would like to thank Enke Chen for his valuable comments The authors would like to thank Enke Chen, Krishna Swamy and Ramesh
and suggestions on this document. Yakkala for their valuable comments and suggestions on this document.
13. Contributors 15. Contributors
Satya Mohanty Satya Mohanty
Cisco Cisco
Email: satyamoh@cisco.com Email: satyamoh@cisco.com
Shunwan Zhuang Shunwan Zhuang
Huawei Huawei
Email: zhuangshunwan@huawei.com Email: zhuangshunwan@huawei.com
Chao Huang Chao Huang
Alibaba Inc Alibaba Inc
skipping to change at page 25, line 32 skipping to change at page 31, line 32
Email: liujh@ruijie.com.cn Email: liujh@ruijie.com.cn
Zhichun Jiang Zhichun Jiang
Tencent Tencent
Email: zcjiang@tencent.com Email: zcjiang@tencent.com
Shaowen Ma Shaowen Ma
Juniper Networks Juniper Networks
mashaowen@gmail.com mashaowen@gmail.com
14. References 16. References
14.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>. October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>. <https://www.rfc-editor.org/info/rfc5082>.
14.2. Informative References 16.2. Informative References
[FIPS-180-4] [FIPS-180-4]
"Secure Hash Standard (SHS), FIPS PUB 180-4", March 2012. "Secure Hash Standard (SHS), FIPS PUB 180-4", March 2012.
[I-D.ietf-lsvr-bgp-spf] [I-D.ietf-lsvr-bgp-spf]
Patel, K., Lindem, A., Zandi, S., and W. Henderickx, Patel, K., Lindem, A., Zandi, S., and W. Henderickx,
"Shortest Path Routing Extensions for BGP Protocol", "Shortest Path Routing Extensions for BGP Protocol",
draft-ietf-lsvr-bgp-spf-01 (work in progress), May 2018. draft-ietf-lsvr-bgp-spf-03 (work in progress), September
2018.
[I-D.ketant-idr-bgp-ls-bgp-only-fabric] [I-D.ketant-idr-bgp-ls-bgp-only-fabric]
Talaulikar, K., Filsfils, C., ananthamurthy, k., and S. Talaulikar, K., Filsfils, C., ananthamurthy, k., Zandi,
Zandi, "BGP Link-State Extensions for BGP-only Fabric", S., Dawra, G., and M. Durrani, "BGP Link-State Extensions
draft-ketant-idr-bgp-ls-bgp-only-fabric-00 (work in for BGP-only Fabric", draft-ketant-idr-bgp-ls-bgp-only-
progress), March 2018. fabric-01 (work in progress), September 2018.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<https://www.rfc-editor.org/info/rfc4202>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009, RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>. <https://www.rfc-editor.org/info/rfc5706>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello [RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
Cryptographic Authentication", RFC 7349, Cryptographic Authentication", RFC 7349,
DOI 10.17487/RFC7349, August 2014, DOI 10.17487/RFC7349, August 2014,
<https://www.rfc-editor.org/info/rfc7349>. <https://www.rfc-editor.org/info/rfc7349>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
skipping to change at page 27, line 23 skipping to change at page 33, line 34
Cisco Systems Cisco Systems
Email: ketant@cisco.com Email: ketant@cisco.com
Kunyang Bi Kunyang Bi
Huawei Huawei
Email: bikunyang@huawei.com Email: bikunyang@huawei.com
Jeff Tantsura Jeff Tantsura
Nuage Networks Apstra
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Nikos Triantafillis Nikos Triantafillis
Apstra
Email: ntriantafillis@gmail.com Email: nikos@apstra.com
 End of changes. 129 change blocks. 
422 lines changed or deleted 764 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/