< draft-xu-idr-neighbor-autodiscovery-05.txt   draft-xu-idr-neighbor-autodiscovery-06.txt >
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Alibaba Inc Internet-Draft Alibaba Inc
Intended status: Standards Track K. Bi Intended status: Standards Track K. Bi
Expires: October 9, 2018 Huawei Expires: October 24, 2018 Huawei
J. Tantsura J. Tantsura
Nuage Networks Nuage Networks
N. Triantafillis N. Triantafillis
LinkedIn LinkedIn
K. Talaulikar K. Talaulikar
Cisco Cisco
April 7, 2018 April 22, 2018
BGP Neighbor Autodiscovery BGP Neighbor Autodiscovery
draft-xu-idr-neighbor-autodiscovery-05 draft-xu-idr-neighbor-autodiscovery-06
Abstract Abstract
BGP has been used as the underlay routing protocol in many hyper- BGP has been used as the underlay routing protocol in many hyper-
scale data centers. This document proposes a BGP neighbor scale data centers. This document proposes a BGP neighbor
autodiscovery mechanism that greatly simplifies BGP deployments. autodiscovery mechanism that greatly simplifies BGP deployments.
This mechanism is very useful for those hyper-scale data centers This mechanism is very useful for those hyper-scale data centers
where BGP is used as the underlay routing protocol. where BGP is used as the underlay routing protocol.
Requirements Language Requirements Language
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 October 9, 2018. This Internet-Draft will expire on October 24, 2018.
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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BGP Hello Message Format . . . . . . . . . . . . . . . . . . 3 3. BGP Hello Message Format . . . . . . . . . . . . . . . . . . 3
4. Hello Message Procedure . . . . . . . . . . . . . . . . . . . 5 4. Hello Message Procedure . . . . . . . . . . . . . . . . . . . 10
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 7 7.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 11
7.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7 7.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
BGP has been used as the underlay routing protocol instead of IGP in BGP has been used as the underlay routing protocol instead of IGP in
many hyper-scale data centers [RFC7938]. Furthermore, there is an many hyper-scale data centers [RFC7938]. Furthermore, there is an
ongoing effort to leverage BGP link-state distribution mechanism to ongoing effort to leverage BGP link-state distribution mechanism to
achieve BGP-SPF [I-D.keyupate-lsvr-bgp-spf]. However, BGP is not achieve BGP-SPF [I-D.keyupate-lsvr-bgp-spf]. However, BGP is not
good as an IGP from the perspective of deployment automation and good as an IGP from the perspective of deployment automation and
simplicity. For instance, the IP address and the Autonomous System simplicity. For instance, the IP address and the Autonomous System
Number (ASN) of each and every BGP neighbor have to be manually Number (ASN) of each and every BGP neighbor have to be manually
skipping to change at page 3, line 15 skipping to change at page 3, line 15
are used for BGP session establishment purpose. To make those are used for BGP session establishment purpose. To make those
loopback addresses of directly connected BGP peers reachable from one loopback addresses of directly connected BGP peers reachable from one
another, either static routes have to be configured or some kind of another, either static routes have to be configured or some kind of
IGP has to be enabled. The former is not good from the network IGP has to be enabled. The former is not good from the network
automation perspective while the latter is not good from the network automation perspective while the latter is not good from the network
simplification perspective (i.e., running less routing protocols). simplification perspective (i.e., running less routing protocols).
This draft specifies a BGP neighbor autodiscovery mechanism by This draft specifies a BGP neighbor autodiscovery mechanism by
borrowing some ideas from the Label Distribution Protocol (LDP) borrowing some ideas from the Label Distribution Protocol (LDP)
[RFC5036] . More specifically, directly connected BGP routers could [RFC5036] . More specifically, directly connected BGP routers could
automatically discovery the loopback address and the ASN of one other automatically discovery each other through the exchange of the to-be-
through the exchange of the to-be-defined BGP messages. The BGP defined BGP Hello messages. The BGP session establishment process as
session establishment process as defined in [RFC4271] could be defined in [RFC4271] could be triggered once directly connected BGP
triggered once directly connected BGP neighbors are discovered from neighbors are discovered from one another. Note that the BGP session
one another. Note that the BGP session should be established over should be established over the discovered the peering address of the
the discovered loopback address of the BGP neighbor. In addition, to BGP neighbor and in most cases the peering address is a loopback
eliminate the need of configuring static routes or enabling IGP for address. In addition, to eliminate the need of configuring static
the loopback addresses, a certain type of routes towards the BGP routes or enabling IGP for the loopback addresses, a certain type of
neighbor's loopback addresses are dynamically instantiated once the routes towards the BGP neighbor's loopback addresses as advertised as
BGP neighbor has been discovered. The administrative distance of peering addresses are dynamically instantiated once the BGP neighbor
such type of routes MUST be smaller than their equivalents that are has been discovered. The administrative distance of such type of
learnt by the regular BGP update messages . Otherwise, circular routes MUST be smaller than their equivalents that are learnt by the
dependency would occur once these loopback addresses are advertised regular BGP update messages . Otherwise, circular dependency would
via the regular BGP updates. occur once these loopback addresses are advertised via the regular
BGP updates.
2. Terminology 2. Terminology
This memo makes use of the terms defined in [RFC4271]. This memo makes use of the terms defined in [RFC4271].
3. BGP Hello Message Format 3. BGP Hello Message Format
To automatically discover directly connected BGP neighbors, a BGP To automatically discover directly connected BGP neighbors, a BGP
router periodically sends BGP HELLO messages out those interfaces on router periodically sends BGP HELLO messages out those interfaces on
which BGP neighbor autodiscovery are enabled. The BGP HELLO message which BGP neighbor autodiscovery are enabled. The BGP HELLO message
is a new BGP message which has the same fixed-size BGP header as the MUST sent as a UDP packet with a destination port of TBD (179 is the
exiting BGP messages. However, the HELLO message MUST sent as UDP preferred port number value) addressed for the "all routers on this
packets addressed to the to-be-assigned BGP discovery port (179 is subnet" group multicast address (i.e., 224.0.0.2 in the IPv4 case and
the suggested port value) for the "all routers on this subnet" group FF02::2 in the IPv6 case). The IP source address is set to the
multicast address (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in address of the interface over which the message is sent out.
the IPv6 case). The IP source address is set to the address of the
interface over which the message is sent out.
In addition to the fixed-size BGP header, the HELLO message contains The HELLO message contains the following fields:
the following fields:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hold Time | Message Length | | Version | Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS number | | AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | | TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BGP Hello Message Figure 1: BGP Hello Message
Version: This 1-octet unsigned integer indicates the protocol Version: This 1-octet unsigned integer indicates the protocol
version number of the message. The current BGP version number is version number of the message. The current BGP version number is
4. 4.
Hold Time: Hello hold timer in seconds. Hello Hold Time specifies Type: The type of BGP message (Hello - TBD value from BGP Message
the time the sending BGP peer will maintain its record of Hellos Types Registry)
from the receiving BGP peer without receipt of another Hello. A
pair of BGP peers negotiates the hold times they use for Hellos
from each other. Each proposes a hold time. The hold time used
is the minimum of the hold times proposed in their Hellos. A
value of 0 means use the default 15 seconds.
Message Length: This 2-octet unsigned integer specifies the length Message Length: This 2-octet unsigned integer specifies the length
in 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 Hello message sender.
BGP Identifier: BGP Identifier of the Hello message sender.
Hold Time: Hello hold timer in seconds. Hello Hold Time specifies
the time the receiving BGP peer will maintain its record of Hellos
from the sending BGP peer without receipt of another Hello. The
RECOMMENDED default value is 15 seconds. A value of 0 means that
the receiving BGP peer should maintain its record until the link
is UP.
Reserved: SHOULD be set to 0 by sender and MUST be ignored by
receiver.
TLVs: This field contains one or more TLVs as described below. TLVs: This field contains one or more TLVs as described below.
The Accepted ASN List TLV format is shown as follows: The Accepted ASN List TLV is an optional TLV that is used to signal
the AS numbers from which the router would accept BGP sessions. When
not signaled, it indicates that the router will accept BGP peering
from any ASN from its neighbors. Only a single instance of this TLV
is included and its 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=TBD1 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accepted ASN List(variable) | | Accepted ASN List(variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Accepted ASN List TLV Figure 2: Accepted ASN List TLV
Type: TBD1 Type: TBD1
Length:Specifies the length of the Value field in octets. Length:Specifies the length of the Value field in octets.
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.
The Connection Address TLV format is shown as follows: The Peering Address TLV is used to indicate to the neighbor the
address to which they should establish BGP session. For each peering
address, the router can specify its supported AFI/SAFI(s). When the
AFI/SAFI values are specified as 0/0, then it indicates that the
neighbor can attempt for negotiation of any AFI/SAFIs. The
indication of AFI/SAFI(s) in the Peering Address TLV is not intended
as an alternative for the MP capabilities negotiation mechanism.
The Peering Address TLV format is shown below and at least one
instance of this TLV MUST be present.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD2 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Address (4-octet or 16-octet) | | Flags | No. AFI/SAFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (4-octet or 16-octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Connection Address TLV
Type: TBD2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | SAFI | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Peering Address TLV
Type: TBD2
Length:Specifies the length of the Value field in octets. Length:Specifies the length of the Value field in octets.
Connection Address: This variable-length field indicates the IPv4 Flags : Current defined bits are as follows. All other bits
or IPv6 loopback address which is used for establishing BGP SHOULD be cleared by sender and MUST be ignored by receiver.
sessions.
The Router ID TLV format is shown as follows: Bit 0x1 - address is IPv6 when set and IPv4 when clear
Number of AFI/SAFI: indicates the number of AFI/SAFI pairs that
the router supports on the given peering address.
Reserved: sender SHOULD set to 0 and receiver MUST ignore.
Address: This 4 or 16 octect field indicates the IPv4 or IPv6
address which is used for establishing BGP sessions.
AFI/SAFI : one or more pairs of these values that indicate the
supported capabilities on the peering address.
Sub-TLVs : currently none defined
When the Peering Address used is not the directly connected interface
address (e.g. when it is a loopback address) then local prefix(es)
that cover the peering address(es) MUST be signaled by the router.
This allows the neighbor to learn these local prefix(es) and to
program routes for them over the directly connected interfaces over
which they are being signalled. The Local Prefixes TLV is used to
only signal prefixes that are locally configured on the router and
its 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=TBD3 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID (4-octet or 16-octet) | | No. of IPv4 Prefixes | No. of IPv6 Prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Router ID TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Mask | ...
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Mask | ...
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Local Prefixes TLV
Type: TBD3 Type: TBD3
Length:Specifies the length of the Value field in octets and it's Length:Specifies the length of the Value field in octets
set to 4 for the IPv4-address-formatted BGP Router ID.
Router ID: This variable-length field indicates the BGP router ID No. of IPv4 Prefixes : specifies the number of IPv4 prefixes.
which could be used for performing the BGP-SPF algorithm as When value is 0, then it indicates no IPv4 Prefixes are present.
described in [I-D.keyupate-lsvr-bgp-spf].
No. of IPv6 Prefixes : specifies the number of IPv6 prefixes.
When value is 0, then it indicates no IPv6 Prefixes are present.
IPv4 Prefix Address & Prefix Mask: Zero or more pairs of IPv4
prefix address and their mask.
IPv6 Prefix Address & Prefix Mask: Zero or more pairs of IPv6
prefix address and their mask.
Sub-TLVs : currently none defined
The Link Attributes TLV is a mandatory TLV that signals to the
neighbor the link attributes of the interface on the local router. A
single instance of this TLV MUST be present in the message. The Link
Attributes TLV is as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of IPv4 Addresses | No. of IPv6 Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Local Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Mask | ...
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Local Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Mask | ...
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Link Attributes TLV
Type: TBD4
Length:Specifies the length of the Value field in octets
Local Interface ID : the local interface ID of the interface (e.g.
the MIB-2 ifIndex)
Flags : Currently defined bits are as follows. Other bits SHOULD
be cleared by sender and MUST be ignored by receiver.
Bit 0x1 - indicates link is enabled for IPv4
Bit 0x2 - indicates link is enabled for IPv6
Reserved: SHOULD be set to 0 by sender and MUST be ignored by
receiver.
No. of IPv4 Addresses : specifies the number of IPv4 local
addresses on the interface. When value is 0, then it indicates no
IPv4 Prefixes are present or the interface is IP unnumbered.
No. of IPv6 Addresses : specifies the number of IPv6 Global
addresses on the interface. When value is 0, then it indicates no
IPv6 Global Prefixes are present or the interface is only
configured with IPv6 link-local addresses
IPv4 Address & Mask: Zero or more pairs of IPv4 address and their
mask.
IPv6 Address & Mask: Zero or more pairs of IPv6 address and their
mask.
Sub-TLVs : currently none defined
The Neighbor TLV is used by a BGP router to indicate the peering
address and information about the neighbors that have been discovered
by the router on the specific link and their status. The BGP session
establishment process begins when both the neighbors accept each
other over at least one underlying inter-connecting link between
them. The Neighbor TLV format is as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Peering Address (4-octet or 16-octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Neighbor TLV
Type: TBD5
Length:Specifies the length of the Value field in octets
Flags : Currently defined 0x1 bit is clear when Peering Address is
IPv4 and set when IPv6. Other bits SHOULD be clear by sender and
MUST be ignored by receiver.
Status : Indicates the status code of the peering for the
particular session over this link. The following codes are
currently defined
0 - Indicates 1-way detection of the peer
1 - Indicates rejection of the peer due to local policy reasons
(i.e. local router would not be initiating or accepting session
to this neighbor)
2 - Indicates 2-way detection of the peering by both neighbors
3 - Indicates that the BGP peering session has been established
between the neighbors and that this link would be utilized for
forwarding to the peer BGP nexthop
Reserved: SHOULD be set to 0 by sender and MUST be ignored by
receiver.
Neighbor Peering Address: This 4 or 16 octect field indicates the
IPv4 or IPv6 peering address of the neighbor for which peering
status is being reported.
Sub-TLVs : currently none defined
4. Hello Message Procedure 4. Hello Message Procedure
A BGP peer receiving Hellos from another peer maintains a Hello A BGP peer receiving Hellos from another peer maintains a Hello
adjacency corresponding to the Hellos. The peer maintains a hold adjacency corresponding to the Hellos. The peer maintains a hold
timer with the Hello adjacency, which it restarts whenever it timer with the Hello adjacency, which it restarts whenever it
receives a Hello that matches the Hello adjacency. If the hold timer receives a Hello that matches the Hello adjacency. If the hold timer
for a Hello adjacency expires the peer discards the Hello adjacency. for a Hello adjacency expires the peer discards the Hello adjacency.
We recommend that the interval between Hello transmissions be at most We recommend that the interval between Hello transmissions be at most
one third of the Hello hold time. one third of the Hello hold time.
A BGP session with a peer has one or more Hello adjacencies. A BGP session with a peer has one or more Hello adjacencies.
A BGP session has multiple Hello adjacencies when a pair of BGP peers A BGP session has multiple Hello adjacencies when a pair of BGP peers
is connected by multiple links that have the same connection address is connected by multiple links that have the same connection address
(e.g., multiple PPP links between a pair of routers). In this (e.g., multiple point-to-point links between a pair of routers). In
situation, the Hellos a BGP peer sends on each such link carry the this situation, the Hellos a BGP peer sends on each such link carry
same Connection Address. In addition, to eliminate the need of the same Peering Address. In addition, to eliminate the need of
configuring static routes or enabling IGP for advertising the configuring static routes or enabling IGP for advertising the
loopback addresses, a certain type of routes towards the BGP loopback addresses, a certain type of routes towards the BGP
neighbor's loopback addresses (e.g., carried in the Connection neighbor's loopback addresses (i.e. carried in the Local Prefixes
Address TLV) could be dynamically created once the BGP neighbor has TLV) could be dynamically created once the BGP neighbor has been
been discovered. The administrative distance of such type of routes discovered. The administrative distance of such type of routes MUST
MUST be smaller than their equivalents which are learnt via the be smaller than their equivalents which are learnt via the normal BGP
normal BGP update messages. Otherwise, circular dependency problem update messages. Otherwise, circular dependency problem would occur
would occur once these loopback addresses are advertised via the once these loopback addresses are advertised via the normal BGP
normal BGP update messages as well. update messages as well.
BGP uses the regular receipt of BGP Hellos to indicate a peer's BGP uses the regular receipt of BGP Hellos to indicate a peer's
intent to keep BGP session identified by the Hello. A BGP peer intent to keep BGP session identified by the Hello. A BGP peer
maintains a hold timer with each Hello adjacency that it restarts maintains a hold timer with each Hello adjacency that it restarts
when it receives a Hello that matches the adjacency. If the timer when it receives a Hello that matches the adjacency. If the timer
expires without receipt of a matching Hello from the peer, BGP expires without receipt of a matching Hello from the peer, BGP
concludes that the peer no longer wishes to keep BGP session for that concludes that the peer no longer wishes to keep BGP session for that
link or that the peer has failed. The BGP peer then deletes the link or that the peer has failed. The BGP peer then deletes the
Hello adjacency. The route towards the BGP neighbor's loopback Hello adjacency. The route towards the BGP neighbor's loopback
address that had been dynamically created due to that BGP Hello address that had been dynamically created due to that BGP Hello
adjacency SHOULD be deleted accordingly. When the last Hello adjacency SHOULD be deleted accordingly. When the last Hello
adjacency for an BGP session is deleted, the BGP peer terminates the adjacency for an BGP session is deleted, the BGP peer terminates the
BGP session and closing the transport connection. BGP session and closing the transport connection.
5. Contributors 5. Contributors
Satya Mohanty Satya Mohanty
Cisco Cisco
Email: satyamoh@cisco.com Email: satyamoh@cisco.com
Shunwan Zhuang
Huawei
Email: zhuangshunwan@huawei.com
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Enke Chen for his valuable comments The authors would like to thank Enke Chen for his valuable comments
and suggestions on this document. and suggestions on this document.
7. IANA Considerations 7. IANA Considerations
7.1. BGP Hello Message 7.1. BGP Hello Message
This document requests IANA to allocate a new UDP port for BGP Hello This document requests IANA to allocate a new UDP port (179 is the
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: TBD1 (179 is the suggested value) -- To be assigned by IANA. Port Number: TBD1 (179 is the preferred value) -- To be assigned by IANA.
7.2. TLVs of BGP Hello Message 7.2. TLVs of BGP Hello Message
This document requests IANA to create a new registry "TLVs of BGP This document requests IANA to create a new registry "TLVs of BGP
Hello Message" with the following registration procedure: Hello Message" with the following registration procedure:
Registry Name: TLVs of BGP Hello Message. Registry Name: TLVs of BGP Hello Message.
Value TLV Name Reference Value TLV Name Reference
------- ------------------------------------------ ------------- ------- ------------------------------------------ -------------
0 Reserved This document 0 Reserved This document
1 Accepted ASN List This document 1 Accepted ASN List This document
2 Connection Address This document 2 Peering Address This document
3 Router ID This document 3 Local Prefixes This document
4-65500 Unassigned 4 Link Attributes This document
5 Neighbor This document
6-65500 Unassigned
65501-65534 Experimental This document 65501-65534 Experimental This document
65535 Reserved This document 65535 Reserved This document
8. Security Considerations 8. Security Considerations
For security purposes, BGP speakers usually only accept TCP For security purposes, BGP speakers usually only accept TCP
connection attempts to port 179 from the specified BGP peers or those connection attempts to port 179 from the specified BGP peers or those
within the configured address range. With the BGP neighbor auto- within the configured address range. With the BGP neighbor auto-
discovery mechanism, it's configurable to enable or disable sending/ discovery mechanism, it's configurable to enable or disable sending/
receiving BGP hello messages on the per-interface basis and BGP hello receiving BGP hello messages on the per-interface basis and BGP hello
 End of changes. 34 change blocks. 
82 lines changed or deleted 286 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/