< draft-ietf-bier-te-arch-08.txt   draft-ietf-bier-te-arch-09.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: January 14, 2021 Bouygues Telecom Expires: May 3, 2021 Bouygues Telecom
M. Menth M. Menth
University of Tuebingen University of Tuebingen
July 13, 2020 Oct 30, 2020
Tree Engineering for Bit Index Explicit Replication (BIER-TE) Tree Engineering for Bit Index Explicit Replication (BIER-TE)
draft-ietf-bier-te-arch-08 draft-ietf-bier-te-arch-09
Abstract Abstract
This memo introduces per-packet stateless strict and loose path This memo introduces per-packet stateless strict and loose path
steered replication and forwarding for Bit Index Explicit Replication steered replication and forwarding for Bit Index Explicit Replication
packets (RFC8279). This is called BIER Tree Engineering (BIER-TE). packets (RFC8279). This is called BIER Tree Engineering (BIER-TE).
BIER-TE can be used as a path steering mechanism in future Traffic BIER-TE can be used as a path steering mechanism in future Traffic
Engineering solutions for BIER (BIER-TE). Engineering solutions for BIER (BIER-TE).
BIER-TE leverages RFC8279 and extends it with a new semantic for bits BIER-TE leverages RFC8279 and extends it with a new semantic for bits
skipping to change at page 2, line 48 skipping to change at page 2, line 48
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 January 14, 2021. This Internet-Draft will expire on May 3, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . 5 1.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . 5
1.2. BIER-TE Topology and adjacencies . . . . . . . . . . . . 8 1.2. BIER-TE Topology and adjacencies . . . . . . . . . . . . 8
1.3. Comparison with BIER . . . . . . . . . . . . . . . . . . 9 1.3. Comparison with BIER . . . . . . . . . . . . . . . . . . 9
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 9 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 9
2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. The Multicast Flow Overlay . . . . . . . . . . . . . . . 10 2.1. The Multicast Flow Overlay . . . . . . . . . . . . . . . 10
2.2. The BIER-TE Controller . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 11 network topology . . . . . . . . . . . . . . . . . . 11
2.2.2. Changes in the network topology . . . . . . . . . . . 11 2.2.2. Changes in the network topology . . . . . . . . . . . 11
2.2.3. Set up per-multicast flow BIER-TE state . . . . . . . 11 2.2.3. Set up per-multicast flow BIER-TE state . . . . . . . 11
2.2.4. Link/Node Failures and Recovery . . . . . . . . . . . 12 2.2.4. Link/Node Failures and Recovery . . . . . . . . . . . 12
2.3. The BIER-TE Forwarding Layer . . . . . . . . . . . . . . 12 2.3. The BIER-TE Forwarding Layer . . . . . . . . . . . . . . 12
2.4. The Routing Underlay . . . . . . . . . . . . . . . . . . 12 2.4. The Routing Underlay . . . . . . . . . . . . . . . . . . 12
2.5. Traffic Engineering Considerations . . . . . . . . . . . 12 2.5. Traffic Engineering Considerations . . . . . . . . . . . 13
3. BIER-TE Forwarding . . . . . . . . . . . . . . . . . . . . . 13 3. BIER-TE Forwarding . . . . . . . . . . . . . . . . . . . . . 14
3.1. The Bit Index Forwarding Table (BIFT) . . . . . . . . . . 13 3.1. The Bit Index Forwarding Table (BIFT) . . . . . . . . . . 14
3.2. Adjacency Types . . . . . . . . . . . . . . . . . . . . . 14 3.2. Adjacency Types . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. Forward Connected . . . . . . . . . . . . . . . . . . 15 3.2.1. Forward Connected . . . . . . . . . . . . . . . . . . 15
3.2.2. Forward Routed . . . . . . . . . . . . . . . . . . . 15 3.2.2. Forward Routed . . . . . . . . . . . . . . . . . . . 16
3.2.3. ECMP . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.3. ECMP . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4. Local Decap . . . . . . . . . . . . . . . . . . . . . 16 3.2.4. Local Decap . . . . . . . . . . . . . . . . . . . . . 16
3.3. Encapsulation considerations . . . . . . . . . . . . . . 16 3.3. Encapsulation considerations . . . . . . . . . . . . . . 17
3.4. Basic BIER-TE Forwarding Example . . . . . . . . . . . . 16 3.4. Basic BIER-TE Forwarding Example . . . . . . . . . . . . 17
3.5. Forwarding comparison with BIER . . . . . . . . . . . . . 19 3.5. Forwarding comparison with BIER . . . . . . . . . . . . . 19
3.6. Requirements . . . . . . . . . . . . . . . . . . . . . . 19 3.6. Requirements . . . . . . . . . . . . . . . . . . . . . . 20
4. BIER-TE Controller BitPosition Assignments . . . . . . . . . 20 4. BIER-TE Controller BitPosition Assignments . . . . . . . . . 20
4.1. P2P Links . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. P2P Links . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. BFER . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2. BFER . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Leaf BFERs . . . . . . . . . . . . . . . . . . . . . . . 20 4.3. Leaf BFERs . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. LANs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4. LANs . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5. Hub and Spoke . . . . . . . . . . . . . . . . . . . . . . 22 4.5. Hub and Spoke . . . . . . . . . . . . . . . . . . . . . . 22
4.6. Rings . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.6. Rings . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7. Equal Cost MultiPath (ECMP) . . . . . . . . . . . . . . . 23 4.7. Equal Cost MultiPath (ECMP) . . . . . . . . . . . . . . . 24
4.8. Routed adjacencies . . . . . . . . . . . . . . . . . . . 26 4.8. Routed adjacencies . . . . . . . . . . . . . . . . . . . 26
4.8.1. Reducing BitPositions . . . . . . . . . . . . . . . . 26 4.8.1. Reducing BitPositions . . . . . . . . . . . . . . . . 26
4.8.2. Supporting nodes without BIER-TE . . . . . . . . . . 26 4.8.2. Supporting nodes without BIER-TE . . . . . . . . . . 27
4.9. Reuse of BitPositions (without DNR) . . . . . . . . . . . 26 4.9. Reuse of BitPositions (without DNR) . . . . . . . . . . . 27
4.10. Summary of BP optimizations . . . . . . . . . . . . . . . 28 4.10. Summary of BP optimizations . . . . . . . . . . . . . . . 28
5. Avoiding loops and duplicates . . . . . . . . . . . . . . . . 29 5. Avoiding duplicates and loops . . . . . . . . . . . . . . . . 29
5.1. Loops . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1. Loops . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. Duplicates . . . . . . . . . . . . . . . . . . . . . . . 29 5.2. Duplicates . . . . . . . . . . . . . . . . . . . . . . . 30
6. BIER-TE Forwarding Pseudocode . . . . . . . . . . . . . . . . 29 6. BIER-TE Forwarding Pseudocode . . . . . . . . . . . . . . . . 30
7. Managing SI, subdomains and BFR-ids . . . . . . . . . . . . . 32 7. Managing SI, subdomains and BFR-ids . . . . . . . . . . . . . 33
7.1. Why SI and sub-domains . . . . . . . . . . . . . . . . . 33 7.1. Why SI and sub-domains . . . . . . . . . . . . . . . . . 34
7.2. Bit assignment comparison BIER and BIER-TE . . . . . . . 34 7.2. Bit assignment comparison BIER and BIER-TE . . . . . . . 35
7.3. Using BFR-id with BIER-TE . . . . . . . . . . . . . . . . 34 7.3. Using BFR-id with BIER-TE . . . . . . . . . . . . . . . . 35
7.4. Assigning BFR-ids for BIER-TE . . . . . . . . . . . . . . 35 7.4. Assigning BFR-ids for BIER-TE . . . . . . . . . . . . . . 36
7.5. Example bit allocations . . . . . . . . . . . . . . . . . 36 7.5. Example bit allocations . . . . . . . . . . . . . . . . . 37
7.5.1. With BIER . . . . . . . . . . . . . . . . . . . . . . 36 7.5.1. With BIER . . . . . . . . . . . . . . . . . . . . . . 37
7.5.2. With BIER-TE . . . . . . . . . . . . . . . . . . . . 37 7.5.2. With BIER-TE . . . . . . . . . . . . . . . . . . . . 38
7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. BIER-TE and Segment Routing . . . . . . . . . . . . . . . . . 38 8. BIER-TE and Segment Routing . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 40 12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 47
13.2. Informative References . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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
BIER-TE Topology. Other BPs are left without adjacency. The BFR BIER-TE Topology. Other BPs are left without adjacency. The BFR
replicate and forwards BIER packets to adjacent BPs that are set in replicate and forwards BIER packets to adjacent BPs that are set in
the packet. BPs are normally also reset upon forwarding to avoid the packet. BPs are normally also reset upon forwarding to avoid
duplicates and loops. This is detailed further below. duplicates and loops. This is detailed further below.
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
represent leaves or edges of the intended delivery tree. Bloom [Bloom70] to represent leaves or edges of the intended delivery tree.
filters in general can support larger trees/topologies with fewer
addressing bits than explicit bitstrings, but they introduce the Bloom filters in general can support larger trees/topologies with
heuristic risk of false positives and cannot reset bits in the fewer addressing bits than explicit bitstrings, but they introduce
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. 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:
skipping to change at page 7, line 20 skipping to change at page 7, line 20
because of p8, BFR4 to BFR5 because of p10 and BFR5 to BFR6 because because of p8, BFR4 to BFR5 because of p10 and BFR5 to BFR6 because
of p12. p12 also makes BFR6 receive and decapsulate the packet. of p12. p12 also makes BFR6 receive and decapsulate the packet.
To send in addition to BFR6 via BFR4 also a copy to BFR3, the To send in addition to BFR6 via BFR4 also a copy to BFR3, the
bitstring needs to be (p2,p5,p8,p10,p12,p13). When this packet is bitstring needs to be (p2,p5,p8,p10,p12,p13). When this packet is
examined by BFR2, p5 causes one copy to be sent to BFR3 and p8 one examined by BFR2, p5 causes one copy to be sent to BFR3 and p8 one
copy to BFR4. When BFR3 receives the packet, p13 will cause it to copy to BFR4. When BFR3 receives the packet, p13 will cause it to
receive and decapsulate the packet. receive and decapsulate the packet.
If instead the bitstring was (p2,p6,p8,p10,p12,p13), the packet would If instead the bitstring was (p2,p6,p8,p10,p12,p13), the packet would
be copied by BFR5 towards BFR3 because p6 instead of BFR2 to BFR5 be copied by BFR5 towards BFR3 because of p6 instead of being copied
because of p6 in the prior case. This is showing the ability of the by BFR2 to BFR3 because of p5 in the prior case. This is showing the
shown BIER-TE Topology to make the traffic pass across any possible ability of the shown BIER-TE Topology to make the traffic pass across
path and be replicated where desired. any possible path and be replicated where desired.
BIER-TE has various options to minimize BP assignments, many of which BIER-TE has various options to minimize BP assignments, many of which
are based on assumptions about the required multicast traffic paths are based on assumptions about the required multicast traffic paths
and bandwidth consumption in the network. and bandwidth consumption in the network.
The following picture shows a modified example, in which Rtr2 and The following picture shows a modified example, in which Rtr2 and
Rtr5 are assumed not to support BIER-TE, so traffic has to be unicast Rtr5 are assumed not to support BIER-TE, so traffic has to be unicast
encapsulated across them. Unicast tunneling of BIER-TE packets can encapsulated across them. Unicast tunneling of BIER-TE packets can
leverage any feasible mechanism such as MPLS or IP, these leverage any feasible mechanism such as MPLS or IP, these
encapsulations are out of scope of this document. To emphasize non- encapsulations are out of scope of this document. To emphasize non-
skipping to change at page 8, line 37 skipping to change at page 8, line 37
BFR6: p5 -> local_decap BFR6: p5 -> local_decap
p6 -> local_decap p6 -> local_decap
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 from BFR3 to BFR6 uses (p1,p2,p3,p4,p5). A
(p1,p2,p3,p4,p6), or via BFR6 (p2,p3,p4,p6,p7) or (p1.p3,p4,p5,p8). packet from BFR1 to BFR3,BFR4 and from BFR4 to BFR uses
(p1,p2,p3,p4,p6). A packet from BFR1 to BFR4, and from BFR4 to BFR6
and from BFR6 to BFR3 uses (p2,p3,p4,p6,p7). A packet from BFR1 to
BFR3, and from BFR3 to BFR6 and from BFR6 to BFR4 uses
(p1,p3,p4,p5,p8).
1.2. BIER-TE Topology and adjacencies 1.2. 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 compared to BIER is the BIER-TE
should happens and how to minimize the required BP for segments is - topology as introduced through the two examples in Section 1.1. It
as shown in these two examples - the BIER-TE topology. is used to control where replication can or should happen and how to
minimize the required number of BP for adjacencies.
The BIER-TE Topology consists of the BIFT of all the BFR and can also The BIER-TE Topology consists of the BIFT of all the BFR and can also
be expressed in a diagram as a graph where the edges are the be expressed as a directed graph where the edges are the adjacencies
adjacencies between the BFR. Adjacencies are naturally between the BFR labelled with the BP used for the adjacency.
unidirectional. BP can be reused across multiple adjacencies as long Adjacencies are naturally unidirectional. BP can be reused across
as this does not lead to undesired duplicates or loops as explained multiple adjacencies as long as this does not lead to undesired
further down in the text. duplicates or loops as explained 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.3. 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. explicit paths calculated 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 12, line 32 skipping to change at page 12, line 37
TE Controller. For every BP that is set in the BitString, and that TE Controller. For every BP that is set in the BitString, and that
has one or more adjacencies in the BIFT, a copy is made according to has one or more adjacencies in the BIFT, a copy is made according to
the type of adjacencies for that BP in the BIFT. Before sending any the type of adjacencies for that BP in the BIFT. Before sending any
copy, the BFR resets all BP in the BitString of the packet for which copy, the BFR resets all BP in the BitString of the packet for which
the BFR has one or more adjacencies in the BIFT, except when the the BFR has one or more adjacencies in the BIFT, except when the
adjacency indicates "DoNotReset" (DNR, see Section 3.2.1). This is adjacency indicates "DoNotReset" (DNR, see 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 For forward_connected adjacencies, BIER-TE is sending BIER packets to
neighbors as L2 (unicasted) BIER packets without requiring a routing directly connected BIER-TE neighbors as L2 (unicasted) BIER packets
underlay. BIER-TE forwarding uses the Routing underlay for without requiring a routing underlay. For forward_routed
forward_routed adjacencies which copy BIER-TE packets to not- adjacencies, BIER-TE forwarding encapsulates a copy of the BIER
directly-connected BFRs (see below for adjacency definitions). packet so that it can be delivered by the forwarding plane of the
routing underlay to the routable destination address indicated in the
adjacency. See Section 3.2.2 for the adjacency definition.
BIER relies on the routing underlay to calculate paths towards BFER
and derive next-hop BFR adjacencies for those paths. This commonly
relies on BIER specific extensions to the routing protocols of the
routing underlay but may also be established by a controller. In
BIER-TE, the next-hops of a packet are determined by the bitstring
through the BIER-TE Controller established adjacencies on the BFR for
the BPs of the bitsring. There is thus no need for BFER specific
routing underlay extensions to forward BIER packets with BIER-TE
semantics.
BIER encapsulations may have BFER independent extensions in the
routing underlay, such as the label range for BIER packets in the
BIER over MPLS encapsulation ([RFC8296]). These BIER specific
functions of the routing underlay are equally useable by BIER-TE.
Alternatively, these encapsulation parameters can be provisioned by
the BIER-TE controller into the forward_connected or forward_routed
adjacencies directly without relying on a routing underlay.
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
forwarding plane needs to receive fast adjacency up/down forwarding plane needs to receive fast adjacency up/down
notifications: Link up/down or neighbor up/down, e.g. from BFD. notifications: Link up/down or neighbor up/down, e.g. from BFD.
Providing these notifications is considered to be part of the routing Providing these notifications is considered to be part of the routing
underlay in this document. underlay in this document.
2.5. Traffic Engineering Considerations 2.5. Traffic Engineering Considerations
Traffic Engineering ([I-D.dt-teas-rfc3272bis]) provides performance Traffic Engineering ([I-D.ietf-teas-rfc3272bis]) provides performance
optimization of operational IP networks while utilizing network optimization of operational IP networks while utilizing network
resources economically and reliably. The key elements needed to resources economically and reliably. The key elements needed to
effect TE are policy, path steering and resource management. These effect TE are policy, path steering and resource management. These
elements require support at the control/controller level and within elements require support at the control/controller level and within
the forwarding plane. the forwarding plane.
Policy decisions are made within the BIER-TE control plane, i.e., Policy decisions are made within the BIER-TE control plane, i.e.,
within BIER-TE Controllers. Controllers use policy when composing within BIER-TE Controllers. Controllers use policy when composing
BitStrings (BFR flow state) and BFR BIFT state. The mapping of user/ BitStrings (BFR flow state) and BFR BIFT state. The mapping of user/
IP traffic to specific BitStrings/BIER-TE flows is made based on IP traffic to specific BitStrings/BIER-TE flows is made based on
policy. The specifics details of BIER-TE policies and how a policy. The specifics details of BIER-TE policies and how a
controller uses such are out of scope of this document. controller uses such are out of scope of this document.
Path steering is supported via the definition of a BitString. Path steering is supported via the definition of a BitString.
BitStrings used in BIER-TE are composed based on policy and resource BitStrings used in BIER-TE are composed based on policy and resource
management considerations. When composing BIER-TE BitStrings, a management considerations. When composing BIER-TE BitStrings, a
Controller MUST take into account the resources available at each BFR Controller MUST take into account the resources available at each BFR
and for each BP when it is providing congestion loss free services and for each BP when it is providing congestion loss free services
such as for Rate Controlled Service Disciplines (RCSD). Resource such as Rate Controlled Service Disciplines [RCSD94]. Resource
availability could be provided for example via routing protocol availability could be provided for example via routing protocol
information, but may also be obtained via a BIER-TE control protocol. information, but may also be obtained via a BIER-TE control protocol
The resource usage of the BIER-TE traffic admitted by the BIER-TE such as Netconf or any other protocol commonly used by a PCE to
controller can be solely tracked on the BIER-TE Controller based on understand the resources of the network it operates on. The resource
local accounting as long as no forward_routed adjacencies are used usage of the BIER-TE traffic admitted by the BIER-TE controller can
(see below for definition of forward_routed adjacencies). When be solely tracked on the BIER-TE Controller based on local accounting
as long as no forward_routed adjacencies are used (see Section 3.2.1
for the definition of forward_routed adjacencies). When
forward_routed adjacencies are used, the paths selected by the forward_routed adjacencies are used, the paths selected by the
underlying routing protocol need to be tracked as well. underlying routing protocol need to be tracked as well.
Resource management has implications on the forwarding plane beyond Resource management has implications on the forwarding plane beyond
the BIER-TE defined steering of packets. This includes allocation of the BIER-TE defined steering of packets. This includes allocation of
buffers to guarantee the worst case requirements of admitted RCSD buffers to guarantee the worst case requirements of admitted RCSD
trafic and potential policing and/or rate-shaping mechanisms, trafic and potential policing and/or rate-shaping mechanisms,
typically done via various forms of queuing. This level of resource typically done via various forms of queuing. This level of resource
control, while optional, is important in networks that wish to control, while optional, is important in networks that wish to
support congestion management policies to control or regulate the support congestion management policies to control or regulate the
skipping to change at page 14, line 46 skipping to change at page 15, line 38
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 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 BIER-TE Controller does not have to have the same adjacencies. the BIER-TE Controller does not have to have the same adjacencies.
This is up to the BIER-TE Controller. BPs for p2p links are one case This is up to the BIER-TE Controller. BPs for p2p links are one case
(see below). (see below).
{VRF}indicates the Virtual Routing and Forwarding context into which
the BIER payload is to be delivered. This is optional and depends on
the multicast flow overlay.
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.
Packets sent to an adjacency with "DoNotReset" (DNR) set in the BIFT Packets sent to an adjacency with "DoNotReset" (DNR) set in the BIFT
will not have the BitPosition for that adjacency reset when the BFR will not have the BitPosition for that adjacency reset when the BFR
creates a copy for it. The BitPosition will still be reset for creates a copy for it. The BitPosition will still be reset for
skipping to change at page 16, line 38 skipping to change at page 17, line 29
only the forwarding model (BIER/BIER-TE) would have to be defined per only the forwarding model (BIER/BIER-TE) would have to be defined per
subdomain. If it is desirable to support both BIER and BIER-TE subdomain. If it is desirable to support both BIER and BIER-TE
forwarding in the same subdomain, then additional labels would need forwarding in the same subdomain, then additional labels would need
to be assigned for BIER-TE forwarding. to be assigned for BIER-TE forwarding.
"forward_routed" requires an encapsulation permitting to unicast "forward_routed" requires an encapsulation permitting to unicast
BIER-TE packets to a specific interface address on a target BFR. BIER-TE packets to a specific interface address on a target BFR.
With MPLS encapsulation, this can simply be done via a label stack With MPLS encapsulation, this can simply be done via a label stack
with that addresses label as the top label - followed by the label with that addresses label as the top label - followed by the label
assigned to (SI,subdomain) - and if necessary (see above) BIER-TE. assigned to (SI,subdomain) - and if necessary (see above) BIER-TE.
With non-MPLS encapsulation, some form of IP tunneling (IP in IP, With non-MPLS encapsulation, some form of IP encapsulation would be
LISP, GRE) would be required. required (for example IP/GRE).
The encapsulation used for "forward_routed" adjacencies can equally The encapsulation used for "forward_routed" adjacencies can equally
support existing advanced adjacency information such as "loose source support existing advanced adjacency information such as "loose source
routes" via e.g. MPLS label stacks or appropriate header extensions routes" via e.g. MPLS label stacks or appropriate header extensions
(e.g. for IPv6). (e.g. for IPv6).
3.4. Basic BIER-TE Forwarding Example 3.4. Basic BIER-TE Forwarding Example
[RFC Editor: remove this section.] [RFC Editor: remove this section.]
skipping to change at page 25, line 45 skipping to change at page 26, line 32
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 BIER-TE identifiers. The solutions chosen 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
BIER-TE Controller to choose the seed, independent of such seed BIER-TE Controller to choose the seed, independent of such seed
source that the BIER-TE Controller may not be able to control well, source that the BIER-TE Controller may not be able to control well,
and even calculate 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
skipping to change at page 29, line 5 skipping to change at page 29, line 45
consecutive in paths, but depending on scenario, this may limit consecutive in paths, but depending on scenario, this may limit
the feasible path steering options (Section 4.9). the feasible path steering 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 steering choices is limited Especially when the set of required path steering choices is limited
and the set of possible subsets of BFER that should be able to and the set of possible subsets of BFER that should be able to
receive traffic is limited, further optimizations of BP are possible. receive traffic is limited, further optimizations of BP are possible.
The hub & spoke optimization is a simple example of such traffic The hub & spoke optimization is a simple example of such traffic
pattern dependent optimizations. pattern dependent optimizations.
5. Avoiding loops and duplicates 5. Avoiding duplicates and loops
5.1. Loops 5.1. Loops
Whenever BIER-TE creates a copy of a packet, the BitString of that Whenever BIER-TE creates a copy of a packet, the BitString of that
copy will have all BitPositions cleared that are associated with copy will have all BitPositions cleared that are associated with
adjacencies on the BFR. This inhibits looping of packets. The only adjacencies on the BFR. This inhibits looping of packets. The only
exception are adjacencies with DNR set. exception are adjacencies with DNR set.
With DNR set, looping can happen. Consider in the ring picture that With DNR set, looping can happen. Consider in the ring picture that
link L4 from BFR3 is plugged into the L1 interface of BFRa. This link L4 from BFR3 is plugged into the L1 interface of BFRa. This
skipping to change at page 40, line 19 skipping to change at page 41, 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, Lou Berger and Jeffrey Zhang Neale Ranns, Dirk Trossen, Sandy Zheng, Lou Berger and Jeffrey Zhang
for their reviews and suggestions. for their reviews 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:
09: Incorporated fixes for feedback from Shepherd (Xuesong Geng).
Added references for Bloom Filders and Rate Controlled Service
Disciplines.
1.1 Fixed numbering of example 1 topology explanation. Improved
language on second example (less abbreviating to avoid confusion
about meaning).
1.2 Improved explanation of BIER-TE topology, fixed terminology of
graphs (BIER-TE topology is a directed graph where the edges are
the adjacencies).
2.4 Fixed and amended routing underlay explanations: detailled why
no need for BFER routing underlay routing protocol etensions, but
potential to re-use BIER routing underlay routing protocol
extensions for non-BFER related extensions.
3.1 Added explanation for VRF and its use in adjacencies.
08: Incorporated (with hopefully acceptable fixes) for Lou 08: Incorporated (with hopefully acceptable fixes) for Lou
suggested section 2.5, TE considerations. suggested section 2.5, TE considerations.
Fixes are primarily to the point to a) emphasize that BIER-TE does Fixes are primarily to the point to a) emphasize that BIER-TE does
not depend on the routing underlay unless forward_routed not depend on the routing underlay unless forward_routed
adjacencies are used, and b) that the allocation and tracking of adjacencies are used, and b) that the allocation and tracking of
resources does not explicitly have to be tied to BPs, because they resources does not explicitly have to be tied to BPs, because they
are just steering labels. Instead, it would ideally come from are just steering labels. Instead, it would ideally come from
per-hop resource management that can be maintained only via local per-hop resource management that can be maintained only via local
accounting in the controller. accounting in the controller.
skipping to change at page 45, line 44 skipping to change at page 47, line 23
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
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.dt-teas-rfc3272bis] [Bloom70] Bloom, B., "Space/time trade-offs in hash coding with
Farrel, A., "Overview and Principles of Internet Traffic allowable errors", Comm. ACM 13(7):422-6, July 1970.
Engineering", draft-dt-teas-rfc3272bis-11 (work in
progress), May 2020.
[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-03 (work in progress), February 2020. response-04 (work in progress), July 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] [I-D.ietf-teas-rfc3272bis]
Qiang, L., Geng, X., Liu, B., Eckert, T., Geng, L., and G. Farrel, A., "Overview and Principles of Internet Traffic
Li, "Large-Scale Deterministic IP Network", draft-qiang- Engineering", draft-ietf-teas-rfc3272bis-01 (work in
detnet-large-scale-detnet-05 (work in progress), September progress), July 2020.
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>.
[RCSD94] Zhang, H. and D. Domenico, "Rate-Controlled Service
Disciplines", Journal of High-Speed Networks, 1994, May
1994, <https://dl.acm.org/doi/10.5555/2692227.2692232>.
[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>.
Authors' Addresses Authors' Addresses
Toerless Eckert (editor) Toerless Eckert (editor)
Futurewei Technologies Inc. Futurewei Technologies Inc.
2330 Central Expy 2330 Central Expy
 End of changes. 35 change blocks. 
90 lines changed or deleted 144 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/