One document matched: draft-ietf-bier-idr-extensions-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-bier-idr-extensions-01"
ipr="trust200902">
<front>
<title abbrev="BGP Extensions for BIER">BGP Extensions for BIER</title>
<author fullname="Xiaohu Xu" initials="X.X." role="editor" surname="Xu">
<organization>Huawei</organization>
<address>
<email>xuxiaohu@huawei.com</email>
</address>
</author>
<author fullname="Mach Chen" initials="M.C" surname="Chen">
<organization>Huawei</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>mach.chen@huawei.com</email>
<uri/>
</address>
</author>
<author fullname="Keyur Patel" initials="K.P" surname="Patel">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>keyupate@cisco.com</email>
<uri/>
</address>
</author>
<author fullname="IJsbrand Wijnands" initials="I.W" surname="Wijnands">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>ice@cisco.com</email>
<uri/>
</address>
</author>
<author fullname="Antoni Przygienda" initials="A.P." surname="Przygienda">
<organization>Juniper</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>prz@juniper.net</email>
<uri/>
</address>
</author>
<!--
-->
<date day="" month="" year="2016"/>
<abstract>
<t>Bit Index Explicit Replication (BIER) is a new multicast forwarding
architecture which doesn't require an explicit tree-building protocol
and doesn't require intermediate routers to maintain any multicast
state. BIER is applicable in a multi-tenant data center network
environment for efficient delivery of Broadcast, Unknown-unicast and
Multicast (BUM) traffic while eliminating the need for maintaining a
huge amount of multicast state in the underlay. This document describes
BGP extensions for advertising the BIER-specific information. These
extensions are applicable in those multi-tenant data centers where BGP
instead of IGP is deployed as an underlay for network reachability
advertisement. These extensions may also be applicable in other
scenarios.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Bit Index Explicit Replication (BIER) <xref
target="I-D.ietf-bier-architecture"/> is a new multicast forwarding
architecture which doesn't require an explicit tree-building protocol
and doesn't require intermediate routers to maintain any multicast
state. BIER is applicable in a multi-tenant data center network
environment for efficient delivery of Broadcast, Unknown-unicast and
Multicast (BUM) traffic while eliminating the need for maintaining a
huge amount of multicast state in the underlay <xref
target="I-D.ietf-bier-use-cases"/>. This document describes BGP
extensions for advertising the BIER-specific information. More
specifically, in this document, we define a new optional, non-transitive
BGP attribute, referred to as the BIER attribute, to convey the
BIER-specific information such as BFR-ID, BitString Length (BSL) and so
on. In addition, this document specifies procedures to prevent the BIER
attribute from "leaking out" of a BIER domain . These extensions are
applicable in those multi-tenant data centers where BGP instead of IGP
is used as an underlay <xref
target="I-D.ietf-rtgwg-bgp-routing-large-dc"/>. These extensions may
also be applicable to other BGP based network scenarios.</t>
<section 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>
</section>
</section>
<section anchor="Abbreviations_Terminology" title="Terminology">
<t>This memo makes use of the terms defined in <xref target="RFC4271"/>
and <xref target="I-D.ietf-bier-architecture"/>.</t>
</section>
<section title="BIER Path Attribute">
<t>This draft defines a new optional, transitive BGP path attribute,
referred to as the BIER attribute. This attribute can be attached to a
BGP UPDATE message by the originator so as to indicate the BIER-specific
information of a particular BFR which is identified by the /32 or /128
address prefix contained in the NLRI. In other words, if the BIER path
attribute is present, the NLRI is treated by BIER as a "BFR-prefix".
When creating a BIER attribute, a BFR needs to include one BIER TLV for
every <Sub-domain, BFR-ID> pair that it supports.</t>
<t>The attribute type code for the BIER Attribute is TBD. The value
field of the BIER Attribute contains one or more BIER TLV as shown in
Figure 1.</t>
<t><figure>
<artwork align="center"><![CDATA[ 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=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain | BFR-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Figure 1:BIER TLV
]]></artwork>
</figure><list>
<t>Type: Two octets encoding the BIER TLV Type: TBD.</t>
<t>Length: Two octets encoding the length in octets of the TLV,
including the type and length fields. The length is encoded as an
unsigned binary integer. (Note that the minimum length is 8,
indicating that no sub-TLV is present.)</t>
<t>Sub-domain: a one-octet field encoding the sub-domain ID
corresponding to the BFR-ID.</t>
<t>BFR-ID: a two-octet field encoding the BFR-ID.</t>
<t>Sub-TLVs: contains one or more sub-TLV. The BIER MPLS
Encapsulation sub-TLV is one of such sub-TLVs.</t>
</list></t>
<t>The BIER MPLS Encapsulation sub-TLV is encoded as follows: <figure>
<artwork align="center"><![CDATA[ 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=TBD | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Range Base |Lbl Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2:BIER MPLS Encapsulation sub-TLV
]]></artwork>
</figure></t>
<t><list>
<t>Type:TBD</t>
<t>Length:12</t>
<t>Label Range Size: a one-octet field indicating the size of the
label range.</t>
<t>Label Range Base: a 3-octet field where the 20 rightmost bits
represent the first label in the label range while the other bits
MUST be set to 0 when transmitting, and MUST be ignored upon
receipt.</t>
<t>BSL: a one-octet field indicating the length of the Bitstring in
4-octets. The field MUST be filled with one of the valid BSL values
as specified in <xref target="I-D.ietf-bier-architecture"/>. Upon
receiving a BSL-TLV containing an invalid BSL value, it MUST be
ignored.</t>
</list></t>
</section>
<section anchor="Encaps" title="Originating BIER Attribute">
<t>An implementation that supports the BIER attribute MUST support a
policy to enable or disable the creation of the BIER attribute and its
attachment to specific BGP routes. An implementation MAY disable the
creation of the BIER attribute unless explicitly configured to do so
otherwise. A BGP speaker MUST only attach the locally created BIER
attribute to a BGP UPDATE message in which at least one of its
BFR-prefixes is contained in the NLRI.</t>
</section>
<section title="Restrictions on Sending/Receiving ">
<t>An implementation that supports the BIER attribute MUST support a
per-EBGP-session policy, that indicates whether the attribute is enabled
or disabled for use on that session. The BIER attribute MUST NOT be sent
on any EBGP peers for which the session policy is not configured. If an
BIER attribute is received on a BGP session for which session policy is
not configured, then the received attribute MUST be treated exactly as
if it were an unrecognised non-transitive attribute. That is, "it MUST
be quietly ignored and not passed along to other BGP peers".</t>
<t>To prevent the BIER attribute from "leaking out" of an BIER domain,
each BGP router on the BIER domain MUST support an outbound route
announcement policy. Such a policy MUST be disabled on each EBGP session
by default unless explicitly configured.</t>
</section>
<section title="Deployment Considerations">
<t>It's assumed by this document that the BIER domain is aligned with
the Administrative Domain (AD) which are composed of multiple ASes
(either private or public ASes). Use of the BIER attribute in other
scenarios is outside the scope of this document.</t>
<t>Since the BIER attribute is an optional, transitive BGP path
attribute, a non-BFR BGP speakers could still advertise the received
route with a BIER attribute. This is desirable in the incremental
deployment scenario where a BGP speaker could tunnel a BIER packet or
the payload of a BIER packet to a BFER directly if the BGP next-hop of
the route for that BFER is a non-BFR. Furthermore, a BGP speaker is
allowed to tunnel a BIER packet to the BGP next-hop if these two
BFR-capable BGP neighbors are not directly connected (e.g., multi-hop
EBGP) .</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks a lot for Eric Rosen and Peter Psenak for their valuable
comments on this document.</t>
<!---->
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to assign a codepoint in the "BGP Path Attributes"
registry to the BIER attribute. IANA shall create a registry for "BGP
BIER Attribute Types". The type field consists of two octets, with
possible values from 1 to 655355 (The value 0 is "reserved".) The
allocation policy for this field is to be "First Come First Serve". Type
codes should be allocated for BIER TLV and BIER MPLS Encapsulation
sub-TLV respectively.</t>
<!---->
</section>
<section anchor="Security" title="Security Considerations">
<t>This document introduces no new security considerations beyond those
already specified in <xref target="RFC4271"/>.</t>
<!---->
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<?rfc include="reference.I-D.ietf-bier-architecture"?>
<?rfc include="reference.I-D.ietf-bier-mpls-encapsulation"?>
<?rfc include="reference.RFC.4271"?>
<!---->
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-bier-use-cases"?>
<?rfc include="reference.I-D.ietf-rtgwg-bgp-routing-large-dc"?>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:25:18 |