BGP Extended Community
for Identifying the Target NodesHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinajie.dong@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinazhuangshunwan@huawei.comNokiaAntwerpBEgunter.van_de_velde@nokia.comBGP has been used to distribute different types of routing and policy
information. In some cases, the information distributed may be only
intended for one or a particular group of BGP nodes in the network.
Currently BGP does not have a generic mechanism of designating the
target nodes of the routing information. This document defines a new
type of BGP Extended Community called "Node Target". The mechanism of
using the Node Target Extended Community to steer BGP route distribution
to particular BGP nodes is specified.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.BGP has been used to distribute different
types of routing and policy information. In some cases, the information
distributed may be only intended for one or a particular group receiving
BGP nodes in the network. One typical use case is the distribution of
BGP Flow Spec rules only to a particular group of
BGP nodes. Such a targeting mechanism is considered useful that it can
save the resources on nodes which do not need that information.Currently BGP does not have a generic mechanism of designating the
set of nodes to which the information is to be distributed. Route Target
(RT) as defined in was designed for the
matching of VPN routes into the target VPN Routing and Forwarding tables
(VRFs) on PE nodes. Although introduces the
mechanism of steering the SR policy information to the target head end
node based on RT, it is only defined for the SR Policy Address Family.
Although it is possible to reuse RTs to control the distribution of
non-VPN information to one or a group of receiving nodes, such mechanism
is not applicable when the information to be distributed is VPN-specific
and is advertised with a set of RTs for the VRF matching. In that case,
the matching of any of the VPN RTs in the Update will result in the
information eligible for installation, regardless of whether the RTs
representing the target nodes are matched or not. Thus a mechanism which
is independent from the control of VPN route to VRF distribution is
needed.Another possible approach is to configure, on each router, a
community and the corresponding policies to match the community to
determine whether to accept the received routes. Such mechanism relies
on manual configuration thus is considered error-prone. It is preferable
by some operators that an automatic approach can be provided, which
would make the operation much easier.This document defines a new type of BGP Extended Community called
"Node Target". The mechanism of using the Node Target extended community
to steer BGP route distribution to particular BGP nodes is also
specified.This section defines a new BGP Extended Community called "Node Target Extended Community". It can be a
transitive extended community with the high-order octect of the type set
to 0x01, or a non-transitive extended community with the high-order
octect type set to 0x41. The sub-type of the Node Target Extended
Community is TBA.The format of Node Target Extended Community is shown in Figure
1.Where:Target BGP Identifier (4 octets): The BGP Identifier of a target
node. It is a 4-octet, unsigned, non-zero integer as defined in .Reserved field (2 octets): Reserved for future use, MUST be set to
zero on transmission and ignored on receipt.One or more Node Target extended communities MAY be carried in an
Update message to designate a group of target BGP nodes.In this section, the mechanism for intra-domain scenario is
described, the mechanism for inter-domain scenario is for further study.
The domain here refers to an administrative domain, which may consists
of one or multiple ASes managed by a single operator.When a network controller or BGP speaker plans to advertise some BGP
routing or policy information only to one or a group of BGP nodes in the
network, it MUST put the BGP Identifier of each target node into the
Node Target extended communities, and attach the Node Target extended
communities to the routes or policies to be advertised.When a BGP speaker receives a BGP Update which contains one or more
Node Target extended communities, it MUST check the target BGP
Identifiers carried in the Node Target extended communities of the
Update.If the target BGP Identifier in any of the Node Target extended
community matches with the local BGP Identifier, this node is one of
the target nodes of the Update, the information in the Update is
eligible to be kept and installed on this node.If this node is a Route Reflector, and in the Update there is
one or more Node Target extended communities which contains
non-local BGP Identifiers, information in the Update are
eligible be reflected to its peers according to the rules
defined in . The RR may check the BGP
Identifiers of its peers to determine the set of peers which are
the target nodes of the Update, and only reflect the information
in the Update to the matched BGP peers.If this node is an Autonomous System Border Router (ASBR),
and the BGP Identifiers of one or more of its EBGP peers match
with the Node Target extended communities in the Update,
information in the Update is eligible to be advertised to the
matched EBGP peers.If the target BGP Identifier in any of the Node target extended
community does not match with the local BGP Identifier, this node is
not the target node of Update, the information in the Update is not
eligible to be installed on this node.If this node is a Route Reflector, information in the Update
is eligible to be reflected to its peers according to the rules
defined in . The RR may check the BGP
Identifiers of its peers to determine the set of peers which are
the target nodes of the Update, and only reflect the information
in the Update to the matched BGP peers.The Node Target extended community introduced in this document can be
deployed incrementally in the network. For BGP speakers which understand
the Node Target extended community, it is used to determine whether the
nodes are the target nodes of the Update. For BGP speakers which do not
understand the Node Target extended community, it will be ignored and
the information in the Update will be processed and advertised based on
normal BGP procedure. Although this could ensure that the target nodes
can always obtain the information needed, this may result in unnecessary
state maintained on legacy BGP speakers. And if the information
advertised is the Flow Spec rules, the legacy BGP speakers may install
unnecessary flowspec rules, this may have impact on traffic which
matches such rules, thus may result in unexpected traffic steering or
filtering behaviors on such nodes. This may be mitigated by setting
appropriate routing policies on the legacy BGP nodes.This document requests that IANA assigns one new sub-type for "Node
Target Extended Community" from the "Transitive IPv4-Address-Specific
Extended Community" registry of the "BGP Eextended Communities"
registry.This document requests that IANA assigns the same sub-type for "Node
Target Extended Community" from the "Non-Transitive
IPv4-Address-Specific Extended Community" registry of the "BGP Eextended
Communities" registry.This document does not change the security properties of BGP.The authors would like to thank Zhenbin Li, Ercin Torun, Jeff Haas
and Robert Raszuk for the review and discussion of this document.