One document matched: draft-lapukhov-bgp-opaque-signaling-03.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-lapukhov-bgp-opaque-signaling-03" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="draft-lapukhov-bgp-opaque-signaling">Use of BGP for Opaque Signaling</title>
<author initials="P." surname="Lapukhov" fullname="Petr Lapukhov">
<organization>Facebook</organization>
<address>
<postal>
<street>1 Hacker Way</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>
<email>petr@fb.com</email>
</address>
</author>
<author initials="E." surname="Aries" fullname="Ebben Aries" role="editor">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1133 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>exa@juniper.net</email>
</address>
</author>
<author initials="P." surname="Marques" fullname="Pedro Marques">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>roque@juniper.net</email>
</address>
</author>
<author initials="E." surname="Nkposong" fullname="Edet Nkposong">
<organization>Salesforce.com Inc</organization>
<address>
<postal>
<street>The Landmark @ One Market, ST 300</street>
<city>San Francisco</city>
<region>CA</region>
<code>94105</code>
<country>US</country>
</postal>
<email>enkposong@salesforce.com</email>
</address>
</author>
<date year="2016"/>
<area>Routing</area>
<workgroup>Inter-Domain Routing</workgroup>
<keyword>Internet Draft</keyword>
<keyword>BGP</keyword>
<keyword>Opaque</keyword>
<keyword>Key-Value</keyword>
<abstract>
<t>
Border Gateway Protocol with multi-protocol extensions (MP-BGP) enables the use of the protocol for dissemination of virtually any information. This document proposes a new Address Family/Subsequent Address Family to be used for distribution of opaque data. This functionality is intended to be used by applications other than BGP for exchange of their own data on top of BGP mesh. The structure of such data SHOULD NOT be interpreted by the regular BGP speakers, rather the goal is to use BGP purely as a convenient and scalable communication system.
</t>
</abstract>
<note title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section title="Introduction" anchor="intro" toc="default">
<t>
Implementation of <xref target="RFC4760">Multiprotocol Extensions for BGP-4</xref> gives the ability to pass arbitrary data in BGP protocol messages. This capability has been leveraged by many for dissemination of non-routing related information over BGP (e.g. <xref target="RFC5575">"Dissemination of Flow Specification Rules"</xref> as well as <xref target="I-D.ietf-idr-ls-distribution">"North-Bound Distribution of Link-State and TE Information using BGP"</xref>). However, there has been no channel defined explicitly to disseminate data with arbitrary payload. The intended use case is for applications other than BGP to leverage the protocol machinery for distribution (broadcasting) of their own state in the network domain. Publishers and consumers will use BGP UPDATE messages over TCP transport to submit and receive opaque data. It is up to the BGP implementation to provide a custom API for message producers or consumers, if needed.
</t>
</section>
<section title="BGP Opaque Data AFI" toc="default">
<t>
This document introduces a new AFI known as a "BGP Opaque Data AFI" with the actual value to be assigned by IANA. The purpose of this AFI is to exchange opaque information within a BGP network. The propagation scope is to be controlled by the usual means of BGP policy, except that the policy SHOULD not match on NLRI information in any form other than an opaque string.
</t>
</section>
<section title="BGP Key-Value SAFI" toc="default">
<t>
This document introduces a new SAFI known as "BGP Key-Value SAFI" with the actual value to be assigned by IANA. The purpose of this SAFI is exchange of opaque information structured as Key-Value binding.
</t>
</section>
<section title="BGP VPN Key-Value SAFI" toc="default">
<t>
This document introduces a new SAFI known as a "BGP VPN Key-Value SAFI" with the actual value to be assigned by IANA. The purpose of this SAFI is exchange of opaque information structured as a Key-Value binding over service provider backbone providing Virtual Private Networks as a service. The <xref target="RFC4364"/> defines a method and procedures for implementing VPNs using BGP as a control plane. All the procedures of <xref target="RFC4364"/> apply to the BGP VPN Key-Value SAFI. Under this SAFI, the NLRI for the opaque information has the mandatory 8 bytes of Route Distinguisher at the beginning of the NLRI field.
</t>
</section>
<section title="Capability Advertisement" toc="default">
<t>
A BGP speaker that wishes to exchange Opaque Data MUST use the Multiprotocol Extensions Capability Code, as defined in <xref target="RFC4760"/>, to advertise the corresponding AFI/SAFI pair.
</t>
</section>
<section title="Disseminating Key-Value bindings" toc="default">
<t>
This document proposes a distributed, eventually consistent Key-Value store on top of existing BGP protocol transport mechanism. The "Key" and "Value" portions are to be encoded as the NLRI part of MP_REACH_NLRI attribute.
<list style="symbols">
<t>
Publishers advertise keys along with associated values into the routing domain. The BGP network disseminates that state by propagating the encoded data following regular BGP protocol operations.
</t>
<t>
Consumers receive the information via BGP protocol UPDATE messages. Only publishers and consumers of the opaque data are supposed to interpret its contents. The rest of the BGP network acts merely as a dissemination system.
</t>
</list>
</t>
<t>
Multiple publishers can advertise the same key bound to different values. Only the "Key" part of MP_REACH_NLRI filed MUST be used to differentiate unique advertisements in such case. It is also possible for the advertised binding to have the same Key-Value pairs, but differ in some other BGP attributes. In that case, the BGP implementation MUST follow the regular best-path selection logic to prevent duplicate information in the network. A consumer will receive the value created by the publisher "closest" in terms of BGP best-path selection logic, based on the policies that exist in the routing domain. This document does not propose methods to achieve strong global consensus for all published values of a given key, as it's generally impossible in eventually consistent data distribution systems.
</t>
<section title="Publishing a Key-Value binding" toc="default">
<t>
The encoding scheme proposed below follows the semantics of a Key-Value binding. The "Key" and "Value" are stored in the NLRI section of the MP_REACH_NLRI attribute, as shown on <xref target="mp_reach_nlri"/>.
</t>
<figure title="MP_REACH_NLRI Layout" anchor="mp_reach_nlri" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Address (1 octet), must be zero |
+---------------------------------------------------------+
| Reserved (1 octet), must be zero |
+---------------------------------------------------------+
| Opaque Key Length (2 octets) |
+---------------------------------------------------------+
| Opaque Key Data (variable) |
+---------------------------------------------------------+
| Opaque Value Data (variable) |
+---------------------------------------------------------+
</artwork>
</figure>
<t>
<list style="symbols">
<t>
The AFI/SAFI values are to be allocated by IANA.
</t>
<t>
Length of Next Hop Address: must be zero, indicating empty next-hop.
</t>
<t>
Opaque Key Length: identifies the size of the Key field in octets, an unsigned integer value. The field MUST have a value of at least one octet under the Key-Value SAFI and at least 9 octets under the VPN Key-Value SAFI. Violating this requirement MUST cause the receiver to ignore the advertised Key-Value binding.
</t>
<t>
Opaque Key Data: the byte string representing the opaque key contents.
</t>
<t>
Opaque Value Data: The length of this field is determined by subtracting the length of all previous fields from the total length of MP_REACH_NLRI attribute. This field MAY be empty.
</t>
</list>
</t>
<t>
The maximum size of the Opaque "Key" and "Value" fields together is limited by the BGP UPDATE message size. With the default BGP protocol implementation is may not exceed 4096 octets (see <xref target="RFC4271"/> Section 4). However, if <xref target="I-D.ietf-idr-bgp-extended-messages"/> is implemented, the UPDATE message size could be as large as 65536 octets.
</t>
</section>
<section title="Removing a Key-Value binding" toc="default">
<t>
The removal procedure follows the regular MP-BGP route withdrawal, using the MP_UNREACH_NLRI attribute. This section defines the attribute structure for the new AFI/SAFI.
</t>
<t>
The specific MP_UNREACH_NLRI format is shown on <xref target="mp_unreach_nlri"/>. This message instructs the receiving BGP speaker to delete the N bindings corresponding to Key 1, Key 2 ... Key N if the keys have been previously learned from the withdrawing speaker. If any of the keys could not be found in the LocRIB or has not been previously received from the withdrawing BGP peer, such key removal request MUST be ignored and the event MAY be logged. For the Key-Value SAFI, each key length field must have the value of at least "1". For the VPN Key-Value SAFI, each key length must be at least 9 octets long. Violation of of these constraints MUST cause the receiver of the UPDATE message to ignore the corresponding key withdrawal.
</t>
<figure title="MP_UNREACH_NLRI attribute layout" anchor="mp_unreach_nlri" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Opaque Key 1 Length (1 octet) |
+---------------------------------------------------------+
| Opaque Key 1 Data (variable) |
+---------------------------------------------------------+
~ ~
| Opaque Key N Length (1 octet) |
+---------------------------------------------------------+
| Opaque Key N Data (variable) |
+---------------------------------------------------------+
</artwork>
</figure>
</section>
</section>
<section title="Manageability Considerations" anchor="op_considerations" toc="default">
<section title="Propagating multiple values for the same key" anchor="add_path" toc="default">
<t>
It is possible to propagate multiple values associated with the same key using the Add-Path extension defined in <xref target="I-D.ietf-idr-add-paths" />. However, this document recommends that instead unique key values SHOULD be used for this purpose. It is up to the consumers and publishers of the opaque data to settle on single unique value using some kind of consensus protocol.
</t>
<t>
As a recommendation, the originators of key-value pairs may use the origin ASN and the IPv4 or IPv6 address assigned to the originating BGP speaker to create a unique key prefix. Alternatively, UUIDs could be used to generate the unique key names, see <xref target="RFC4122"/>
</t>
</section>
<section title="Automated filtering">
<t>
One can leverage mechanics described in <xref target="RFC4684"/> and use the route-target extended community attribute to identify "channels" where key-value bindings are published. The consumers would signal their interest in particular "channel" by advertising the corresponding router-target membership. The publications then need to carry the router-target extended community attribute to restrict information propagation.
</t>
</section>
<section title="Filtering via policy">
<t>
Ad-doc message filtering could be implemented using BGP standard (see <xref target="RFC4271"/>) or extended community attributes (see <xref target="RFC4360"/>). The semantic of these attributes is to determined by the policy and publishers/consumers. Filtering could be done locally on receiving BGP speaker, or on remote BGP speaker, by using outbound route filtering feature defined in <xref target="RFC5291"/>.
</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>
For the purpose of this work, IANA would be asked to allocate values for the new AFI and SAFIs.
</t>
</section>
<section title="Security Considerations" toc="default">
<t>
This document does not introduce any changes in terms of BGP security. The usual set of issues that arise from running multiple AFI/SAFI's over single BGP session would apply in this case. Additional concerns may be raised due to increase of the volume and rate of change of the information distributed by means of opaque signaling.
</t>
</section>
<section title="Acknowledgements" toc="default">
<t>
Keyur Patel provided useful feedback and suggested a practical implementation of unique key semantic and support for VPN Key-Value SAFI.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.4271.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4122.xml"?>
<?rfc include="reference.RFC.4360.xml"?>
<?rfc include="reference.RFC.4364.xml"?>
<?rfc include="reference.RFC.4684.xml"?>
<?rfc include="reference.RFC.4760.xml"?>
<?rfc include="reference.RFC.5291.xml"?>
<?rfc include="reference.RFC.5575.xml"?>
<?rfc include="reference.I-D.ietf-idr-add-paths"?>
<?rfc include="reference.I-D.ietf-idr-ls-distribution"?>
<?rfc include="reference.I-D.ietf-idr-bgp-extended-messages"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:50:00 |