< draft-ietf-bier-te-arch-05.txt   draft-ietf-bier-te-arch-06.txt >
Network Working Group T. Eckert, Ed. Network Working Group T. Eckert, Ed.
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Standards Track G. Cauchie Intended status: Standards Track G. Cauchie
Expires: May 4, 2020 Bouygues Telecom Expires: August 22, 2020 Bouygues Telecom
M. Menth M. Menth
University of Tuebingen University of Tuebingen
November 1, 2019 February 19, 2020
Traffic Engineering for Bit Index Explicit Replication (BIER-TE) Path Engineering for Bit Index Explicit Replication (BIER-TE)
draft-ietf-bier-te-arch-05 draft-ietf-bier-te-arch-06
Abstract Abstract
This memo introduces per-packet stateless strict and loose path This memo introduces per-packet stateless strict and loose path
engineered replication and forwarding for Bit Index Explicit engineered replication and forwarding for Bit Index Explicit
Replication packets ([RFC8279]). This is called BIER-TE. Replication packets (RFC8279). This is called BIER-TE.
BIER-TE leverages the BIER architecture ([RFC8279]) and extends it BIER-TE leverages RFC8279 and extends it with a new semantic for bits
with a new semantic for bits in the bitstring. BIER-TE can leverage in the bitstring. BIER-TE can leverage BIER forwarding engines with
BIER forwarding engines with little or no changes. little or no changes.
In BIER, the BitPositions (BP) of the packets bitstring indicate BIER In BIER, the BitPositions (BP) of the packets bitstring indicate BIER
Forwarding Egress Routers (BFER), and hop-by-hop forwarding uses a Forwarding Egress Routers (BFER), and hop-by-hop forwarding uses a
Routing Underlay such as an IGP. Routing Underlay such as an IGP.
In BIER-TE, BitPositions indicate adjacencies. The BIFT of each BFR In BIER-TE, BitPositions indicate adjacencies. The BIFT of each BFR
are only populated with BPs that are adjacent to the BFR in the BIER- are only populated with BPs that are adjacent to the BFR in the BIER-
TE topology. The BIER-TE topology can consist of layer 2 or remote TE topology. The BIER-TE topology can consist of layer 2 or remote
(route) adjacencies. The BFR then replicates and forwards BIER (route) adjacencies. The BFR then replicates and forwards BIER
packets to those adjacencies. This results in the aforementioned packets to those adjacencies. This results in the aforementioned
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 https://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 May 4, 2020. This Internet-Draft will expire on August 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . 4 1.1. BIER-TE and Traffic Engineering . . . . . . . . . . . . . 4
1.2. BIER-TE Topology and adjacencies . . . . . . . . . . . . 7 1.2. Basic Examples . . . . . . . . . . . . . . . . . . . . . 5
1.3. Comparison with BIER . . . . . . . . . . . . . . . . . . 8 1.3. BIER-TE Topology and adjacencies . . . . . . . . . . . . 8
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 8 1.4. Comparison with BIER . . . . . . . . . . . . . . . . . . 9
2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 9
2.1. The Multicast Flow Overlay . . . . . . . . . . . . . . . 9 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. The BIER-TE Controller Host . . . . . . . . . . . . . . . 9 2.1. The Multicast Flow Overlay . . . . . . . . . . . . . . . 10
2.2. The BIER-TE Controller . . . . . . . . . . . . . . . . . 10
2.2.1. Assignment of BitPositions to adjacencies of the 2.2.1. Assignment of BitPositions to adjacencies of the
network topology . . . . . . . . . . . . . . . . . . 10 network topology . . . . . . . . . . . . . . . . . . 11
2.2.2. Changes in the network topology . . . . . . . . . . . 10 2.2.2. Changes in the network topology . . . . . . . . . . . 11
2.2.3. Set up per-multicast flow BIER-TE state . . . . . . . 10 2.2.3. Set up per-multicast flow BIER-TE state . . . . . . . 11
2.2.4. Link/Node Failures and Recovery . . . . . . . . . . . 11 2.2.4. Link/Node Failures and Recovery . . . . . . . . . . . 12
2.3. The BIER-TE Forwarding Layer . . . . . . . . . . . . . . 11 2.3. The BIER-TE Forwarding Layer . . . . . . . . . . . . . . 12
2.4. The Routing Underlay . . . . . . . . . . . . . . . . . . 11 2.4. The Routing Underlay . . . . . . . . . . . . . . . . . . 12
3. BIER-TE Forwarding . . . . . . . . . . . . . . . . . . . . . 11 3. BIER-TE Forwarding . . . . . . . . . . . . . . . . . . . . . 12
3.1. The Bit Index Forwarding Table (BIFT) . . . . . . . . . . 11 3.1. The Bit Index Forwarding Table (BIFT) . . . . . . . . . . 12
3.2. Adjacency Types . . . . . . . . . . . . . . . . . . . . . 13 3.2. Adjacency Types . . . . . . . . . . . . . . . . . . . . . 14
3.2.1. Forward Connected . . . . . . . . . . . . . . . . . . 13 3.2.1. Forward Connected . . . . . . . . . . . . . . . . . . 14
3.2.2. Forward Routed . . . . . . . . . . . . . . . . . . . 13 3.2.2. Forward Routed . . . . . . . . . . . . . . . . . . . 14
3.2.3. ECMP . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.3. ECMP . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.4. Local Decap . . . . . . . . . . . . . . . . . . . . . 14 3.2.4. Local Decap . . . . . . . . . . . . . . . . . . . . . 15
3.3. Encapsulation considerations . . . . . . . . . . . . . . 14 3.3. Encapsulation considerations . . . . . . . . . . . . . . 15
3.4. Basic BIER-TE Forwarding Example . . . . . . . . . . . . 14 3.4. Basic BIER-TE Forwarding Example . . . . . . . . . . . . 15
3.5. Forwarding comparison with BIER . . . . . . . . . . . . . 17 3.5. Forwarding comparison with BIER . . . . . . . . . . . . . 18
3.6. Requirements . . . . . . . . . . . . . . . . . . . . . . 17 3.6. Requirements . . . . . . . . . . . . . . . . . . . . . . 18
4. BIER-TE Controller Host BitPosition Assignments . . . . . . . 18 4. BIER-TE Controller BitPosition Assignments . . . . . . . . . 19
4.1. P2P Links . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. P2P Links . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. BFER . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. BFER . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Leaf BFERs . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Leaf BFERs . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. LANs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. LANs . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5. Hub and Spoke . . . . . . . . . . . . . . . . . . . . . . 20 4.5. Hub and Spoke . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Rings . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6. Rings . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7. Equal Cost MultiPath (ECMP) . . . . . . . . . . . . . . . 21 4.7. Equal Cost MultiPath (ECMP) . . . . . . . . . . . . . . . 22
4.8. Routed adjacencies . . . . . . . . . . . . . . . . . . . 24 4.8. Routed adjacencies . . . . . . . . . . . . . . . . . . . 25
4.8.1. Reducing BitPositions . . . . . . . . . . . . . . . . 24 4.8.1. Reducing BitPositions . . . . . . . . . . . . . . . . 25
4.8.2. Supporting nodes without BIER-TE . . . . . . . . . . 24 4.8.2. Supporting nodes without BIER-TE . . . . . . . . . . 25
4.9. Reuse of BitPositions (without DNR) . . . . . . . . . . . 24 4.9. Reuse of BitPositions (without DNR) . . . . . . . . . . . 25
4.10. Summary of BP optimizations . . . . . . . . . . . . . . . 26 4.10. Summary of BP optimizations . . . . . . . . . . . . . . . 27
5. Avoiding loops and duplicates . . . . . . . . . . . . . . . . 27 5. Avoiding loops and duplicates . . . . . . . . . . . . . . . . 28
5.1. Loops . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Loops . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Duplicates . . . . . . . . . . . . . . . . . . . . . . . 27 5.2. Duplicates . . . . . . . . . . . . . . . . . . . . . . . 28
6. BIER-TE Forwarding Pseudocode . . . . . . . . . . . . . . . . 27 6. BIER-TE Forwarding Pseudocode . . . . . . . . . . . . . . . . 28
7. Managing SI, subdomains and BFR-ids . . . . . . . . . . . . . 30 7. Managing SI, subdomains and BFR-ids . . . . . . . . . . . . . 31
7.1. Why SI and sub-domains . . . . . . . . . . . . . . . . . 31 7.1. Why SI and sub-domains . . . . . . . . . . . . . . . . . 32
7.2. Bit assignment comparison BIER and BIER-TE . . . . . . . 32 7.2. Bit assignment comparison BIER and BIER-TE . . . . . . . 33
7.3. Using BFR-id with BIER-TE . . . . . . . . . . . . . . . . 32 7.3. Using BFR-id with BIER-TE . . . . . . . . . . . . . . . . 33
7.4. Assigning BFR-ids for BIER-TE . . . . . . . . . . . . . . 33 7.4. Assigning BFR-ids for BIER-TE . . . . . . . . . . . . . . 34
7.5. Example bit allocations . . . . . . . . . . . . . . . . . 34 7.5. Example bit allocations . . . . . . . . . . . . . . . . . 35
7.5.1. With BIER . . . . . . . . . . . . . . . . . . . . . . 34 7.5.1. With BIER . . . . . . . . . . . . . . . . . . . . . . 35
7.5.2. With BIER-TE . . . . . . . . . . . . . . . . . . . . 35 7.5.2. With BIER-TE . . . . . . . . . . . . . . . . . . . . 36
7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 37
8. BIER-TE and Segment Routing (SR) . . . . . . . . . . . . . . 36 8. BIER-TE and Segment Routing . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 38 12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
BIER-TE shares architecture, terminology and packet formats with BIER BIER-TE shares architecture, terminology and packet formats with BIER
as described in [RFC8279] and [RFC8296]. This document describes as described in [RFC8279] and [RFC8296]. This document describes
BIER-TE in the expectation that the reader is familiar with these two BIER-TE in the expectation that the reader is familiar with these two
documents. documents.
In BIER-TE, BitPositions (BP) indicate adjacencies. The BIFT of each In BIER-TE, BitPositions (BP) indicate adjacencies. The BIFT of each
BFR is only populated with BP that are adjacent to the BFR in the BFR is only populated with BP that are adjacent to the BFR in the
skipping to change at page 4, line 24 skipping to change at page 4, line 29
Note that related work, [I-D.ietf-roll-ccast] uses bloom filters to Note that related work, [I-D.ietf-roll-ccast] uses bloom filters to
represent leaves or edges of the intended delivery tree. Bloom represent leaves or edges of the intended delivery tree. Bloom
filters in general can support larger trees/topologies with fewer filters in general can support larger trees/topologies with fewer
addressing bits than explicit bitstrings, but they introduce the addressing bits than explicit bitstrings, but they introduce the
heuristic risk of false positives and cannot reset bits in the heuristic risk of false positives and cannot reset bits in the
bitstring during forwarding to avoid loops. For these reasons, BIER- bitstring during forwarding to avoid loops. For these reasons, BIER-
TE uses explicit bitstrings like BIER. The explicit bitstrings of TE uses explicit bitstrings like BIER. The explicit bitstrings of
BIER-TE can also be seen as a special type of bloom filter, and this BIER-TE can also be seen as a special type of bloom filter, and this
is how related work [ICC] describes it. is how related work [ICC] describes it.
1.1. Basic Examples 1.1. BIER-TE and Traffic Engineering
BIER-TE is not a standalone, complete traffic engineering signaling
solution like RSVP with RSVP-TE extensions ([RFC2205], [RFC3209]).
Instead it is a BIER derived architecture and forwarding plane that
allows to signal "source-routed" engineered path and replication
points without per-path/replication-point state on the transit nodes.
It is therefore more similar to Segment Routing (SR, ([RFC8402]))
than RSVP-TE, except that SR does not provide stateless replication
point and receiver set signaling in its packet header. See Section 8
for a more detailled discussion of BIER-TE and SR.
BIER-TE can be used alone in use cases not requiring bandwidth or
buffer resource reservations, such as high resilient services through
dual transmission with engineered path diversity or optimization of
network capacity utilization through engineered paths/trees ("load
balancing across non-ECMP paths"). BIER-TE it is intended to scale
better for the number of multicast flows in these use cases than
traditional IP multicast plus other stateful path engineering
mechanisms due to its stateless nature.
BIER-TE could be combined with transit-node stateless bandwidth
admission control (AC) mechanisms to provide path engineered
multicast traffic with bandwidth reservations. In Section 2 below,
the AC function is expected to be integrated into the BIER-TE
Controller in these use-cases.
BIER-TE could be combined with transit-node stateless buffer
management such as [I-D.qiang-detnet-large-scale-detnet] to provide
path engineered multicast traffic with guaranteed bounded latency.
Note that bounded latency solutions also require bandwidth
reservations as explained above.
BIER-TE could be combined with transit-node stateful bandwidth and
buffer management mechanisms such as per-hop/per-flow shaping used in
Guaranteed Services ([RFC2212]), but scalability may not be as good
as in a complete transit-node stateless combinations. Nevertheless,
BIER-TE still avoids the need for per-flow replication state, which
is typically scaling limited separate from shaping state. BIER-TE
also continues to provide the benefits of path engineering with per-
packet selection of subsets of destinations and no need for in-
network reconvergence of per-flow replication state.
Mechanisms how to combine bandwidth and/or buffer reservation
mechanisms with BIER-TE are outside the scope of this document.
1.2. Basic Examples
BIER-TE forwarding is best introduced with simple examples. BIER-TE forwarding is best introduced with simple examples.
BIER-TE Topology: BIER-TE Topology:
Diagram: Diagram:
p5 p6 p5 p6
--- BFR3 --- --- BFR3 ---
p3/ p13 \p7 p3/ p13 \p7
skipping to change at page 7, line 40 skipping to change at page 8, line 40
p7 -> forward_routed to BFR3 p7 -> forward_routed to BFR3
p8 -> forward_routed to BFR4 p8 -> forward_routed to BFR4
Figure 2: BIER-TE basic overlay example Figure 2: BIER-TE basic overlay example
To send a BIER-TE packet from BFR1 via BFR3 to BFR6, the bitstring is To send a BIER-TE packet from BFR1 via BFR3 to BFR6, the bitstring is
(p1,p5). From BFR1 via BFR4 to BFR6 it is (p2,p6). A packet from (p1,p5). From BFR1 via BFR4 to BFR6 it is (p2,p6). A packet from
BFR1 to BFR3,BFR4 and BFR6 can use (p1,p2,p3,p4,p5) or BFR1 to BFR3,BFR4 and BFR6 can use (p1,p2,p3,p4,p5) or
(p1,p2,p3,p4,p6), or via BFR6 (p2,p3,p4,p6,p7) or (p1.p3,p4,p5,p8). (p1,p2,p3,p4,p6), or via BFR6 (p2,p3,p4,p6,p7) or (p1.p3,p4,p5,p8).
1.2. BIER-TE Topology and adjacencies 1.3. BIER-TE Topology and adjacencies
The key new component in BIER-TE to control where replication can or The key new component in BIER-TE to control where replication can or
should happens and how to minimize the required BP for segments is - should happens and how to minimize the required BP for segments is -
as shown in these two examples - the BIER-TE topology. as shown in these two examples - the BIER-TE topology.
The BIER-TE Topology effectively consists of the BIFT of all the BFR The BIER-TE Topology effectively consists of the BIFT of all the BFR
and can also be expressed in a diagram as a graph where the edges are and can also be expressed in a diagram as a graph where the edges are
the adjacencies between the BFR. Adjacencies are naturally the adjacencies between the BFR. Adjacencies are naturally
unidirectional. BP can be reused across multiple adjacencies as long unidirectional. BP can be reused across multiple adjacencies as long
as this does not lead to undesired duplicates or loops as explained as this does not lead to undesired duplicates or loops as explained
further down in the text. further down in the text.
If the BIER-TE topology represents the underlying (layer 2) topology If the BIER-TE topology represents the underlying (layer 2) topology
of the network, this is called "native" BIER-TE as shown in the first of the network, this is called "native" BIER-TE as shown in the first
example. This can be freely mixed with "overlay" BIER-TE, in example. This can be freely mixed with "overlay" BIER-TE, in
"forward_routed" adjacencies are used. "forward_routed" adjacencies are used.
1.3. Comparison with BIER 1.4. Comparison with BIER
The key differences over BIER are: The key differences over BIER are:
o BIER-TE replaces in-network autonomous path calculation by o BIER-TE replaces in-network autonomous path calculation by
explicit paths calculated off-path by the BIER-TE controller host. explicit paths calculated off-path by the BIER-TE Controller.
o In BIER-TE every BitPosition of the BitString of a BIER-TE packet o In BIER-TE every BitPosition of the BitString of a BIER-TE packet
indicates one or more adjacencies - instead of a BFER as in BIER. indicates one or more adjacencies - instead of a BFER as in BIER.
o BIER-TE in each BFR has no routing table but only a BIER-TE o BIER-TE in each BFR has no routing table but only a BIER-TE
Forwarding Table (BIFT) indexed by SI:BitPosition and populated Forwarding Table (BIFT) indexed by SI:BitPosition and populated
with only those adjacencies to which the BFR should replicate with only those adjacencies to which the BFR should replicate
packets to. packets to.
BIER-TE headers use the same format as BIER headers. BIER-TE headers use the same format as BIER headers.
skipping to change at page 8, line 41 skipping to change at page 9, line 41
If the BIER-TE domain is also running BIER, then the BFIR-ID in BIER- If the BIER-TE domain is also running BIER, then the BFIR-ID in BIER-
TE packets can be set to the same BFIR-ID as used with BIER packets. TE packets can be set to the same BFIR-ID as used with BIER packets.
If the BIER-TE domain is not running full BIER or does not want to If the BIER-TE domain is not running full BIER or does not want to
reduce the need to allocate bits in BIER bitstrings for BFIR-ID reduce the need to allocate bits in BIER bitstrings for BFIR-ID
values, then the allocation of BFIR-ID values in BIER-TE packets can values, then the allocation of BFIR-ID values in BIER-TE packets can
be done through other mechanisms outside the scope of this document, be done through other mechanisms outside the scope of this document,
as long as this is appropriately agreed upon between all BFIR/BFER. as long as this is appropriately agreed upon between all BFIR/BFER.
1.4. Requirements Language 1.5. Requirements Language
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. Components 2. Components
End to end BIER-TE operations consists of four mayor components: The End to end BIER-TE operations consists of four mayor components: The
"Multicast Flow Overlay", the "BIER-TE control plane" consisting of "Multicast Flow Overlay", the "BIER-TE control plane" consisting of
the "BIER-TE Controller Host" and its signaling channels to the BFR, the "BIER-TE Controller" and its signaling channels to the BFR, the
the "Routing Underlay" and the "BIER-TE forwarding layer". The Bier- "Routing Underlay" and the "BIER-TE forwarding layer". The Bier-TE
TE Controller Host is the new architectural component in BIER-TE Controller is the new architectural component in BIER-TE compared to
compared to BIER. BIER.
Picture 2: Components of BIER-TE Picture 2: Components of BIER-TE
<------BGP/PIM-----> <------BGP/PIM----->
|<-IGMP/PIM-> multicast flow <-PIM/IGMP->| |<-IGMP/PIM-> multicast flow <-PIM/IGMP->|
overlay overlay
[BIER-TE Controller Host] <=> [BIER-TE Topology] [BIER-TE Controller] <=> [BIER-TE Topology]
BIER-TE control plane BIER-TE control plane
^ ^ ^ ^ ^ ^
/ | \ BIER-TE control protocol / | \ BIER-TE control protocol
| | | e.g. Netconf/Restconf/Yang | | | e.g. Netconf/Restconf/Yang
v v v v v v
Src -> Rtr1 -> BFIR-----BFR-----BFER -> Rtr2 -> Rcvr Src -> Rtr1 -> BFIR-----BFR-----BFER -> Rtr2 -> Rcvr
|<----------------->| |<----------------->|
BIER-TE forwarding layer BIER-TE forwarding layer
skipping to change at page 9, line 35 skipping to change at page 10, line 35
|<--------------------->| |<--------------------->|
Routing underlay Routing underlay
Figure 3: BIER-TE architecture Figure 3: BIER-TE architecture
2.1. The Multicast Flow Overlay 2.1. The Multicast Flow Overlay
The Multicast Flow Overlay operates as in BIER. See [RFC8279]. The Multicast Flow Overlay operates as in BIER. See [RFC8279].
Instead of interacting with the BIER forwarding layer (as in BIER), Instead of interacting with the BIER forwarding layer (as in BIER),
it interacts with the BIER-TE Controller Host. it interacts with the BIER-TE Controller.
2.2. The BIER-TE Controller Host 2.2. The BIER-TE Controller
The BIER-TE controller host is representing the control plane of The BIER-TE Controller is representing the control plane of BIER-TE.
BIER-TE. It communicates two sets of information with BFRs: It communicates two sets of information with BFRs:
During initial provisioning or modifications of the network topology, During initial provisioning or modifications of the network topology,
the controller discovers the network topology and creates the BIER-TE the BIER-TE Controller discovers the network topology and creates the
topology from it: determine which adjacencies are required/desired BIER-TE topology from it: determine which adjacencies are required/
and assign BitPositions to them. Then it signals the resulting of desired and assign BitPositions to them. Then it signals the
BitPositions and their adjacencies to each BFR to set up their BIER- resulting of BitPositions and their adjacencies to each BFR to set up
TE BIFTs. their BIER-TE BIFTs.
During day-to-day operations of the network, the controller signals During day-to-day operations of the network, the BIER-TE Controller
to BFIRs what multicast flows are mapped to what BitStrings. signals to BFIRs what multicast flows are mapped to what BitStrings.
Communications between the BIER-TE controller host to BFRs is ideally Communications between the BIER-TE Controller and BFRs is ideally via
via standardized protocols and data-models such as Netconf/Restconf/ standardized protocols and data-models such as Netconf/Restconf/Yang.
Yang. This is currently outside the scope of this document. Vendor- This is currently outside the scope of this document. Vendor-
specific CLI on the BFRs is also a possible stopgap option (as in specific CLI on the BFRs is also a possible stopgap option (as in
many other SDN solutions lacking definition of standardized data many other SDN solutions lacking definition of standardized data
model). model).
For simplicity, the procedures of the BIER-TE controller host are For simplicity, the procedures of the BIER-TE Controller are
described in this document as if it is a single, centralized described in this document as if it is a single, centralized
automated entity, such as an SDN controller. It could equally be an automated entity, such as an SDN controller. It could equally be an
operator setting up CLI on the BFRs. Distribution of the functions operator setting up CLI on the BFRs. Distribution of the functions
of the BIER-TE controller host is currently outside the scope of this of the BIER-TE Controller is currently outside the scope of this
document. document.
2.2.1. Assignment of BitPositions to adjacencies of the network 2.2.1. Assignment of BitPositions to adjacencies of the network
topology topology
The BIER-TE controller host tracks the BFR topology of the BIER-TE The BIER-TE Controller tracks the BFR topology of the BIER-TE domain.
domain. It determines what adjacencies require BitPositions so that It determines what adjacencies require BitPositions so that BIER-TE
BIER-TE explicit paths can be built through them as desired by explicit paths can be built through them as desired by operator
operator policy. policy.
The controller then pushes the BitPositions/adjacencies to the BIFT The BIER-TE Controller then pushes the BitPositions/adjacencies to
of the BFRs, populating only those SI:BitPositions to the BIFT of the BIFT of the BFRs, populating only those SI:BitPositions to the
each BFR to which that BFR should be able to send packets to - BIFT of each BFR to which that BFR should be able to send packets to
adjacencies connecting to this BFR. - adjacencies connecting to this BFR.
2.2.2. Changes in the network topology 2.2.2. Changes in the network topology
If the network topology changes (not failure based) so that If the network topology changes (not failure based) so that
adjacencies that are assigned to BitPositions are no longer needed, adjacencies that are assigned to BitPositions are no longer needed,
the controller can re-use those BitPositions for new adjacencies. the BIER-TE Controller can re-use those BitPositions for new
First, these BitPositions need to be removed from any BFIR flow state adjacencies. First, these BitPositions need to be removed from any
and BFR BIFT state, then they can be repopulated, first into BIFT and BFIR flow state and BFR BIFT state, then they can be repopulated,
then into the BFIR. first into BIFT and then into the BFIR.
2.2.3. Set up per-multicast flow BIER-TE state 2.2.3. Set up per-multicast flow BIER-TE state
The BIER-TE controller host interacts with the multicast flow overlay The BIER-TE Controller interacts with the multicast flow overlay to
to determine what multicast flow needs to be sent by a BFIR to which determine what multicast flow needs to be sent by a BFIR to which set
set of BFER. It calculates the desired distribution tree across the of BFER. It calculates the desired distribution tree across the
BIER-TE domain based on algorithms outside the scope of this document BIER-TE domain based on algorithms outside the scope of this document
(e.g. CSFP, Steiner Tree, ...). It then pushes the calculated (e.g. CSFP, Steiner Tree, ...). It then pushes the calculated
BitString into the BFIR. BitString into the BFIR.
See [I-D.ietf-bier-multicast-http-response] for a solution describing See [I-D.ietf-bier-multicast-http-response] for a solution describing
this interaction. this interaction.
2.2.4. Link/Node Failures and Recovery 2.2.4. Link/Node Failures and Recovery
When link or nodes fail or recover in the topology, BIER-TE can When link or nodes fail or recover in the topology, BIER-TE can
quickly respond with the optional FRR procedures described in [I- quickly respond with the optional FRR procedures described in [I-
D.eckert-bier-te-frr]. It can also more slowly react by D.eckert-bier-te-frr]. It can also more slowly react by
recalculating the BitStrings of affected multicast flows. This recalculating the BitStrings of affected multicast flows. This
reaction is slower than the FRR procedure because the controller reaction is slower than the FRR procedure because the BIER-TE
needs to receive link/node up/down indications, recalculate the Controller needs to receive link/node up/down indications,
desired BitStrings and push them down into the BFIRs. With FRR, this recalculate the desired BitStrings and push them down into the BFIRs.
is all performed locally on a BFR receiving the adjacency up/down With FRR, this is all performed locally on a BFR receiving the
notification. adjacency up/down notification.
2.3. The BIER-TE Forwarding Layer 2.3. The BIER-TE Forwarding Layer
When the BIER-TE Forwarding Layer receives a packet, it simply looks When the BIER-TE Forwarding Layer receives a packet, it simply looks
up the BitPositions that are set in the BitString of the packet in up the BitPositions that are set in the BitString of the packet in
the Bit Index Forwarding Table (BIFT) that was populated by the BIER- the Bit Index Forwarding Table (BIFT) that was populated by the BIER-
TE controller host. For every BP that is set in the BitString, and TE Controller. For every BP that is set in the BitString, and that
that has one or more adjacencies in the BIFT, a copy is made has one or more adjacencies in the BIFT, a copy is made according to
according to the type of adjacencies for that BP in the BIFT. Before the type of adjacencies for that BP in the BIFT. Before sending any
sending any copy, the BFR resets all BP in the BitString of the copy, the BFR resets all BP in the BitString of the packet for which
packet for which the BFR has one or more adjacencies in the BIFT, the BFR has one or more adjacencies in the BIFT, except when the
except when the adjacency indicates "DoNotReset" (DNR, see adjacency indicates "DoNotReset" (DNR, see Section 3.2.1). This is
Section 3.2.1). This is done to inhibit that packets can loop. done to inhibit that packets can loop.
2.4. The Routing Underlay 2.4. The Routing Underlay
BIER-TE is sending BIER packets to directly connected BIER-TE BIER-TE is sending BIER packets to directly connected BIER-TE
neighbors as L2 (unicasted) BIER packets without requiring a routing neighbors as L2 (unicasted) BIER packets without requiring a routing
underlay. BIER-TE forwarding uses the Routing underlay for underlay. BIER-TE forwarding uses the Routing underlay for
forward_routed adjacencies which copy BIER-TE packets to not- forward_routed adjacencies which copy BIER-TE packets to not-
directly-connected BFRs (see below for adjacency definitions). directly-connected BFRs (see below for adjacency definitions).
If the BFR intends to support FRR for BIER-TE, then the BIER-TE If the BFR intends to support FRR for BIER-TE, then the BIER-TE
skipping to change at page 12, line 14 skipping to change at page 13, line 14
BIER-TE can support multiple subdomains like BIER. Each one with a BIER-TE can support multiple subdomains like BIER. Each one with a
separate BIFT separate BIFT
In the BIER architecture, indices into the BIFT are explained to be In the BIER architecture, indices into the BIFT are explained to be
both BFR-id and SI:BitString (BitPosition). This is because there is both BFR-id and SI:BitString (BitPosition). This is because there is
a 1:1 relationship between BFR-id and SI:BitString - every bit in a 1:1 relationship between BFR-id and SI:BitString - every bit in
every SI is/can be assigned to a BFIR/BFER. In BIER-TE there are every SI is/can be assigned to a BFIR/BFER. In BIER-TE there are
more bits used in each BitString than there are BFIR/BFER assigned to more bits used in each BitString than there are BFIR/BFER assigned to
the bitstring. This is because of the bits required to express the the bitstring. This is because of the bits required to express the
(traffic engineered) path through the topology. The BIER-TE engineered path through the topology. The BIER-TE forwarding
forwarding definitions do therefore not use the term BFR-id at all. definitions do therefore not use the term BFR-id at all. Instead,
Instead, BFR-ids are only used as required by routing underlay, flow BFR-ids are only used as required by routing underlay, flow overlay
overlay of BIER headers. Please refer to Section 7 for explanations of BIER headers. Please refer to Section 7 for explanations how to
how to deal with SI, subdomains and BFR-id in BIER-TE. deal with SI, subdomains and BFR-id in BIER-TE.
------------------------------------------------------------------ ------------------------------------------------------------------
| Index: | Adjacencies: | | Index: | Adjacencies: |
| SI:BitPosition | <empty> or one or more per entry | | SI:BitPosition | <empty> or one or more per entry |
================================================================== ==================================================================
| 0:1 | forward_connected(interface,neighbor{,DNR}) | | 0:1 | forward_connected(interface,neighbor{,DNR}) |
------------------------------------------------------------------ ------------------------------------------------------------------
| 0:2 | forward_connected(interface,neighbor{,DNR}) | | 0:2 | forward_connected(interface,neighbor{,DNR}) |
| | forward_connected(interface,neighbor{,DNR}) | | | forward_connected(interface,neighbor{,DNR}) |
------------------------------------------------------------------ ------------------------------------------------------------------
skipping to change at page 12, line 45 skipping to change at page 13, line 45
| 0:6 | ECMP({adjacency1,...adjacencyN}, seed) | | 0:6 | ECMP({adjacency1,...adjacencyN}, seed) |
------------------------------------------------------------------ ------------------------------------------------------------------
... ...
| BitStringLength | ... | | BitStringLength | ... |
------------------------------------------------------------------ ------------------------------------------------------------------
Bit Index Forwarding Table Bit Index Forwarding Table
Figure 4: BIFT adjacencies Figure 4: BIFT adjacencies
The BIFT is programmed into the data plane of BFRs by the BIER-TE The BIFT is programmed into the data plane of BFRs by the BIER-TE
controller host and used to forward packets, according to the rules Controller and used to forward packets, according to the rules
specified in the BIER-TE Forwarding Procedures. specified in the BIER-TE Forwarding Procedures.
Adjacencies for the same BP when populated in more than one BFR by Adjacencies for the same BP when populated in more than one BFR by
the controller does not have to have the same adjacencies. This is the BIER-TE Controller does not have to have the same adjacencies.
up to the controller. BPs for p2p links are one case (see below). This is up to the BIER-TE Controller. BPs for p2p links are one case
(see below).
3.2. Adjacency Types 3.2. Adjacency Types
3.2.1. Forward Connected 3.2.1. Forward Connected
A "forward_connected" adjacency is towards a directly connected BFR A "forward_connected" adjacency is towards a directly connected BFR
neighbor using an interface address of that BFR on the connecting neighbor using an interface address of that BFR on the connecting
interface. A forward_connected adjacency does not route packets but interface. A forward_connected adjacency does not route packets but
only L2 forwards them to the neighbor. only L2 forwards them to the neighbor.
skipping to change at page 15, line 9 skipping to change at page 16, line 9
[RFC Editor: remove this section.] [RFC Editor: remove this section.]
THIS SECTION TO BE REMOVED IN RFC BECAUSE IT WAS SUPERCEEDED BY THIS SECTION TO BE REMOVED IN RFC BECAUSE IT WAS SUPERCEEDED BY
SECTION 1.1 EXAMPLE - UNLESS REVIEWERS CHIME IN AND EXPRESS DESIRE TO SECTION 1.1 EXAMPLE - UNLESS REVIEWERS CHIME IN AND EXPRESS DESIRE TO
KEEP THIS ADDITIONAL EXAMPLE SECTION. KEEP THIS ADDITIONAL EXAMPLE SECTION.
Step by step example of basic BIER-TE forwarding. This does not use Step by step example of basic BIER-TE forwarding. This does not use
ECMP or forward_routed adjacencies nor does it try to minimize the ECMP or forward_routed adjacencies nor does it try to minimize the
number of required BitPositions for the topology. number of required BitPositions for the topology.
[Bier-Te Controller Host] [BIER-TE Controller]
/ | \ / | \
v v v v v v
| p13 p1 | | p13 p1 |
+- BFIR2 --+ | +- BFIR2 --+ |
| | p2 p6 | LAN2 | | p2 p6 | LAN2
| +-- BFR3 --+ | | +-- BFR3 --+ |
| | | p7 p11 | | | | p7 p11 |
Src -+ +-- BFER1 --+ Src -+ +-- BFER1 --+
| | p3 p8 | | | | p3 p8 | |
skipping to change at page 15, line 36 skipping to change at page 16, line 36
LAN1 | p5 p9 +-- BFER2 --+ LAN1 | p5 p9 +-- BFER2 --+
| +-- Rcv2 | +-- Rcv2
| |
LAN3 LAN3
IP |..... BIER-TE network......| IP IP |..... BIER-TE network......| IP
Figure 5: BIER-TE Forwarding Example Figure 5: BIER-TE Forwarding Example
pXX indicate the BitPositions number assigned by the BIER-TE pXX indicate the BitPositions number assigned by the BIER-TE
controller host to adjacencies in the BIER-TE topology. For example, Controller to adjacencies in the BIER-TE topology. For example, p9
p9 is the adjacency towards BFR5 on the LAN connecting to BFER2. is the adjacency towards BFR5 on the LAN connecting to BFER2.
BIFT BFIR2: BIFT BFIR2:
p13: local_decap() p13: local_decap()
p2: forward_connected(BFR3) p2: forward_connected(BFR3)
BIFT BFR3: BIFT BFR3:
p1: forward_connected(BFIR2) p1: forward_connected(BFIR2)
p7: forward_connected(BFER1) p7: forward_connected(BFER1)
p8: forward_connected(BFR4) p8: forward_connected(BFR4)
BIFT BFER1: BIFT BFER1:
p11: local_decap() p11: local_decap()
p6: forward_connected(BFR3) p6: forward_connected(BFR3)
p8: forward_connected(BFR4) p8: forward_connected(BFR4)
Figure 6: BIER-TE Forwarding Example Adjacencies Figure 6: BIER-TE Forwarding Example Adjacencies
...and so on. ...and so on.
For example, we assume that some multicast traffic seen on LAN1 needs For example, we assume that some multicast traffic seen on LAN1 needs
to be sent via BIER-TE by BFIR2 towards Rcv1 and Rcv2. The to be sent via BIER-TE by BFIR2 towards Rcv1 and Rcv2. The BIER-TE
controller determines it wants it to pass this traffic across the Controller determines it wants it to pass this traffic across the
following paths: following paths:
-> BFER1 ---------------> Rcv1 -> BFER1 ---------------> Rcv1
BFIR2 -> BFR3 BFIR2 -> BFR3
-> BFR4 -> BFR5 -> BFER2 -> Rcv2 -> BFR4 -> BFR5 -> BFER2 -> Rcv2
Figure 7: BIER-TE Forwarding Example Paths Figure 7: BIER-TE Forwarding Example Paths
These paths equal to the following BitString: p2, p5, p7, p8, p10, These paths equal to the following BitString: p2, p5, p7, p8, p10,
p11, p12. p11, p12.
skipping to change at page 16, line 51 skipping to change at page 17, line 51
BitString. The BIFT of BFIR2 has only p2 and p13 populated. Only p2 BitString. The BIFT of BFIR2 has only p2 and p13 populated. Only p2
is in the BitString and this is an adjacency towards BFR3. BFIR2 is in the BitString and this is an adjacency towards BFR3. BFIR2
therefore resets p2 in the BitString and sends a copy towards BFR2. therefore resets p2 in the BitString and sends a copy towards BFR2.
BFR3 sees a BitString of p5,p7,p8,p10,p11,p12. It is only interested BFR3 sees a BitString of p5,p7,p8,p10,p11,p12. It is only interested
in p1,p7,p8. It creates a copy of the packet to BFER1 (due to p7) in p1,p7,p8. It creates a copy of the packet to BFER1 (due to p7)
and one to BFR4 (due to p8). It resets p7, p8 before sending. and one to BFR4 (due to p8). It resets p7, p8 before sending.
BFER1 sees a BitString of p5,p10,p11,p12. It is only interested in BFER1 sees a BitString of p5,p10,p11,p12. It is only interested in
p6,p7,p8,p11 and therefore considers only p11. p11 is a "local_decap" p6,p7,p8,p11 and therefore considers only p11. p11 is a "local_decap"
adjacency installed by the BIER-TE controller host because BFER1 adjacency installed by the BIER-TE Controller because BFER1 should
should pass packets to IP multicast. The local_decap adjacency pass packets to IP multicast. The local_decap adjacency instructs
instructs BFER1 to create a copy, decapsulate it from the BIER header BFER1 to create a copy, decapsulate it from the BIER header and pass
and pass it on to the NextProtocol, in this example IP multicast. IP it on to the NextProtocol, in this example IP multicast. IP
multicast will then forward the packet out to LAN2 because it did multicast will then forward the packet out to LAN2 because it did
receive PIM or IGMP joins on LAN2 for the traffic. receive PIM or IGMP joins on LAN2 for the traffic.
Further processing of the packet in BFR4, BFR5 and BFER2 accordingly. Further processing of the packet in BFR4, BFR5 and BFER2 accordingly.
3.5. Forwarding comparison with BIER 3.5. Forwarding comparison with BIER
Forwarding of BIER-TE is designed to allow common forwarding hardware Forwarding of BIER-TE is designed to allow common forwarding hardware
with BIER. In fact, one of the main goals of this document is to with BIER. In fact, one of the main goals of this document is to
encourage the building of forwarding hardware that can not only encourage the building of forwarding hardware that can not only
support BIER, but also BIER-TE - to allow experimentation with BIER- support BIER, but also BIER-TE - to allow experimentation with BIER-
TE and support building of BIER-TE control plane code. TE and support building of BIER-TE control plane code.
The pseudocode in Section 6 shows how existing BIER/BIFT forwarding The pseudocode in Section 6 shows how existing BIER/BIFT forwarding
can be amended to support basic BIER-TE forwarding, by using BIER can be amended to support basic BIER-TE forwarding, by using BIER
BIFT's F-BM. Only the masking of bits due to avoid duplicates must BIFT's F-BM. Only the masking of bits due to avoid duplicates must
be skipped when forwarding is for BIER-TE. be skipped when forwarding is for BIER-TE.
Whether to use BIER or BIER-TE forwarding can simply be a configured Whether to use BIER or BIER-TE forwarding can simply be a configured
choice per subdomain and accordingly be set up by a BIER-TE choice per subdomain and accordingly be set up by a BIER-TE
controller host. The BIER packet encapsulation [RFC8296] too can be Controller. The BIER packet encapsulation [RFC8296] too can be
reused without changes except that the currently defined BIER-TE ECMP reused without changes except that the currently defined BIER-TE ECMP
adjacency does not leverage the entropy field so that field would be adjacency does not leverage the entropy field so that field would be
unused when BIER-TE forwarding is used. unused when BIER-TE forwarding is used.
3.6. Requirements 3.6. Requirements
Basic BIER-TE forwarding MUST support to configure Subdomains to use Basic BIER-TE forwarding MUST support to configure Subdomains to use
basic BIER-TE forwarding rules (instead of BIER). With basic BIER-TE basic BIER-TE forwarding rules (instead of BIER). With basic BIER-TE
forwarding, every bit MUST support to have zero or one adjacency. It forwarding, every bit MUST support to have zero or one adjacency. It
MUST support the adjacency types forward_connected without DNR flag, MUST support the adjacency types forward_connected without DNR flag,
skipping to change at page 17, line 49 skipping to change at page 18, line 49
forwarding exactly the same as BIER forwarding with the exception of forwarding exactly the same as BIER forwarding with the exception of
skipping the aforementioned F-BM masking on egress. skipping the aforementioned F-BM masking on egress.
BIER-TE forwarding SHOULD support the DNR flag, as this is highly BIER-TE forwarding SHOULD support the DNR flag, as this is highly
useful to save bits in rings (see Section 4.6). useful to save bits in rings (see Section 4.6).
BIER-TE forwarding MAY support more than one adjacency on a bit and BIER-TE forwarding MAY support more than one adjacency on a bit and
ECMP adjacencies. The importance of ECMP adjacencies is unclear when ECMP adjacencies. The importance of ECMP adjacencies is unclear when
traffic engineering is used because it may be more desirable to traffic engineering is used because it may be more desirable to
explicitly steer traffic across non-ECMP paths to make per-path explicitly steer traffic across non-ECMP paths to make per-path
traffic calculation easier for controllers. Having more than one traffic calculation easier for BIER-TE Controllers. Having more than
adjacency for a bit allows further savings of bits in hub&spoke one adjacency for a bit allows further savings of bits in hub&spoke
scenarios, but unlike rings it is less "natural" to flood traffic scenarios, but unlike rings it is less "natural" to flood traffic
across multiple links unconditional. Both ECMP and multiple across multiple links unconditional. Both ECMP and multiple
adjacencies are forwarding plane features that should be possible to adjacencies are forwarding plane features that should be possible to
support later when needed as they do not impact the basic BIER-TE support later when needed as they do not impact the basic BIER-TE
replication loop. This is true because there is no inter-copy replication loop. This is true because there is no inter-copy
dependency through resetting of F-BM as in BIER. dependency through resetting of F-BM as in BIER.
4. BIER-TE Controller Host BitPosition Assignments 4. BIER-TE Controller BitPosition Assignments
This section describes how the BIER-TE controller host can use the This section describes how the BIER-TE Controller can use the
different BIER-TE adjacency types to define the BitPositions of a different BIER-TE adjacency types to define the BitPositions of a
BIER-TE domain. BIER-TE domain.
Because the size of the BitString is limiting the size of the BIER-TE Because the size of the BitString is limiting the size of the BIER-TE
domain, many of the options described exist to support larger domain, many of the options described exist to support larger
topologies with fewer BitPositions (4.1, 4.3, 4.4, 4.5, 4.6, 4.7, topologies with fewer BitPositions (4.1, 4.3, 4.4, 4.5, 4.6, 4.7,
4.8). 4.8).
4.1. P2P Links 4.1. P2P Links
skipping to change at page 21, line 51 skipping to change at page 22, line 51
================================================================== ==================================================================
| 0:6 | ECMP({forward_connected(L1, BFR1), | | 0:6 | ECMP({forward_connected(L1, BFR1), |
| | forward_connected(L2, BFR1), | | | forward_connected(L2, BFR1), |
| | forward_connected(L3, BFR1)}, seed) | | | forward_connected(L3, BFR1)}, seed) |
------------------------------------------------------------------ ------------------------------------------------------------------
Figure 11: ECMP Example Figure 11: ECMP Example
This document does not standardize any ECMP algorithm because it is This document does not standardize any ECMP algorithm because it is
sufficient for implementations to document their freely chosen ECMP sufficient for implementations to document their freely chosen ECMP
algorithm. This allows the BIER-TE controller host to calculate ECMP algorithm. This allows the BIER-TE Controller to calculate ECMP
paths and seeds. The following picture shows an example ECMP paths and seeds. The following picture shows an example ECMP
algorithm: algorithm:
forward(packet, ECMP(adj(0), adj(1),... adj(N-1), seed)): forward(packet, ECMP(adj(0), adj(1),... adj(N-1), seed)):
i = (packet(bier-header-entropy) XOR seed) % N i = (packet(bier-header-entropy) XOR seed) % N
forward packet to adj(i) forward packet to adj(i)
Figure 12: ECMP algorithm Example Figure 12: ECMP algorithm Example
In the following example, all traffic from BFR1 towards BFR10 is In the following example, all traffic from BFR1 towards BFR10 is
skipping to change at page 23, line 45 skipping to change at page 24, line 45
This issue in BFR2/BFR3 is called polarization. It results from the This issue in BFR2/BFR3 is called polarization. It results from the
re-use of the same hash function across multiple consecutive hops in re-use of the same hash function across multiple consecutive hops in
topologies like these. To resolve this issue, the ECMP adjacency on topologies like these. To resolve this issue, the ECMP adjacency on
BFR1 can be set up with a different seed2 than the ECMP adjacencies BFR1 can be set up with a different seed2 than the ECMP adjacencies
on BFR2/BFR3. BFR2/BFR3 can use the same hash because packets will on BFR2/BFR3. BFR2/BFR3 can use the same hash because packets will
not sequentially pass across both of them. Therefore, they can also not sequentially pass across both of them. Therefore, they can also
use the same BP 0:7. use the same BP 0:7.
Note that ECMP solutions outside of BIER often hide the seed by auto- Note that ECMP solutions outside of BIER often hide the seed by auto-
selecting it from local entropy such as unique local or next-hop selecting it from local entropy such as unique local or next-hop
identifiers. The solutions choosen for BIER-TE to allow the identifiers. The solutions choosen for BIER-TE to allow the BIER-TE
controller to explicitly set the seed maximizes the ability of the Controller to explicitly set the seed maximizes the ability of the
controller to choose the seed, independent of such seed source that BIER-TE Controller to choose the seed, independent of such seed
the controller may not be able to control well, and even calculate source that the BIER-TE Controller may not be able to control well,
optimized seeds for multi-hop cases. and even calculate optimized seeds for multi-hop cases.
4.8. Routed adjacencies 4.8. Routed adjacencies
4.8.1. Reducing BitPositions 4.8.1. Reducing BitPositions
Routed adjacencies can reduce the number of BitPositions required Routed adjacencies can reduce the number of BitPositions required
when the traffic engineering requirement is not hop-by-hop explicit when the path engineering requirement is not hop-by-hop explicit path
path selection, but loose-hop selection. Routed adjacencies can also selection, but loose-hop selection. Routed adjacencies can also
allow to operate BIER-TE across intermediate hop routers that do not allow to operate BIER-TE across intermediate hop routers that do not
support BIER-TE. support BIER-TE.
............... ...............
...BFR1--... ...--L1-- BFR2... ...BFR1--... ...--L1-- BFR2...
... .Routers. ...--L2--/ ... .Routers. ...--L2--/
...BFR4--... ...------ BFR3... ...BFR4--... ...------ BFR3...
............... | ............... |
LO LO
Network Area 1 Network Area 1
skipping to change at page 25, line 48 skipping to change at page 26, line 48
shown in Figure 17, but only the following explanations: A BFIR/ shown in Figure 17, but only the following explanations: A BFIR/
sender (e.g.: video headend) is attached to area 1, and area 2...6 sender (e.g.: video headend) is attached to area 1, and area 2...6
contain receivers/BFER. Assume each area had a distribution ring, contain receivers/BFER. Assume each area had a distribution ring,
each with two BPs to indicate the direction (as explained in before). each with two BPs to indicate the direction (as explained in before).
These two BPs could be reused across the 5 areas. Packets would be These two BPs could be reused across the 5 areas. Packets would be
replicated through other BPs to the desired subset of areas, and once replicated through other BPs to the desired subset of areas, and once
a packet copy reaches the ring of the area, the two ring BPs come a packet copy reaches the ring of the area, the two ring BPs come
into play. This reuse is a case of (B), but it limits the topology into play. This reuse is a case of (B), but it limits the topology
choices: Packets can only flow around the same direction in the rings choices: Packets can only flow around the same direction in the rings
of all areas. This may or may not be acceptable based on the desired of all areas. This may or may not be acceptable based on the desired
traffic engineering: If resilient transmission is the traffic path engineering: If resilient transmission is the path engineering
engineering goal, then it is likely a good optimization, if the goal, then it is likely a good optimization, if the bandwidth of each
bandwidth of each ring was to be optimized separately, it would not ring was to be optimized separately, it would not be a good
be a good limitation. limitation.
4.10. Summary of BP optimizations 4.10. Summary of BP optimizations
This section reviewed a range of techniques by which a controller can This section reviewed a range of techniques by which a BIER-TE
create a BIER-TE topology in a way that minimizes the number of Controller can create a BIER-TE topology in a way that minimizes the
necessary BPs. number of necessary BPs.
Without any optimization, a controller would attempt to map the Without any optimization, a BIER-TE Controller would attempt to map
network subnet topology 1:1 into the BIER-TE topology and every the network subnet topology 1:1 into the BIER-TE topology and every
subnet adjacent neighbor requires a forward_connected BP and every subnet adjacent neighbor requires a forward_connected BP and every
BFER requires a local_decap BP. BFER requires a local_decap BP.
The optimizations described are then as follows: The optimizations described are then as follows:
o P2p links require only one BP (Section 4.1). o P2p links require only one BP (Section 4.1).
o All leaf-BFER can share a single local_decap BP (Section 4.3). o All leaf-BFER can share a single local_decap BP (Section 4.3).
o A LAN with N BFR needs at most N BP (one for each BFR). It only o A LAN with N BFR needs at most N BP (one for each BFR). It only
skipping to change at page 26, line 45 skipping to change at page 27, line 45
o ECMP adjacencies to N neighbors can replace N BP with 1 BP. o ECMP adjacencies to N neighbors can replace N BP with 1 BP.
Multihop ECMP can avoid polarization through different seeds of Multihop ECMP can avoid polarization through different seeds of
the ECMP algorithm (Section 4.7). the ECMP algorithm (Section 4.7).
o Routed adjacencies allow to "tunnel" across non-BIER-TE capable o Routed adjacencies allow to "tunnel" across non-BIER-TE capable
routers and across BIER-TE capable routers where no traffic- routers and across BIER-TE capable routers where no traffic-
steering or replications are required (Section 4.8). steering or replications are required (Section 4.8).
o BP can generally be reused across nodes that do not need to be o BP can generally be reused across nodes that do not need to be
consecutive in paths, but depending on scenario, this may limit consecutive in paths, but depending on scenario, this may limit
the feasible traffic engineering options (Section 4.9). the feasible path engineering options (Section 4.9).
Note that the described list of optimizations is not exhaustive. Note that the described list of optimizations is not exhaustive.
Especially when the set of required path engineering choices is Especially when the set of required path engineering choices is
limited and the set of possible subsets of BFER that should be able limited and the set of possible subsets of BFER that should be able
to receive traffic is limited, further optimizations of BP are to receive traffic is limited, further optimizations of BP are
possible. The hub & spoke optimization is a simple example of such possible. The hub & spoke optimization is a simple example of such
traffic pattern dependent optimizations. traffic pattern dependent optimizations.
5. Avoiding loops and duplicates 5. Avoiding loops and duplicates
skipping to change at page 27, line 29 skipping to change at page 28, line 29
To inhibit looping in the face of such physical misconfiguration, To inhibit looping in the face of such physical misconfiguration,
only forward_connected adjacencies are permitted to have DNR set, and only forward_connected adjacencies are permitted to have DNR set, and
the link layer port unique unicast destination address of the the link layer port unique unicast destination address of the
adjacency (e.g. MAC address) protects against closing the loop. adjacency (e.g. MAC address) protects against closing the loop.
Link layers without port unique link layer addresses should not be Link layers without port unique link layer addresses should not be
used with the DNR flag set. used with the DNR flag set.
5.2. Duplicates 5.2. Duplicates
Duplicates happen when the topology of the BitString is not a tree Duplicates happen when the topology of the BitString is not a tree
but redundantly connecting BFRs with each other. The controller must but redundantly connecting BFRs with each other. The BIER-TE
therefore ensure to only create BitStrings that are trees in the Controller must therefore ensure to only create BitStrings that are
topology. trees in the topology.
When links are incorrectly physically re-connected before the When links are incorrectly physically re-connected before the BIER-TE
controller updates BitStrings in BFIRs, duplicates can happen. Like Controller updates BitStrings in BFIRs, duplicates can happen. Like
loops, these can be inhibited by link layer addressing in loops, these can be inhibited by link layer addressing in
forward_connected adjacencies. forward_connected adjacencies.
If interface or loopback addresses used in forward_routed adjacencies If interface or loopback addresses used in forward_routed adjacencies
are moved from one BFR to another, duplicates can equally happen. are moved from one BFR to another, duplicates can equally happen.
Such re-addressing operations must be coordinated with the Such re-addressing operations must be coordinated with the BIER-TE
controller. Controller.
6. BIER-TE Forwarding Pseudocode 6. BIER-TE Forwarding Pseudocode
The following simplified pseudocode for BIER-TE forwarding is using The following simplified pseudocode for BIER-TE forwarding is using
BIER forwarding pseudocode of [RFC8279], section 6.5 with the one BIER forwarding pseudocode of [RFC8279], section 6.5 with the one
modification necessary to support basic BIER-TE forwarding. Like the modification necessary to support basic BIER-TE forwarding. Like the
BIER pseudo forwarding code, for simplicity it does hide the details BIER pseudo forwarding code, for simplicity it does hide the details
of the adjacency processing inside PacketSend() which can be of the adjacency processing inside PacketSend() which can be
forward_connected, forward_routed or local_decap. forward_connected, forward_routed or local_decap.
skipping to change at page 29, line 6 skipping to change at page 30, line 6
of BPs without any considerations for the other BPs - and without any of BPs without any considerations for the other BPs - and without any
prior, cross-BP shared processing. prior, cross-BP shared processing.
The above simplified pseudocode is elaborated further as follows: The above simplified pseudocode is elaborated further as follows:
o This pseudocode eliminates per-bit F-BM, therefore reducing state o This pseudocode eliminates per-bit F-BM, therefore reducing state
by BitStringLength^2*SI and eliminating the need for per-packet- by BitStringLength^2*SI and eliminating the need for per-packet-
copy masking operation except for adjacencies with DNR flag set: copy masking operation except for adjacencies with DNR flag set:
* AdjacentBits[SI] are bits with a non-empty list of adjacencies. * AdjacentBits[SI] are bits with a non-empty list of adjacencies.
This can be computed whenever the BIER-TE controller host This can be computed whenever the BIER-TE Controller updates
updates the adjacencies. the adjacencies.
* Only the AdjacentBits need to be examined in the loop for * Only the AdjacentBits need to be examined in the loop for
packet copies. packet copies.
* The packets BitString is masked with those AdjacentBits on * The packets BitString is masked with those AdjacentBits on
ingress to avoid packets looping. ingress to avoid packets looping.
o The code loops over the adjacencies because there may be more than o The code loops over the adjacencies because there may be more than
one adjacency for a bit. one adjacency for a bit.
skipping to change at page 31, line 49 skipping to change at page 32, line 49
service instance may only support configuration of a single subdomain service instance may only support configuration of a single subdomain
it should rely on. it should rely on.
To be able to easily reuse (and modify as little as possible) To be able to easily reuse (and modify as little as possible)
existing BIER procedures including flow-overlay and routing underlay, existing BIER procedures including flow-overlay and routing underlay,
when BIER-TE forwarding is added, we therefore reuse SI and subdomain when BIER-TE forwarding is added, we therefore reuse SI and subdomain
logically in the same way as they are used in BIER: All necessary logically in the same way as they are used in BIER: All necessary
BFIR/BFER for a service use a single BIER-TE BIFT and are split BFIR/BFER for a service use a single BIER-TE BIFT and are split
across as many SI as necessary (see below). Different services may across as many SI as necessary (see below). Different services may
use different subdomains that primarily exist to provide more use different subdomains that primarily exist to provide more
efficient replication (and for BIER-TE desirable traffic engineering) efficient replication (and for BIER-TE desirable path engineering)
for different subsets of BFIR/BFER. for different subsets of BFIR/BFER.
7.2. Bit assignment comparison BIER and BIER-TE 7.2. Bit assignment comparison BIER and BIER-TE
In BIER, bitstrings only need to carry bits for BFER, which leads to In BIER, bitstrings only need to carry bits for BFER, which leads to
the model that BFR-ids map 1:1 to each bit in a bitstring. the model that BFR-ids map 1:1 to each bit in a bitstring.
In BIER-TE, bitstrings need to carry bits to indicate not only the In BIER-TE, bitstrings need to carry bits to indicate not only the
receiving BFER but also the intermediate hops/links across which the receiving BFER but also the intermediate hops/links across which the
packet must be sent. The maximum number of BFER that can be packet must be sent. The maximum number of BFER that can be
supported in a single bitstring or BIFT:SI depends on the number of supported in a single bitstring or BIFT:SI depends on the number of
bits necessary to represent the desired topology between them. bits necessary to represent the desired topology between them.
"Desired" topology because it depends on the physical topology, and "Desired" topology because it depends on the physical topology, and
on the desire of the operator to allow for explicit traffic on the desire of the operator to allow for explicit path engineering
engineering across every single hop (which requires more bits), or across every single hop (which requires more bits), or reducing the
reducing the number of required bits by exploiting optimizations such number of required bits by exploiting optimizations such as unicast
as unicast (forward_route), ECMP or flood (DNR) over "uninteresting" (forward_route), ECMP or flood (DNR) over "uninteresting" sub-parts
sub-parts of the topology - e.g. parts where different trees do not of the topology - e.g. parts where different trees do not need to
need to take different paths due to traffic-engineering reasons. take different paths due to traffic-engineering reasons.
The total number of bits to describe the topology vs. the BFER in a The total number of bits to describe the topology vs. the BFER in a
BIFT:SI can range widely based on the size of the topology and the BIFT:SI can range widely based on the size of the topology and the
amount of alternative paths in it. The higher the percentage, the amount of alternative paths in it. The higher the percentage, the
higher the likelihood, that those topology bits are not just BIER-TE higher the likelihood, that those topology bits are not just BIER-TE
overhead without additional benefit, but instead that they will allow overhead without additional benefit, but instead that they will allow
to express desirable traffic-engineering path alternatives. to express desirable traffic-engineering path alternatives.
7.3. Using BFR-id with BIER-TE 7.3. Using BFR-id with BIER-TE
Because there is no 1:1 mapping between bits in the bitstring and Because there is no 1:1 mapping between bits in the bitstring and
BFER, BIER-TE cannot simply rely on the BIER 1:1 mapping between bits BFER, BIER-TE cannot simply rely on the BIER 1:1 mapping between bits
in a bitstring and BFR-id. in a bitstring and BFR-id.
In BIER, automatic schemes could assign all possible BFR-ids In BIER, automatic schemes could assign all possible BFR-ids
sequentially to BFERs. This will not work in BIER-TE. In BIER-TE, sequentially to BFERs. This will not work in BIER-TE. In BIER-TE,
the operator or BIER-TE controller host has to determine a BFR-id for the operator or BIER-TE Controller has to determine a BFR-id for each
each BFER in each required subdomain. The BFR-id may or may not have BFER in each required subdomain. The BFR-id may or may not have a
a relationship with a bit in the bitstring. Suggestions are detailed relationship with a bit in the bitstring. Suggestions are detailed
below. Once determined, the BFR-id can then be configured on the below. Once determined, the BFR-id can then be configured on the
BFER and used by flow overlay, routing underlay and the BIER header BFER and used by flow overlay, routing underlay and the BIER header
almost the same as the BFR-id in BIER. almost the same as the BFR-id in BIER.
The one exception are application/flow-overlays that automatically The one exception are application/flow-overlays that automatically
calculate the bitstring(s) of BIER packets by converting BFR-id to calculate the bitstring(s) of BIER packets by converting BFR-id to
bits. In BIER-TE, this operation can be done in two ways: bits. In BIER-TE, this operation can be done in two ways:
"Independent branches": For a given application or (set of) trees, "Independent branches": For a given application or (set of) trees,
the branches from a BFIR to every BFER are independent of the the branches from a BFIR to every BFER are independent of the
branches to any other BFER. For example, shortest part trees have branches to any other BFER. For example, shortest part trees have
independent branches. independent branches.
"Interdependent branches": When a BFER is added or deleted from a "Interdependent branches": When a BFER is added or deleted from a
particular distribution tree, branches to other BFER still in the particular distribution tree, branches to other BFER still in the
tree may need to change. Steiner tree are examples of dependent tree may need to change. Steiner tree are examples of dependent
branch trees. branch trees.
If "independent branches" are sufficient, the BIER-TE controller host If "independent branches" are sufficient, the BIER-TE Controller can
can provide to such applications for every BFR-id a SI:bitstring with provide to such applications for every BFR-id a SI:bitstring with the
the BIER-TE bits for the branch towards that BFER. The application BIER-TE bits for the branch towards that BFER. The application can
can then independently calculate the SI:bitstring for all desired then independently calculate the SI:bitstring for all desired BFER by
BFER by OR'ing their bitstrings. OR'ing their bitstrings.
If "interdependent branches" are required, the application could call If "interdependent branches" are required, the application could call
a BIER-TE controller host API with the list of required BFER-id and a BIER-TE Controller API with the list of required BFER-id and get
get the required bitstring back. Whenever the set of BFER-id the required bitstring back. Whenever the set of BFER-id changes,
changes, this is repeated. this is repeated.
Note that in either case (unlike in BIER), the bits in BIER-TE may Note that in either case (unlike in BIER), the bits in BIER-TE may
need to change upon link/node failure/recovery, network expansion and need to change upon link/node failure/recovery, network expansion and
network load by other traffic (as part of traffic engineering goals). network load by other traffic (as part of traffic engineering goals).
Interactions between such BFIR applications and the BIER-TE Interactions between such BFIR applications and the BIER-TE
controller host do therefore need to support dynamic updates to the Controller do therefore need to support dynamic updates to the
bitstrings. bitstrings.
7.4. Assigning BFR-ids for BIER-TE 7.4. Assigning BFR-ids for BIER-TE
For a non-leaf BFER, there is usually a single bit k for that BFER For a non-leaf BFER, there is usually a single bit k for that BFER
with a local_decap() adjacency on the BFER. The BFR-id for such a with a local_decap() adjacency on the BFER. The BFR-id for such a
BFER is therefore most easily the one it would have in BIER: SI * BFER is therefore most easily the one it would have in BIER: SI *
bitstring-length + k. bitstring-length + k.
As explained earlier in the document, leaf BFERs do not need such a As explained earlier in the document, leaf BFERs do not need such a
separate bit because the fact alone that the BIER-TE packet is separate bit because the fact alone that the BIER-TE packet is
forwarded to the leaf BFER indicates that the BFER should decapsulate forwarded to the leaf BFER indicates that the BFER should decapsulate
it. Such a BFER will have one or more bits for the links leading it. Such a BFER will have one or more bits for the links leading
only to it. The BFR-id could therefore most easily be the BFR-id only to it. The BFR-id could therefore most easily be the BFR-id
derived from the lowest bit for those links. derived from the lowest bit for those links.
These two rules are only recommendations for the operator or BIER-TE These two rules are only recommendations for the operator or BIER-TE
controller assigning the BFR-ids. Any allocation scheme can be used, Controller assigning the BFR-ids. Any allocation scheme can be used,
the BFR-ids just need to be unique across BFRs in each subdomain. the BFR-ids just need to be unique across BFRs in each subdomain.
It is not currently determined if a single subdomain could or should It is not currently determined if a single subdomain could or should
be allowed to forward both BIER and BIER-TE packets. If this should be allowed to forward both BIER and BIER-TE packets. If this should
be supported, there are two options: be supported, there are two options:
A. BIER and BIER-TE have different BFR-id in the same subdomain. A. BIER and BIER-TE have different BFR-id in the same subdomain.
This allows higher replication efficiency for BIER because their BFR- This allows higher replication efficiency for BIER because their BFR-
id can be assigned sequentially, while the bitstrings for BIER-TE id can be assigned sequentially, while the bitstrings for BIER-TE
will have also the additional bits for the topology. There is no will have also the additional bits for the topology. There is no
skipping to change at page 35, line 25 skipping to change at page 36, line 25
subdomain 0 can even be helpful or even necessary in BIER. subdomain 0 can even be helpful or even necessary in BIER.
7.5.2. With BIER-TE 7.5.2. With BIER-TE
In BIER-TE one needs to determine a subset of the physical topology In BIER-TE one needs to determine a subset of the physical topology
and attached BFER so that the "desired" representation of this and attached BFER so that the "desired" representation of this
topology and the BFER fit into a single bitstring. This process topology and the BFER fit into a single bitstring. This process
needs to be repeated until the whole topology is covered. needs to be repeated until the whole topology is covered.
Once bits/SIs are assigned to topology and BFER, BFR-id is just a Once bits/SIs are assigned to topology and BFER, BFR-id is just a
derived set of identifiers from the operator/BIER-TE controller as derived set of identifiers from the operator/BIER-TE Controller as
explained above. explained above.
Every time that different sub-topologies have overlap, bits need to Every time that different sub-topologies have overlap, bits need to
be repeated across the bitstrings, increasing the overall amount of be repeated across the bitstrings, increasing the overall amount of
bits required across all bitstring/SIs. In the worst case, random bits required across all bitstring/SIs. In the worst case, random
subsets of BFER are assigned to different SI. This is much worse subsets of BFER are assigned to different SI. This is much worse
than in BIER because it not only reduces replication efficiency with than in BIER because it not only reduces replication efficiency with
the same number of overall bits, but even further - because more bits the same number of overall bits, but even further - because more bits
are required due to duplication of bits for topology across multiple are required due to duplication of bits for topology across multiple
SI. Intelligent BFER to SI assignment and selecting specific SI. Intelligent BFER to SI assignment and selecting specific
skipping to change at page 36, line 38 skipping to change at page 37, line 38
The number of BFIR/BFER possible in a subdomain is smaller than in The number of BFIR/BFER possible in a subdomain is smaller than in
BIER because BIER-TE uses additional bits for topology. BIER because BIER-TE uses additional bits for topology.
Subdomains can in BIER-TE be used like in BIER to create more Subdomains can in BIER-TE be used like in BIER to create more
efficient replication to known subsets of BFER. efficient replication to known subsets of BFER.
Assigning bits for BFER intelligently into the right SI is more Assigning bits for BFER intelligently into the right SI is more
important in BIER-TE than in BIER because of replication efficiency important in BIER-TE than in BIER because of replication efficiency
and overall amount of bits required. and overall amount of bits required.
8. BIER-TE and Segment Routing (SR) 8. BIER-TE and Segment Routing
Segment Routing (SR ([RFC8402])) aims to enable lightweight path SR aims to enable lightweight path engineering via loose source
engineering via loose source routing. Compared to its more heavy- routing. Compared to its more heavy-weight predecessor RSVP-TE, SR
weight predecessor RSVP-TE ([RFC3209]), SR does for example not does for example not require per-path signaling to each of these
require per-path signaling to each of these hops. hops.
BIER-TE supports the same design philosophy for multicast. Like in BIER-TE supports the same design philosophy for multicast. Like in
SR, it relies on source-routing - via the definition of a BitString. SR, it relies on source-routing - via the definition of a BitString.
Like SR, it only requires to consider the "hops" on which either Like SR, it only requires to consider the "hops" on which either
replication has to happen, or across which the traffic should be replication has to happen, or across which the traffic should be
steered (even without replication). Any other hops can be skipped steered (even without replication). Any other hops can be skipped
via the use of routed adjacencies. via the use of routed adjacencies.
BIER-TE BitPosition (BP) can be understood as the BIER-TE equivalent BIER-TE BitPosition (BP) can be understood as the BIER-TE equivalent
of "forwarding segments" in SR, but they have a different scope than of "forwarding segments" in SR, but they have a different scope than
skipping to change at page 38, line 19 skipping to change at page 39, line 19
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Greg Shepherd, Ijsbrand Wijnands, The authors would like to thank Greg Shepherd, Ijsbrand Wijnands,
Neale Ranns, Dirk Trossen, Sandy Zheng and Jeffrey Zhang for their Neale Ranns, Dirk Trossen, Sandy Zheng and Jeffrey Zhang for their
extensive review and suggestions. extensive review and suggestions.
12. Change log [RFC Editor: Please remove] 12. Change log [RFC Editor: Please remove]
draft-ietf-bier-te-arch: draft-ietf-bier-te-arch:
06: Concern by Lou berger re. BIER-TE as full traffic engineering
solution.
Changed title "Traffic Engineering" to "Path Engineering"
Added intro section of relationship BIER-TE to traffic
engineering.
Changed "traffic engineering" term in text" to "path engineering",
where appropriate
Other:
Shortened "BIER-TE Controller Host" to "BIER-TE Controller".
Fixed up all instances of controller to do this.
05: Review Jeffrey Zhang. 05: Review Jeffrey Zhang.
Part 2: Part 2:
4.3 added note about leaf-BFER being also a propery of routing 4.3 added note about leaf-BFER being also a propery of routing
setup. setup.
4.7 Added missing details from example to avoid confusion with 4.7 Added missing details from example to avoid confusion with
routed adjacencies, also compressed explanatory text and better routed adjacencies, also compressed explanatory text and better
justification why seed is explicitly configured by controller. justification why seed is explicitly configured by controller.
skipping to change at page 39, line 22 skipping to change at page 40, line 38
example ECMP algorithm, highlight that doc does not standardize example ECMP algorithm, highlight that doc does not standardize
ECMP algorithm. ECMP algorithm.
Review from Dirk Trossen: Review from Dirk Trossen:
1. Added mentioning of prior work for traffic engineered paths 1. Added mentioning of prior work for traffic engineered paths
with bloom filters. with bloom filters.
2. Changed title from layers to components and added "BIER-TE 2. Changed title from layers to components and added "BIER-TE
control plane" to "BIER-TE controller host" to make it clearer, control plane" to "BIER-TE Controller" to make it clearer, what it
what it does. does.
2.2.3. Added reference to I-D.ietf-bier-multicast-http-response 2.2.3. Added reference to I-D.ietf-bier-multicast-http-response
as an example solution. as an example solution.
2.3. clarified sentence about resetting BPs before sending copies 2.3. clarified sentence about resetting BPs before sending copies
(also forgot to mention DNR here). (also forgot to mention DNR here).
3.4. Added text saying this section will be removed unless IESG 3.4. Added text saying this section will be removed unless IESG
review finds enough redeeming value in this example given how -03 review finds enough redeeming value in this example given how -03
introduced section 1.1 with basic examples. introduced section 1.1 with basic examples.
skipping to change at page 42, line 30 skipping to change at page 43, line 47
id in BIER-TE and to give an example how to efficiently assign id in BIER-TE and to give an example how to efficiently assign
bits for a large topology requiring multiple SI. bits for a large topology requiring multiple SI.
02: Added further detailed for rings - how to support input from 02: Added further detailed for rings - how to support input from
all ring nodes. all ring nodes.
01: Fixed BFIR -> BFER for section 4.3. 01: Fixed BFIR -> BFER for section 4.3.
01: Added explanation of SI, difference to BIER ECMP, 01: Added explanation of SI, difference to BIER ECMP,
consideration for Segment Routing, unicast FRR, considerations for consideration for Segment Routing, unicast FRR, considerations for
encapsulation, explanations of BIER-TE controller host and CLI. encapsulation, explanations of BIER-TE Controller and CLI.
00: Initial version. 00: Initial version.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
skipping to change at page 43, line 11 skipping to change at page 44, line 27
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-bier-multicast-http-response] [I-D.ietf-bier-multicast-http-response]
Trossen, D., Rahman, A., Wang, C., and T. Eckert, Trossen, D., Rahman, A., Wang, C., and T. Eckert,
"Applicability of BIER Multicast Overlay for Adaptive "Applicability of BIER Multicast Overlay for Adaptive
Streaming Services", draft-ietf-bier-multicast-http- Streaming Services", draft-ietf-bier-multicast-http-
response-01 (work in progress), June 2019. response-03 (work in progress), February 2020.
[I-D.ietf-roll-ccast] [I-D.ietf-roll-ccast]
Bergmann, O., Bormann, C., Gerdes, S., and H. Chen, Bergmann, O., Bormann, C., Gerdes, S., and H. Chen,
"Constrained-Cast: Source-Routed Multicast for RPL", "Constrained-Cast: Source-Routed Multicast for RPL",
draft-ietf-roll-ccast-01 (work in progress), October 2017. draft-ietf-roll-ccast-01 (work in progress), October 2017.
[I-D.qiang-detnet-large-scale-detnet]
Qiang, L., Geng, X., Liu, B., Eckert, T., Geng, L., and G.
Li, "Large-Scale Deterministic IP Network", draft-qiang-
detnet-large-scale-detnet-05 (work in progress), September
2019.
[ICC] Reed, M., Al-Naday, M., Thomos, N., Trossen, D., [ICC] Reed, M., Al-Naday, M., Thomos, N., Trossen, D.,
Petropoulos, G., and S. Spirou, "Stateless multicast Petropoulos, G., and S. Spirou, "Stateless multicast
switching in software defined networks", IEEE switching in software defined networks", IEEE
International Conference on Communications (ICC), Kuala International Conference on Communications (ICC), Kuala
Lumpur, Malaysia, 2016, May 2016, Lumpur, Malaysia, 2016, May 2016,
<https://ieeexplore.ieee.org/document/7511036>. <https://ieeexplore.ieee.org/document/7511036>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212,
DOI 10.17487/RFC2212, September 1997,
<https://www.rfc-editor.org/info/rfc2212>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
 End of changes. 68 change blocks. 
202 lines changed or deleted 282 lines changed or added

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