< draft-ietf-bier-te-arch-02.txt   draft-ietf-bier-te-arch-03.txt >
Network Working Group T. Eckert, Ed. Network Working Group T. Eckert, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track G. Cauchie Intended status: Standards Track G. Cauchie
Expires: November 15, 2019 Bouygues Telecom Expires: January 9, 2020 Bouygues Telecom
W. Braun
M. Menth M. Menth
University of Tuebingen University of Tuebingen
May 14, 2019 July 8, 2019
Traffic Engineering for Bit Index Explicit Replication (BIER-TE) Traffic Engineering for Bit Index Explicit Replication (BIER-TE)
draft-ietf-bier-te-arch-02 draft-ietf-bier-te-arch-03
Abstract Abstract
This document proposes an architecture for BIER-TE: Traffic This memo introduces per-packet stateless strict and loose path
Engineering for Bit Index Explicit Replication (BIER). engineered replication and forwarding for Bit Index Explicit
Replication packets ([RFC8279]). This is called BIER-TE.
BIER-TE shares part of its architecture with BIER as described in BIER-TE leverages the BIER architecture ([RFC8279]) and extends it
[RFC8279]. It also proposes to share the packet format with BIER. with a new semantic for bits in the bitstring. BIER-TE can leverage
BIER forwarding engines with little or no changes.
BIER-TE forwards and replicates packets like BIER based on a In BIER, the BitPositions (BP) of the packets bitstring indicate BIER
BitString in the packet header but it does not require an IGP. It Forwarding Egress Routers (BFER), and hop-by-hop forwarding uses a
does support traffic engineering by explicit hop-by-hop forwarding Routing Underlay such as an IGP.
and loose hop forwarding of packets. It does support Fast ReRoute
(FRR) for link and node protection and incremental deployment. In BIER-TE, BitPositions indicate adjacencies. The BIFT of each BFR
Because BIER-TE like BIER operates without explicit in-network tree- are only populated with BPs that are adjacent to the BFR in the BIER-
building but also supports traffic engineering, it is more similar to TE topology. The BIER-TE topology can consist of layer 2 or remote
SR than RSVP-TE. (route) adjacencies. The BFR then replicates and forwards BIER
packets to those adjacencies. This results in the aforementioned
strict and loose path forwarding.
BIER-TE can co-exist with BIER forwarding in the same domain, for
example by using seperate sub-domains. In the absence of routed
adjacencies, BIER-TE does not require a BIER routing underlay, and
can then be operated without requiring an IGP routing protocol.
BIER-TE operates without explicit in-network tree-building and
carries the multicast distribution tree in the packet header. It can
therefore be a good fit to support multicast path steering in Segment
Routing (SR) networks.
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 November 15, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. BIER-TE Topology and adjacencies . . . . . . . . . . . . 7
2. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Comparison with BIER . . . . . . . . . . . . . . . . . . 8
2.1. The Multicast Flow Overlay . . . . . . . . . . . . . . . 5 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 8
2.2. The BIER-TE Controller Host . . . . . . . . . . . . . . . 5 2. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. The Multicast Flow Overlay . . . . . . . . . . . . . . . 9
2.2. The BIER-TE Controller Host . . . . . . . . . . . . . . . 9
2.2.1. Assignment of BitPositions to adjacencies of the 2.2.1. Assignment of BitPositions to adjacencies of the
network topology . . . . . . . . . . . . . . . . . . 6 network topology . . . . . . . . . . . . . . . . . . 10
2.2.2. Changes in the network topology . . . . . . . . . . . 6 2.2.2. Changes in the network topology . . . . . . . . . . . 10
2.2.3. Set up per-multicast flow BIER-TE state . . . . . . . 6 2.2.3. Set up per-multicast flow BIER-TE state . . . . . . . 10
2.2.4. Link/Node Failures and Recovery . . . . . . . . . . . 6 2.2.4. Link/Node Failures and Recovery . . . . . . . . . . . 10
2.3. The BIER-TE Forwarding Layer . . . . . . . . . . . . . . 7 2.3. The BIER-TE Forwarding Layer . . . . . . . . . . . . . . 11
2.4. The Routing Underlay . . . . . . . . . . . . . . . . . . 7 2.4. The Routing Underlay . . . . . . . . . . . . . . . . . . 11
3. BIER-TE Forwarding . . . . . . . . . . . . . . . . . . . . . 7 3. BIER-TE Forwarding . . . . . . . . . . . . . . . . . . . . . 11
3.1. The Bit Index Forwarding Table (BIFT) . . . . . . . . . . 7 3.1. The Bit Index Forwarding Table (BIFT) . . . . . . . . . . 11
3.2. Adjacency Types . . . . . . . . . . . . . . . . . . . . . 8 3.2. Adjacency Types . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Forward Connected . . . . . . . . . . . . . . . . . . 8 3.2.1. Forward Connected . . . . . . . . . . . . . . . . . . 12
3.2.2. Forward Routed . . . . . . . . . . . . . . . . . . . 9 3.2.2. Forward Routed . . . . . . . . . . . . . . . . . . . 13
3.2.3. ECMP . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. ECMP . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. Local Decap . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. Local Decap . . . . . . . . . . . . . . . . . . . . . 13
3.3. Encapsulation considerations . . . . . . . . . . . . . . 10 3.3. Encapsulation considerations . . . . . . . . . . . . . . 14
3.4. Basic BIER-TE Forwarding Example . . . . . . . . . . . . 10 3.4. Basic BIER-TE Forwarding Example . . . . . . . . . . . . 14
3.5. Forwarding comparison with BIER . . . . . . . . . . . . . 12 3.5. Forwarding comparison with BIER . . . . . . . . . . . . . 16
3.6. Requirements . . . . . . . . . . . . . . . . . . . . . . 13 3.6. Requirements . . . . . . . . . . . . . . . . . . . . . . 17
4. BIER-TE Controller Host BitPosition Assignments . . . . . . . 13 4. BIER-TE Controller Host BitPosition Assignments . . . . . . . 17
4.1. P2P Links . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. P2P Links . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. BFER . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. BFER . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Leaf BFERs . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Leaf BFERs . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. LANs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. LANs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Hub and Spoke . . . . . . . . . . . . . . . . . . . . . . 15 4.5. Hub and Spoke . . . . . . . . . . . . . . . . . . . . . . 19
4.6. Rings . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.6. Rings . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.7. Equal Cost MultiPath (ECMP) . . . . . . . . . . . . . . . 16 4.7. Equal Cost MultiPath (ECMP) . . . . . . . . . . . . . . . 20
4.8. Routed adjacencies . . . . . . . . . . . . . . . . . . . 19 4.8. Routed adjacencies . . . . . . . . . . . . . . . . . . . 23
4.8.1. Reducing BitPositions . . . . . . . . . . . . . . . . 19 4.8.1. Reducing BitPositions . . . . . . . . . . . . . . . . 23
4.8.2. Supporting nodes without BIER-TE . . . . . . . . . . 19 4.8.2. Supporting nodes without BIER-TE . . . . . . . . . . 23
5. Avoiding loops and duplicates . . . . . . . . . . . . . . . . 19 5. Avoiding loops and duplicates . . . . . . . . . . . . . . . . 23
5.1. Loops . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Loops . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Duplicates . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Duplicates . . . . . . . . . . . . . . . . . . . . . . . 24
6. BIER-TE Forwarding Pseudocode . . . . . . . . . . . . . . . . 20 6. BIER-TE Forwarding Pseudocode . . . . . . . . . . . . . . . . 24
7. Managing SI, subdomains and BFR-ids . . . . . . . . . . . . . 23 7. Managing SI, subdomains and BFR-ids . . . . . . . . . . . . . 27
7.1. Why SI and sub-domains . . . . . . . . . . . . . . . . . 24 7.1. Why SI and sub-domains . . . . . . . . . . . . . . . . . 28
7.2. Bit assignment comparison BIER and BIER-TE . . . . . . . 25 7.2. Bit assignment comparison BIER and BIER-TE . . . . . . . 29
7.3. Using BFR-id with BIER-TE . . . . . . . . . . . . . . . . 25 7.3. Using BFR-id with BIER-TE . . . . . . . . . . . . . . . . 29
7.4. Assigning BFR-ids for BIER-TE . . . . . . . . . . . . . . 26 7.4. Assigning BFR-ids for BIER-TE . . . . . . . . . . . . . . 30
7.5. Example bit allocations . . . . . . . . . . . . . . . . . 27 7.5. Example bit allocations . . . . . . . . . . . . . . . . . 31
7.5.1. With BIER . . . . . . . . . . . . . . . . . . . . . . 27 7.5.1. With BIER . . . . . . . . . . . . . . . . . . . . . . 31
7.5.2. With BIER-TE . . . . . . . . . . . . . . . . . . . . 28 7.5.2. With BIER-TE . . . . . . . . . . . . . . . . . . . . 32
7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. BIER-TE and Segment Routing . . . . . . . . . . . . . . . . . 29 8. BIER-TE and Segment Routing (SR) . . . . . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 30 12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . 38
13.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
1.1. Overview BIER-TE shares architecture, terminology and packet formats with BIER
as described in [RFC8279] and [RFC8296]. This document describes
BIER-TE in the expectation that the reader is familiar with these two
documents.
This document specifies the architecture for BIER-TE: traffic In BIER-TE, BitPositions (BP) indicate adjacecies. The BIFT of each
engineering for Bit Index Explicit Replication BIER. 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
replicate and forwards BIER packets to adjacent BPs that are set in
the packet. BPs are normally also reset upon forwarding to avoid
duplicates and loops. This is detailled further below.
BIER-TE shares architecture and packet formats with BIER as described 1.1. Basic Examples
in [RFC8279].
BIER-TE forwards and replicates packets like BIER based on a BIER-TE forwarding is best introduced with simple examples.
BitString in the packet header but it does not require an IGP. It
does support traffic engineering by explicit hop-by-hop forwarding BIER-TE Topology:
and loose hop forwarding of packets. It does support incremental
deployment and a Fast ReRoute (FRR) extension for link and node Diagram:
protection is given in [I-D.eckert-bier-te-frr]. Because BIER-TE
like BIER operates without explicit in-network tree-building but also p5 p6
supports traffic engineering, it is more similar to Segment Routing --- BFR3 ---
(SR) than RSVP-TE. p3/ p13 \p7
BFR1 ---- BFR2 BFR5 ----- BFR6
p1 p2 p4\ p14 /p10 p11 p12
--- BFR4 ---
p8 p9
(simplified) BIER-TE Bit Index Forwarding Tables (BIFT):
BFR1: p1 -> local_decap
p2 -> forward_connected to BFR2
BFR2: p1 -> forward_connected to BFR1
p5 -> forward_connected to BFR3
p8 -> forward_connected to BFR4
BFR3: p3 -> forward_connected to BFR2
p7 -> forward_connected to BFR5
p13 -> local_decap
BFR4: p4 -> forward_connected to BFR2
p10 -> forward_connected to BFR5
p14 -> local_decap
BFR5: p6 -> forward_connected to BFR3
p9 -> forward_connected to BFR4
p12 -> forward_connected to BFR6
BFR6: p11 -> forward_connected to BFR5
p12 -> local_decap
Figure 1: BIER-TE basic example
Consider the simple network in the above BIER-TE overview example
picture with 6 BFR. p1...p14 are the BitPositions (BP) used. All BFR
can act as ingres BFR (BFIR), BFR1, BFR3, BFR4 and BFR6 can also be
egres BFR (BFER). Forward_connected is the name for adjacencies that
are representing subnet adjacencies of the network. Local_decap is
the name of the adjacency to decapsulate BIER-TE packets and pass
their payload to higher layer processing.
Assume a packet from BFR1 should be sent via BFR4 to BFR6. This
requires a bitstring (p2,p8,p10,p12). When this packet is examined
by BIER-TE on BFR1, the only BitPosition from the bitstring that is
also set in the BIFT is p2. This will cause BFR1 to to send the only
copy of the packet to BFR2. Similarily, BFR2 will forward to BFR4
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.
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
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
receive and decapsulate the packet.
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
because of p6 in the prior casse. This is showing the ability of the
shown BIER-TE Topology to make the traffic pass across any possible
path and be replicated where desired.
BIER-TE has various options to minimize BP assignments, many of which
are based on assumptions about the required multicast traffic paths
and bandwidth consumption in the network.
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
encapsulated across them. Unicast tunneling of BIER-TE packets can
leverage any feasible mechanism such as MPLS or IP, these
encapsulations are out of scope of this document. To emphasize non-
native forwarding of BIER-TE packets, these adjacencies are called
"forward_routed", but otherwise there is no difference in their
processing over the aforementioned "forward_connected" adjacencies.
In addition, bits are saved in the following example by assuming that
BFR1 only needs to be BFIR but not BFER or transit BFR.
BIER-TE Topology:
Diagram:
p1 p3 p7
....> BFR3 <.... p5
........ ........>
BFR1 (Rtr2) (Rtr5) BFR6
........ ........>
....> BFR4 <.... p6
p2 p4 p8
(simplified) BIER-TE Bit Index Forwarding Tables (BIFT):
BFR1: p1 -> forward_routed to BFR3
p2 -> forward_routed to BFR4
BFR3: p3 -> local_decap
p5 -> forward_routed to BFR6
BFR4: p4 -> local_decap
p6 -> forward_routed to BFR6
BFR6: p5 -> local_decap
p6 -> local_decap
p7 -> forward_routed to BFR3
p8 -> forward_routed to BFR4
Figure 2: BIER-TE basic overlay example
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
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).
1.2. BIER-TE Topology and adjacencies
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 -
as shown in these two examples - the BIER-TE topology.
The BIER-TE Topology effectively consists of the BIFT of all the the
BFR and can also be expressed in a diagram as a graph where the edges
are the adjacencies between the BFR. Adjacencies are naturally
unidirectional. BP can be reused across multiple adjacencies as long
as this does not lead to undesired duplicates or loops as explained
further down in the text.
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
example. This can be freely mixed with "overlay" BIER-TE, in
"forward_routed" adjacencies are used.
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 offpath by the BIER-TE controller host. explicit paths calculated offpath by the BIER-TE controller host.
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 4, line 32 skipping to change at page 8, 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.2. 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. Layering 2. Layering
End to end BIER-TE operations consists of four components: The End to end BIER-TE operations consists of four layers: The "Multicast
"Multicast Flow Overlay", the "BIER-TE Controller Host", the "Routing Flow Overlay", the "BIER-TE Controller Host", the "Routing Underlay"
Underlay" and the "BIER-TE forwarding layer". and the "BIER-TE forwarding layer". The Bier-TE Controller Host is
the new architectural element in BIER-TE compared toBIER .
Picture 2: Layers of BIER-TE Picture 2: Layers of BIER-TE
<------BGP/PIM-----> <------BGP/PIM----->
|<-IGMP/PIM-> multicast flow <-PIM/IGMP->| |<-IGMP/PIM-> multicast flow <-PIM/IGMP->|
overlay overlay
[Bier-TE Controller Host] [BIER-TE Controller Host] <=> [BIER-TE Topology]
^ ^ ^ ^ ^ ^
/ | \ BIER-TE control protocol / | \ BIER-TE control protocol
| | | eg.: Netconf/Restconf/Yang | | | eg.: Netconf/Restconf/Yang
v v v v v v
Src -> Rtr1 -> BFIR-----BFR-----BFER -> Rtr2 -> Rcvr Src -> Rtr1 -> BFIR-----BFR-----BFER -> Rtr2 -> Rcvr
|--------------------->| |--------------------->|
BIER-TE forwarding layer BIER-TE forwarding layer
|<- BIER-TE domain-->| |<- BIER-TE domain-->|
|<--------------------->| |<--------------------->|
Routing underlay Routing underlay
Figure 1: BIER-TE architecture Figure 3: BIER-TE architecture
2.1. The Multicast Flow Overlay 2.1. The Multicast Flow Overlay
The Multicast Flow Overlay operates as in BIER. See [RFC8279]. The Multicast Flow Overlay operates as in BIER. See [RFC8279].
Instead of interacting with the BIER layer, it interacts with the Instead of interacting with the BIER forwarding layer layer (as in
BIER-TE Controller Host BIER), it interacts with the BIER-TE Controller Host.
2.2. The BIER-TE Controller Host 2.2. The BIER-TE Controller Host
The BIER-TE controller host is representing the control plane of The BIER-TE controller host is representing the control plane of
BIER-TE. It communicates two sets of information with BFRs: BIER-TE. It communicates two sets of information with BFRs:
During bring-up or modifications of the network topology, the During bring-up or modifications of the network topology, the
controller discovers the network topology, assigns BitPositions to controller discovers the network topology and creates the BIER-TE
adjacencies and signals the resulting mapping of BitPositions to topology from it: determine which adjacencies are required/desired
adjacencies to each BFR connecting to the adjacency. and assign BitPositions to them. Then it signals the resulting of
BitPositions and their adjacencies to each BFR to set up their BIER-
TE BIFTs.
During day-to-day operations of the network, the controller signals During day-to-day operations of the network, the controller signals
to BFIRs what multicast flows are mapped to what BitStrings. to BFIRs what multicast flows are mapped to what BitStrings.
Communications between the BIER-TE controller host to BFRs is ideally Communications between the BIER-TE controller host to BFRs is ideally
via standardized protocols and data-models such as Netconf/Retconf/ via standardized protocols and data-models such as Netconf/Retconf/
Yang. This is currently outside the scope of this document. Vendor- Yang. This is currently outside the scope of this document. Vendor-
specific CLI on the BFRs is also a possible stopgap option (as in specific CLI on the BFRs is also a possible stopgap option (as in
many other SDN solutions lacking definition of standardized data many other SDN solutions lacking definition of standardized data
model). model).
skipping to change at page 8, line 18 skipping to change at page 12, line 21
------------------------------------------------------------------ ------------------------------------------------------------------
| Index: | Adjacencies: | | Index: | Adjacencies: |
| SI:BitPosition | <empty> or one or more per entry | | SI:BitPosition | <empty> or one or more per entry |
================================================================== ==================================================================
| 0:1 | forward_connected(interface,neighbor,DNR) | | 0:1 | forward_connected(interface,neighbor,DNR) |
------------------------------------------------------------------ ------------------------------------------------------------------
| 0:2 | forward_connected(interface,neighbor,DNR) | | 0:2 | forward_connected(interface,neighbor,DNR) |
| | forward_connected(interface,neighbor,DNR) | | | forward_connected(interface,neighbor,DNR) |
------------------------------------------------------------------ ------------------------------------------------------------------
| 0:3 | local_decap([VRF]) | | 0:3 | local_decap({VRF}) |
------------------------------------------------------------------ ------------------------------------------------------------------
| 0:4 | forward_routed([VRF,]l3-neighbor) | | 0:4 | forward_routed({VRF,}l3-neighbor) |
------------------------------------------------------------------ ------------------------------------------------------------------
| 0:5 | <empty> | | 0:5 | <empty> |
------------------------------------------------------------------ ------------------------------------------------------------------
| 0:6 | ECMP({adjacency1,...adjacencyN}, seed) | | 0:6 | ECMP({adjacency1,...adjacencyN}, seed) |
------------------------------------------------------------------ ------------------------------------------------------------------
... ...
| BitStringLength | ... | | BitStringLength | ... |
------------------------------------------------------------------ ------------------------------------------------------------------
Bit Index Forwarding Table Bit Index Forwarding Table
Figure 2: BIFT adjacencies Figure 4: BIFT adjacencies
The BIFT is programmed into the data plane of BFRs by the BIER-TE The BIFT is programmed into the data plane of BFRs by the BIER-TE
controller host and used to forward packets, according to the rules controller host and used to forward packets, according to the rules
specified in the BIER-TE Forwarding Procedures. specified in the BIER-TE Forwarding Procedures.
Adjacencies for the same BP when populated in more than one BFR by Adjacencies for the same BP when populated in more than one BFR by
the controller do not have to have the same adjacencies. This is up the controller do not have to have the same adjacencies. This is up
to the controller. BPs for p2p links are one case (see below). to the controller. BPs for p2p links are one case (see below).
3.2. Adjacency Types 3.2. Adjacency Types
skipping to change at page 11, line 29 skipping to change at page 15, line 29
| p14 p4 | | p14 p4 |
+- BFIR1 --+ | +- BFIR1 --+ |
| +-- BFR5 --+ p10 p12 | | +-- BFR5 --+ p10 p12 |
LAN1 | p5 p9 +-- BFER2 --+ LAN1 | p5 p9 +-- BFER2 --+
| +-- Rcv2 | +-- Rcv2
| |
LAN3 LAN3
IP |..... BIER-TE network......| IP IP |..... BIER-TE network......| IP
Figure 3: BIER-TE Forwarding Example Figure 5: BIER-TE Forwarding Example
pXX indicate the BitPositions number assigned by the BIER-TE pXX indicate the BitPositions number assigned by the BIER-TE
controller host to adjacencies in the BIER-TE topology. For example, controller host to adjacencies in the BIER-TE topology. For example,
p9 is the adjacency towards BFR9 on the LAN connecting to BFER2. p9 is the adjacency towards BFR9 on the LAN connecting to BFER2.
BIFT BFIR2: BIFT BFIR2:
p13: local_decap() p13: local_decap()
p2: forward_connected(BFR3) p2: forward_connected(BFR3)
BIFT BFR3: BIFT BFR3:
p1: forward_connected(BFIR2) p1: forward_connected(BFIR2)
p7: forward_connected(BFER1) p7: forward_connected(BFER1)
p8: forward_connected(BFR4) p8: forward_connected(BFR4)
BIFT BFER1: BIFT BFER1:
p11: local_decap() p11: local_decap()
p6: forward_connected(BFR3) p6: forward_connected(BFR3)
p8: forward_connected(BFR4) p8: forward_connected(BFR4)
Figure 4: BIER-TE Forwarding Example Adjacencies Figure 6: BIER-TE Forwarding Example Adjacencies
...and so on. ...and so on.
Traffic needs to flow from BFIR2 towards Rcv1, Rcv2. The controller Traffic needs to flow from BFIR2 towards Rcv1, Rcv2. The controller
determines it wants it to pass across the following paths: determines it wants it to pass across the following paths:
-> BFER1 ---------------> Rcv1 -> BFER1 ---------------> Rcv1
BFIR2 -> BFR3 BFIR2 -> BFR3
-> BFR4 -> BFR5 -> BFER2 -> Rcv2 -> BFR4 -> BFR5 -> BFER2 -> Rcv2
Figure 5: BIER-TE Forwarding Example Paths Figure 7: BIER-TE Forwarding Example Paths
These paths equal to the following BitString: p2, p5, p7, p8, p10, These paths equal to the following BitString: p2, p5, p7, p8, p10,
p11, p12. p11, p12.
This BitString is set up in BFIR2. Multicast packets arriving at This BitString is set up in BFIR2. Multicast packets arriving at
BFIR2 from Src are assigned this BitString. BFIR2 from Src are assigned this BitString.
BFIR2 forwards based on that BitString. It has p2 and p13 populated. BFIR2 forwards based on that BitString. It has p2 and p13 populated.
Only p13 is in BitString which has an adjacency towards BFR3. BFIR2 Only p13 is in BitString which has an adjacency towards BFR3. BFIR2
resets p2 in BitString and sends a copy towards BFR2. resets p2 in BitString and sends a copy towards BFR2.
skipping to change at page 14, line 46 skipping to change at page 18, line 46
unique BitPosition. The adjacency of this BitPosition is a unique BitPosition. The adjacency of this BitPosition is a
forward_connected adjacency towards the BFR and this BitPosition is forward_connected adjacency towards the BFR and this BitPosition is
populated into the BIFT of all the other BFRs on that LAN. populated into the BIFT of all the other BFRs on that LAN.
BFR1 BFR1
|p1 |p1
LAN1-+-+---+-----+ LAN1-+-+---+-----+
p3| p4| p2| p3| p4| p2|
BFR3 BFR4 BFR7 BFR3 BFR4 BFR7
Figure 6: LAN Example Figure 8: LAN Example
If Bandwidth on the LAN is not an issue and most BIER-TE traffic If Bandwidth on the LAN is not an issue and most BIER-TE traffic
should be copied to all neighbors on a LAN, then BitPositions can be should be copied to all neighbors on a LAN, then BitPositions can be
saved by assigning just a single BitPosition to the LAN and saved by assigning just a single BitPosition to the LAN and
populating the BitPosition of the BIFTs of each BFRs on the LAN with populating the BitPosition of the BIFTs of each BFRs on the LAN with
a list of forward_connected adjacencies to all other neighbors on the a list of forward_connected adjacencies to all other neighbors on the
LAN. LAN.
This optimization does not work in the face of BFRs redundantly This optimization does not work in the face of BFRs redundantly
connected to more than one LANs with this optimization because these connected to more than one LANs with this optimization because these
skipping to change at page 16, line 15 skipping to change at page 20, line 15
v v v v
| | | |
L1 | L2 | L3 L1 | L2 | L3
/-------- BFRa ---- BFRb --------------------\ /-------- BFRa ---- BFRb --------------------\
| | | |
\- BFR1 - BFR2 - BFR3 - ... - BFR29 - BFR30 -/ \- BFR1 - BFR2 - BFR3 - ... - BFR29 - BFR30 -/
| | L4 | | | | L4 | |
p33| p15| p33| p15|
BFRd BFRc BFRd BFRc
Figure 7: Ring Example Figure 9: Ring Example
Note that this example only permits for packets to enter the ring at Note that this example only permits for packets to enter the ring at
BFRa and BFRb, and that packets will always travel clockwise. If BFRa and BFRb, and that packets will always travel clockwise. If
packets should be allowed to enter the ring at any ring BFR, then one packets should be allowed to enter the ring at any ring BFR, then one
would have to use two ring BitPositions. One for clockwise, one for would have to use two ring BitPositions. One for clockwise, one for
counterclockwise. counterclockwise.
Both would be set up to stop rotating on the same link, eg: L1. When Both would be set up to stop rotating on the same link, eg: L1. When
the ingress ring BFR creates the clockwise copy, it will reset the the ingress ring BFR creates the clockwise copy, it will reset the
counterclockwise BitPosition because the DNR bit only applies to the counterclockwise BitPosition because the DNR bit only applies to the
skipping to change at page 17, line 22 skipping to change at page 21, line 22
| 0:6 | ECMP({L1-to-BFR2,L2-to-BFR2,L3-to-BFR2}, seed) | | 0:6 | ECMP({L1-to-BFR2,L2-to-BFR2,L3-to-BFR2}, seed) |
------------------------------------------------------------------ ------------------------------------------------------------------
BIFT entry in BFR2: BIFT entry in BFR2:
------------------------------------------------------------------ ------------------------------------------------------------------
| Index | Adjacencies | | Index | Adjacencies |
================================================================== ==================================================================
| 0:6 | ECMP({L1-to-BFR1,L2-to-BFR1,L3-to-BFR1}, seed) | | 0:6 | ECMP({L1-to-BFR1,L2-to-BFR1,L3-to-BFR1}, seed) |
------------------------------------------------------------------ ------------------------------------------------------------------
Figure 8: ECMP Example Figure 10: ECMP Example
In the following example, all traffic from BFR1 towards BFR10 is In the following example, all traffic from BFR1 towards BFR10 is
intended to be ECMP load split equally across the topology. This intended to be ECMP load split equally across the topology. This
example is not mean as a likely setup, but to illustrate that ECMP example is not mean as a likely setup, but to illustrate that ECMP
can be used to share BPs not only across link bundles, and it can be used to share BPs not only across link bundles, and it
explains the use of the seed parameter. explains the use of the seed parameter.
BFR1 BFR1
/ \ / \
/L11 \L12 /L11 \L12
skipping to change at page 18, line 34 skipping to change at page 22, line 34
BIFT entry in BFR2: BIFT entry in BFR2:
------------------------------------------------------------------ ------------------------------------------------------------------
| 0:6 | ECMP({L21-to-BFR4,L22-to-BFR5}, seed) | | 0:6 | ECMP({L21-to-BFR4,L22-to-BFR5}, seed) |
------------------------------------------------------------------ ------------------------------------------------------------------
BIFT entry in BFR3: BIFT entry in BFR3:
------------------------------------------------------------------ ------------------------------------------------------------------
| 0:6 | ECMP({L31-to-BFR6,L32-to-BFR7}, seed) | | 0:6 | ECMP({L31-to-BFR6,L32-to-BFR7}, seed) |
------------------------------------------------------------------ ------------------------------------------------------------------
Figure 9: Polarization Example Figure 11: Polarization Example
With the setup of ECMP in above topology, traffic would not be With the setup of ECMP in above topology, traffic would not be
equally load-split. Instead, links L22 and L31 would see no traffic equally load-split. Instead, links L22 and L31 would see no traffic
at all: BFR2 will only see traffic from BFR1 for which the ECMP hash at all: BFR2 will only see traffic from BFR1 for which the ECMP hash
in BFR1 selected the first adjacency in a list of 2 adjacencies: link in BFR1 selected the first adjacency in a list of 2 adjacencies: link
L11-to-BFR2. When forwarding in BFR2 performs again an ECMP with two L11-to-BFR2. When forwarding in BFR2 performs again an ECMP with two
adjacencies on that subset of traffic, then it will again select the adjacencies on that subset of traffic, then it will again select the
first of its two adjacencies to it: L21-to-BFR4. And therefore L22 first of its two adjacencies to it: L21-to-BFR4. And therefore L22
and BFR5 sees no traffic. and BFR5 sees no traffic.
skipping to change at page 19, line 21 skipping to change at page 23, line 21
Routed adjacencies can reduce the number of BitPositions required Routed adjacencies can reduce the number of BitPositions required
when the traffic engineering requirement is not hop-by-hop explicit when the traffic engineering requirement is not hop-by-hop explicit
path selection, but loose-hop selection. path selection, but loose-hop selection.
............... ............... ............... ...............
BFR1--... Redundant ...--L1-- BFR2... Redundant ...--- BFR1--... Redundant ...--L1-- BFR2... Redundant ...---
\--... Network ...--L2--/ ... Network ...--- \--... Network ...--L2--/ ... Network ...---
BFR4--... Segment 1 ...--L3-- BFR3... Segment 2 ...--- BFR4--... Segment 1 ...--L3-- BFR3... Segment 2 ...---
............... ............... ............... ...............
Figure 10: Routed Adjacencies Example Figure 12: Routed Adjacencies Example
Assume the requirement in above network is to explicitly engineer Assume the requirement in above network is to explicitly engineer
paths such that specific traffic flows are passed from segment 1 to paths such that specific traffic flows are passed from segment 1 to
segment 2 via link L1 (or via L2 or via L3). segment 2 via link L1 (or via L2 or via L3).
To achieve this, BFR1 and BFR4 are set up with a forward_routed To achieve this, BFR1 and BFR4 are set up with a forward_routed
adjacency BitPosition towards an address of BFR2 on link L1 (or link adjacency BitPosition towards an address of BFR2 on link L1 (or link
L2 BFR3 via L3). L2 BFR3 via L3).
For paths to be engineered through a specific node BFR2 (or BFR3), For paths to be engineered through a specific node BFR2 (or BFR3),
skipping to change at page 21, line 22 skipping to change at page 25, line 22
if (!F-BM) continue; if (!F-BM) continue;
BFR-NBR = BIFT[Index+Offset]->BFR-NBR; BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
PacketCopy = Copy(Packet); PacketCopy = Copy(Packet);
PacketCopy->BitString &= F-BM; [2] PacketCopy->BitString &= F-BM; [2]
PacketSend(PacketCopy, BFR-NBR); PacketSend(PacketCopy, BFR-NBR);
// The following must not be done for BIER-TE: // The following must not be done for BIER-TE:
// Packet->BitString &= ~F-BM; [1] // Packet->BitString &= ~F-BM; [1]
} }
} }
Figure 11: Simplified BIER-TE Forwarding Pseudocode Figure 13: Simplified BIER-TE Forwarding Pseudocode
The difference is that in BIER-TE, step [1] must not be performed. The difference is that in BIER-TE, step [1] must not be performed.
In BIER, this step is necessary to avoid duplicates when two or more In BIER, this step is necessary to avoid duplicates when two or more
BFER are reachable via the same neighbor. The F-BM of all those BFER BFER are reachable via the same neighbor. The F-BM of all those BFER
bits will indicate each others bits, and step [1] will reset all bits will indicate each others bits, and step [1] will reset all
these bits on the first copy made for the first of those BFER bits these bits on the first copy made for the first of those BFER bits
set in the BitString, hence skipping any further copies to that set in the BitString, hence skipping any further copies to that
neighbor. neighbor.
skipping to change at page 23, line 26 skipping to change at page 27, line 26
Packet->Entropy, seed); Packet->Entropy, seed);
adjacency = ListOfAdjacencies[I]; adjacency = ListOfAdjacencies[I];
} }
PacketCopy = Copy(Packet); PacketCopy = Copy(Packet);
switch(adjacency) { switch(adjacency) {
case forward_connected(interface,neighbor,DNR): case forward_connected(interface,neighbor,DNR):
if(DNR) if(DNR)
PacketCopy->BitString |= 2<<(Index-1); PacketCopy->BitString |= 2<<(Index-1);
SendToL2Unicast(PacketCopy,interface,neighbor); SendToL2Unicast(PacketCopy,interface,neighbor);
case forward_routed([VRF],neighbor): case forward_routed({VRF},neighbor):
SendToL3(PacketCopy,[VRF,]l3-neighbor); SendToL3(PacketCopy,{VRF,}l3-neighbor);
case local_decap([VRF],neighbor): case local_decap({VRF},neighbor):
DecapBierHeader(PacketCopy); DecapBierHeader(PacketCopy);
PassTo(PacketCopy,[VRF,]Packet->NextProto); PassTo(PacketCopy,{VRF,}Packet->NextProto);
} }
} }
} }
} }
Figure 12: BIER-TE Forwarding Pseudocode Figure 14: BIER-TE Forwarding Pseudocode
7. Managing SI, subdomains and BFR-ids 7. Managing SI, subdomains and BFR-ids
When the number of bits required to represent the necessary hops in When the number of bits required to represent the necessary hops in
the topology and BFER exceeds the supported bitstring length, the topology and BFER exceeds the supported bitstring length,
multiple SI and/or subdomains must be used. This section discusses multiple SI and/or subdomains must be used. This section discusses
how. how.
BIER-TE forwarding does not require the concept of BFR-id, but BIER-TE forwarding does not require the concept of BFR-id, but
routing underlay, flow overlay and BIER headers may. This section routing underlay, flow overlay and BIER headers may. This section
skipping to change at page 27, line 40 skipping to change at page 31, line 40
area1 area2 area3 area1 area2 area3
BFR1a BFR1b BFR2a BFR2b BFR3a BFR3b BFR1a BFR1b BFR2a BFR2b BFR3a BFR3b
| \ / \ / | | \ / \ / |
................................ ................................
. Core . . Core .
................................ ................................
| / \ / \ | | / \ / \ |
BFR4a BFR4b BFR5a BFR5b BFR6a BFR6b BFR4a BFR4b BFR5a BFR5b BFR6a BFR6b
area4 area5 area6 area4 area5 area6
Figure 13: Scaling BIER-TE bits by reuse Figure 15: Scaling BIER-TE bits by reuse
With random allocation of BFR-id to BFER, each receiving area would With random allocation of BFR-id to BFER, each receiving area would
(most likely) have to receive all 4 copies of the BIER packet because (most likely) have to receive all 4 copies of the BIER packet because
there would be BFR-id for each of the 4 SI in each of the areas. there would be BFR-id for each of the 4 SI in each of the areas.
Only further towards each BFER would this duplication subside - when Only further towards each BFER would this duplication subside - when
each of the 4 trees runs out of branches. each of the 4 trees runs out of branches.
If BFR-id are allocated intelligently, then all the BFER in an area If BFR-id are allocated intelligently, then all the BFER in an area
would be given BFR-id with as few as possible different SI. Each would be given BFR-id with as few as possible different SI. Each
area would only have to forward one or two packets instead of 4. area would only have to forward one or two packets instead of 4.
skipping to change at page 29, line 38 skipping to change at page 33, line 38
The number of BFIR/BFER possible in a subdomain is smaller than in The number of BFIR/BFER possible in a subdomain is smaller than in
BIER because BIER-TE uses additional bits for topology. BIER because BIER-TE uses additional bits for topology.
Subdomains can in BIER-TE be used like in BIER to create more Subdomains can in BIER-TE be used like in BIER to create more
efficient replication to known subsets of BFER. efficient replication to known subsets of BFER.
Assigning bits for BFER intelligently into the right SI is more Assigning bits for BFER intelligently into the right SI is more
important in BIER-TE than in BIER because of replication efficiency important in BIER-TE than in BIER because of replication efficiency
and overall amount of bits required. and overall amount of bits required.
8. BIER-TE and Segment Routing 8. BIER-TE and Segment Routing (SR)
Segment Routing aims to achieve lightweight path engineering via Segment Routing (SR ([RFC8402])) aims to enable lightweight path
loose source routing. Compared for example to RSVP-TE, it does not engineering via loose source routing. Compared to its more heavy-
weight predecessor RSVP-TE ([RFC3209]), SR does for example not
require per-path signaling to each of these hops. require per-path signaling to each of these hops.
BIER-TE is supports the same design philosophy for multicast. Like BIER-TE supports the same design philosophy for multicast. Like in
in SR, it relies on source-routing - via the definition of a SR, it relies on source-routing - via the definition of a BitString.
BitString. Like SR, it only requires to consider the "hops" on which Like SR, it only requires to consider the "hops" on which either
either replication has to happen, or across which the traffic should replication has to happen, or across which the traffic should be
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.
Instead of defining BitPositions for non-replicating hops, it is BIER-TE BitPosition (BP) can be understood as the BIER-TE equivalent
equally possible to use segment routing encapsulations (eg: MPLS of "forwarding segments" in SR, but they have a different scope than
label stacks) for "forward_routed" adjacencies. SR forwarding segments. Whereas forwarding segments in SR are global
or local, BPs in BIER-TE have a scope that is the group of BFR(s)
that have adjacencies for this BP in their BIFT. This can be called
"adjacency" scoped forwarding segments.
Note that BIER itself is also similar to SR - it achieves the same as Adjacency scope could be global, but then every BFR would need an
"Shortest Path SID" where the label stack uses only one SID to adjacency for this BP, for example a forward_routed adjacency with
indicate the egres node of the SR domain. Instead of routing such a encapsulation to the global SR SID of the destination. Such a BP
SR packet hop-by-hop based on that SID, BIER routes the packet hop- would always result in ingres replication though. The first BFR
by-hop based on the BFER-id bits of the egres nodes of the BIER encountering this BP would directly replicate to it. Only by using
domain. What BIER does not allow is to indicate intermediate hops, non-global adjacency scope for BPs can traffic be steered and
or terms of SR lavbel stacks with more than one SID in the stack (for replicated on non-ingres BFR.
the same SR domain). This is what BIER-TE provides.
SR can naturally be combined with BIER-TE and help to optimize it.
For example, instead of defining BitPositions for non-replicating
hops, it is equally possible to use segment routing encapsulations
(eg: MPLS label stacks) for the encapsulation of "forward_routed"
adjacencies.
Note that BIER itself can also be seen to be similar to SR. BIER BPs
act as global destination Node-SIDs and the BIER bitstring is simply
a highly optimized mechanism to indicate multiple such SIDS and let
the network take care of effectively replicating the packet hop-by-
hop to each destination Node-SID. What BIER does not allow is to
indicate intermediate hops, or terms of SR the ability to indicate a
sequence of SID to reach the destination. This is what BIER-TE and
its adjacency scoped BP enables.
9. Security Considerations 9. Security Considerations
The security considerations are the same as for BIER with the The security considerations are the same as for BIER with the
following differences: following differences:
BFR-ids and BFR-prefixes are not used in BIER-TE, nor are procedures BFR-ids and BFR-prefixes are not used in BIER-TE, nor are procedures
for their distribution, so these are not attack vectors against BIER- for their distribution, so these are not attack vectors against BIER-
TE. TE.
skipping to change at page 30, line 40 skipping to change at page 35, line 9
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Greg Shepherd, Ijsbrand Wijnands and The authors would like to thank Greg Shepherd, Ijsbrand Wijnands and
Neale Ranns for their extensive review and suggestions. Neale Ranns for their extensive review and suggestions.
12. Change log [RFC Editor: Please remove] 12. Change log [RFC Editor: Please remove]
draft-ietf-bier-te-arch: draft-ietf-bier-te-arch:
03: Last call textual changes by authors to improve readability:
removed Wolfgang Braun as co-authors (as requested).
Improved abstract to be more explanatory. Removed mentioning of
FRR (not conluded on so far).
Added new text into Introduction setion because the text was too
difficult to jump into (too many forward pointers). This
primarily consists of examples and the early introduction of the
BIER-TE Topology concept enabled by these examples.
Amended comparison to SR.
Changed syntax from [VRF] to {VRF} to indicate its optional and to
make idnits happy.
Split references into normative / informative, added references.
02: Refresh after IETF104 discussion: changed intended status back 02: Refresh after IETF104 discussion: changed intended status back
to standard. Reasoning: to standard. Reasoning:
Tighter review of standards document == ensures arch will be Tighter review of standards document == ensures arch will be
better prepared for possible adoption by other WGs (e.g.: DetNet) better prepared for possible adoption by other WGs (e.g.: DetNet)
or std. bodies. or std. bodies.
Requirement against the degree of existing implementations is self Requirement against the degree of existing implementations is self
defined by the WG. BIER WG seems to think it is not necessary to defined by the WG. BIER WG seems to think it is not necessary to
apply multiple interoperating implementions against an apply multiple interoperating implementions against an
skipping to change at page 33, line 13 skipping to change at page 38, line 7
01: Fixed BFIR -> BFER for section 4.3. 01: Fixed BFIR -> BFER for section 4.3.
01: Added explanation of SI, difference to BIER ECMP, 01: Added explanation of SI, difference to BIER ECMP,
consideration for Segment Routing, unicast FRR, considerations for consideration for Segment Routing, unicast FRR, considerations for
encapsulation, explanations of BIER-TE controller host and CLI. encapsulation, explanations of BIER-TE controller host and CLI.
00: Initial version. 00: Initial version.
13. References 13. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 13.1. Normative References
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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)
Huawei USA - Futurewei Technologies Inc. Huawei USA - 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
Gregory Cauchie Gregory Cauchie
Bouygues Telecom Bouygues Telecom
Email: GCAUCHIE@bouyguestelecom.fr Email: GCAUCHIE@bouyguestelecom.fr
Wolfgang Braun
University of Tuebingen
Email: wolfgang.braun@uni-tuebingen.de
Michael Menth Michael Menth
University of Tuebingen University of Tuebingen
Email: menth@uni-tuebingen.de Email: menth@uni-tuebingen.de
 End of changes. 45 change blocks. 
141 lines changed or deleted 342 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/