draft-ietf-bier-architecture-07.txt   draft-ietf-bier-architecture-08.txt 
Internet Engineering Task Force IJ. Wijnands, Ed. Internet Engineering Task Force IJ. Wijnands, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Experimental E. Rosen, Ed. Intended status: Experimental E. Rosen, Ed.
Expires: December 23, 2017 Juniper Networks, Inc. Expires: March 17, 2018 Juniper Networks, Inc.
A. Dolganow A. Dolganow
Nokia Nokia
T. Przygienda T. Przygienda
Juniper Networks, Inc. Juniper Networks, Inc.
S. Aldrin S. Aldrin
Google, Inc. Google, Inc.
June 21, 2017 September 13, 2017
Multicast using Bit Index Explicit Replication Multicast using Bit Index Explicit Replication
draft-ietf-bier-architecture-07 draft-ietf-bier-architecture-08
Abstract Abstract
This document specifies a new architecture for the forwarding of This document specifies a new architecture for the forwarding of
multicast data packets. It provides optimal forwarding of multicast multicast data packets. It provides optimal forwarding of multicast
packets through a "multicast domain". However, it does not require a packets through a "multicast domain". However, it does not require a
protocol for explicitly building multicast distribution trees, nor protocol for explicitly building multicast distribution trees, nor
does it require intermediate nodes to maintain any per-flow state. does it require intermediate nodes to maintain any per-flow state.
This architecture is known as "Bit Index Explicit Replication" This architecture is known as "Bit Index Explicit Replication"
(BIER). When a multicast data packet enters the domain, the ingress (BIER). When a multicast data packet enters the domain, the ingress
router determines the set of egress routers to which the packet needs router determines the set of egress routers to which the packet needs
to be sent. The ingress router then encapsulates the packet in a to be sent. The ingress router then encapsulates the packet in a
BIER header. The BIER header contains a bitstring in which each bit BIER header. The BIER header contains a bitstring in which each bit
represents exactly one egress router in the domain; to forward the represents exactly one egress router in the domain; to forward the
packet to a given set of egress routers, the bits corresponding to packet to a given set of egress routers, the bits corresponding to
those routers are set in the BIER header. Elimination of the per- those routers are set in the BIER header. The procedures for
flow state and the explicit tree-building protocols results in a forwarding a packet based on its BIER header are specified in this
considerable simplification. document. Elimination of the per-flow state and the explicit tree-
building protocols results in a considerable simplification.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 23, 2017.
This Internet-Draft will expire on March 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The BFR Identifier and BFR-Prefix . . . . . . . . . . . . . . 6 2. The BFR Identifier and BFR-Prefix . . . . . . . . . . . . . . 6
3. Encoding BFR Identifiers in BitStrings . . . . . . . . . . . 7 3. Encoding BFR Identifiers in BitStrings . . . . . . . . . . . 7
4. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. The Routing Underlay . . . . . . . . . . . . . . . . . . 10 4.1. The Routing Underlay . . . . . . . . . . . . . . . . . . 10
4.2. The BIER Layer . . . . . . . . . . . . . . . . . . . . . 11 4.2. The BIER Layer . . . . . . . . . . . . . . . . . . . . . 11
4.3. The Multicast Flow Overlay . . . . . . . . . . . . . . . 11 4.3. The Multicast Flow Overlay . . . . . . . . . . . . . . . 12
5. Advertising BFR-ids and BFR-Prefixes . . . . . . . . . . . . 12 5. Advertising BFR-ids and BFR-Prefixes . . . . . . . . . . . . 12
6. BIER Intra-Domain Forwarding Procedures . . . . . . . . . . . 13 6. BIER Intra-Domain Forwarding Procedures . . . . . . . . . . . 14
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. BFR Neighbors . . . . . . . . . . . . . . . . . . . . . . 15 6.2. BFR Neighbors . . . . . . . . . . . . . . . . . . . . . . 16
6.3. The Bit Index Routing Table . . . . . . . . . . . . . . . 16 6.3. The Bit Index Routing Table . . . . . . . . . . . . . . . 16
6.4. The Bit Index Forwarding Table . . . . . . . . . . . . . 17 6.4. The Bit Index Forwarding Table . . . . . . . . . . . . . 17
6.5. The BIER Forwarding Procedure . . . . . . . . . . . . . . 18 6.5. The BIER Forwarding Procedure . . . . . . . . . . . . . . 18
6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 20 6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 20
6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 21 6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 21
6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22 6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22
6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 24 6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 24
6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 24 6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 24
6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 25 6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 25
6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 27 6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 27
6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 28 6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 28
6.10. Use of Different BitStringLengths within a Domain . . . . 31 6.10. Use of Different BitStringLengths within a Domain . . . . 30
6.10.1. BitStringLength Compatibility Check . . . . . . . . 32 6.10.1. BitStringLength Compatibility Check . . . . . . . . 32
6.10.2. Handling BitStringLength Mismatches . . . . . . . . 33 6.10.2. Handling BitStringLength Mismatches . . . . . . . . 33
6.10.3. Transitioning from One BitStringLength to Another . 34 6.10.3. Transitioning from One BitStringLength to Another . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Operational Considerations . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 7.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 35
10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
11.1. Normative References . . . . . . . . . . . . . . . . . . 36 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 36 11. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
12.1. Normative References . . . . . . . . . . . . . . . . . . 38
12.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This document specifies a new architecture for the forwarding of This document specifies a new architecture for the forwarding of
multicast data packets. It provides optimal forwarding of multicast multicast data packets. The architecture provides optimal forwarding
data packets through a "multicast domain". However, it does not of multicast data packets through a "multicast domain". However, it
require the use of a protocol for explicitly building multicast does not require the use of a protocol for explicitly building
distribution trees, and it does not require intermediate nodes to multicast distribution trees, and it does not require intermediate
maintain any per-flow state. This architecture is known as "Bit nodes to maintain any per-flow state. This architecture is known as
Index Explicit Replication" (BIER). "Bit Index Explicit Replication" (BIER).
A router that supports BIER is known as a "Bit-Forwarding Router" A router that supports BIER is known as a "Bit-Forwarding Router"
(BFR). The BIER control plane protocols (see Section 4.2) run within (BFR). The BIER control plane protocols (see Section 4.2) run within
a "BIER domain", allowing the BFRs within that domain to exchange the a "BIER domain", allowing the BFRs within that domain to exchange the
information needed for them to forward packets to each other using information needed for them to forward packets to each other using
BIER. BIER.
A multicast data packet enters a BIER domain at a "Bit-Forwarding A multicast data packet enters a BIER domain at a "Bit-Forwarding
Ingress Router" (BFIR), and leaves the BIER domain at one or more Ingress Router" (BFIR), and leaves the BIER domain at one or more
"Bit-Forwarding Egress Routers" (BFERs). A BFR that receives a "Bit-Forwarding Egress Routers" (BFERs). A BFR that receives a
skipping to change at page 5, line 15 skipping to change at page 5, line 20
Suppose that a given packet has been assigned to sub-domain 0, and Suppose that a given packet has been assigned to sub-domain 0, and
needs to be delivered to three BFERs, where those BFERs have BFR-ids needs to be delivered to three BFERs, where those BFERs have BFR-ids
in sub-domain 0 of 13, 126, and 235 respectively. The BFIR would in sub-domain 0 of 13, 126, and 235 respectively. The BFIR would
create a BIER encapsulation with the SI set to zero, and with bits create a BIER encapsulation with the SI set to zero, and with bits
13, 126, and 235 of the BitString set. (All other bits of the 13, 126, and 235 of the BitString set. (All other bits of the
BitString would be clear.) If the packet also needs to be sent to a BitString would be clear.) If the packet also needs to be sent to a
BFER whose BFR-id is 257, the BFIR would have to create a second copy BFER whose BFR-id is 257, the BFIR would have to create a second copy
of the packet, and the BIER encapsulation would specify an SI of 1, of the packet, and the BIER encapsulation would specify an SI of 1,
and a BitString with bit 1 set and all the other bits clear. and a BitString with bit 1 set and all the other bits clear.
It is generally advantageous to assign the BFR-ids of a given sub- It is generally advantageous to assign the BFR-ids of a given
domain so that as many BFERs as possible can be represented in a sub-domain so that as many BFERs as possible can be represented in a
single bit string. single bit string.
Suppose a BFR, call it BFR-A, receives a packet whose BIER Suppose a BFR, call it BFR-A, receives a packet whose BIER
encapsulation specifies an SI of 0, and a BitString with bits 13, 26, encapsulation specifies an SI of 0, and a BitString with bits 13, 26,
and 235 set. Suppose BFR-A has two BFR neighbors, BFR-B and BFR-C, and 235 set. Suppose BFR-A has two BFR neighbors, BFR-B and BFR-C,
such that the best path to BFERs 13 and 26 is via BFR-B, but the best such that the best path to BFERs 13 and 26 is via BFR-B, but the best
path to BFER 235 is via BFR-C. Then BFR-A will replicate the packet, path to BFER 235 is via BFR-C. Then BFR-A will replicate the packet,
sending one copy to BFR-B and one copy to BFR-C. However, BFR-A will sending one copy to BFR-B and one copy to BFR-C. However, BFR-A will
clear bit 235 in the BitString of the packet copy it sends to BFR-B, clear bit 235 in the BitString of the packet copy it sends to BFR-B,
and will clear bits 13 and 26 in the BitString of the packet copy it and will clear bits 13 and 26 in the BitString of the packet copy it
sends to BFR-C. As a result, BFR-B will forward the packet only sends to BFR-C. As a result, BFR-B will forward the packet only
towards BFERs 13 and 26, and BFR-C will forward the packet only towards BFERs 13 and 26, and BFR-C will forward the packet only
towards BFER 235. This ensures that each BFER receives only one copy towards BFER 235. This ensures that each BFER receives only one copy
of the packet. of the packet.
Detailed procedures for forwarding a BIER-encapsulated packet through
a BIER domain can be found in Section 6.
With this forwarding procedure, a multicast data packet can follow an With this forwarding procedure, a multicast data packet can follow an
optimal path from its BFIR to each of its BFERs. Further, since the optimal path from its BFIR to each of its BFERs. Further, since the
set of BFERs for a given packet is explicitly encoded into the BIER set of BFERs for a given packet is explicitly encoded into the BIER
header, the packet is not sent to any BFER that does not need to header, the packet is not sent to any BFER that does not need to
receive it. This allows for optimal forwarding of multicast traffic. receive it. This allows for optimal forwarding of multicast traffic.
This optimal forwarding is achieved without any need for transit BFRs This optimal forwarding is achieved without any need for transit BFRs
to maintain per-flow state, or to run a multicast tree-building to maintain per-flow state, or to run a multicast tree-building
protocol. protocol.
The idea of encoding the set of egress nodes into the header of a The idea of encoding the set of egress nodes into the header of a
skipping to change at page 7, line 10 skipping to change at page 7, line 17
RECOMMENDED to assign all the BFR-ids from the range [1,256]. If RECOMMENDED to assign all the BFR-ids from the range [1,256]. If
there are more than 256 BFERs, but less than 512, it is RECOMMENDED there are more than 256 BFERs, but less than 512, it is RECOMMENDED
to assign all the BFR-ids from the range [1,512], with as few "holes" to assign all the BFR-ids from the range [1,512], with as few "holes"
as possible in the earlier range. However, in some deployments, it as possible in the earlier range. However, in some deployments, it
may be advantageous to depart from this recommendation; this is may be advantageous to depart from this recommendation; this is
discussed further in Section 3. discussed further in Section 3.
In some deployments, it may not be possible to support (in a given In some deployments, it may not be possible to support (in a given
sub-domain) the full range of 65535 BFR-ids. For example, if the sub-domain) the full range of 65535 BFR-ids. For example, if the
BFRs in a given sub-domain only support 16 SIs and if they only BFRs in a given sub-domain only support 16 SIs and if they only
support BitStringLengths of 256 or less, then only 16*256=4096 BFR- support BitStringLengths of 256 or less, then only 16*256=4096
ids can be supported in that sub-domain. BFR-ids can be supported in that sub-domain.
3. Encoding BFR Identifiers in BitStrings 3. Encoding BFR Identifiers in BitStrings
To encode a BFR-id in a BIER data packet, one must convert the BFR-id To encode a BFR-id in a BIER data packet, one must convert the BFR-id
to an SI and a BitString. This conversion depends upon the parameter to an SI and a BitString. This conversion depends upon the parameter
we are calling "BitStringLength". The conversion is done as follows. we are calling "BitStringLength". The conversion is done as follows.
If the BFR-id is N, then If the BFR-id is N, then
o SI is the integer part of the quotient (N-1)/BitStringLength o SI is the integer part of the quotient (N-1)/BitStringLength
skipping to change at page 8, line 9 skipping to change at page 8, line 18
BFIR is provisioned to use a particular Imposition BitStringLength BFIR is provisioned to use a particular Imposition BitStringLength
and a particular Imposition sub-domain when imposing the and a particular Imposition sub-domain when imposing the
encapsulation on a given set of packets, all other BFRs with BFR-ids encapsulation on a given set of packets, all other BFRs with BFR-ids
in that sub-domain SHOULD be provisioned to process received BIER in that sub-domain SHOULD be provisioned to process received BIER
packets with that BitStringLength (i.e., all other BFRs with BFR-ids packets with that BitStringLength (i.e., all other BFRs with BFR-ids
in that sub-domain SHOULD be provisioned with that BitStringLength as in that sub-domain SHOULD be provisioned with that BitStringLength as
a Disposition BitStringLength for that sub-domain. Exceptions to a Disposition BitStringLength for that sub-domain. Exceptions to
this rule MAY be made under certain conditions; this is discussed in this rule MAY be made under certain conditions; this is discussed in
Section 6.10. Section 6.10.
Every BFIR MUST be capable of being provisioned with an Imposition When a BIER encapsulation is specified, the specification MUST define
BitStringLength of 256. Every BFR and BFER MUST be capable of being a default BitStringLength for the encapsulation. Every BFIR
provisioned with a Disposition BitStringLength of 256. supporting that encapsulation MUST be capable of being provisioned
with that default BitStringLength as its Imposition BitStringLength.
Every BFR and BFER supporting that encapsulation MUST be capable of
being provisioned with that default BitStringLength as a Disposition
BitStringLength.
Particular BIER encapsulation types MAY allow other BitStringLengths The specification of a BIER encapsulation MAY also allow the use of
to be OPTIONALLY supported. For example, when using either of the other BitStringLengths.
encapsulations specified in [MPLS_BIER_ENCAPS], a BFR may be capable
of being provisioned to use any or all of the following
BitStringLengths as Imposition BitStringLengths and as Disposition
BitStringLengths: 64, 128, 256, 512, 1024, 2048, and 4096.
If a BFR is capable of being provisioned with a given value of If a BFR is capable of being provisioned with a given value of
BitStringLength as an Imposition BitStringLength, it MUST also be BitStringLength as an Imposition BitStringLength, it MUST also be
capable of being provisioned with that same value as one of its capable of being provisioned with that same value as one of its
Disposition BitStringLengths. It SHOULD be capable of being Disposition BitStringLengths. It SHOULD be capable of being
provisioned with all legal smaller values of BitStringLength as both provisioned with all legal smaller values of BitStringLength as both
Imposition and Disposition BitStringLength. Imposition and Disposition BitStringLength.
In order to support transition from one BitStringLength to another, In order to support transition from one BitStringLength to another,
every BFR MUST be capable of being provisioned to simultaneously use every BFR MUST be capable of being provisioned to simultaneously use
skipping to change at page 9, line 17 skipping to change at page 9, line 27
as well. as well.
Suppose, for example, that a BFIR determines that a given packet Suppose, for example, that a BFIR determines that a given packet
needs to be forwarded to three BFERs, whose BFR-ids (in the needs to be forwarded to three BFERs, whose BFR-ids (in the
appropriate sub-domain) are 27, 235, and 497. The BFIR will have to appropriate sub-domain) are 27, 235, and 497. The BFIR will have to
forward two copies of the packet. One copy, associated with SI=0, forward two copies of the packet. One copy, associated with SI=0,
will have a BitString with bits 27 and 235 set. The other copy, will have a BitString with bits 27 and 235 set. The other copy,
associated with SI=1, will have a BitString with bit 241 set. associated with SI=1, will have a BitString with bit 241 set.
In order to minimize the number of copies that must be made of a In order to minimize the number of copies that must be made of a
given multicast packet, it is RECOMMENDED that the BFR-ids be given multicast packet, it is RECOMMENDED that the BFR-ids used in a
assigned "densely" (see Section 2) from the numbering space. This given sub-domain be assigned "densely" (see Section 2) from the
will minimize the number of SIs that have to be used in the domain. numbering space. This will minimize the number of SIs that have to
However, depending upon the details of a particular deployment, other be used in that sub-domain. However, depending upon the details of a
assignment methods may be more advantageous. Suppose, for example, particular deployment, other assignment methods may be more
that in a certain deployment, every multicast flow is either intended advantageous. Suppose, for example, that in a certain deployment,
for the "east coast" or for the "west coast". In such a deployment, every multicast flow is either intended for the "east coast" or for
it would be advantageous to assign BFR-ids so that all the "west the "west coast". In such a deployment, it would be advantageous to
coast" BFR-ids fall into the same SI-subset, and so that all the assign BFR-ids so that all the "west coast" BFR-ids fall into the
"east coast" BFR-ids fall into the same SI-subset. same SI-subset, and so that all the "east coast" BFR-ids fall into
the same SI-subset.
When a BFR receives a BIER data packet, it will infer the SI from the When a BFR receives a BIER data packet, it will infer the SI from the
encapsulation. The set of BFERs to which the packet needs to be encapsulation. The set of BFERs to which the packet needs to be
forwarded can then be inferred from the SI and the BitString. forwarded can then be inferred from the SI and the BitString.
In some of the examples given later in this document, we will use a In some of the examples given later in this document, we will use a
BitStringLength of 4, and will represent a BFR-id in the form BitStringLength of 4, and will represent a BFR-id in the form
"SI:xyzw", where SI is the Set Identifier of the BFR-id (assuming a "SI:xyzw", where SI is the Set Identifier of the BFR-id (assuming a
BitStringLength of 4), and xyzw is a string of 4 bits. A BitStringLength of 4), and xyzw is a string of 4 bits. A
BitStringLength of 4 is used only in the examples; we would not BitStringLength of 4 is used only in the examples; we would not
skipping to change at page 10, line 40 skipping to change at page 10, line 45
packet traveling from BFR-A to BFER-B will follow the path that OSPF packet traveling from BFR-A to BFER-B will follow the path that OSPF
has selected for unicast traffic from BFR-A to BFER-B. has selected for unicast traffic from BFR-A to BFER-B.
If one wants to have multicast traffic from BFR-A to BFER-B travel a If one wants to have multicast traffic from BFR-A to BFER-B travel a
path that is different from the path used by the unicast traffic from path that is different from the path used by the unicast traffic from
A to B, one can use a different underlay. For example, if multi- A to B, one can use a different underlay. For example, if multi-
topology OSPF is being used, one OSPF topology could be used for topology OSPF is being used, one OSPF topology could be used for
unicast traffic, and the other for multicast traffic. (Each topology unicast traffic, and the other for multicast traffic. (Each topology
would be considered to be a different underlay.) Alternatively, one would be considered to be a different underlay.) Alternatively, one
could deploy a routing underlay that creates a multicast-specific could deploy a routing underlay that creates a multicast-specific
tree of some sort, perhaps a Steiner tree. Then BIER could be used tree of some sort. Then BIER could be used to forward multicast data
to forward multicast data packets along the multicast-specific tree, packets along the multicast-specific tree, while unicast packets
while unicast packets follow the "ordinary" OSPF best path. It is follow the "ordinary" OSPF best path. (In a case like this, many
even possible to have multiple routing underlays used by BIER, as multicast flows could be traveling along a single tree, and the
long as one can infer from a data packet's BIER encapsulation which BitString carried by a particular packet would identify those nodes
underlay is being used for that packet. of the tree that need to receive that packet.) It is even possible
to have multiple routing underlays used by BIER, as long as one can
infer from a data packet's BIER encapsulation which underlay is being
used for that packet.
If multiple routing underlays are used in a single BIER domain, each If multiple routing underlays are used in a single BIER domain, each
BIER sub-domain MUST be associated with a single routing underlay. BIER sub-domain MUST be associated with a single routing underlay.
(Though multiple sub-domains may be associated with the same routing (Though multiple sub-domains may be associated with the same routing
underlay.) A BFR that belongs to multiple sub-domains MUST be underlay.) A BFR that belongs to multiple sub-domains MUST be
provisioned to know which routing underlay is used by each sub- provisioned to know which routing underlay is used by each
domain. By default (i.e., in the absence of any provisioning to the sub-domain. By default (i.e., in the absence of any provisioning to
contrary), each sub-domain uses the default topology of the unicast the contrary), each sub-domain uses the default topology of the
IGP as the routing underlay. unicast IGP as the routing underlay.
In scenarios where EBGP is used as the IGP, the underlay adjacencies,
by default, are the BGP adjacencies.
Specification of the protocol and procedures of the routing underlay Specification of the protocol and procedures of the routing underlay
is outside the scope of this document. is outside the scope of this document.
4.2. The BIER Layer 4.2. The BIER Layer
The BIER layer consists of the protocol and procedures that are used The BIER layer consists of the protocol and procedures that are used
in order to transmit a multicast data packet across a BIER domain, in order to transmit a multicast data packet across a BIER domain,
from its BFIR to its BFERs. This includes the following components: from its BFIR to its BFERs. This includes the following components:
skipping to change at page 12, line 14 skipping to change at page 12, line 28
For example, suppose the BFIR and BFERs are Provider Edge (PE) For example, suppose the BFIR and BFERs are Provider Edge (PE)
routers providing Multicast Virtual Private Network (MVPN) service. routers providing Multicast Virtual Private Network (MVPN) service.
The multicast flow overlay consists of the protocols and procedures The multicast flow overlay consists of the protocols and procedures
described in [RFC6513] and [RFC6514]. The MVPN signaling described described in [RFC6513] and [RFC6514]. The MVPN signaling described
in those RFCs enables an ingress PE to determine the set of egress in those RFCs enables an ingress PE to determine the set of egress
PEs for a given multicast flow (or set of flows); it also enables an PEs for a given multicast flow (or set of flows); it also enables an
egress PE to determine the "Virtual Routing and Forwarding Tables" egress PE to determine the "Virtual Routing and Forwarding Tables"
(VRFs) to which multicast packets from the backbone network should be (VRFs) to which multicast packets from the backbone network should be
sent. MVPN signaling also has several components that depend on the sent. MVPN signaling also has several components that depend on the
type of "tunneling technology" used to carry multicast data though type of "tunneling technology" used to carry multicast data through
the network. Since BIER is, in effect, a new type of "tunneling the network. Since BIER is, in effect, a new type of "tunneling
technology", some extensions to the MVPN signaling are needed in technology", some extensions to the MVPN signaling are needed in
order to properly interface the multicast flow overlay with the BIER order to properly interface the multicast flow overlay with the BIER
layer. These are specified in [BIER-MVPN]. layer. These are specified in [BIER-MVPN].
MVPN is just one example of a multicast flow overlay. Protocols and MVPN is just one example of a multicast flow overlay. Protocols and
procedures for other overlays will be provided in companion procedures for other overlays will be provided in companion
documents. It is also possible to implement the multicast flow documents. It is also possible to implement the multicast flow
overlay by means of a "Software Defined Network" (SDN) controller. overlay by means of a "Software Defined Network" (SDN) controller.
Specification of the protocols and procedures of the multicast flow Specification of the protocols and procedures of the multicast flow
skipping to change at page 12, line 39 skipping to change at page 13, line 6
As stated in Section 2, each BFER is assigned (by provisioning) a As stated in Section 2, each BFER is assigned (by provisioning) a
BFR-id (for a given BIER sub-domain). Each BFER must advertise these BFR-id (for a given BIER sub-domain). Each BFER must advertise these
assignments to all the other BFRs in the domain. Similarly, each BFR assignments to all the other BFRs in the domain. Similarly, each BFR
is assigned (by provisioning) a BFR-prefix (for a given BIER domain), is assigned (by provisioning) a BFR-prefix (for a given BIER domain),
and must advertise this assignment to all the other BFRs in the and must advertise this assignment to all the other BFRs in the
domain. Finally, each BFR has been provisioned to use a certain set domain. Finally, each BFR has been provisioned to use a certain set
of Disposition BitStringLengths for each sub-domain, and must of Disposition BitStringLengths for each sub-domain, and must
advertise these to all other BFRs in the domain. advertise these to all other BFRs in the domain.
If the BIER domain is also a link state routing IGP domain (i.e., an If the BIER domain is also a link state routing IGP domain (i.e., an
OSPF or IS-IS domain), the advertisement of the BFR-prefix, <sub- OSPF or IS-IS domain), the advertisement of the BFR-prefix,
domain-id,BFR-id> and BitStringLength can be done using the <sub-domain-id,BFR-id> and BitStringLength can be done using the
advertisement capabilities of the IGP. For example, if a BIER domain advertisement capabilities of the IGP. For example, if a BIER domain
is also an OSPF domain, these advertisements can be done using the is also an OSPF domain, these advertisements can be done using the
OSPF "Opaque Link State Advertisement" (Opaque LSA) mechanism. OSPF "Opaque Link State Advertisement" (Opaque LSA) mechanism.
Details of the necessary extensions to OSPF and IS-IS will be Details of the necessary extensions to OSPF and IS-IS will be
provided in companion documents. (See [OSPF_BIER_EXTENSIONS] and provided in companion documents. (See [OSPF_BIER_EXTENSIONS] and
[ISIS_BIER_EXTENSIONS].) [ISIS_BIER_EXTENSIONS].)
These advertisements enable each BFR to associate a given <sub- If, in a particular deployment, the BIER domain is not an OSPF or
domain-id, BFR-id> with a given BFR-prefix. As will be seen in ISIS domain, procedures suitable to the deployment must be used to
advertise this information. Details of the necessary procedures will
be provided in companion documents. For example, if BGP is the only
routing algorithm used in the BIER domain, the procedures of
[BGP_BIER_EXTENSIONS] may be used.
These advertisements enable each BFR to associate a given
<sub-domain-id, BFR-id> with a given BFR-prefix. As will be seen in
subsequent sections of this document, knowledge of this association subsequent sections of this document, knowledge of this association
is an important part of the forwarding process. is an important part of the forwarding process.
Since each BFR needs to have a unique (in each sub-domain) BFR-id, Since each BFR needs to have a unique (in each sub-domain) BFR-id,
two different BFRs will not advertise ownership of the same <sub- two different BFRs will not advertise ownership of the same
domain-id, BFR-id> unless there has been a provisioning error. <sub-domain-id, BFR-id> unless there has been a provisioning error.
o If BFR-A determines that BFR-B and BFR-C have both advertised the o If BFR-A determines that BFR-B and BFR-C have both advertised the
same BFR-id for the same sub-domain, BFR-A MUST log an error. same BFR-id for the same sub-domain, BFR-A MUST log an error.
Suppose that the duplicate BFR-id is "N". When BFR-A is Suppose that the duplicate BFR-id is "N". When BFR-A is
functioning as a BFIR, it MUST NOT encode the BFR-id value N in functioning as a BFIR, it MUST NOT encode the BFR-id value N in
the BIER encapsulation of any packet that has been assigned to the the BIER encapsulation of any packet that has been assigned to the
given sub-domain, even if it has determined that the packet needs given sub-domain, even if it has determined that the packet needs
to be received by BFR-B and/or BFR-C. to be received by BFR-B and/or BFR-C.
This will mean that BFR-B and BFR-C cannot receive multicast This will mean that BFR-B and BFR-C cannot receive multicast
traffic at all in the given sub-domain until the provisioning traffic at all in the given sub-domain until the provisioning
error is fixed. However, that is preferable to having them error is fixed. However, that is preferable to having them
receive each other's traffic. receive each other's traffic.
o If BFR-A has been provisioned with BFR-id N for a particular sub- o If BFR-A has been provisioned with BFR-id N for a particular
domain, has not yet advertised its ownership of BFR-id N for that sub-domain, has not yet advertised its ownership of BFR-id N for
sub-domain, but has received an advertisement from a different BFR that sub-domain, but has received an advertisement from a
(say BFR-B) that is advertising ownership of BFR-id N for the same different BFR (say BFR-B) that is advertising ownership of BFR-id
sub-domain, then BFR-A SHOULD log an error, and MUST NOT advertise N for the same sub-domain, then BFR-A SHOULD log an error, and
its own ownership of BFR-id N for that sub-domain as long as the MUST NOT advertise its own ownership of BFR-id N for that
advertisement from BFR-B is extant. sub-domain as long as the advertisement from BFR-B is extant.
This procedure may prevent the accidental misconfiguration of a This procedure may prevent the accidental misconfiguration of a
new BFR from impacting an existing BFR. new BFR from impacting an existing BFR.
If a BFR advertises that it has a BFR-id of 0 in a particular sub- If a BFR advertises that it has a BFR-id of 0 in a particular
domain, other BFRs receiving the advertisement MUST interpret that sub-domain, other BFRs receiving the advertisement MUST interpret
advertisement as meaning that the advertising BFR does not have a that advertisement as meaning that the advertising BFR does not have
BFR-id in that sub-domain. a BFR-id in that sub-domain.
6. BIER Intra-Domain Forwarding Procedures 6. BIER Intra-Domain Forwarding Procedures
This section specifies the rules for forwarding a BIER-encapsulated This section specifies the rules for forwarding a BIER-encapsulated
data packet within a BIER domain. These rules are not intended to data packet within a BIER domain. These rules are not intended to
specify an implementation strategy; to conform to this specification, specify an implementation strategy; to conform to this specification,
an implementation need only produce the same results that these rules an implementation need only produce the same results that these rules
produce. produce.
6.1. Overview 6.1. Overview
skipping to change at page 14, line 40 skipping to change at page 15, line 15
8. For each partition: 8. For each partition:
a. Make a copy of the packet. a. Make a copy of the packet.
b. Clear any bit in the packet's BitString that identifies a b. Clear any bit in the packet's BitString that identifies a
BFER that is not in the partition. BFER that is not in the partition.
c. Transmit the packet to the associated next hop. (If the next c. Transmit the packet to the associated next hop. (If the next
hop is the null next hop, the packet is discarded.) hop is the null next hop, the packet is discarded.)
If a BFR receives a BIER-encapsulated packet whose sub-domain, SI and If a BFR receives a BIER-encapsulated packet whose <sub-domain, SI,
BitString identify that BFR itself, then the BFR is also a BFER for BitString> triple identifies that BFR itself, then the BFR is also a
that packet. As a BFER, it must pass the payload to the multicast BFER for that packet. As a BFER, it must pass the payload to the
flow overlay. If the BitString has bits set for other BFRs, the multicast flow overlay. If the BitString has bits set for other
packet also needs to be forwarded further within the BIER domain. If BFRs, the packet also needs to be forwarded further within the BIER
the BF(E)R also forwards one or more copies of the packet within the domain. If the BF(E)R also forwards one or more copies of the packet
BIER domain, the bit representing the BFR's own BFR-id MUST be clear within the BIER domain, the bit representing the BFR's own BFR-id
in all the copies. MUST be clear in all the copies.
When BIER on a BFER is to pass a packet to the multicast flow When BIER on a BFER is to pass a packet to the multicast flow
overlay, it of course decapsulates the packet by removing the BIER overlay, it of course decapsulates the packet by removing the BIER
header. However, it may be necessary to provide the multicast flow header. However, it may be necessary to provide the multicast flow
overlay with contextual information obtained from the BIER overlay with contextual information obtained from the BIER
encapsulation. The information that needs to pass between the BIER encapsulation. The information that needs to pass between the BIER
layer and the multicast flow overlay is specific to the multicast layer and the multicast flow overlay is specific to the multicast
flow overlay. Specification of the interaction between the BIER flow overlay. Specification of the interaction between the BIER
layer and the multicast flow overlay is outside the scope of this layer and the multicast flow overlay is outside the scope of this
specification. specification.
skipping to change at page 19, line 22 skipping to change at page 19, line 22
This procedure causes the packet to be forwarded to a particular This procedure causes the packet to be forwarded to a particular
BFR-NBR only once. The number of lookups in the BIFT is the same as BFR-NBR only once. The number of lookups in the BIFT is the same as
the number of BFR-NBRs to which the packet must be forwarded; it is the number of BFR-NBRs to which the packet must be forwarded; it is
not necessary to do a separate lookup for each destination BFER. not necessary to do a separate lookup for each destination BFER.
When a packet is sent to a particular BFR-NBR, the BitString is not When a packet is sent to a particular BFR-NBR, the BitString is not
the only part of the BIER header that needs to be modified. If there the only part of the BIER header that needs to be modified. If there
is a TTL field in the BIER header, it will need to be decremented. is a TTL field in the BIER header, it will need to be decremented.
In addition, when either of the encapsulations of [MPLS_BIER_ENCAPS] In addition, when either of the encapsulations of [MPLS_BIER_ENCAPS]
is used, the BIFT-id field is likely to require modification, based is used, the BIFT-id field is likely to require modification, based
on signaling from the BFR-NBR to which the packet is being sent. on signaling from the BFR-NBR to which the packet is being sent. The
BIFT-id field of an incoming BIER packet implicitly identifies a Set
Identifier, a Sub-Domain and a BitStringLength. If the packet is
sent to a particular BFR-NBR, the BIFT-id field must be changed to
whatever value that BFR-NBR has advertised for the same Set
Identifier, Sub-Domain, and BitStringLength. (If the encapsulation
of Section 2.1 of [MPLS_BIER_ENCAPS] is used, this is essentially an
MPLS label swap operation.)
Suppose it has been decided (by the above rules) to send a packet to Suppose it has been decided (by the above rules) to send a packet to
a particular BFR-NBR. If that BFR-NBR is connected via multiple a particular BFR-NBR. If that BFR-NBR is connected via multiple
parallel interfaces, it may be desirable to apply some form of load parallel interfaces, it may be desirable to apply some form of load
balancing. Load balancing algorithms are outside the scope of this balancing. Load balancing algorithms are outside the scope of this
document. However, if the packet's encapsulation contains an document. However, if the packet's encapsulation contains an
"entropy" field, the entropy field SHOULD be respected; two packets "entropy" field, the entropy field SHOULD be respected; two packets
with the same value of the entropy field SHOULD be sent on the same with the same value of the entropy field SHOULD be sent on the same
interface (if possible). interface (if possible).
skipping to change at page 27, line 35 skipping to change at page 27, line 35
Note that if there are three paths to one destination and four paths Note that if there are three paths to one destination and four paths
to another, 12 BIFTs would be required in order to get even splitting to another, 12 BIFTs would be required in order to get even splitting
of the load to each of those two destinations. Of course, each BIFT of the load to each of those two destinations. Of course, each BIFT
uses some memory, and one might be willing to have less optimal uses some memory, and one might be willing to have less optimal
splitting in order to have fewer BIFTs. How that tradeoff is made is splitting in order to have fewer BIFTs. How that tradeoff is made is
an implementation or deployment decision. an implementation or deployment decision.
6.8. Prevention of Loops and Duplicates 6.8. Prevention of Loops and Duplicates
The BitString in a BIER-encapsulated packet specifies the set of The BitString in a BIER-encapsulated packet specifies the set of
BFERs to which that packet is to be forwarded. When a BIER- BFERs to which that packet is to be forwarded. When a
encapsulated packet is replicated, no two copies of the packet will BIER-encapsulated packet is replicated, no two copies of the packet
ever have a BFER in common. If one of the packet's BFERs forwards will ever have a BFER in common. If one of the packet's BFERs
the packet further, that will first clear the bit that identifies forwards the packet further, that will first clear the bit that
itself. As a result, duplicate delivery of packets is not possible identifies itself. As a result, duplicate delivery of packets is not
with BIER. possible with BIER.
As long as the routing underlay provides a loop free path between As long as the routing underlay provides a loop free path between
each pair of BFRs, BIER-encapsulated packets will not loop. Since each pair of BFRs, BIER-encapsulated packets will not loop. Since
the BIER layer does not create any paths of its own, there is no need the BIER layer does not create any paths of its own, there is no need
for any BIER-specific loop prevention techniques beyond the for any BIER-specific loop prevention techniques beyond the
forwarding procedures specified in Section 6.5. forwarding procedures specified in Section 6.5.
If, at some time, the routing underlay is not providing a loop free If, at some time, the routing underlay is not providing a loop free
path between BFIR-A and BFER-B, then BIER encapsulated packets may path between BFIR-A and BFER-B, then BIER encapsulated packets may
loop while traveling from BFIR-A to BFER-B. However, such loops will loop while traveling from BFIR-A to BFER-B. However, such loops will
skipping to change at page 28, line 15 skipping to change at page 28, line 15
These properties of BIER eliminate the need for the "reverse path These properties of BIER eliminate the need for the "reverse path
forwarding" (RPF) check that is used in conventional IP multicast forwarding" (RPF) check that is used in conventional IP multicast
forwarding. forwarding.
6.9. When Some Nodes do not Support BIER 6.9. When Some Nodes do not Support BIER
The procedures of section Section 6.2 presuppose that, within a given The procedures of section Section 6.2 presuppose that, within a given
BIER domain, all the nodes adjacent to a given BFR in a given routing BIER domain, all the nodes adjacent to a given BFR in a given routing
underlay are also BFRs. However, it is possible to use BIER even underlay are also BFRs. However, it is possible to use BIER even
when this is not the case, as long as the ingress and egress nodes when this is not the case, as long as the ingress and egress nodes
are BFRs. In this section, we assume that the routing underlay is an are BFRs. In this section, we describe procedures that can be used
SPF-based IGP that computes a shortest path tree from each node to if the routing underlay is an SPF-based IGP that computes a shortest
all other nodes in the domain. path tree from each node to all other nodes in the domain.
At a given BFR, say BFR B, start with a copy of the IGP-computed At a given BFR, say BFR B, start with a copy of the IGP-computed
shortest path tree from BFR B to each router in the domain. (This shortest path tree from BFR B to each router in the domain. (This
tree is computed by the SPF algorithm of the IGP.) Let's call this tree is computed by the SPF algorithm of the IGP.) Let's call this
copy the "BIER-SPF tree rooted at BFR B." BFR B then modifies this copy the "BIER-SPF tree rooted at BFR B." BFR B then modifies this
BIER-SPF tree as follows. BIER-SPF tree as follows.
1. BFR B looks in turn at each of B's child nodes on the BIER-SPF 1. BFR B looks in turn at each of B's child nodes on the BIER-SPF
tree. tree.
skipping to change at page 28, line 45 skipping to change at page 28, line 45
of the previous step. of the previous step.
When all of the child nodes (the original child nodes plus any new When all of the child nodes (the original child nodes plus any new
ones) have been examined, B's children on the BIER-SPF tree will all ones) have been examined, B's children on the BIER-SPF tree will all
be BFRs. be BFRs.
When the BIFT is constructed, B's child nodes on the BIER-SPF tree When the BIFT is constructed, B's child nodes on the BIER-SPF tree
are considered to be the BFR-NBRs. The F-BMs must be computed are considered to be the BFR-NBRs. The F-BMs must be computed
appropriately, based on the BFR-NBRs. appropriately, based on the BFR-NBRs.
If one of the encapsulations of [MPLS_BIER_ENCAPS] is used, the BIFT-
id field of the packet may also be modified. The BIFT-id field of an
incoming BIER packet implicitly identifies a Set Identifier, a Sub-
Domain and a BitStringLength. If the packet is sent to a particular
BFR-NBR, the BIFT-id field must be changed to whatever value that
BFR-NBR has advertised for the same Set Identifier, Sub-Domain, and
BitStringLength. The TTL field in the BIFT header MUST also be
decremented. (If the encapsulation of Section 2.1 of
[MPLS_BIER_ENCAPS] is used, this is essentially an MPLS label swap
operation.)
B may now have BFR-NBRs that are not "directly connected" to B via B may now have BFR-NBRs that are not "directly connected" to B via
layer 2. To send a packet to one of these BFR-NBRs, B will have to layer 2. To send a packet to one of these BFR-NBRs, B will have to
send the packet through a unicast tunnel. In an MPLS network, this send the packet through a unicast tunnel. In an MPLS network, this
may be as simple as finding the IGP unicast next hop to the child may be as simple as finding the IGP unicast next hop to the child
node, and pushing on (above the BIER encapsulation header) an MPLS node, and pushing on (above the BIER encapsulation header) an MPLS
label that the IGP next hop has bound to an address of the child label that the IGP next hop has bound to an address of the child
node. (This assumes that the packet is using an MPLS-based BIER node. (This assumes that the packet is using an MPLS-based BIER
encapsulation, such as the one specified in Section 2.1 of encapsulation, such as the one specified in Section 2.1 of
[MPLS_BIER_ENCAPS].) Of course, the BIFT-id in the BIER [MPLS_BIER_ENCAPS].) Of course, the BIFT-id in the BIER
encapsulation header must be the BIFT-id advertised by the child node encapsulation header must be the BIFT-id advertised by the child node
for the packet's Set Index, Sub-Domain, and BitStringLength. for the packet's Set Index, Sub-Domain, and BitStringLength.
If for some reason the unicast tunnel cannot be an MPLS tunnel, any If for some reason the unicast tunnel cannot be an MPLS tunnel, any
other kind of tunnel can be used, as long as the encapsulation for other kind of tunnel can be used, as long as the encapsulation for
that tunnel type has a way of indicating that the payload is a BIER- that tunnel type has a way of indicating that the payload is a
encapsulated packet. BIER-encapsulated packet.
Note that if a BIER-encapsulated packet is not using an MPLS-based Note that if a BIER-encapsulated packet is not using an MPLS-based
BIER encapsulation, it will not be possible to send it through an BIER encapsulation, it will not be possible to send it through an
MPLS tunnel unless it is known that the tunnel only carries BIER MPLS tunnel unless it is known that the tunnel only carries BIER
packets. The reason is that MPLS has no "next protocol type" field. packets. The reason is that MPLS has no "next protocol type" field.
This is not a problem if an MPLS-based BIER encapsulation is used, This is not a problem if an MPLS-based BIER encapsulation is used,
because in that case the BIER encapsulation begins with an MPLS label because in that case the BIER encapsulation begins with an MPLS label
that identifies the packet as a BIER-encapsulated packet. that identifies the packet as a BIER-encapsulated packet.
Of course, the above is not meant as an implementation technique, Of course, the above is not meant as an implementation technique,
skipping to change at page 31, line 7 skipping to change at page 30, line 43
use the multi-topology features of the IGP to set up a BIER-specific use the multi-topology features of the IGP to set up a BIER-specific
topology. This topology would exclude all the non-BIER-capable topology. This topology would exclude all the non-BIER-capable
interfaces that attach to BFRs. BIER would then have to be run in a interfaces that attach to BFRs. BIER would then have to be run in a
sub-domain that is bound to this topology. If unicast tunnels are sub-domain that is bound to this topology. If unicast tunnels are
used to bypass non-BFRs, either the tunnels have to be restricted to used to bypass non-BFRs, either the tunnels have to be restricted to
this topology, or the tunnel endpoints have to be BFRs that do not this topology, or the tunnel endpoints have to be BFRs that do not
have any non-BIER-capable interfaces. have any non-BIER-capable interfaces.
6.10. Use of Different BitStringLengths within a Domain 6.10. Use of Different BitStringLengths within a Domain
The procedures of this section apply only when the same encapsulation
is used throughout the BIER domain. Consideration of the scenario
where both multiple encapsulations and multiple BitStringLengths are
used in a given BIER domain is outside the scope of this document.
It is possible for different BFRs within a BIER domain to be using It is possible for different BFRs within a BIER domain to be using
different Imposition and/or Disposition BitStringLengths. As stated different Imposition and/or Disposition BitStringLengths. As stated
in Section 3: in Section 3:
"if a particular BFIR is provisioned to use a particular "if a particular BFIR is provisioned to use a particular
Imposition BitStringLength and a particular Imposition sub-domain Imposition BitStringLength and a particular Imposition sub-domain
when imposing the encapsulation on a given set of packets, all when imposing the encapsulation on a given set of packets, all
other BFRs with BFR-ids in that sub-domain SHOULD be provisioned other BFRs with BFR-ids in that sub-domain SHOULD be provisioned
to process received BIER packets with that BitStringLength (i.e., to process received BIER packets with that BitStringLength (i.e.,
all other BFRs with BFR-ids in that sub-domain SHOULD be all other BFRs with BFR-ids in that sub-domain SHOULD be
skipping to change at page 33, line 31 skipping to change at page 33, line 28
o Every BFR advertises that it uses BitStringLength F as a o Every BFR advertises that it uses BitStringLength F as a
Disposition BitStringLength for every sub-domain, and Disposition BitStringLength for every sub-domain, and
o If a BFIR is provisioned to use Imposition BitStringLength X and o If a BFIR is provisioned to use Imposition BitStringLength X and
Imposition sub-domain S for a certain class of packets, but the Imposition sub-domain S for a certain class of packets, but the
BitStringLength Compatibility check fails for the combination of BitStringLength Compatibility check fails for the combination of
BitStringLength X and sub-domain S, then the BFIR will fall back BitStringLength X and sub-domain S, then the BFIR will fall back
to using BitStringLength F as the Imposition BitStringLength to using BitStringLength F as the Imposition BitStringLength
whenever the Imposition sub-domain is S. whenever the Imposition sub-domain is S.
It is RECOMMENDED that the value of F be 256. It is RECOMMENDED that the value of F be the default BitStringLength
for the encapsulation being used.
6.10.2. Handling BitStringLength Mismatches 6.10.2. Handling BitStringLength Mismatches
Suppose a packet has been BIER-encapsulated with a BitStringLength Suppose a packet has been BIER-encapsulated with a BitStringLength
value of X, and that the packet has arrived at BFR-A. Now suppose value of X, and that the packet has arrived at BFR-A. Now suppose
that according to the routing underlay, the next hop is BFR-B, but that according to the routing underlay, the next hop is BFR-B, but
BFR-B is not using X as one of its Disposition BitStringLengths. BFR-B is not using X as one of its Disposition BitStringLengths.
What should BFR-A do with the packet? BFR-A has three options. It What should BFR-A do with the packet? BFR-A has three options. It
MUST do one of the three, but the choice of which procedure to follow MUST do one of the three, but the choice of which procedure to follow
is a local matter. The three options are: is a local matter. The three options are:
skipping to change at page 34, line 29 skipping to change at page 34, line 27
Suppose one wants to migrate the BitStringLength used in a particular Suppose one wants to migrate the BitStringLength used in a particular
BIER domain from one value (X) to another value (Y). The following BIER domain from one value (X) to another value (Y). The following
migration procedure can be used. This procedure allows the BFRs to migration procedure can be used. This procedure allows the BFRs to
be reprovisioned one at a time, and does not require a "flag day". be reprovisioned one at a time, and does not require a "flag day".
First, upgrade all the BFRs in the domain so that they use both value First, upgrade all the BFRs in the domain so that they use both value
X and value Y as their Disposition BitStringLengths. Once this is X and value Y as their Disposition BitStringLengths. Once this is
done, reprovision the BFIRs so that they use BitStringLength value Y done, reprovision the BFIRs so that they use BitStringLength value Y
as the Imposition BitStringLength. Once that is done, one may as the Imposition BitStringLength. Once that is done, one may
optionally reprovision all the BFRs so that they no longer use optionally reprovision all the BFRs so that they no longer use
Dispostion BitStringLength X. Disposition BitStringLength X.
7. IANA Considerations 7. Operational Considerations
BIER offers a radical simplification over current IPMulticast
operations; no tree-building control plane, no per-flow forwarding
state, no Reverse Path Forwarding (RPF), no Rendezvous Point (RP)
etc. BIER packet forwarding/replication is along the unicast paths
to each bit position set in the packet, ensuring the encapsulated
multicast packets follow the same path as unicast to each set bit in
the header. The BIER FIB can be derived from the unicast SPF
calculated unicast FIB, or any other forwarding path calculation in
or out of band. Each bit will follow this unicast path from the
entry point of the BIER domain to edge device with that assigned bit.
Due to these differences, operational expectation from traditional
multicast solutions do not apply to a BIER domain. There is no
granular per-flow state at each node defining a tree. Monitoring
flows at the forwarding plane level, (S,G) entries, is not provided
in a BIER node. BIER FIB packet counters may be maintained for BFR-
IDs or next-hop neighbors. Any flow based metrics will require
deeper packet inspection which is outside of the scope of this
document. In this way, BIER is again more like unicast.
It is this reduction in state that allows for one of the key
operational benefits of BIER, deterministic convergence. The BIER
FIB can converge immediately after the unicast FIB regardless of how
many multicast flows are transiting the links. Careful monitoring of
(S,G) utilization is not required within a BIER domain.
7.1. Configuration
A BIER domain requires that each edge node (BFER) be given a unique
bit position in the BIER mask (BFR-id). The BFR-id must be
configured on each BFER and associated with a unique IP address of
that BFER. Any existing manual or automated configuration tools must
provide access to BIER specific configuration. The association of
the BFR-id with a unique address of the BFER to which it is assigned
must also be advertised into the IGP of the BIER domain. This may be
implied from the BIER configuration or require IGP specific
configuration. This document does not dictate any specific
configuration methodology.
8. IANA Considerations
This document contains no actions for IANA. This document contains no actions for IANA.
8. Security Considerations 9. Security Considerations
When BIER is paired with a particular multicast flow overlay, it When BIER is paired with a particular multicast flow overlay, it
inherits the security considerations of that layer. Similarly, when inherits the security considerations of that layer. Similarly, when
BIER is paired with a particular routing underlay, it inherits the BIER is paired with a particular routing underlay, it inherits the
security considerations of that layer. security considerations of that layer.
If the BIER encapsulation of a particular packet specifies an SI or a If the BIER encapsulation of a particular packet specifies an SI or a
BitString other than the one intended by the BFIR, the packet is BitString other than the one intended by the BFIR, the packet is
likely to be misdelivered. If the BIER encapsulation of a packet is likely to be misdelivered. If the BIER encapsulation of a packet is
modified (through error or malfeasance) in a way other than that modified (through error or malfeasance) in a way other than that
specified in this document, the packet may be misdelivered. specified in this document, the packet may be misdelivered. Some
modifications of the BIER encapsulation, e.g., setting every bit in
the BitString, may result in (intentional or unintentional) Denial of
Service (DoS) attacks.
If a BFIR is compromised, it may impose a BIER encapsulation with all
the bits in the BitString set, which would also result in a DoS
attack.
Every BFR MUST be provisioned to know which of its interfaces lead to
a BIER domain and which do not. BIER-encapsulated packets MUST NOT
be accepted from outside the BIER domain. (Reception of
BIER-encapsulated packets from outside the BIER domain would create
an attack vector for DoS attacks, as an attacker might set all the
bits in the BitString.)
If two interfaces lead to different BIER domains, the BFR MUST be
provisioned to know that those two interfaces lead to different BIER
domains. If the provisioning is not correct, BIER-encapsulated
packets from one BIER domain may "leak" into another; this is likely
to result in misdelivery of packets.
DoS attacks may also result from incorrect provisioning (through
error or malfeasance) of the BFRs.
If the procedures used for advertising BFR-ids and BFR-prefixes are If the procedures used for advertising BFR-ids and BFR-prefixes are
not secure, an attack on those procedures may result in incorrect not secure, an attack on those procedures may result in incorrect
delivery of BIER-encapsulated packets. delivery of BIER-encapsulated packets.
Every BFR must be provisioned to know which of its interfaces lead to 10. Acknowledgements
a BIER domain and which do not. If two interfaces lead to different
BIER domains, the BFR must be provisioned to know that those two
interfaces lead to different BIER domains. If the provisioning is
not correct, BIER-encapsulated packets from one BIER domain may
"leak" into another; this is likely to result in misdelivery of
packets.
9. Acknowledgements
The authors wish to thank Rajiv Asati, Alia Atlas, John Bettink, Ross The authors wish to thank Rajiv Asati, Alia Atlas, John Bettink, Ross
Callon (who contributed much of the text on deterministic ECMP), Callon (who contributed much of the text on deterministic ECMP),
Nagendra Kumar, Christian Martin, Neale Ranns, Greg Shepherd, Albert Nagendra Kumar, Christian Martin, Neale Ranns, Greg Shepherd, Albert
Tian, Ramji Vaithianathan, Xiaohu Xu and Jeffrey Zhang for their Tian, Ramji Vaithianathan, Xiaohu Xu and Jeffrey Zhang for their
ideas and contributions to this work. ideas and contributions to this work.
10. Contributor Addresses The authors also wish to thank Sue Hares, Victor Kuarsingh, and Dan
Romascanu for their reviews of this document.
11. Contributor Addresses
Below is a list of other contributing authors in alphabetical order: Below is a list of other contributing authors in alphabetical order:
Gregory Cauchie Gregory Cauchie
Bouygues Telecom Bouygues Telecom
Email: gcauchie@bouyguestelecom.fr Email: gcauchie@bouyguestelecom.fr
Mach (Guoyi) Chen Mach (Guoyi) Chen
Huawei Huawei
skipping to change at page 36, line 28 skipping to change at page 37, line 36
Email: Uwe.Joorde@telekom.de Email: Uwe.Joorde@telekom.de
Luay Jalil Luay Jalil
Verizon Verizon
1201 E Arapaho Rd. 1201 E Arapaho Rd.
Richardson, TX 75081 Richardson, TX 75081
United States United States
Email: luay.jalil@verizon.com Email: luay.jalil@verizon.com
Greg Shepherd
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States
Email: shep@cisco.com
Jeff Tantsura Jeff Tantsura
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks", in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, DOI 10.17487/RFC3443, January 2003, RFC 3443, DOI 10.17487/RFC3443, January 2003,
<http://www.rfc-editor.org/info/rfc3443>. <https://www.rfc-editor.org/info/rfc3443>.
11.2. Informative References 12.2. Informative References
[BGP_BIER_EXTENSIONS]
Xu, X., Chen, M., Patel, K., Wijnands, IJ., and T.
Przygienda, "BGP Extensions BIER", internet-draft draft-
ietf-bier-idr-extensions-02.txt, January 2017.
[BIER-MVPN] [BIER-MVPN]
Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T.
Przygienda, "Multicast VPN Using BIER", internet-draft Przygienda, "Multicast VPN Using BIER", internet-draft
draft-ietf-bier-mvpn-05.txt, January 2017. draft-ietf-bier-mvpn-07.txt, July 2017.
[Boivie_Feldman] [Boivie_Feldman]
Boivie, R. and N. Feldman, "Small Group Multicast", Boivie, R. and N. Feldman, "Small Group Multicast",
(expired) draft-boivie-sgm-02.txt, February 2001. (expired) draft-boivie-sgm-02.txt, February 2001.
[ISIS_BIER_EXTENSIONS] [ISIS_BIER_EXTENSIONS]
Ginsberg, L., Przygienda, T., Aldrin, S., and J. Zhang, Ginsberg, L., Przygienda, T., Aldrin, S., and J. Zhang,
"BIER Support via ISIS", internet-draft draft-ietf-bier- "BIER Support via ISIS", internet-draft draft-ietf-bier-
isis-extensions-04.txt, March 2017. isis-extensions-04.txt, March 2017.
skipping to change at page 37, line 25 skipping to change at page 38, line 51
Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J.,
Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Aldrin, S., and I. Meilik, "Encapsulation for Bit Index
Explicit Replication in MPLS and non-MPLS Networks Explicit Replication in MPLS and non-MPLS Networks
Networks", internet-draft draft-ietf-bier-mpls- Networks", internet-draft draft-ietf-bier-mpls-
encapsulation-07.txt, June 2017. encapsulation-07.txt, June 2017.
[OSPF_BIER_EXTENSIONS] [OSPF_BIER_EXTENSIONS]
Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A.,
Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions
for Bit Index Explicit Replication", internet-draft draft- for Bit Index Explicit Replication", internet-draft draft-
ietf-bier-ospf-bier-extensions-05.txt, March 2017. ietf-bier-ospf-bier-extensions-06.txt, June 2017.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
Authors' Addresses Authors' Addresses
IJsbrand Wijnands (editor) IJsbrand Wijnands (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
 End of changes. 51 change blocks. 
135 lines changed or deleted 230 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/