One document matched: draft-przygienda-bier-isis-ranges-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-przygienda-bier-isis-ranges-00" ipr="trust200902" obsoletes="" submissionType="IETF" updates="" xml:lang="en">
<front>
<title abbrev="draft-przygienda-bier-isis-ranges-00">BIER support via ISIS</title>
<author fullname="Tony Przygienda" initials="A." surname="Przygienda">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone/>
<facsimile/>
<email>antoni.przygienda@ericsson.com</email>
<uri/>
</address>
</author>
<date day="27" month="Sep" year="2014"/>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>Specification of an ISIS extension to support BIER domains.
</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 format="default" pageno="false" target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction" toc="default">
<t>
Bit Index Explicit Replication (BIER) <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/>
defines an architecture where
all intended multicast receivers are encoded as bitmask in the Multicast packet
header within different encapsulations such as
<xref format="default" pageno="false" target="I-D.draft-wijnands-mpls-bier-encapsulation-00"/>.
A router that receives such a packet will forward the packet
based on the Bit Position in the packet header towards the
receiver(s), following a precomputed tree for each of the bits in
the packet. Each receiver is represented by a unique bit in the bitmask.
</t>
<t>
This document presents necessary extensions to the currently deployed ISIS for IP <xref format="default" pageno="false" target="RFC7142"/> protocol to support distribution of information necessary for operation of BIER domains.
This document defines a new TLV to be distributed by
every router participating in such BIER domains.
</t>
</section>
<section title="Terminology" toc="default">
<t>
Some of the terminology specified in <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/> is replicated here and extended
by necessary definitions:</t>
<t>
<list style="hanging">
<t hangText="BIER:">Bit Index Explicit Replication (The overall
architecture of forwarding multicast using a Bit Position).</t>
<t hangText="BIER-OL:">BIER Overlay Signaling. (The method for the
BFIR to learn about BFER's).</t>
<t hangText="BM:">Bit Mask (A bit stream of a certain fixed
length. Each Bit represents a receiver).</t>
<t hangText="P-BM:">Packet Bit Mask (A Bit Mask included in the
Multicast Packet).</t>
<t hangText="BP:">Bit Position (A single Bit from the Bit Mask
that represents a receiver).</t>
<t hangText="BFR:">Bit Forwarding Router (A router that
participates in Bit Index Multipoint Forwarding).</t>
<t hangText="BFIR:">Bit Forwarding Ingress Router (The ingress
border router that inserts the BM into the packet).</t>
<t hangText="BFER:">Bit Forwarding Egress Router. A router that
participates in Bit Index Forwarding as leaf. Each
BFER must be a BFR.</t>
<t hangText="BFT:">Bit Forwarding Tree used to reach all BFERs in a domain.</t>
<t hangText="BIFT:">Bit Index Forwarding Table (A Bit index
forwarding table).</t>
<t hangText="BMS:">Bit Mask Set. Set containing bit positions of all
BFER participating in a set.</t>
<t hangText="BMP:">Bit Mask Position, a given bit in a BMS.</t>
</list>
</t>
</section>
<section anchor="IANA" title="IANA Considerations" toc="default">
<t>This document requests IANA to assign sub-TLV type values from the ISIS router capability TLV <xref format="default" pageno="false" target="RFC4971"/> registry.</t>
</section>
<section title="Concepts">
<section title="BIER as Capability">
<t>This draft introduces a sub-TLV in the router capabilites TLV <xref format="default" pageno="false" target="RFC4971"/> to distribute the information.
Any of the router's loopback addresses that it originates are considered BFR prefixes as required by <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/>. The question whether
a particular loopback address is routable in a specific topology <xref format="default" pageno="false" target="RFC5120"/> can be resolved by <xref format="default" pageno="false" target="I-D.draft-xu-isis-routable-ip-address-01"/>.
</t>
</section>
<section title="BIER Domain Identifier">
<t>
ISIS can carry BIER information not only for a single BIER domain but for multiple, distinct domains.
This allows to run many disjoint BIER layers within the same <xref format="default" pageno="false" target="RFC5120">Multi-Topology</xref> easily instead
of always forcing different multicast overlays to share the exactly same set of BFRs and resources. Moreover, multi topology <xref format="default" pageno="false" target="RFC5120"/>
can be used for the purpose of restricting links that certain set of BIER domains can use or change metrics of such links. A BIER set is therefore always uniquely identified by
the tuple of topology T, domain D it belongs to and its number S, denoted as <T,D,S>. The domain itself has as its unique attributes the encapsulation, bitmask length
and the type of tree it is using to forward BIER frames (currently always SPF).
</t>
</section>
</section>
<section title="Procedures">
<section title="Enabling a BIER Domain">
<t>A given domain D in a multi-topology T <xref format="default" pageno="false" target="RFC5120"/>
(denoted as <T,D> from now on) is normally not advertised to preserve the scaling of the protocol (i.e. ISIS
carries no TLVs containing any of the elements related to <T,D>) and
is enabled by a first BIER sub-TLV (<xref target="S2L"></xref>) containing <T,D> being advertised into the area.
The trigger itself is outside the scope of this draft but can be .e.g. a VPN desiring to initiate a domain
as MP2MP or P2MP tree or a BMP being administratively assigned to a BFER and
advertised via BIER TLV into the area or any other means within Multicast BIER Overlay(s) using BIER domains.</t>
</section>
<section title="Length of Bitmasks" anchor="BML">
<t> All routers in the flooding scope of the BIER TLVs SHOULD advertise the same bit mask length for a given <T,D>.
A router discovering bitmask lengths advertised that are shorter
than its own MUST report a misconfiguration of a specific <T,D>.
Each router MUST compute BFTs for <T,D> using only routers having the same mask length as its own
advertised Bit Mask Length in BIER sub-TLV for <T,D>.
</t>
<section title="Special Consideration">
<t>
The same router MAY advertise for different <T,D> combinations two different mask lengths. This allows
to cleanly delineate domains crossing the same router but using different mask lengths in the encoding, even within the same topology.
</t>
</section>
</section>
<section title="Encapsulation">
<t>Since encapsulation is an attribute of a domain <T,D> just like bitmask length, all rules that apply to Bitmask Length per <xref target="BML"/> apply to it well.</t>
</section>
<section title="Label Advertisements">
<t>
Each router MAY advertise within the sub-TLV of an according <T,D> (denoted further as TLV<T,D>) a valid starting label value and a non-zero range length.
It MUST advertise a valid label value and a non-zero range length IF it
has computed itself as being on the BFT rooted at any of the BFRs with valid BFR-ids (except itself) participating in <T,D>.
</t>
<t>A router CAN withdraw its TLV<T,D> if it does not want to participate in the domain due to resource constraints, label space optimization,
administrative configuration or any other reasons. In case a router advertises a label range size of 0 for <T,D> it MUST be excluded from the
BIER BFTs for <T,D>.
</t>
<section title="Special Consideration">
<t>A router MUST advertise a for <T,D> label range size that guarantees to cover the
maximum BFR-id injected into <T,D>
(which implies a certain set id as described in <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/>). Any router
that violates this condition MUST be excluded from BIER BFTs for <T,D>.
</t>
</section>
</section>
<section title="BFR-id Advertisements">
<t>
Each BFER MAY advertise with its TLV<T,D> the according BFR-id that it has administratively chosen.
</t>
<t>If two BFRs advertise in their TLV<T,D> the same value for BFR-id, all routers MUST report it as misconfiguration and disregard those routers for all
BIER calculations and procedures to align with <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/>.
Such routers with colliding assignments MAY still act as BFIRs but will be never able to receive traffic.
</t>
</section>
</section>
<section title="Packet Formats" toc="default">
<t>All ISIS BIER information is carried within the router capability TLV <xref format="default" pageno="false" target="RFC4971"/> with S bit clear.</t>
<section title="BIER BFR sub-TLV" anchor="S2L">
<t>
This sub-TLV carries the information for the BIER domains that the router participates in as BFR. It can repeat multiple times. If the same <T,D> is
advertised more than once, the first one in the first sub-TLV in the fragment with the lowest ID MUST be used.
</t>
<figure align="left" alt="" height="" suppress-title="false" title="" width="">
<artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve">
<![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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | Bier Domain ID | Bit Msk Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lbl Range Size| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-id |A|R|T| Reserv | Encaps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">TBD1.</t>
<t hangText="Length:">2 octets.</t>
<t hangText="MT-ID:"> <xref format="default" pageno="false" target="RFC5120">Multi-Topology</xref>, 1 octet.</t>
<t hangText="BIER Domain ID:"> Unique identifier for a BIER domain, 2 octets.</t>
<t hangText="Label Range Size:">Number of labest in the range used on encapsulation for this BIER domain, 1 octet. </t>
<t hangText="Label:">First label of the range used on encapsulation for this BIER domain, 20 bits.
The label is used by e.g. <xref format="default" pageno="false" target="I-D.draft-wijnands-mpls-bier-encapsulation-00"/> to forward traffic to sets of BFERs.
</t>
<t hangText="Local BitMask Length:">Bitmask length for this BFR per <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/>.</t>
<t hangText="Encapsulation Type:">The BIER encapsulation type,
1 octet. Allowed values are:
<list style="hanging">
<t hangText="0">MPLS per <xref format="default" pageno="false" target="I-D.draft-wijnands-mpls-bier-encapsulation-00"/>.</t>
</list>
</t>
<t hangText="A">Indicates administratively set value if set, otherwise the BFR-id value MUST be considered as not assigned in this TLV.</t>
<t hangText="R">Reserved for future use. MUST be 0.</t>
<t hangText="T">Reserved for future use. MUST be 0.</t>
<t hangText="Reserved">MUST be 0 on send, ignored on receive.</t>
</list>
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations" toc="default">
<t>
The extension does not introduce any known new protocol vulnerabilities.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements" toc="default">
<t>The draft is aligned with the <xref format="default" pageno="false" target="I-D.draft-kumar-ospf-bier-extension-00"/>
draft as far as the protocol mechanisms overlap.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5120"?>
<?rfc include="reference.RFC.4971"?>
<?rfc include="reference.RFC.7142"?>
<reference anchor="I-D.draft-wijnands-bier-architecture-00">
<front>
<title>Stateless Multicast using Bit Index Explicit Replication
Architecture</title>
<author initials="IJ" surname="Wijnands">
<organization/>
</author>
<date month="February" year="2014"/>
</front>
<seriesInfo name="internet-draft" value="draft-wijnands-bier-architecture-00.txt"/>
<format target="http://tools.ietf.org/id/draft-wijnands-bier-architecture-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.draft-wijnands-mpls-bier-encapsulation-00">
<front>
<title>Bit Index Explicit Replication using MPLS
encapsulation</title>
<author initials="IJ" surname="Wijnands et al.">
<organization/>
</author>
<date month="February" year="2014"/>
</front>
<seriesInfo name="internet-draft" value="draft-wijnands-mpls-bier-encapsulation-00.txt"/>
<format target="http://tools.ietf.org/id/draft-wijnands-mpls-bier-encapsulation-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.draft-xu-isis-routable-ip-address-01">
<front>
<title>Carrying Routable IP Addresses in IS-IS Router Capability TLV</title>
<author initials="U" surname="Chunduri et al.">
<organization/>
</author>
<date month="September" year="2014"/>
</front>
<seriesInfo name="internet-draft" value="draft-xu-isis-routable-ip-address-01.txt"/>
<format target="http://tools.ietf.org/id/draft-xu-isis-routable-ip-address-01.txt" type="TXT"/>
</reference>
<reference anchor="I-D.draft-kumar-ospf-bier-extension-00">
<front> <title>OSPF Extension for Bit Index Explicit Replication</title>
<author surname="Psenak" initials="P"> <organization/> </author>
<author surname="Wijnands" initials="IJ"> <organization/> </author>
<date year="2014" month="September"/> </front>
<seriesInfo name="internet-draft" value="draft-ietf-ospf-prefix-link-attr-00.txt"/>
<format target="http://tools.ietf.org/id/draft-ietf-ospf-prefix-link-attr-00.txt" type="TXT"/> </reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:18:58 |