BGP Auto
DiscoveryIndividualrobert@raszuk.netGoogle1600 Amphitheatre ParkwayMountain ViewCA94043USjrmitche@puck.nether.netGoogle1600 Amphitheatre ParkwayMountain View, CA94043USwarren@kumari.netArrcusUSkeyur@arrcus.comJuniper Networks1194 N. Mathilda AveSunnyvaleCAUSAjgs@juniper.netThis document describes a method for automating portions of a
router's BGP configuration via discovery of BGP peers with which to
establish further sessions from an initial "bootstrap" router. This
method can apply for establishment of either Internal or External BGP
peering sessions.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.An idea for IBGP Auto Mesh was originally presented
at IETF 57. The concept made use of an IGP (either ISIS or OSPF) for
flooding BGP auto discovery information. In this proposal both
auto-discovery/bootstrapping and propagation of BGP configuration
parameters occur within the BGP4 protocol itself.The IGP based IBGP discovery mechanism presented was well fitted to
the native IP switching, in which all nodes in the IGP need to
participate in BGP mesh. However, it also came with a number of
drawbacks, some of which include the requirement for leaking between
area boundaries or possible race conditions between disjoint flooding
paths from which the information arrived.The BGP peer auto discovery mechanism described in this document was
conceived initially in 2008 as a way to distribute peering session
establishment information via BGP for IBGP applications which are only
active on the edge of the network. For example, these applications
include BGP MPLS IP VPNs , rt-constrain
, flow-spec , or Multicast VPNs . However the idea was not documented for the
community to discuss further at that time.In 2011, another solution for BGP peer discovery that targeted EBGP
peer discovery for Internet Exchange Point (IXP) participants was
described in . This idea
was useful as a potential alternative solution for operators who wished
to maintain individual peering sessions with other IXP participants,
rather than receiving information through route-servers operated by the
IXP operator without the associated administrative burden of configuring
and maintaining sessions with all the other participants. This draft
distributed the participant sessions information utilizing a BGP
capability code that was ill-suited for
updating the information after initial session establishment.This draft represents an attempt by the authors of both drafts to
provide a solution that can be used in multiple IBGP or EBGP
applications when the operator desires to automatically collect and
distribute basic BGP session establishment information from a
centralized BGP speaker.The base BGP-4 specification utilizes
TCP for session establishment between peers, which requires prior
knowledge of the endpoint's address to which a BGP session should be
targeted. This endpoint in most deployments is configured manually by
the operator at each end of pair of network elements. In numerous
applications, the list of all valid endpoints may be available
centrally; however, the task of configuring or updating all of the
network elements that require this information becomes a much larger
task.The most typical application of this in most networks is the
establishment of a full mesh of IBGP routers to distribute standard IPv4
and IPv6 unicast routing information, such as the Internet route table,
within an Autonomous System (AS). This was one of the reasons that lead
to the introduction of BGP Route Reflection . The most common benefits/drawbacks associated
with route reflection are listed below:Configuration ease when adding or deleting new IBGP peersReduction number of TCP sessions to be handled by ASBRs/PEsInformation reduction – best path propagation onlyLimitation for new applications that require more than best path
propagationRoute instabilities caused by information reduction (ex:
oscillations) etc. ...Another application which requires prior knowledge of a large number
of BGP endpoints is at Internet Exchange Points (IXP). These networks
are specifically built and operated as locations for different networks
to peer and exchange traffic. Multilateral Interconnection at an IXP
is
utilized to avoid having each participant at the IXP having to contact
all of the other participants to enter into peering relationships,
utilizing a Route Server (RS). Some of the reasons why participants peer
with route-servers at IXPs include:reducing the administrative burden of arranging and configuring
BGP sessions with all the other participantsnot wanting (or being able) to carry views from all the
participantsrelying on the IXP operator to implement routing policy decisions
(see )This document describes an alternate solution for BGP peering session
endpoint information discovery. This alternate solution reduces the
administrative burden of configuring and maintaining BGP sessions in
both IBGP applications (such as the full or partial mesh) and EBGP
applications (such as at an IXP) as described above. This document does
not address the other reasons why operators may choose to take alternative
approaches that still require manual configuration or relying other
devices for routing information distribution; however, auto-discovery
and manual configuration are not mutually exclusive, and it is expected
that some network elements will utilize both approaches.In many cases existing route reflectors (in the IBGP use case) or
route-servers (in the IXP) case may be utilized for the bootstrapping
discovery mechanism in this document. This has several advantages:Re-use of already deployed devices for an add on and incremental
automated BGP peer discoveryCurrent place and operation in the network is optimal for session
establishment for the relevant subset of clients that need the
information.A verification only mode to analyze and generate a warning only
message when manual IBGP peering configuration mistakes are
detected.The amount of discovery information distributed via this mechanism is
likely to be orders of magnitude less than the amount of underlying
prefix (or other information) distributed today by existing route
reflectors or route servers, so scalability for this mechanism should
not be a concern.This mechanism is designed to work on a per AFI/SAFI basis. For
example, a currently deployed route reflector, providing route
reflection for IPv4 unicast routes could continue in that function and
at the same time provide a BGP peer discovery functionality for that or
other address families. That could have a very positive effect for the
deployment of any of the new address families as core RRs would not need
to be upgraded to support new address families yet could still serve as
information brokers for them.In order to propagate information describing their BGP active
configuration (activated AFI/SAFIs) we propose to define a new address
family with the NLRI format of <Group_ID:Router_ID>.The new address family will inherit current BGP update & msg
formats as well as all necessary attributes used for normal and loop
free BGP route distribution.The Group Identifier Group_ID is a four octet value, and Router_ID is
a four octet value .The new type code for the new BGP Peer Discovery AFI/SAFI will be
TBD1.The role of the Group_ID is to allow scoped group creation in the
same ASN/AFI/SAFI tuple. If not set by the operator, implying all peers
will be in the same group, this value will be all zeros.The way to group mesh interconnectivity is left to the operator. The
Group_ID could be used for instance to group sub-AS or RR clients (if
the RR is not doing client to client reflection), or for tying sets of
EBGP peers to specific policy. A similar model takes place today for
interconnecting confederation Sub-ASes as described in .A new BGP Peer Discovery Attribute is defined to carry information
about all activated and flagged for automatic provisioning AFI/SAFIs by
a given BGP speaker. The format of the new BGP Peer Discovery Attribute
is defined below in :The attribute flags and type code fields are detailed in :Bit 0 - Optional attribute (value 1)Bit 1 - Non transitive attribute (value 0)Bit 2 - Partial bit (value 0 for optional non transitive
attributes)Bit 3 - Extended length of two octets (value 1)Bit 4-7 - Unused (value all zeros)Type code - Attribute type code TBD2Each BGP Peer Discovery Attribute contains one or more of the
AFI/SAFI Descriptors as shown in :AFI/SAFI Descriptor Flags (1 octet):O bit - Route originator or EBGP speaker (Yes – 1, No
– 0)F bit - Force new peering. Default not set – 0, set –
1.I bit - Informational only (Do not attempt to establish a BGP
connection)Peer Autonomous System Number:This is the neighbor's BGP Autonomous System Number (ASN), as
described in , that should be expected
for peering, iBGP if it matches the local router ASN, eBGP
otherwise.Identifier:This field is set to 0. If a non-zero value is set then the peer
connection should be viewed as a tuple of
<AFI/SAFI/Identifier>. Also at the same time the peer
connection should be viewed as <AFI/SAFI/Identifier> and a
separate connection should be initiated if the peer connection is
not yet established.Peering Address:Depending on the value of Peering AFI peering address on which
BGP speaker is expecting to receive BGP session OPEN messages.The special value of AFI/SAFI Descriptor can be all zeros. That will
indicate that the information contained in the Group_id applies to all
AFI/SAFIs given receiver supports. In those cases BGP OPEN msg will
negotiate the subset of AFI/SAFIs to be established between given BGP
peers.It is expected that when Router_ID is changed on the BGP speaker
sessions are restarted and therefore NLRI received with the former
Router_ID withdrawn. When sessions restart, the new Router_ID will be
sent in the NLRI corresponding to the BGP speaker with the reconfigured
Router_ID. It is highly advised to change Router_ID only when critical
as the impact to BGP is for any AFI/SAFI sever. An implementation may
force the user to configure BGP Router_ID explicitly, before activating
the new BGP Peer Discovery AFI/SAFI.From the RR perspective as each BGP speaker can have only one
Router_ID value, there would be only a single BGP Peer Discovery NLRI
originated by one. It was a conscious design decision not to create a
new BGP attribute for the reflector and require route reflector to build
an aggregate list of AFI/SAFI descriptors common to given set of BGP
Peer Discovery NLRIs in such a new attribute. We prefer to allow RR to
remain simple with no additional code changes required for the price of
no update packing possibility when it handles BGP Peer Discovery NLRIs
in an atomic way.Implementations MAY support local configuration of all possible
remote peering address ranges, autonomous system numbers or other
filters expected to be received via BGP Peer Discovery, or on a per
group basis. Implementations SHOULD allow operators to group specific
auto-discovered peers with specific groups based on Group_ID.On the receive side, a persistent cache SHOULD be maintained by BGP
with all received information about other BGP speakers announcing their
BGP Peer Discovery information in a given Group’s scope.BGP Peer Discovery implementation should allow for per address
family, subsequent address family and Group_ID disjoint topologies
granularity.When multiple AFI/SAFI pairs match on any two BGP speakers and value
of the Identifier passed on AFI/SAFI Descriptor field is set to all
zeros only one BGP session should be attempted. Regular BGP capabilities
will be used to negotiate given AFI/SAFI mutual set. AFI/SAFI
granularity is required to allow for disjoint topologies of different
information being distributed by BGP.BGP speakers "O" flag eligible may establish session with any other
BGP speaker if passing all peering criteria for a given AFI/SAFI.BGP speakers "O" flag not eligible (ex: P routers) should not
establish IBGP peering to any other "O" flag not eligible BGP
speakers.When peering address changes for an existing AFI/SAFI and new BGP
update is received with the new peering address old peering should
remain intact when "F" flag is not set (default = 0). When session is
cleared manually or goes down for any other reason, the new peering
address should be used.When "F" flag is set new peering address should be used immediately
and current BGP session to the peer restarted for given AFI/SAFI.All implementations SHOULD still allow manual neighbor establishments
which in fact could be complimentary and co-existing to the BGP Peer
Auto Discovery neighbors.In addition BGP Peer Auto Discovery exchange can be enabled just for
informational purposes while provisioning would remain manual before
operational teams get familiar with new capability and verify it's
mechanics.Within each Group_ID upon which auto-discovery is enabled, it is
expected that neighbors will form sessions with all peers received
within the group. This allows the building of full-mesh or partial-mesh
topologies of peers for iBGP by varying the Group_ID field.Incremental deployment with enabling just a few routers to advertise
BGP Peer Discovery AF while maintaining manual configuration based
peering with the rest of the network is supported.Another key aspect of today's BGP deployment, other then peer to peer
filtering push via ORF , is outbound
customization of BGP information to be distributed among various peers.
The most common tools for such customization could be peer templates,
peer groups or any other similar local configuration grouping.
Individual members of such groups can still be added to them manually,
and BGP auto-discovery peers can be grouped to such groups using the
Group_ID. The Peer Discovery implementation supports the ability to
specify peer ranges which could automatically achieve addition or
deletion of BGP peers to such groups. This can save a lot of manual
configuration and customization for outbound policies shared by multiple
peers. Individual session customization would be still possible by
manual provisioning.A BGP speaker that wishes to exchange BGP Peer Discovery Information
must use the the BGP Multiprotocol Extensions Capability Code as defined
in , to advertise the corresponding (AFI,
SAFI) pair.This document defines a new BGP Auto Discovery SAFI type code TBD1
which will be used to carry local BGP peering configuration data. That
value will need to be assigned by IANA from BGP SAFI Type Code
space.This document defines a new NLRI format, called BGP Auto Discovery
NLRI, to be carried in BGP Auto Discovery SAFI using BGP multiprotocol
extensions. This document defines a new BGP optional transitive
attribute, called BGP Peer Discovery Attribute. A new attribute type
code TBD2 is to be assigned by IANA from the BGP path attribute Type
Code space.This document defines a new BGP Capability Type code (TBD3) to be
allocated by IANA.Once TBD1, TBD2, and TBD3 values are allocated please replace them in
the above text.This document allows for local configuration of BGP authentication
mechanisms such as BGP-MD5 or TCP-AO and these are highly recommended for
deployment on the BGP peer auto-discovery neighbor sessions. Similar
authentication could be configured on a per peer or peer-group basis
based on the auto-discovery information received before session
establishment, however no exchange of authentication information occurs
within the protocol itself. Operators SHOULD NOT use peer auto-discovery
with untrusted peers as attacks on implementation scalability could be
triggered by overwhelming the router with a larger number of
auto-discovery peers then can be supported. Operators should also use
caution on what addresses and AFI/SAFI combinations they want to allow
reception of auto-discovery information for.The BGP auto-discovery idea contained in this document was originally
developed by Pedro Roque Margues and Robert Raszuk in 2008 to cover the
IBGP full mesh use case however it was not published at that time.TBD