Network Working Group J. Dong
Internet-Draft S. Zhuang
Intended status: Standards Track Huawei Technologies
Expires: September 6, 2018 G. Van de Velde
Nokia
March 5, 2018
BGP Extended Community for Identifying the Target Node
draft-dong-idr-node-target-ext-comm-00
Abstract
BGP has been used to distribute different types of routing and policy
information in the network. In some cases, the information
distributed may be only intended for one or several particular
receiving BGP nodes in the network. BGP does not have a general
mechanism for designating the receiving node of the routing
information. This document defines a new type of BGP extended
community called "Node Target". The mechanism and of using the Node
Target extended community to steer BGP route distribution to
particular BGP nodes is specified.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Dong, et al. Expires September 6, 2018 [Page 1]
Internet-Draft BGP Node Target Extended Community March 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Node Target Extended Communities . . . . . . . . . . . . . . 3
2.1. IPv4 Node Target Extended Community . . . . . . . . . . . 3
2.2. IPv6 Node Target Extended Community . . . . . . . . . . . 3
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
BGP [RFC4271] has been used to distribute different types of routing
and policy information in the network. In some cases, the
information distributed may be only intended for one or several
particular receiving BGP nodes in the network. A typical use case is
the distribution of BGP FlowSpec [RFC5575] policies to some
particular BGP nodes.
BGP does not have a general mechanism for designating the receiving
nodes of the information to be distributed. Route Target (RT) as
defined in [RFC4364] is used for the distribution of VPN routes into
the target VPN Routing and Forwarding tables (VRFs) on a set of PE
nodes. Although it is possible to use RTs to control the
distribution of non VPN-specific information to a particular node,
such mechanism is not applicable when the information to be
distributed is VPN-specific and relies on RTs to match the target
VRF. Thus a new mechanism is needed to control the distribution of
Dong, et al. Expires September 6, 2018 [Page 2]
Internet-Draft BGP Node Target Extended Community March 2018
BGP information to particular BGP nodes, which is independent from
the control of VPN route distribution to VRF.
2. Node Target Extended Communities
2.1. IPv4 Node Target Extended Community
For IPv4 networks, this section defines a new BGP extended community
[RFC4360] called "IPv4 Node Target Extended Community". It is a
transitive extended community with type 0x01 and sub-type TBA.
The format of IPv4 Node Target Extended Community is shown in
Figure 1.
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 (0x01) | Sub-Type (TBA)| Target IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IPv4 Address (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IPv4 Node Target extended community
Target IPv4 address field: A local IPv4 address of the target node.
When the target IPv4 address is set to 0.0.0.0, it means all the BGP
nodes in the network are the target nodes.
Reserved field: Reserved for future use, MUST be set to zero on
transmission and ignored on receipt.
One or more IPv4 Node Target extended communities may be carried in a
BGP Update message.
2.2. IPv6 Node Target Extended Community
For IPv6 networks, a new IPv6 Address Specific BGP Extended Community
[RFC5701] called "IPv6 Node Target extended community" is defined.
It is a transitive IPv6 address specific extended community with type
0x00 and sub-type TBA.
The format of this extended community is shown in Figure 2.
Dong, et al. Expires September 6, 2018 [Page 3]
Internet-Draft BGP Node Target Extended Community March 2018
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 (0x00) | Sub-Type (TBA)| Target IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IPv6 Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IPv6 Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IPv6 Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IPv6 Address (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IPv6 Node Target extended community
Target IPv6 address field: A IPv6 address of the target node. When
the target IPv6 address is set to "0:0:0:0:0:0:0:0" ( :: ), it means
all the BGP nodes in the network are the target nodes.
Reserved field: Reserved for future use, MUST be set to zero on
transmission and ignored on receipt.
One or more IPv6 Node Target extended communities may be carried in a
BGP Update message.
3. Procedures
In this version only the usage of the proposed mechanism in the
intra-AS scenario is described, more details about the inter-AS
scenario is for further study.
When a controller or BGP speaker plans to advertise some BGP
information only to some particular BGP nodes in the network, it MUST
put the IPv4 or IPv6 address of each target node into the IPv4 or
IPv6 Node Target extended communities, and attach the IPv4 or IPv6
Node Target extended communities to the BGP Update message to be
advertised.
If a non-RR BGP speaker receives an Update message which contains one
or more IPv4 or IPv6 Node Target extended communities, it MUST check
the target IPv4 or IPv6 addresses carried in the extended
communities.
o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node
Target extended community matches with one of the local IP
addresses, the receiving BGP speaker is one of the target nodes of
the information in the Update, and the information in the Update
is eligible to be kept and installed by the receiving BGP speaker.
Dong, et al. Expires September 6, 2018 [Page 4]
Internet-Draft BGP Node Target Extended Community March 2018
o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node
Target extended community does not match with any local IP
address, the receiving BGP speaker is not the target node of
information in the Update, the information in the received Update
message MUST not be used.
If a route-reflector (RR) receives an BGP Update message which
contains one or more IPv4 or IPv6 Node Target extended communities,
it MUST check the target IPv4 or IPv6 addresses carried in the IPv4
or IPv6 Node Target extended communities.
o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node
Target extended community matches with one of the local IP
addresses, this RR is one of the target nodes of information in
the Update, and such information is eligible to be kept and
installed by this RR. If there is no other IPv4 or IPv6 Node
Target extended communities in the Update, the RR MUST NOT
advertise the information in this Update further to its neighbors.
If there is other IPv4 or IPv6 Node Target extended communities,
the RR SHOULD first remove the local matched Node Target extended
community, then reflect the routes with the remaining Node Target
Extended Communities according to [RFC4456].
o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node
target extended community does not match with any local IP
address, this RR is not the target node of routes in the Update,
the rules defined in [RFC4456] are used for the reflection of the
received route.
4. IANA Considerations
This document requests that IANA assigns one new sub-type for "IPv4
Node Target extended community" from the "Transitive IPv4-Address-
Specific Extended Community" registry of the "BGP extended
communities" registry.
This document requests that IANA assigns one new type for "IPv6 Node
Target extended community" from the "Transitive IPv6-Address-Specific
Extended Community" registry of the "BGP extended communities"
registry.
5. Security Considerations
This document does not change the security properties of BGP.
Dong, et al. Expires September 6, 2018 [Page 5]
Internet-Draft BGP Node Target Extended Community March 2018
6. Acknowledgements
The authors would like to thank Zhenbin Li for the discussion and
review of this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community
Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009,
<https://www.rfc-editor.org/info/rfc5701>.
7.2. Informative References
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
Authors' Addresses
Dong, et al. Expires September 6, 2018 [Page 6]
Internet-Draft BGP Node Target Extended Community March 2018
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Gunter Van de Velde
Nokia
Antwerp
BE
Email: gunter.van_de_velde@nokia.com
Dong, et al. Expires September 6, 2018 [Page 7]