< draft-ietf-bier-te-arch-06.txt   draft-ietf-bier-te-arch-07.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: August 22, 2020 Bouygues Telecom Expires: September 10, 2020 Bouygues Telecom
M. Menth M. Menth
University of Tuebingen University of Tuebingen
February 19, 2020 March 9, 2020
Path Engineering for Bit Index Explicit Replication (BIER-TE) Tree Engineering for Bit Index Explicit Replication (BIER-TE)
draft-ietf-bier-te-arch-06 draft-ietf-bier-te-arch-07
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 steered replication and forwarding for Bit Index Explicit Replication
Replication packets (RFC8279). This is called 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
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
in the bitstring. BIER-TE can leverage BIER forwarding engines with in the bitstring. BIER-TE can leverage 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 (routed) 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
strict and loose path forwarding. strict and loose path steering and replications.
BIER-TE can co-exist with BIER forwarding in the same domain, for BIER-TE can co-exist with BIER forwarding in the same domain, for
example by using separate sub-domains. In the absence of routed example by using separate BIER sub-domains. In the absence of routed
adjacencies, BIER-TE does not require a BIER routing underlay, and adjacencies, BIER-TE does not require a BIER routing underlay, and
can then be operated without requiring an IGP routing protocol. can then be operated without requiring an Interior Gateway Routing
protocol (IGP).
BIER-TE operates without explicit in-network tree-building and BIER-TE operates without explicit in-network tree-state and carries
carries the multicast distribution tree in the packet header. It can the multicast distribution tree in the packet header. It can
therefore be a good fit to support multicast path steering in Segment therefore be a good fit to support multicast path steering in Segment
Routing (SR) networks. Routing (SR) networks.
Name explanation
[RFC-editor: This section to be removed before publication.]
Explanation for name change from BIER-TE to mean "Traffic
Engineering" to BIER-TE "Tree Engineering" in WG last-call (to
benefit IETF/IESG reviewers):
This document started by calling itself BIER-TE, "Traffic
Engineering" as it is a mode of BIER specifically beneficial for
Traffic Engineering. It supports per-packet bitstring based policy
steering and replication. BIER-TE technology itself does not provide
a complete traffic engineering solution for BIER but would require
combination with other technologies for a full BIER based TE
solution, such as a PCE and queuing mechanisms to provide bandwidth
and latency reservations. It is also not the only option to build a
traffic engineering solution utilizing BIER, for example BIER trees
could be steered through IGP metric engineering, such as through
Flex-Topologies. The architecure for Traffic Engineering with either
modes of BIER (BIER-TE/BIER) is intended to be defined in a separate
document, most likely in TEAs WG.
Because the name of such an overall solution is intended to be BIER-
TE, the expansion of BIER-TE was therefore changed to name this BIER
mode "Tree Engineering", so the overall solution can be distinguished
better from its tree building/engineering method without having to
change the long time well-established abbreviation BIER-TE.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 August 22, 2020. This Internet-Draft will expire on September 10, 2020.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. BIER-TE and Traffic Engineering . . . . . . . . . . . . . 4 1.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . 5
1.2. Basic Examples . . . . . . . . . . . . . . . . . . . . . 5 1.2. BIER-TE Topology and adjacencies . . . . . . . . . . . . 8
1.3. BIER-TE Topology and adjacencies . . . . . . . . . . . . 8 1.3. Comparison with BIER . . . . . . . . . . . . . . . . . . 9
1.4. Comparison with BIER . . . . . . . . . . . . . . . . . . 9 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 9
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 9
2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 9
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
skipping to change at page 4, line 29 skipping to change at page 5, line 11
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. BIER-TE and Traffic Engineering 1.1. Basic Examples
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 8, 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.3. 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 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 consists of the BIFT of all the BFR and can also
and can also be expressed in a diagram as a graph where the edges are be expressed in a diagram as a graph where the edges are the
the adjacencies between the BFR. Adjacencies are naturally 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.4. 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 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
skipping to change at page 9, 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.5. Requirements Language 1.4. 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" and its signaling channels to the BFR, the the "BIER-TE Controller" and its signaling channels to the BFR, the
skipping to change at page 14, line 42 skipping to change at page 14, line 42
If the Routing Underlay has FRR, it will perform FRR independent of If the Routing Underlay has FRR, it will perform FRR independent of
BIER-TE for packets forwarded across a forward_routed adjacency. BIER-TE for packets forwarded across a forward_routed adjacency.
3.2.3. ECMP 3.2.3. ECMP
The ECMP mechanisms in BIER are tied to the BIER BIFT and are The ECMP mechanisms in BIER are tied to the BIER BIFT and are
therefore not directly useable with BIER-TE. The following therefore not directly useable with BIER-TE. The following
procedures describe ECMP for BIER-TE that we consider to be procedures describe ECMP for BIER-TE that we consider to be
lightweight but also well manageable. It leverages the existing lightweight but also well manageable. It leverages the existing
entropy parameter in the BIER header to keep packets of the flows on entropy parameter in the BIER header to keep packets of the flows on
the same path and it introduces a "seed" parameter to allow the same path and it introduces a "seed" parameter to allow for
engineering traffic to be polarized or randomized across multiple traffic flows to be polarized or randomized across multiple hops.
hops.
An "Equal Cost Multipath" (ECMP) adjacency has a list of two or more An "Equal Cost Multipath" (ECMP) adjacency has a list of two or more
adjacencies included in it. It copies the BIER-TE to one of those adjacencies included in it. It copies the BIER-TE to one of those
adjacencies based on the ECMP hash calculation. The BIER-TE ECMP adjacencies based on the ECMP hash calculation. The BIER-TE ECMP
hash algorithm must select the same adjacency from that list for all hash algorithm must select the same adjacency from that list for all
packets with the same "entropy" value in the BIER-TE header if the packets with the same "entropy" value in the BIER-TE header if the
same number of adjacencies and same seed are given as parameters. same number of adjacencies and same seed are given as parameters.
Further use of the seed parameter is explained below. Further use of the seed parameter is explained below.
3.2.4. Local Decap 3.2.4. Local Decap
skipping to change at page 18, line 47 skipping to change at page 18, line 47
forward_routed and local_decap. All other BIER-TE forwarding forward_routed and local_decap. All other BIER-TE forwarding
features are optional. These basic BIER-TE requirements make BIER-TE features are optional. These basic BIER-TE requirements make BIER-TE
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 steering 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 BIER-TE Controllers. Having more than traffic calculation easier for BIER-TE Controllers. Having more than
one 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.
skipping to change at page 25, line 10 skipping to change at page 25, line 10
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
when the path engineering requirement is not hop-by-hop explicit path when the path steering requirement is not hop-by-hop explicit 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
skipping to change at page 26, line 9 skipping to change at page 26, line 9
use the DNR flag as described above, but it can also be done for non- use the DNR flag as described above, but it can also be done for non-
DNR adjacencies. This section only discussses this non-DNR case. DNR adjacencies. This section only discussses this non-DNR case.
Because BP are reset after passing a BFR with an adjacency for that Because BP are reset after passing a BFR with an adjacency for that
BP, reuse of BP across multiple BFR does not introduce any problems BP, reuse of BP across multiple BFR does not introduce any problems
with duplicates or loops that do not also exist when every adjacency with duplicates or loops that do not also exist when every adjacency
has a unique BP: Instead of setting one BP in a BitString that is has a unique BP: Instead of setting one BP in a BitString that is
reused in N-adjacencies, one would get the same or worse results if reused in N-adjacencies, one would get the same or worse results if
each of these adjacencies had a unique BP and all of them where set each of these adjacencies had a unique BP and all of them where set
in the BitString. Instead, based on the case, BPs can be reused in the BitString. Instead, based on the case, BPs can be reused
without limitation, or they introduce fewer path engineering choices, without limitation, or they introduce fewer path steering choices, or
or they do not work. they do not work.
BP cannot be reused across two BFR that would need to be passed BP cannot be reused across two BFR that would need to be passed
sequentially for some path: The first BFR will reset the BP, so those sequentially for some path: The first BFR will reset the BP, so those
paths cannot be built. BP can be set across BFR that would (A) only paths cannot be built. BP can be set across BFR that would (A) only
occur across different paths or (B) across different branches of the occur across different paths or (B) across different branches of the
same tree. same tree.
An example of (A) was given in Figure 13, where BP 0:7, BP 0:8 and BP An example of (A) was given in Figure 13, where BP 0:7, BP 0:8 and BP
0:9 are each reused across multiple BFR because a single packet/path 0:9 are each reused across multiple BFR because a single packet/path
would never be able to reach more than one BFR sharing the same BP. would never be able to reach more than one BFR sharing the same BP.
Assume the example was changed: BFR1 has no ECMP adjacency for BP Assume the example was changed: BFR1 has no ECMP adjacency for BP
0:6, but instead BP 0:5 with forward_connected to BFR2 and BP 0:6 0:6, but instead BP 0:5 with forward_connected to BFR2 and BP 0:6
with forward_connected to BFR3. Packets with both BP 0:5 and BP 0:6 with forward_connected to BFR3. Packets with both BP 0:5 and BP 0:6
would now be able to reach both BFR2 and BFR3 and the still existing would now be able to reach both BFR2 and BFR3 and the still existing
re-use of BP 0:7 between BFR2 and BFR3 is a case of (B) where reuse re-use of BP 0:7 between BFR2 and BFR3 is a case of (B) where reuse
of BP is perfect because it does not limit the set of useful path of BP is perfect because it does not limit the set of useful path
choices: choices:
If instead of reusing BP 0:7, BFR3 used a separate BP 0:10 for its If instead of reusing BP 0:7, BFR3 used a separate BP 0:10 for its
ECMP adjacency, no useful additional path engineering would be ECMP adjacency, no useful additional path steering options would be
enabled. If duplicates at BFR10 where undesirable, this would be enabled. If duplicates at BFR10 where undesirable, this would be
done by not setting BP 0:5 and BP 0:6 for the same packet. If the done by not setting BP 0:5 and BP 0:6 for the same packet. If the
duplicates where desirable (e.g.: resilient transmission), the duplicates where desirable (e.g.: resilient transmission), the
additional BP 0:10 would also not render additional value. additional BP 0:10 would also not render additional value.
Reuse may also save BPs in larger topologies. Consider the topology Reuse may also save BPs in larger topologies. Consider the topology
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
path engineering: If resilient transmission is the path engineering path steering options: If resilient transmission is the path
goal, then it is likely a good optimization, if the bandwidth of each engineering goal, then it is likely a good optimization, if the
ring was to be optimized separately, it would not be a good bandwidth of each ring was to be optimized separately, it would not
limitation. be a good limitation.
4.10. Summary of BP optimizations 4.10. Summary of BP optimizations
This section reviewed a range of techniques by which a BIER-TE This section reviewed a range of techniques by which a BIER-TE
Controller can create a BIER-TE topology in a way that minimizes the Controller can create a BIER-TE topology in a way that minimizes the
number of necessary BPs. number of necessary BPs.
Without any optimization, a BIER-TE Controller would attempt to map Without any optimization, a BIER-TE Controller would attempt to map
the 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
skipping to change at page 27, 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 path engineering 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 engineering choices is Especially when the set of required path steering choices is limited
limited and the set of possible subsets of BFER that should be able and the set of possible subsets of BFER that should be able to
to receive traffic is limited, further optimizations of BP are receive traffic is limited, further optimizations of BP are possible.
possible. The hub & spoke optimization is a simple example of such The hub & spoke optimization is a simple example of such traffic
traffic pattern dependent optimizations. pattern dependent optimizations.
5. Avoiding loops and duplicates 5. Avoiding loops and duplicates
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.
skipping to change at page 32, 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 path engineering) efficient replication (and for BIER-TE desirable path steering) for
for different subsets of BFIR/BFER. 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 path engineering on the desire of the operator to allow for explicit path steeering
across every single hop (which requires more bits), or reducing the across every single hop (which requires more bits), or reducing the
number of required bits by exploiting optimizations such as unicast number of required bits by exploiting optimizations such as unicast
(forward_route), ECMP or flood (DNR) over "uninteresting" sub-parts (forward_route), ECMP or flood (DNR) over "uninteresting" sub-parts
of the topology - e.g. parts where different trees do not need to of the topology - e.g. parts where different trees do not need to
take different paths due to traffic-engineering reasons. take different paths due to path steering 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 path steering 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 has to determine a BFR-id for each the operator or BIER-TE Controller has to determine a BFR-id for each
skipping to change at page 34, line 25 skipping to change at page 34, line 25
then independently calculate the SI:bitstring for all desired BFER by then independently calculate the SI:bitstring for all desired 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 API with the list of required BFER-id and get a BIER-TE Controller API with the list of required BFER-id and get
the required bitstring back. Whenever the set of BFER-id changes, the required bitstring back. Whenever the set of BFER-id 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 resource consumption by other traffic as part of traffic
Interactions between such BFIR applications and the BIER-TE engineering goals (e.g.: re-optimization of lower priority traffic
flows). Interactions between such BFIR applications and the BIER-TE
Controller 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.
skipping to change at page 37, line 16 skipping to change at page 37, line 16
same forward_routed(BFRja), and bib with forward_routed(BFRjb). On same forward_routed(BFRja), and bib with forward_routed(BFRjb). On
all area edge BFR, bea in BIFT:SI=k is populated with all area edge BFR, bea in BIFT:SI=k is populated with
forward_routed(BFRka) and beb in BIFT:SI=k with forward_routed(BFRka) and beb in BIFT:SI=k with
forward_routed(BFRkb). forward_routed(BFRkb).
For BIER-TE forwarding of a packet to some subset of BFER across all For BIER-TE forwarding of a packet to some subset of BFER across all
areas, a BFIR would create at most 6 copies, with SI=1...SI=6, In areas, a BFIR would create at most 6 copies, with SI=1...SI=6, In
each packet, the bits indicate bits for topology and BFER in that each packet, the bits indicate bits for topology and BFER in that
topology plus the four bits to indicate whether to pass this packet topology plus the four bits to indicate whether to pass this packet
via the ingress area a or b border BFR and the egress area a or b via the ingress area a or b border BFR and the egress area a or b
border BFR, therefore allowing path engineering for those two border BFR, therefore allowing path steering for those two "unicast"
"unicast" legs: 1) BFIR to ingress are edge and 2) core to egress legs: 1) BFIR to ingress are edge and 2) core to egress area edge.
area edge. Replication only happens inside the egress areas. For Replication only happens inside the egress areas. For BFER in the
BFER in the same area as in the BFIR, these four bits are not used. same area as in the BFIR, these four bits are not used.
7.6. Summary 7.6. Summary
BIER-TE can like BIER support multiple SI within a sub-domain to BIER-TE can like BIER support multiple SI within a sub-domain to
allow re-using the concept of BFR-id and therefore minimize BIER-TE allow re-using the concept of BFR-id and therefore minimize BIER-TE
specific functions in underlay routing, flow overlay methods and BIER specific functions in underlay routing, flow overlay methods and BIER
headers. headers.
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 8. BIER-TE and Segment Routing
SR aims to enable lightweight path engineering via loose source SR aims to enable lightweight path steering via loose source routing.
routing. Compared to its more heavy-weight predecessor RSVP-TE, SR Compared to its more heavy-weight predecessor RSVP-TE, SR does for
does for example not require per-path signaling to each of these example not 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 39, line 12 skipping to change at page 39, line 12
for their distribution, so these are not attack vectors against BIER- for their distribution, so these are not attack vectors against BIER-
TE. TE.
10. IANA Considerations 10. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
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, Lou Berger and Jeffrey Zhang
extensive review 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:
06: Concern by Lou berger re. BIER-TE as full traffic engineering 07: Further reworking text for Lou.
Renamed BIER-PE to BIER-TE standing for "Tree Engineering" after
votes from BIER WG.
Removed section 1.1 (introduced by version 06) because not
considered necessary in this doc by Lou (for framework doc).
Added [RFC editor pls. remove] Section to explain name change to
future reviewers.
06: Concern by Lou Berger re. BIER-TE as full traffic engineering
solution. solution.
Changed title "Traffic Engineering" to "Path Engineering" Changed title "Traffic Engineering" to "Path Engineering"
Added intro section of relationship BIER-TE to traffic Added intro section of relationship BIER-PE to traffic
engineering. engineering.
Changed "traffic engineering" term in text" to "path engineering", Changed "traffic engineering" term in text" to "path engineering",
where appropriate where appropriate
Other: Other:
Shortened "BIER-TE Controller Host" to "BIER-TE Controller". Shortened "BIER-TE Controller Host" to "BIER-TE Controller".
Fixed up all instances of controller to do this. Fixed up all instances of controller to do this.
skipping to change at page 44, line 34 skipping to change at page 44, line 45
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-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.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Authors' Addresses Authors' Addresses
Toerless Eckert (editor) Toerless Eckert (editor)
Futurewei Technologies Inc. Futurewei Technologies Inc.
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara 95050
USA USA
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
 End of changes. 37 change blocks. 
134 lines changed or deleted 102 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/