One document matched: draft-lapukhov-bgp-opaque-signaling-01.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-01" obsoletes=""
updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Use of BGP for 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 along with new optional
transitive attribute 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 MAY to 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 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>
<t>
One application of this extension could be auto-discovery of various
services in the data-center network that uses BGP as the routing protocol
of choice (<xref target="I-D.ietf-rtgwg-bgp-routing-large-dc"/>).
</t>
<t>
Another application is building and testing new routing protocols or
BGP extensions within existing BGP implementation.
The new protocol/extension may influence routing either by directly
communicating to the RIB/FIB of the router it runs on, or by overriding
BGP paths via BGP route injection. An example of such BGP extension could be
<xref target="WISER"/>
</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.
</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 a
Key-Value binding.
</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 to implement a distributed, eventually
consistent Key-Value store on top of existing BGP protocol
mechanics. The "Key" portion is to be encoded as the NLRI part
of MP_REACH_NLRI attribute and "Value" encoded using a new
optional transitive attribute.
<list style="symbols">
<t>
Publishers, acting as BGP speakers, advertise keys along
with associated values into the routing domain. The BGP
network synchronizes that state by propagating the encoded
data following regular BGP protocol operations.
</t>
<t>
Consumers, acting as BGP speakers, 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 (NLRI) bound to
different values. 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, BGP would follow the 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 any method of achieving global consensus for
all published values for a given key.
</t>
<section title="Publishing a Key-Value binding" toc="default">
<t>
The encoding scheme proposed below follows the semantics of a
Key-Value bindings. The "Key" is 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 (1 octet) |
+---------------------------------------------------------+
| Opaque Key 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, since no
information is encoded in the next-hop address field.
</t>
<t>
Opaque Key Length: identifies the size of the Key field.
If field is set to zero, the implementation MUST ignore
the advertisement.
</t>
<t>
Opaque Key Data: the byte string representing the opaque
key contents. This portion SHOULD NOT be interpreted by
BGP implementation.
</t>
</list>
</t>
<t>
The "Value" portion of a published binding is to be encoded in
a new optional transitive attribute as shown on <xref
target="opaque_value_attribute"/>:
</t>
<figure title="OPAQUE_VALUE attribute layout"
anchor="opaque_value_attribute" suppress-title="false"
align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left"
alt="" width="" height="">
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 |0 0 0 0| Opaque Value Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| Opaque Value Data (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
</artwork>
</figure>
<t>
<list style="symbols">
<t>
Type: Identifies the new OPAQUE_VALUE attribute, with the
value to be allocated by IANA.
</t>
<t>
Opaque Value Length: Two octets encoding the total length
of the attribute in octets, including the Type and Length
fields. The length is encoded as an unsigned binary
integer. The four most significant bits of this field MUST
be set to zero, due to the limit imposed by maximum BGP
message size. Note that the minimum length is 3,
indicating that no Opaque Value Data field is present.
Such binding, in presence of non-zero length key is still
valid, as it informs the consumers that the key "exists".
</t>
<t>
Opaque Value Data: A field containing zero or more octets.
This portion SHOULD NOT be interpreted by BGP
implementations.
</t>
</list>
</t>
<t>
Even when the OPAQUE_VALUE optional transitive attribute is
not present in BGP advertisement, the BGP implementation MUST
still retain Opaque Key (NLRI) in its LocRIB and propagate it
further as usual. This case is to be interpreted as an
announcement of the key existence.
</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 message shown on <xref target="mp_unreach_nlri"/>
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 is not found in the LocRIB or has not been previously
received from the withdrawing BGP peer, such key removal
request MUST be ignored.
</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 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 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 consensum protocol.
</t>
</section>
</section>
<section title="Message filtering" toc="default">
<t>
Limiting the scope of opaque information flooding is an
important operational concern. BGP already has the mechanisms
needed to control this process, and these mechanisms are briefly
reviewed below.
</t>
<section title="Automated filtering">
<t>
One can leverage mechanics presented 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 contain the router-target extended community attribute
to constrain 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 speaker, or on remote 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 SAFI, as well as a value for the new
optional transitive attribute.
</t>
</section>
<section title="Manageability Considerations" toc="default">
<t>
TBD
</t>
</section>
<section title="Security Considerations" toc="default">
<t>
This document does not introduce any changes in terms of BGP
security.
</t>
</section>
<section title="Acknowledgements" toc="default">
<t>
TBD
</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.4360.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-rtgwg-bgp-routing-large-dc"?>
<reference anchor="WISER" target="http://research.microsoft.com/en-us/um/people/ratul/papers/nsdi2007-wiser.pdf">
<front>
<title>
Mutually Controlled Routing with Independent ISPs
</title>
<author initials="R" surname="Mahajan" fullname="Ratul Mahajan"/>
<author initials="D" surname="Wetherall" fullname="David Wetherall"/>
<author initials="T" surname="Anderson" fullname="Thomas Anderson"/>
<date year="2007"/>
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 16:43:44 |