draft-ietf-bier-architecture-06.txt   draft-ietf-bier-architecture-07.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: Standards Track E. Rosen, Ed. Intended status: Experimental E. Rosen, Ed.
Expires: October 26, 2017 Juniper Networks, Inc. Expires: December 23, 2017 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.
April 24, 2017 June 21, 2017
Multicast using Bit Index Explicit Replication Multicast using Bit Index Explicit Replication
draft-ietf-bier-architecture-06 draft-ietf-bier-architecture-07
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
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 http://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 October 26, 2017. This Internet-Draft will expire on December 23, 2017.
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 (http://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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. The Routing Underlay . . . . . . . . . . . . . . . . . . 9 4.1. The Routing Underlay . . . . . . . . . . . . . . . . . . 10
4.2. The BIER Layer . . . . . . . . . . . . . . . . . . . . . 10 4.2. The BIER Layer . . . . . . . . . . . . . . . . . . . . . 11
4.3. The Multicast Flow Overlay . . . . . . . . . . . . . . . 11 4.3. The Multicast Flow Overlay . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . 13
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. BFR Neighbors . . . . . . . . . . . . . . . . . . . . . . 15 6.2. BFR Neighbors . . . . . . . . . . . . . . . . . . . . . . 15
6.3. The Bit Index Routing Table . . . . . . . . . . . . . . . 15 6.3. The Bit Index Routing Table . . . . . . . . . . . . . . . 16
6.4. The Bit Index Forwarding Table . . . . . . . . . . . . . 16 6.4. The Bit Index Forwarding Table . . . . . . . . . . . . . 17
6.5. The BIER Forwarding Procedure . . . . . . . . . . . . . . 17 6.5. The BIER Forwarding Procedure . . . . . . . . . . . . . . 18
6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 19 6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 20
6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20 6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 21
6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21 6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22
6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 23 6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 24
6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 23 6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 24
6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 24 6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 25
6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 26 6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 27
6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 27 6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 28
6.10. Use of Different BitStringLengths within a Domain . . . . 29 6.10. Use of Different BitStringLengths within a Domain . . . . 31
6.10.1. BitStringLength Compatibility Check . . . . . . . . 30 6.10.1. BitStringLength Compatibility Check . . . . . . . . 32
6.10.2. Handling BitStringLength Mismatches . . . . . . . . 32 6.10.2. Handling BitStringLength Mismatches . . . . . . . . 33
6.10.3. Transitioning from One BitStringLength to Another . 32 6.10.3. Transitioning from One BitStringLength to Another . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 33 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 35 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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. It provides optimal forwarding of multicast
data packets through a "multicast domain". However, it does not data packets through a "multicast domain". However, it does not
require the use of a protocol for explicitly building multicast require the use of a protocol for explicitly building multicast
distribution trees, and it does not require intermediate nodes to distribution trees, and it does not require intermediate nodes to
maintain any per-flow state. This architecture is known as "Bit maintain any per-flow state. This architecture is known as "Bit
Index Explicit Replication" (BIER). Index Explicit Replication" (BIER).
skipping to change at page 3, line 33 skipping to change at page 3, line 33
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
multicast data packet from another BFR in the same BIER domain, and multicast data packet from another BFR in the same BIER domain, and
forwards the packet to another BFR in the same BIER domain, will be forwards the packet to another BFR in the same BIER domain, will be
known as a "transit BFR" for that packet. A single BFR may be a BFIR known as a "transit BFR" for that packet. A single BFR may be a BFIR
for some multicast traffic while also being a BFER for some multicast for some multicast traffic while also being a BFER for some multicast
traffic and a transit BFR for some multicast traffic. In fact, a BFR traffic and a transit BFR for some multicast traffic. In fact, for a
may be the BFIR for a given packet and may also be (one of) the given packet, a BFR may be a BFIR and/or a transit BFR and/or (one
BFER(s), for that packet; it may also forward that packet to one or of) the BFER(s) for that packet.
more additional BFRs.
A BIER domain may contain one or more sub-domains. Each BIER domain A BIER domain may contain one or more sub-domains. Each BIER domain
MUST contain at least one sub-domain, the "default sub-domain" (also MUST contain at least one sub-domain, the "default sub-domain" (also
denoted "sub-domain zero"). If a BIER domain contains more than one denoted "sub-domain zero"). If a BIER domain contains more than one
sub-domain, each BFR in the domain MUST be provisioned to know the sub-domain, each BFR in the domain MUST be provisioned to know the
set of sub-domains to which it belongs. Each sub-domain is set of sub-domains to which it belongs. Each sub-domain is
identified by a sub-domain-id in the range [0,255]. identified by a sub-domain-id in the range [0,255].
For each sub-domain to which a given BFR belongs, if the BFR is For each sub-domain to which a given BFR belongs, if the BFR is
capable of acting as a BFIR or a BFER, it MUST be provisioned with a capable of acting as a BFIR or a BFER, it MUST be provisioned with a
skipping to change at page 5, line 15 skipping to change at page 5, line 15
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.
Note that it is generally advantageous to assign the BFR-ids of a It is generally advantageous to assign the BFR-ids of a given sub-
given sub-domain so that as many BFERs as possible can be represented domain so that as many BFERs as possible can be represented in a
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
skipping to change at page 6, line 18 skipping to change at page 6, line 18
limited to the number of neighboring BFRs; this can be much smaller limited to the number of neighboring BFRs; this can be much smaller
than the number of BFERs. See Section 6 (especially Section 6.4) for than the number of BFERs. See Section 6 (especially Section 6.4) for
details. details.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. The BFR Identifier and BFR-Prefix 2. The BFR Identifier and BFR-Prefix
Each BFR MUST be assigned a "BFR-Prefix". A BFR's BFR-Prefix MUST be Each BFR MUST be assigned a single "BFR-Prefix" for each sub-domain
an IP address (either IPv4 or IPv6) of the BFR, and MUST be unique to which it belongs. A BFR's BFR-Prefix MUST be an IP address
and routable within the BIER domain. It is RECOMMENDED that the (either IPv4 or IPv6) of the BFR. It is RECOMMENDED that the
BFR-prefix be a loopback address of the BFR. Two BFRs in the same BFR-prefix be a loopback address of the BFR.
BIER domain MUST NOT be assigned the same BFR-Prefix. Note that a
BFR in a given BIER domain has the same BFR-prefix in all the sub-
domains of that BIER domain.
A "BFR Identifier" (BFR-id) is a number in the range [1,65535]. In If a BFR belongs to more than one sub-domain, it may (though it need
general, each BFR in a given BIER sub-domain must be assigned a not) have a different BFR-prefix in each sub-domain.
unique number from this range (i.e., two BFRs in the same BIER sub-
domain MUST NOT have the same BFR-id in that sub-domain). However,
if it is known that a given BFR will never need to function as a BFER
or BFIR in a given sub-domain, then it is not necessary to assign a
BFR-id for that sub-domain to that BFR.
Note that the value 0 is not a legal BFR-id. All BFR-Prefixes used within a given sub-domain MUST belong to the
same address family (either IPv4 or IPv6).
The BFR-prefix of a given BFR in a given sub-domain MUST be routable
in that sub-domain. Whether a particular BFR-Prefix is routable in a
given sub-domain depends on the "routing underlay" associated with
that sub-domain. The notion of "routing underlay" is described in
Section 4.1.
A "BFR Identifier" (BFR-id) is a number in the range [1,65535].
Within a given sub-domain, every BFR that may need to function as a
BFIR or BFER MUST have a single BFR-id, which identifies it uniquely
within that sub-domain. A BFR that does not need to function as a
BFIR or BFER in a given sub-domain does not need to have a BFR-id in
that sub-domain.
The value 0 is not a legal BFR-id.
The procedure for assigning a particular BFR-id to a particular BFR The procedure for assigning a particular BFR-id to a particular BFR
is outside the scope of this document. However, it is RECOMMENDED is outside the scope of this document. However, it is RECOMMENDED
that the BFR-ids for each sub-domain be assigned "densely" from the that the BFR-ids for each sub-domain be assigned "densely" from the
numbering space, as this will result in a more efficient encoding numbering space, as this will result in a more efficient encoding
(see Section 3). That is, if there are 256 or fewer BFERs, it is (see Section 3). That is, if there are 256 or fewer BFERs, it is
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
skipping to change at page 8, line 6 skipping to change at page 8, line 14
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 Every BFIR MUST be capable of being provisioned with an Imposition
BitStringLength of 256. Every BFR and BFER MUST be capable of being BitStringLength of 256. Every BFR and BFER MUST be capable of being
provisioned with a Disposition BitStringLength of 256. provisioned with a Disposition BitStringLength of 256.
Particular BIER encapsulation types MAY allow other BitStringLengths Particular BIER encapsulation types MAY allow other BitStringLengths
to be OPTIONALLY supported. For example, when using the to be OPTIONALLY supported. For example, when using either of the
encapsulation specified in [MPLS_BIER_ENCAPS], a BFR may be capable encapsulations specified in [MPLS_BIER_ENCAPS], a BFR may be capable
of being provisioned to use any or all of the following of being provisioned to use any or all of the following
BitStringLengths as Imposition BitStringLengths and as Disposition BitStringLengths as Imposition BitStringLengths and as Disposition
BitStringLengths: 64, 128, 256, 512, 1024, 2048, and 4096. 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.
skipping to change at page 9, line 36 skipping to change at page 9, line 45
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
expect actual deployments to have such a small BitStringLength. expect actual deployments to have such a small BitStringLength.
It is possible that several different forms of BIER encapsulation It is possible that several different forms of BIER encapsulation
will be developed. If so, the particular encapsulation that is used will be developed. If so, the particular encapsulation that is used
in a given deployment will depend on the type of network in a given deployment will depend on the type of network
infrastructure that is used to realize the BIER domain. Details of infrastructure that is used to realize the BIER domain. Details of
the BIER encapsulation(s) will be given in companion documents. An the BIER encapsulation(s) will be given in companion documents. An
encapsulation for use in MPLS networks is described in encapsulation for use in MPLS networks is described in
[MPLS_BIER_ENCAPS] [MPLS_BIER_ENCAPS]; that document also describes a very similar
encapsulation that can be used in non-MPLS networks.
4. Layering 4. Layering
It is helpful to think of the BIER architecture as consisting of It is helpful to think of the BIER architecture as consisting of
three layers: the "routing underlay", the "BIER layer", and the three layers: the "routing underlay", the "BIER layer", and the
"multicast flow overlay". "multicast flow overlay".
4.1. The Routing Underlay 4.1. The Routing Underlay
The "routing underlay" establishes "adjacencies" between pairs of The "routing underlay" establishes "adjacencies" between pairs of
skipping to change at page 10, line 42 skipping to change at page 11, line 7
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 sub-
domain. By default (i.e., in the absence of any provisioning to the domain. By default (i.e., in the absence of any provisioning to the
contrary), each sub-domain uses the default topology of the unicast contrary), each sub-domain uses the default topology of the unicast
IGP as the routing underlay. IGP as the routing underlay.
Note that specification of the protocol and procedures of the routing Specification of the protocol and procedures of the routing underlay
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:
o Protocols and procedures that a given BFR uses to advertise, to o Protocols and procedures that a given BFR uses to advertise, to
all other BFRs in the same BIER domain: all other BFRs in the same BIER domain:
skipping to change at page 11, line 22 skipping to change at page 11, line 36
* optionally, information about the routing underlay associated * optionally, information about the routing underlay associated
with each sub-domain. with each sub-domain.
o The procedures used by a BFIR to impose a BIER header on a o The procedures used by a BFIR to impose a BIER header on a
multicast data packet. multicast data packet.
o The procedures for forwarding BIER-encapsulated packets, and for o The procedures for forwarding BIER-encapsulated packets, and for
modifying the BIER header during transit. modifying the BIER header during transit.
o The procedures used by a BFER to decapsulate a BIER packet and
properly dispatch it.
4.3. The Multicast Flow Overlay 4.3. The Multicast Flow Overlay
The "multicast flow overlay" consists of the set of protocols and The "multicast flow overlay" consists of the set of protocols and
procedures that enable the following set of functions. procedures that enable the following set of functions.
o When a BFIR receives a multicast data packet from outside the BIER o When a BFIR receives a multicast data packet from outside the BIER
domain, the BFIR must determine the set of BFERs for that packet. domain, the BFIR must determine the set of BFERs for that packet.
This information is provided by the multicast flow overlay. This information is provided by the multicast flow overlay.
o When a BFER receives a BIER-encapsulated packet from inside the o When a BFER receives a BIER-encapsulated packet from inside the
skipping to change at page 11, line 49 skipping to change at page 12, line 18
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 though
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 will be specified in a companion document. 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
overlay is outside the scope of this document. overlay is outside the scope of this document.
5. Advertising BFR-ids and BFR-Prefixes 5. Advertising BFR-ids and BFR-Prefixes
skipping to change at page 14, line 32 skipping to change at page 14, line 49
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 and
BitString identify that BFR itself, then the BFR is also a BFER for BitString identify that BFR itself, then the BFR is also a BFER for
that packet. As a BFER, it must pass the payload to the multicast that packet. As a BFER, it must pass the payload to the multicast
flow overlay. If the BitString has bits set for other BFRs, the flow overlay. If the BitString has bits set for other BFRs, the
packet also needs to be forwarded further within the BIER domain. If packet also needs to be forwarded further within the BIER domain. If
the BF(E)R also forwards one or more copies of the packet within the the BF(E)R also forwards one or more copies of the packet within the
BIER domain, the bit representing the BFR's own BFR-id MUST be clear BIER domain, the bit representing the BFR's own BFR-id MUST be clear
in all the copies. in all the copies.
When BIER on a BFER passes a packet to the multicast flow overlay, it When BIER on a BFER is to pass a packet to the multicast flow
may need to provide contextual information obtained from the BIER overlay, it of course decapsulates the packet by removing the BIER
header. However, it may be necessary to provide the multicast flow
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.
If the BIER encapsulation contains a "Time to Live" (TTL) value, this
value is not, by default, inherited by the payload. If a particular
multicast flow overlay needs to know the TTL value, this needs to be
specified in whatever specification defines the interaction between
BIER and that multicast flow overlay.
If the BIER encapsulation contains a Traffic Class field, a Type of
Service field, a Differentiated Services field, or any field of that
sort, the value of that field is not, by default, passed to the
multicast flow overlay. If a particular multicast flow overlay needs
to know the values of such fields, this fact needs to be specified in
whatever specification defines the interaction between BIER and that
multicast flow overlay.
When BIER on a BFER passes a packet to the multicast flow overlay, When BIER on a BFER passes a packet to the multicast flow overlay,
the overlay will determine how to further dispatch the packet. If the overlay will determine how to further dispatch the packet. If
the packet needs to be forwarded into another BIER domain, then the the packet needs to be forwarded into another BIER domain, then the
BFR will act as a BFER in one BIER domain and as a BFIR in another. BFR will act as a BFER in one BIER domain and as a BFIR in another.
A BIER-encapsulated packet cannot pass directly from one BIER domain A BIER-encapsulated packet cannot pass directly from one BIER domain
to another; at the boundary between BIER domains, the packet must be to another; at the boundary between BIER domains, the packet must be
decapsulated and passed to the multicast flow overlay. decapsulated and passed to the multicast flow overlay.
Note that when a BFR transmits multiple copies of a packet within a Note that when a BFR transmits multiple copies of a packet within a
BIER domain, only one copy will be destined to any given BFER. BIER domain, only one copy will be destined to any given BFER.
skipping to change at page 18, line 12 skipping to change at page 19, line 12
copy to the BFR-NBR. (If the BFR-NBR is null, the copy is just copy to the BFR-NBR. (If the BFR-NBR is null, the copy is just
discarded.) Note that when a packet is forwarded to a particular discarded.) Note that when a packet is forwarded to a particular
BFR-NBR, its BitString identifies only those BFERs that are to be BFR-NBR, its BitString identifies only those BFERs that are to be
reached via that BFR-NBR. reached via that BFR-NBR.
8. Now update the original packet's BitString by AND'ing it with the 8. Now update the original packet's BitString by AND'ing it with the
INVERSE of the F-BM (i.e., Packet->Bitstring &= ~F-BM). (This INVERSE of the F-BM (i.e., Packet->Bitstring &= ~F-BM). (This
clears the bits that identify the BFERs to which a copy of the clears the bits that identify the BFERs to which a copy of the
packet has just been forwarded.) Go to step 2. packet has just been forwarded.) Go to step 2.
Note that this procedure causes the packet to be forwarded to a This procedure causes the packet to be forwarded to a particular
particular BFR-NBR only once. The number of lookups in the BIFT is BFR-NBR only once. The number of lookups in the BIFT is the same as
the same as the number of BFR-NBRs to which the packet must be the number of BFR-NBRs to which the packet must be forwarded; it is
forwarded; it is not necessary to do a separate lookup for each not necessary to do a separate lookup for each destination BFER.
destination BFER.
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
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]
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.
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 21, line 8 skipping to change at page 22, line 8
o As the packet's BitString is now zero, the forwarding procedure is o As the packet's BitString is now zero, the forwarding procedure is
complete. complete.
When BFR-B receives the multicast packet from BFR-A, it follows the When BFR-B receives the multicast packet from BFR-A, it follows the
same procedure. The result is that a copy of the packet, with a same procedure. The result is that a copy of the packet, with a
BitString of 0001, is sent to BFR-C. BFR-C applies the same BitString of 0001, is sent to BFR-C. BFR-C applies the same
procedures, and as a result sends a copy of the packet, with a procedures, and as a result sends a copy of the packet, with a
BitString of 0001, to BFR-D. BitString of 0001, to BFR-D.
At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an
F-BM of 0000 and a BFR-NBR of BFR-D itself. This will cause a copy F-BM of 0001 and a BFR-NBR of BFR-D itself. This will cause a copy
of the packet to be delivered to the multicast flow overlay at BFR-D. of the packet to be delivered to the multicast flow overlay at BFR-D.
The packet's BitString will be set to 0000, and the packet will not The packet's BitString will be set to 0000, and the packet will not
be forwarded any further. be forwarded any further.
6.6.2. Example 2 6.6.2. Example 2
This example is similar to Example 1, except that BFIR-A has learned This example is similar to Example 1, except that BFIR-A has learned
from the multicast flow overlay that both BFER-D and BFER-E are from the multicast flow overlay that both BFER-D and BFER-E are
interested in a given multicast flow. If BFIR-A receives a packet of interested in a given multicast flow. If BFIR-A receives a packet of
that flow from outside the BIER domain, BFIR-A applies the BIER that flow from outside the BIER domain, BFIR-A applies the BIER
skipping to change at page 22, line 38 skipping to change at page 23, line 38
o As the packet's BitString is now zero, the forwarding procedure is o As the packet's BitString is now zero, the forwarding procedure is
complete. complete.
Thus BFR-B forwards two copies of the packet. One copy of the Thus BFR-B forwards two copies of the packet. One copy of the
packet, with BitString 0001, has now been sent from BFR-B to BFR-C. packet, with BitString 0001, has now been sent from BFR-B to BFR-C.
Following the same procedures, BFR-C will forward the packet to Following the same procedures, BFR-C will forward the packet to
BFER-D. BFER-D.
At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an
F-BM of 0000 and a BFR-NBR of BFR-D itself. This will cause a copy F-BM of 0001 and a BFR-NBR of BFR-D itself. This will cause a copy
of the packet to be delivered to the multicast flow overlay at BFR-D. of the packet to be delivered to the multicast flow overlay at BFR-D.
The packet's BitString will be set to 0000, and the packet will not The packet's BitString will be set to 0000, and the packet will not
be forwarded any further. be forwarded any further.
The other copy of the packet has been sent from BFR-B to BFER-E, with The other copy of the packet has been sent from BFR-B to BFER-E, with
BitString 0100. BitString 0100.
At BFER-E, the BIFT entry (not pictured) for BFR-id 3 will specify an At BFER-E, the BIFT entry (not pictured) for BFR-id 3 will specify an
F-BM of 0000 and a BFR-NBR of BFR-E itself. This will cause a copy F-BM of 0100 and a BFR-NBR of BFR-E itself. This will cause a copy
of the packet to be delivered to the multicast flow overlay at BFR-E. of the packet to be delivered to the multicast flow overlay at BFR-E.
The packet's BitString will be set to 0000, and the packet will not The packet's BitString will be set to 0000, and the packet will not
be forwarded any further. be forwarded any further.
6.7. Equal Cost Multi-path Forwarding 6.7. Equal Cost Multi-path Forwarding
In many networks, the routing underlay will provide multiple equal In many networks, the routing underlay will provide multiple equal
cost paths from a given BFR to a given BFER. When forwarding cost paths from a given BFR to a given BFER. When forwarding
multicast packets through the network, it can be beneficial to take multicast packets through the network, it can be beneficial to take
advantage of this by load balancing among those paths. This feature advantage of this by load balancing among those paths. This feature
skipping to change at page 27, line 42 skipping to change at page 28, line 42
3. BFR B then continues to look at each of its child nodes, 3. BFR B then continues to look at each of its child nodes,
including any nodes that have been re-parented to B as a result including any nodes that have been re-parented to B as a result
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 and outgoing BIER-MPLS are considered to be the BFR-NBRs. The F-BMs must be computed
labels 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. This may be as simple as send the packet through a unicast tunnel. In an MPLS network, this
finding the IGP unicast next hop to the child node, and pushing on may be as simple as finding the IGP unicast next hop to the child
(above the BIER-MPLS label advertised by the child) the MPLS label node, and pushing on (above the BIER encapsulation header) an MPLS
that the IGP next hop has bound to an address of the child node. (If label that the IGP next hop has bound to an address of the child
for some reason the unicast tunnel cannot be an MPLS tunnel, any node. (This assumes that the packet is using an MPLS-based BIER
other kind of tunnel can be used, as long as it is possible to encapsulation, such as the one specified in Section 2.1 of
encapsulate MPLS within that kind of tunnel.) [MPLS_BIER_ENCAPS].) Of course, the BIFT-id in the BIER
encapsulation header must be the BIFT-id advertised by the child node
for the packet's Set Index, Sub-Domain, and BitStringLength.
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
that tunnel type has a way of indicating that the payload is a BIER-
encapsulated packet.
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
MPLS tunnel unless it is known that the tunnel only carries BIER
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,
because in that case the BIER encapsulation begins with an MPLS label
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,
just as a functional description. just as a functional description.
While the above description assumes that the routing underlay While the above description assumes that the routing underlay
provides an SPF tree, it may also be applicable to other types of provides an SPF tree, it may also be applicable to other types of
routing underlay. routing underlay.
Note that the technique above can also be used to provide "node The technique above can also be used to provide "node protection"
protection" (i.e., to provide fast reroute around nodes that are (i.e., to provide fast reroute around nodes that are believed to have
believed to have failed). If BFR B has a failed BFR-NBR, B can failed). If BFR B has a failed BFR-NBR, B can remove the failed
remove the failed BFR-NBR from the BIER-SPF tree, and can then re- BFR-NBR from the BIER-SPF tree, and can then re-parent the child
parent the child BFR-NBRs of the failed BFR-NBR so that they appear BFR-NBRs of the failed BFR-NBR so that they appear to be B's own
to be B's own child nodes on the tree (i.e., so that they appear to child nodes on the tree (i.e., so that they appear to be B's
be B's BFR-NBRs). Then the usual BIER forwarding procedures apply. BFR-NBRs). Then the usual BIER forwarding procedures apply.
However, getting the packet from B to the child nodes of the failed However, getting the packet from B to the child nodes of the failed
BFR-NBR is a bit more complicated, as it may require using a unicast BFR-NBR is a bit more complicated, as it may require using a unicast
bypass tunnel to get around the failed node. bypass tunnel to get around the failed node.
A simpler variant of step 2 above would be the following: A simpler variant of step 2 above would be the following:
If one of the child nodes does not support BIER, BFR B removes If one of the child nodes does not support BIER, BFR B removes
that node from the tree. All BFERs that are reached through that that node from the tree. All BFERs that are reached through that
child node are then re-parented on the tree, so that BFR B now child node are then re-parented on the tree, so that BFR B now
becomes their parent. becomes their parent.
This variant is simpler because the set of BFERs that are reached This variant is simpler because the set of BFERs that are reached
through a particular child node of B can be determined from the F-BM through a particular child node of B can be determined from the F-BM
in the BIFT. However, if this variant is used, the results are less in the BIFT. However, if this variant is used, the results are less
optimal, because packets will be unicast directly from B to the BFERs optimal, because packets will be unicast directly from B to the BFERs
that are reachable through the non-BIER child node. that are reachable through the non-BIER child node.
When using a unicast MPLS tunnel to get a packet to a BFR-NBR: When using a unicast MPLS tunnel to get a packet to a BFR-NBR:
o the TTL of the MPLS label entry representing the "tunnel" SHOULD o the TTL of the MPLS label entry representing the tunnel SHOULD be
be set to a large value, rather than being copied from the TTL set to a large value, rather than being copied from the TTL value
value from the BIER-MPLS label, and from the BIER encapsulation header, and
o when the tunnel labels are popped off, the TTL from the tunnel o when the tunnel labels are popped off, the TTL from the tunnel
labels SHOULD NOT be copied to the BIER-MPLS label. labels SHOULD NOT be copied to the BIER encapsulation header.
In other words, the TTL processing for the tunnel SHOULD be as In other words, the TTL processing for the tunnel SHOULD be as
specified in [RFC3443] for "Pipe Model" and "Short Pipe Model" LSPs. specified in [RFC3443] for "Pipe Model" and "Short Pipe Model" LSPs.
That way, the TTL of the BIER-MPLS label constrains only the number The same principle applies if the tunnels are not MPLS tunnels; the
of BFRs that the packet may traverse, not the total number of hops. BIER packet SHOULD NOT inherit the TTL from the tunnel encapsulation.
That way, the TTL of the BIER encapsulation header constrains only
the number of BFRs that the packet may traverse, not the total number
of hops.
If two BIER packets have the same value in the entropy field of their
respective BIER headers, and if both are transmitted through a given
tunnel, it is desirable for the tunnel encapsulation to preserve the
fact that the two packets have the same entropy.
The material in this section presupposes that a given node is either The material in this section presupposes that a given node is either
a BFR or not, and that a BFR supports BIER on all its interfaces. It a BFR or not, and that a BFR supports BIER on all its interfaces. It
is however possible that a router will have some line cards that is however possible that a router will have some line cards that
support BIER and some that do not. In such a case, one can think of support BIER and some that do not. In such a case, one can think of
the router as a "partial-BFR", that supports BIER only on some of its the router as a "partial-BFR", that supports BIER only on some of its
interfaces. If it is desired to deploy such partial-BFRs, one can interfaces. If it is desired to deploy such partial-BFRs, one can
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
skipping to change at page 30, line 36 skipping to change at page 32, line 22
BitStringLength is by provisioning. However, the BFIR should also BitStringLength is by provisioning. However, the BFIR should also
perform the BitStringLength Compatibility Check defined below. perform the BitStringLength Compatibility Check defined below.
The combination of Sub-Domain S and Imposition BitStringLength L The combination of Sub-Domain S and Imposition BitStringLength L
passes the BitStringLength Compatibility Check if and only if the passes the BitStringLength Compatibility Check if and only if the
following condition holds: following condition holds:
Every BFR that has advertised its membership in sub-domain S has Every BFR that has advertised its membership in sub-domain S has
also advertised that it is using Disposition BitStringLength L also advertised that it is using Disposition BitStringLength L
(and possibly other BitStringLengths as well) in that Sub-Domain. (and possibly other BitStringLengths as well) in that Sub-Domain.
(If the MPLS encapsulation [MPLS_BIER_ENCAPS] is being used, this (If the MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
means that every BFR that is advertising a label for Sub-Domain S being used, this means that every BFR that is advertising a label
is advertising a label for the combination of Sub-Domain S and for Sub-Domain S is advertising a label for the combination of
Disposition BitStringLength L.) Sub-Domain S and Disposition BitStringLength L.)
If a BFIR has been provisioned to use a particular Imposition If a BFIR has been provisioned to use a particular Imposition
BitStringLength and a particular sub-domain for some set of packets, BitStringLength and a particular sub-domain for some set of packets,
and if that combination of Imposition BitStringLength and sub-domain and if that combination of Imposition BitStringLength and sub-domain
does not pass the BitStringLength Compatibility Check, the BFIR does not pass the BitStringLength Compatibility Check, the BFIR
SHOULD log this fact as an error. It then has the following choice SHOULD log this fact as an error. It then has the following choice
about what to do with the packets: about what to do with the packets:
1. The BFIR MAY use the provisioned Imposition BitStringLength 1. The BFIR MAY use the provisioned Imposition BitStringLength
anyway. If the procedure Paragraph 2 or Paragraph 3 of anyway. If the procedure Paragraph 2 or Paragraph 3 of
skipping to change at page 31, line 45 skipping to change at page 33, line 31
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.
This fallback procedure will work best if the value of F is It is RECOMMENDED that the value of F be 256.
established by the architecture, rather than by provisioning.
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 33, line 36 skipping to change at page 35, line 15
Every BFR must be provisioned to know which of its interfaces lead to Every BFR must be provisioned to know which of its interfaces lead to
a BIER domain and which do not. If two interfaces lead to different 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 BIER domains, the BFR must be provisioned to know that those two
interfaces lead to different BIER domains. If the provisioning is interfaces lead to different BIER domains. If the provisioning is
not correct, BIER-encapsulated packets from one BIER domain may not correct, BIER-encapsulated packets from one BIER domain may
"leak" into another; this is likely to result in misdelivery of "leak" into another; this is likely to result in misdelivery of
packets. packets.
9. Acknowledgements 9. Acknowledgements
The authors wish to thank Rajiv Asati, John Bettink, Ross Callon (who The authors wish to thank Rajiv Asati, Alia Atlas, John Bettink, Ross
contributed much of the text on deterministic ECMP), Nagendra Kumar, Callon (who contributed much of the text on deterministic ECMP),
Christian Martin, Neale Ranns, Greg Shepherd, Albert Tian, Ramji Nagendra Kumar, Christian Martin, Neale Ranns, Greg Shepherd, Albert
Vaithianathan, Xiaohu Xu and Jeffrey Zhang for their ideas and Tian, Ramji Vaithianathan, Xiaohu Xu and Jeffrey Zhang for their
contributions to this work. ideas and contributions to this work.
10. Contributor Addresses 10. 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
skipping to change at page 35, line 21 skipping to change at page 36, line 48
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://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>. <http://www.rfc-editor.org/info/rfc3443>.
11.2. Informative References 11.2. Informative References
[BIER-MVPN]
Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T.
Przygienda, "Multicast VPN Using BIER", internet-draft
draft-ietf-bier-mvpn-05.txt, January 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.
[MPLS_BIER_ENCAPS] [MPLS_BIER_ENCAPS]
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 Networks", internet-draft Explicit Replication in MPLS and non-MPLS Networks
draft-ietf-bier-mpls-encapsulation-06.txt, December 2016. Networks", internet-draft draft-ietf-bier-mpls-
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-05.txt, March 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, <http://www.rfc-editor.org/info/rfc6513>.
 End of changes. 33 change blocks. 
104 lines changed or deleted 177 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/