< draft-ietf-bier-te-arch.txt   draft-ietf-bier-te-arch.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: July 21, 2022 Bouygues Telecom Expires: July 28, 2022 Bouygues Telecom
M. Menth M. Menth
University of Tuebingen University of Tuebingen
January 17, 2022 January 24, 2022
Tree Engineering for Bit Index Explicit Replication (BIER-TE) Tree Engineering for Bit Index Explicit Replication (BIER-TE)
draft-ietf-bier-te-arch-12 draft-ietf-bier-te-arch-12
Abstract Abstract
This memo describes per-packet stateless strict and loose path This memo describes per-packet stateless strict and loose path
steered replication and forwarding for "Bit Index Explicit steered replication and forwarding for "Bit Index Explicit
Replication" (BIER, RFC8279) packets. It is called BIER Tree Replication" (BIER, RFC8279) packets. It is called BIER Tree
Engineering (BIER-TE) and is intended to be used as the path steering Engineering (BIER-TE) and is intended to be used as the path steering
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 July 21, 2022. This Internet-Draft will expire on July 28, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 37 skipping to change at page 3, line 37
5.3.5. Assigning BFR-ids for BIER-TE . . . . . . . . . . . . 43 5.3.5. Assigning BFR-ids for BIER-TE . . . . . . . . . . . . 43
5.3.6. Example bit allocations . . . . . . . . . . . . . . . 43 5.3.6. Example bit allocations . . . . . . . . . . . . . . . 43
5.3.6.1. With BIER . . . . . . . . . . . . . . . . . . . . 43 5.3.6.1. With BIER . . . . . . . . . . . . . . . . . . . . 43
5.3.6.2. With BIER-TE . . . . . . . . . . . . . . . . . . 44 5.3.6.2. With BIER-TE . . . . . . . . . . . . . . . . . . 44
5.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 45 5.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 45
6. BIER-TE and Segment Routing . . . . . . . . . . . . . . . . . 45 6. BIER-TE and Segment Routing . . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 48 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 48
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
11.1. Normative References . . . . . . . . . . . . . . . . . . 59 11.1. Normative References . . . . . . . . . . . . . . . . . . 60
11.2. Informative References . . . . . . . . . . . . . . . . . 59 11.2. Informative References . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Overview 1. Overview
BIER-TE is based on architecture, terminology and packet formats with BIER-TE is based on architecture, terminology and packet formats with
(non-TE) BIER as described in [RFC8279] and [RFC8296]. This document (non-TE) BIER as described in [RFC8279] and [RFC8296]. This document
describes BIER-TE in the expectation that the reader is familiar with describes BIER-TE in the expectation that the reader is familiar with
these two documents. these two documents.
BIER-TE introduces a new semantic for "bit positions" (BP) that BIER-TE introduces a new semantic for "bit positions" (BP) that
indicate adjacencies, as opposed to "Bit Index Explicit Replication" indicate adjacencies, as opposed to "Bit Index Explicit Replication"
skipping to change at page 4, line 44 skipping to change at page 4, line 44
o Section 4 specifies the behavior of the BIER-TE forwarding plane o Section 4 specifies the behavior of the BIER-TE forwarding plane
with the different type of adjacencies and possible variations of with the different type of adjacencies and possible variations of
BIER-TE forwarding pseudocode, and finally the mandatory and BIER-TE forwarding pseudocode, and finally the mandatory and
optional requirements. optional requirements.
o Section 5 describes operational considerations for the BIER-TE o Section 5 describes operational considerations for the BIER-TE
controller, foremost how the BIER-TE controller can optimize the controller, foremost how the BIER-TE controller can optimize the
use of BP by using specific type of BIER-TE adjacencies for use of BP by using specific type of BIER-TE adjacencies for
different type of topological situations, but also how to assign different type of topological situations, but also how to assign
bits to avoid loops and duplicates (which in BIER-TE does not come bits to avoid loops and duplicates (which in BIER-TE does not come
for free), and finally how SI, sub-domains and BFR-ids can be for free), and finally how "Set Identifier" (SI), "sub-domain"
managed by a BIER-TE controller, examples and summary. (SD) and BFR-ids can be managed by a BIER-TE controller, examples
and summary.
o Section 6 concludes the technology specific sections of document o Section 6 concludes the technology specific sections of document
by further relating BIER-TE to SR. by further relating BIER-TE to SR.
Note that related work, [I-D.ietf-roll-ccast] uses Bloom filters Note that related work, [I-D.ietf-roll-ccast] uses Bloom filters
[Bloom70] to represent leaves or edges of the intended delivery tree. [Bloom70] to represent leaves or edges of the intended delivery tree.
Bloom filters in general can support larger trees/topologies with Bloom filters in general can support larger trees/topologies with
fewer addressing bits than explicit BitStrings, but they introduce fewer addressing bits than explicit BitStrings, but they introduce
the heuristic risk of false positives and cannot clear bits in the the heuristic risk of false positives and cannot clear 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. Requirements Language 1.1. Requirements Language
skipping to change at page 6, line 19 skipping to change at page 6, line 19
p5 p6 p5 p6
--- BFR3 --- --- BFR3 ---
p3/ p13 \p7 p15 p3/ p13 \p7 p15
BFR1 ---- BFR2 BFR5 ----- BFR6 BFR1 ---- BFR2 BFR5 ----- BFR6
p1 p2 p4\ p14 /p10 p11 p12 p1 p2 p4\ p14 /p10 p11 p12
--- BFR4 --- --- BFR4 ---
p8 p9 p8 p9
(simplified) BIER-TE Bit Index Forwarding Tables (BIFT): (simplified) BIER-TE Bit Index Forwarding Tables (BIFT):
BFR1: p1 -> local_decap BFR1: p1 -> local_decap()
p2 -> forward_connected() to BFR2 p2 -> forward_connected() to BFR2
BFR2: p1 -> forward_connected() to BFR1 BFR2: p1 -> forward_connected() to BFR1
p5 -> forward_connected() to BFR3 p5 -> forward_connected() to BFR3
p8 -> forward_connected() to BFR4 p8 -> forward_connected() to BFR4
BFR3: p3 -> forward_connected() to BFR2 BFR3: p3 -> forward_connected() to BFR2
p7 -> forward_connected() to BFR5 p7 -> forward_connected() to BFR5
p13 -> local_decap p13 -> local_decap()
BFR4: p4 -> forward_connected() to BFR2 BFR4: p4 -> forward_connected() to BFR2
p10 -> forward_connected() to BFR5 p10 -> forward_connected() to BFR5
p14 -> local_decap p14 -> local_decap()
BFR5: p6 -> forward_connected() to BFR3 BFR5: p6 -> forward_connected() to BFR3
p9 -> forward_connected() to BFR4 p9 -> forward_connected() to BFR4
p12 -> forward_connected() to BFR6 p12 -> forward_connected() to BFR6
BFR6: p11 -> forward_connected() to BFR5 BFR6: p11 -> forward_connected() to BFR5
p15 -> local_decap p15 -> local_decap()
Figure 1: BIER-TE basic example Figure 1: BIER-TE basic example
Consider the simple network in the above BIER-TE overview example Consider the simple network in the above BIER-TE overview example
picture with 6 BFRs. p1...p14 are the bit positions used. All BFRs picture with 6 BFRs. p1...p14 are the bit positions used. All BFRs
can act as an ingress BFR (BFIR), BFR1, BFR3, BFR4 and BFR6 can also can act as an ingress BFR (BFIR), BFR1, BFR3, BFR4 and BFR6 can also
be BFERs. Forward_connected() is the name for adjacencies that are be BFERs. Forward_connected() is the name for adjacencies that are
representing subnet adjacencies of the network. Local_decap() is the representing subnet adjacencies of the network. Local_decap() is the
name of the adjacency to decapsulate BIER-TE packets and pass their name of the adjacency to decapsulate BIER-TE packets and pass their
payload to higher layer processing. payload to higher layer processing.
skipping to change at page 7, line 15 skipping to change at page 7, line 15
Assume a packet from BFR1 should be sent via BFR4 to BFR6. This Assume a packet from BFR1 should be sent via BFR4 to BFR6. This
requires a BitString (p2,p8,p10,p12,p15). When this packet is requires a BitString (p2,p8,p10,p12,p15). When this packet is
examined by BIER-TE on BFR1, the only bit position from the BitString examined by BIER-TE on BFR1, the only bit position from the BitString
that is also set in the BIFT is p2. This will cause BFR1 to send the that is also set in the BIFT is p2. This will cause BFR1 to send the
only copy of the packet to BFR2. Similarly, BFR2 will forward to only copy of the packet to BFR2. Similarly, BFR2 will forward to
BFR4 because of p8, BFR4 to BFR5 because of p10 and BFR5 to BFR6 BFR4 because of p8, BFR4 to BFR5 because of p10 and BFR5 to BFR6
because of p12. p15 finally makes BFR6 receive and decapsulate the because of p12. p15 finally makes BFR6 receive and decapsulate the
packet. packet.
To send in addition to BFR6 via BFR4 also a copy to BFR3, the To send in addition to BFR6 via BFR4 also a copy to BFR3, the
BitString needs to be (p2,p5,p8,p10,p12,p13). When this packet is BitString needs to be (p2,p5,p8,p10,p12,p13,p15). When this packet
examined by BFR2, p5 causes one copy to be sent to BFR3 and p8 one 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 copy to BFR4. When BFR3 receives the packet, p13 will cause it to
receive and decapsulate the packet. receive and decapsulate the packet.
If instead the BitString was (p2,p6,p8,p10,p12,p13,p15), the packet If instead the BitString was (p2,p6,p8,p10,p12,p13,p15), the packet
would be copied by BFR5 towards BFR3 because of p6 instead of being would be copied by BFR5 towards BFR3 because of p6 instead of being
copied by BFR2 to BFR3 because of p5 in the prior case. This is copied by BFR2 to BFR3 because of p5 in the prior case. This is
showing the ability of the shown BIER-TE Topology to make the traffic showing the ability of the shown BIER-TE Topology to make the traffic
pass across any possible path and be replicated where desired. pass across any possible path and be replicated where desired.
BIER-TE has various options to minimize BP assignments, many of which BIER-TE has various options to minimize BP assignments, many of which
are based on assumptions about the required multicast traffic paths are based on out-of-band knowledge about the required multicast
and bandwidth consumption in the network. traffic paths and bandwidth consumption in the network, such as from
pre-deployment planning.
The following picture shows a modified example, in which Rtr2 and Figure 2 shows a modified example, in which Rtr2 and Rtr5 are assumed
Rtr5 are assumed not to support BIER-TE, so traffic has to be unicast not to support BIER-TE, so traffic has to be unicast encapsulated
encapsulated across them. To emphasize non-L2, but routed/tunneled across them. To emphasize non-L2, but routed/tunneled forwarding of
forwarding of BIER-TE packets, these adjacencies are called BIER-TE packets, these adjacencies are called "forward_routed".
"forward_routed". Otherwise, there is no difference in their Otherwise, there is no difference in their processing over the
processing over the aforementioned "forward_connected" adjacencies. aforementioned "forward_connected" adjacencies.
In addition, bits are saved in the following example by assuming that In addition, bits are saved in the following example by assuming that
BFR1 only needs to be BFIR but not BFER or transit BFR. BFR1 only needs to be BFIR but not BFER or transit BFR.
BIER-TE Topology: BIER-TE Topology:
Diagram: Diagram:
p1 p3 p7 p1 p3 p7
....> BFR3 <.... p5 ....> BFR3 <.... p5
........ ........> ........ ........>
BFR1 (Rtr2) (Rtr5) BFR6 BFR1 (Rtr2) (Rtr5) BFR6
........ ........> ........ ........> p9
....> BFR4 <.... p6 ....> BFR4 <.... p6
p2 p4 p8 p2 p4 p8
(simplified) BIER-TE Bit Index Forwarding Tables (BIFT): (simplified) BIER-TE Bit Index Forwarding Tables (BIFT):
BFR1: p1 -> forward_routed() to BFR3 BFR1: p1 -> forward_routed() to BFR3
p2 -> forward_routed() to BFR4 p2 -> forward_routed() to BFR4
BFR3: p3 -> local_decap BFR3: p3 -> local_decap()
p5 -> forward_routed() to BFR6 p5 -> forward_routed() to BFR6
BFR4: p4 -> local_decap BFR4: p4 -> local_decap()
p6 -> forward_routed() to BFR6 p6 -> forward_routed() to BFR6
BFR6: p5 -> local_decap BFR6: p7 -> forward_routed() to BFR3
p6 -> local_decap
p7 -> forward_routed() to BFR3
p8 -> forward_routed() to BFR4 p8 -> forward_routed() to BFR4
p9 -> local_decap()
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 be received by BFR6,
(p1,p5). From BFR1 via BFR4 to BFR6 it is (p2,p6). A packet from the BitString is (p1,p5,p9). From BFR1 via BFR4 to be received by
BFR1 to BFR3,BFR4 and from BFR3 to BFR6 uses (p1,p2,p3,p4,p5). A BFR6, the BitString is (p2,p6,p9). A packet from BFR1 to be received
packet from BFR1 to BFR3,BFR4 and from BFR4 to BFR6 uses by BFR3,BFR4 and from BFR3 to be received by BFR6 uses
(p1,p2,p3,p4,p6). A packet from BFR1 to BFR4, and from BFR4 to BFR6 (p1,p2,p3,p4,p5,p9). A packet from BFR1 to be received by BFR3,BFR4
and from BFR6 to BFR3 uses (p2,p3,p4,p6,p7). A packet from BFR1 to and from BFR4 to be received by BFR6 uses (p1,p2,p3,p4,p6,p9). A
BFR3, and from BFR3 to BFR6 and from BFR6 to BFR4 uses packet from BFR1 to be received by BFR4, and from BFR4 to be received
(p1,p3,p4,p5,p8). by BFR6 and from there to be received by BFR3 uses
(p2,p3,p4,p6,p7,p9). A packet from BFR1 to be received by BFR3, and
from BFR3 to be received by BFR6 there to be received by BFR4 uses
(p1,p3,p4,p5,p8,p9).
2.2. BIER-TE Topology and adjacencies 2.2. BIER-TE Topology and adjacencies
The key new component in BIER-TE compared to (non-TE) BIER is the The key new component in BIER-TE compared to (non-TE) BIER is the
BIER-TE topology as introduced through the two examples in BIER-TE topology as introduced through the two examples in
Section 2.1. It is used to control where replication can or should Section 2.1. It is used to control where replication can or should
happen and how to minimize the required number of BP for adjacencies. happen and how to minimize the required number of BP for adjacencies.
The BIER-TE Topology consists of the BIFTs of all the BFR and can The BIER-TE Topology consists of the BIFTs of all the BFR and can
also be expressed as a directed graph where the edges are the also be expressed as a directed graph where the edges are the
adjacencies between the BFR labelled with the BP used for the adjacencies between the BFR labelled with the BP used for the
adjacency. Adjacencies are naturally unidirectional. BP can be adjacency. Adjacencies are naturally unidirectional. BP can be
reused across multiple adjacencies as long as this does not lead to reused across multiple adjacencies as long as this does not lead to
undesired duplicates or loops as explained further down in the text. undesired duplicates or loops as explained in Section 5.2.
If the BIER-TE topology represents (a subset of) the underlying If the BIER-TE topology represents (a subset of) the underlying
(layer 2) topology of the network as shown in the first example, this (layer 2) topology of the network as shown in the first example, this
may be called a "native" BIER-TE topology. A topology consisting may be called a "native" BIER-TE topology. A topology consisting
only of "forward_routed" adjacencies as shown in the second example only of "forward_routed" adjacencies as shown in the second example
may be called an "overlay" BIER-TE topology. A BIER-TE topology with may be called an "overlay" BIER-TE topology. A BIER-TE topology with
both "forward_connected" and "forward_routed" adjacencies may be both "forward_connected" and "forward_routed" adjacencies may be
called a "hybrid" BIER-TE topology. called a "hybrid" BIER-TE topology.
2.3. Relationship to BIER 2.3. Relationship to BIER
skipping to change at page 10, line 36 skipping to change at page 10, line 36
1. BIRTs are not required on BFRs for BIER-TE when using a BIER- 1. BIRTs are not required on BFRs for BIER-TE when using a BIER-
TE controller because the controller can directly populate TE controller because the controller can directly populate
the BIFTs. In BIER, BIRTs are populated by the distributed the BIFTs. In BIER, BIRTs are populated by the distributed
routing protocol support for BIER, allowing BFRs to populate routing protocol support for BIER, allowing BFRs to populate
their BIFTs locally from their BIRTs. Other BIER-TE control their BIFTs locally from their BIRTs. Other BIER-TE control
plane or management plane options may introduce requirements plane or management plane options may introduce requirements
for BIRTs for BIER-TE BFRs. for BIRTs for BIER-TE BFRs.
2. The BIER-TE layer forwarding plane does not require BFRs to 2. The BIER-TE layer forwarding plane does not require BFRs to
have a unique BP and therefore also no unique BFR-id. See have a unique BP and therefore also no unique BFR-id. See
for example See Section 5.1.3. Section 5.1.3.
3. Identification of BFRs by the BIER-TE control plane is 3. Identification of BFRs by the BIER-TE control plane is
outside the scope of this specification. Whereas the BIER outside the scope of this specification. Whereas the BIER
control plane uses BFR-ids in its BFR to BFR signaling, a control plane uses BFR-ids in its BFR to BFR signaling, a
BIER-TE controller may choose any form of identification BIER-TE controller may choose any form of identification
deemed appropriate. deemed appropriate.
4. BIER-TE forwarding does not use the BFR-id field of the BIER 4. BIER-TE forwarding does not use the BFR-id field of the BIER
packet header. packet header.
skipping to change at page 20, line 15 skipping to change at page 20, line 15
of the list's adjacencies to which the packet is forwarded. If the of the list's adjacencies to which the packet is forwarded. If the
packet's encapsulation contains an entropy field, the entropy field packet's encapsulation contains an entropy field, the entropy field
SHOULD be respected; two packets with the same value of the entropy SHOULD be respected; two packets with the same value of the entropy
field SHOULD be sent on the same adjacency. The seed parameter field SHOULD be sent on the same adjacency. The seed parameter
allows to design hash functions that are easy to implement at high allows to design hash functions that are easy to implement at high
speed without running into polarization issues across multiple speed without running into polarization issues across multiple
consecutive ECMP hops. See Section 5.1.7 for more explanations. consecutive ECMP hops. See Section 5.1.7 for more explanations.
4.2.4. Local Decap(sulation) 4.2.4. Local Decap(sulation)
A "local_decap" adjacency passes a copy of the payload of the BIER-TE A "local_decap()" adjacency passes a copy of the payload of the BIER-
packet to the protocol ("NextProto") within the BFR (IPv4/IPv6, TE packet to the protocol ("NextProto") within the BFR (IPv4/IPv6,
Ethernet,...) responsible for that payload according to the packet Ethernet,...) responsible for that payload according to the packet
header fields. A local_decap() adjacency turns the BFR into a BFER header fields. A local_decap() adjacency turns the BFR into a BFER
for matching packets. Local_decap() adjacencies require the BFER to for matching packets. Local_decap() adjacencies require the BFER to
support routing or switching for NextProto to determine how to support routing or switching for NextProto to determine how to
further process the packet. further process the packet.
4.3. Encapsulation / Co-existence with BIER 4.3. Encapsulation / Co-existence with BIER
Specifications for BIER-TE encapsulation are outside the scope of Specifications for BIER-TE encapsulation are outside the scope of
this document. This section gives explanations and guidelines. this document. This section gives explanations and guidelines.
skipping to change at page 21, line 7 skipping to change at page 21, line 7
be dynamically allocated from MPLS label space only for the set of be dynamically allocated from MPLS label space only for the set of
actually used SD:BSL BIFT. This allows to also allocate non- actually used SD:BSL BIFT. This allows to also allocate non-
overlapping label ranges for BIFT-id that are to be used with BIER-TE overlapping label ranges for BIFT-id that are to be used with BIER-TE
BIFTs. BIFTs.
With MPLS, it is also possible to reuse the same SD space for both With MPLS, it is also possible to reuse the same SD space for both
BIER-TE and BIER, so that the same SD has both a BIER BIFT and BIER-TE and BIER, so that the same SD has both a BIER BIFT and
corresponding range of BIFT-ids and a disjoint BIER-TE BIFT and non- corresponding range of BIFT-ids and a disjoint BIER-TE BIFT and non-
overlapping range of BIFT-ids. overlapping range of BIFT-ids.
When a fixed mapping from BSL, SD, SI is used without specifically When a fixed mapping from BSL, SD and SI to BIFT-id is used which
distinguishing BIER and BIER-TE, such as proposed for non-MPLS does not explicitly partition the BIFT-id space between BIER and
forwarding with [RFC8296] in [I-D.ietf-bier-non-mpls-bift-encoding] BIER-TE, such as proposed for non-MPLS forwarding with [RFC8296]
revision 04, section 5., then it is necessary to allocate disjoint encapsulation in [I-D.ietf-bier-non-mpls-bift-encoding] revision 04,
SDs to BIER and BIER-TE BIFT so that both can be addressed by the section 5., then it is necessary to allocate disjoint SDs to BIER and
BIFT-ids. The encoding proposed in section 6. of the same document BIER-TE BIFT so that both can be addressed by the BIFT-ids. The
does not statically encode BSL or SD into the BIFT-id, but allows for encoding proposed in section 6. of the same document does not
a mapping, and hence could provide for the same freedom as when MPLS statically encode BSL or SD into the BIFT-id, but allows for a
is being used (same or different SD for BIER/BIER-TE). mapping, and hence could provide for the same freedom as when MPLS is
being used (same or different SD for BIER/BIER-TE).
"forward_routed" requires an encapsulation that permits to direct "forward_routed" requires an encapsulation that permits to direct
unicast encapsulated BIER-TE packets to a specific interface address unicast encapsulated BIER-TE packets to a specific interface address
on a target BFR. With MPLS encapsulation, this can simply be done on a target BFR. With MPLS encapsulation, this can simply be done
via a label stack with that addresses label as the top label - via a label stack with that addresses label as the top label -
followed by the label assigned to the (BSL,SD,SI) BitString. With followed by the label assigned to the (BSL,SD,SI) BitString. With
non-MPLS encapsulation, some form of IP encapsulation would be non-MPLS encapsulation, some form of IP encapsulation would be
required (for example IP/GRE). required (for example IP/GRE).
The encapsulation used for "forward_routed" adjacencies can equally The encapsulation used for "forward_routed" adjacencies can equally
skipping to change at page 24, line 5 skipping to change at page 24, line 5
When an adjacency has DNC set, this bit position is set again When an adjacency has DNC set, this bit position is set again
only for the packet copy towards that bit position. only for the packet copy towards that bit position.
o BIFT entries may contain more than one adjacency in support of o BIFT entries may contain more than one adjacency in support of
specific configurations such as Section 5.1.5. The code therefore specific configurations such as Section 5.1.5. The code therefore
includes a loop over these adjacencies. includes a loop over these adjacencies.
o The ECMP adjacency is shown. Its parameters are a seed and a o The ECMP adjacency is shown. Its parameters are a seed and a
ListOfAdjacencies from which one is picked. ListOfAdjacencies from which one is picked.
o The forward_local, forward_routed, local_decap() adjacencies are o The forward_connected(), forward_routed(), local_decap()
shown with their parameters. adjacencies are shown with their parameters.
void ForwardBitMaskPacket_withTE (Packet) void ForwardBitMaskPacket_withTE (Packet)
{ {
SI = GetPacketSI(Packet); SI = GetPacketSI(Packet);
Offset = SI * BitStringLength; Offset = SI * BitStringLength;
// Determine adjacent bits in the Packets BitString // Determine adjacent bits in the Packets BitString
PktAdjacentBits = Packet->BitString & AdjacentBits[SI]; PktAdjacentBits = Packet->BitString & AdjacentBits[SI];
// Clear adjacent bits in Packet header to avoid loops // Clear adjacent bits in Packet header to avoid loops
Packet->BitString &= ~AdjacentBits[SI]; Packet->BitString &= ~AdjacentBits[SI];
skipping to change at page 27, line 12 skipping to change at page 27, line 12
an adjacency for p11. p11 is a "local_decap" adjacency installed by an adjacency for p11. p11 is a "local_decap" adjacency installed by
the BIER-TE Controller to receive a copy of the BIER packet - dispose the BIER-TE Controller to receive a copy of the BIER packet - dispose
of the BIER header and pass the payload to IP multicast. IP of the BIER header and pass the payload to IP multicast. IP
multicast will then forward the packet out to LAN2 because it did multicast will then forward the packet out to LAN2 because it did
receive PIM or IGMP joins on LAN2 for the traffic. receive PIM or IGMP joins on LAN2 for the traffic.
Further processing of the packet in BFR4, BFR5 and BFER2 accordingly. Further processing of the packet in BFR4, BFR5 and BFER2 accordingly.
4.6. BFR Requirements for BIER-TE forwarding 4.6. BFR Requirements for BIER-TE forwarding
BFR MUST support to configure the BIFT of sub-domains so that they BFR that support BIER-TE and BIER MUST support configuration that
use BIER-TE forwarding rules instead of (non-TE) BIER forwarding enables BIER-TE instead of (non-TE) BIER forwarding rules for all
rules. Every BP in the BIFT MUST support to have zero or one BIFT of one or more BIER sub-domains. Every BP in a BIER-TE BIFT
adjacency. Forwarding MUST support the adjacency types MUST support to have zero or one adjacency. BIER-TE forwarding MUST
forward_connected() with clear DNC flag, forward_routed() and support the adjacency types forward_connected() with clear DNC flag,
local_decap. As explained in Section 4.4, these REQUIRED BIER-TE forward_routed() and local_decap. As explained in Section 4.4, these
forwarding functions can be implementeded via the same Forwarding REQUIRED BIER-TE forwarding functions can be implementeded via the
Pseudocode as BIER forwarding except for one modification (skipping same Forwarding Pseudocode as BIER forwarding except for one
one masking with F-BM). modification (skipping one masking with F-BM).
BIER-TE forwarding SHOULD support forward_connected() adjacencies BIER-TE forwarding SHOULD support forward_connected() adjacencies
with a set DNC flag, as this is highly useful to save bits in rings with a set DNC flag, as this is highly useful to save bits in rings
(see Section 5.1.6). (see Section 5.1.6).
BIER-TE forwarding SHOULD support more than one adjacency on a bit. BIER-TE forwarding SHOULD support more than one adjacency on a bit.
This allows to save bits in hub&spoke scenarios (see Section 5.1.5). This allows to save bits in hub&spoke scenarios (see Section 5.1.5).
BIER-TE forwarding MAY support ECMP adjacencies to save bits in ECMP BIER-TE forwarding MAY support ECMP adjacencies to save bits in ECMP
scenarios, see Section 5.1.7 for an example. This is a MAY scenarios, see Section 5.1.7 for an example. This is a MAY
skipping to change at page 30, line 28 skipping to change at page 30, line 28
links can share the same bit position. The bit position on the hub's links can share the same bit position. The bit position on the hub's
BIFT is set up with a list of forward_connected() adjacencies, one BIFT is set up with a list of forward_connected() adjacencies, one
for each Spoke. for each Spoke.
This option is similar to the bit position optimization in LANs: This option is similar to the bit position optimization in LANs:
Redundantly connected spokes need their own bit positions, unless Redundantly connected spokes need their own bit positions, unless
they are themselves Leaf-BFER. they are themselves Leaf-BFER.
This type of optimized BP could be used for example when all traffic This type of optimized BP could be used for example when all traffic
is "broadcast" traffic (very dense receiver set) such as live-TV or is "broadcast" traffic (very dense receiver set) such as live-TV or
situation-awareness (SA). This BP optimization can then be used to many-to-many telemetry including situation-awareness (SA). This BP
explicitly steer different traffic flows across different ECMP paths optimization can then be used to explicitly steer different traffic
in Data-Center or broadband-aggregation networks with minimal use of flows across different ECMP paths in Data-Center or broadband-
BPs. aggregation networks with minimal use of BPs.
5.1.6. Rings 5.1.6. Rings
In L3 rings, instead of assigning a single bit position for every p2p In L3 rings, instead of assigning a single bit position for every p2p
link in the ring, it is possible to save bit positions by setting the link in the ring, it is possible to save bit positions by setting the
"DoNotClear" (DNC) flag on forward_connected() adjacencies. "DoNotClear" (DNC) flag on forward_connected() adjacencies.
For the rings shown in Figure 12, a single bit position will suffice For the rings shown in Figure 12, a single bit position will suffice
to forward traffic entering the ring at BFRa or BFRb all the way up to forward traffic entering the ring at BFRa or BFRb all the way up
to BFR1: to BFR1:
skipping to change at page 46, line 44 skipping to change at page 46, line 44
indicate a sequence of SID to reach the destination. This is what indicate a sequence of SID to reach the destination. This is what
BIER-TE and its adjacency scoped BP enables. BIER-TE and its adjacency scoped BP enables.
7. Security Considerations 7. Security Considerations
If [RFC8296] is used, BIER-TE shares its security considerations. If [RFC8296] is used, BIER-TE shares its security considerations.
BIER-TE shares the security considerations of BIER, [RFC8279], with BIER-TE shares the security considerations of BIER, [RFC8279], with
the following overriding or additional considerations. the following overriding or additional considerations.
BIER-TE forwarding explicitly supports unicast "tunneling" of BIER
packets via forward_routed() adjacencies. The BIER domain security
model is based on a subset of interfaces on a BFR that connect to
other BFR of the same BIER domain. For BIER-TE, this security model
equally applies to such unicast "tunneled" BIER packets. This does
not only include the need to filter received unicast "tunneled" BIER
packets to prohibit injection of such "tunneled" BIER packets from
outside the BIER domain, but also prohibiting forward_routed()
adjacencies to leak BIER packets from the BIER domain. It SHOULD be
possible to configure interfaces to be part of a BIER domain solely
for sending and receiving of unicast "tunneled" BIER packets even if
the interface can not send/receive BIER encapsulated packets.
In BIER, the standardized methods for the routing underlays are IGPs In BIER, the standardized methods for the routing underlays are IGPs
with extensions to distribute BFR-ids and BFR-prefixes. [RFC8401] with extensions to distribute BFR-ids and BFR-prefixes. [RFC8401]
specifies the extensions for IS-IS and [RFC8444] specifies the specifies the extensions for IS-IS and [RFC8444] specifies the
extensions for OSPF. Attacking the protocols for the BIER routing extensions for OSPF. Attacking the protocols for the BIER routing
underlay or (non-TE) BIER layer control plane, or impairment of any underlay or (non-TE) BIER layer control plane, or impairment of any
BFR in a domain may lead to successful attacks against the results of BFR in a domain may lead to successful attacks against the results of
the routing protocol, enabling DoS attacks against paths or the the routing protocol, enabling DoS attacks against paths or the
addressing (BFR-id, BFR-prefixes) used by BIER. addressing (BFR-id, BFR-prefixes) used by BIER.
The reference model for the BIER-TE layer control plane is a BIER-TE The reference model for the BIER-TE layer control plane is a BIER-TE
skipping to change at page 48, line 21 skipping to change at page 48, line 35
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Greg Shepherd, Ijsbrand Wijnands, The authors would like to thank Greg Shepherd, Ijsbrand Wijnands,
Neale Ranns, Dirk Trossen, Sandy Zheng, Lou Berger, Jeffrey Zhang, Neale Ranns, Dirk Trossen, Sandy Zheng, Lou Berger, Jeffrey Zhang,
Carsten Borman and Wolfgang Braun for their reviews and suggestions. Carsten Borman and Wolfgang Braun for their reviews and suggestions.
Special thanks to Xuesong Geng for shepherding the document and for Special thanks to Xuesong Geng for shepherding the document and for
IESG review/suggestions by Alvaro Retana (responsible AD/RTG), IESG review/suggestions by Alvaro Retana (responsible AD/RTG),
Benjamin Kaduk (SEC), Tommy Pauly (TSV), Zaheduzzaman Sarker (TSV), Benjamin Kaduk (SEC), Tommy Pauly (TSV), Zaheduzzaman Sarker (TSV),
Eric Vyncke (INT), Martin Vigoureux (RTG), Robert Wilton (OPS), Eric Eric Vyncke (INT), Martin Vigoureux (RTG), Robert Wilton (OPS), Eric
Kline (INT), Lars Eggert (GEN). Kline (INT), Lars Eggert (GEN), Roman Danyliv (SEC), Ines Robles
(RTGDIR).
10. Change log [RFC Editor: Please remove] 10. Change log [RFC Editor: Please remove]
draft-ietf-bier-te-arch: draft-ietf-bier-te-arch:
12: 12:
RTGDIR review Ines Robles.
Fixed up adjacencies in Example 2 and explanation text to be
explicit about which BFR not only passes, but also receives the
packet.
7. (security considerations). Added paragraph about
forward_routed() and prohibiting BIER packet leaking in/out of
domain.
IESG review Roman Danyliv (SEC).
Several textual/sentence nits/editorials.
IESG review Lars Eggert (GEN). IESG review Lars Eggert (GEN).
Various good editorial word fixed. Various good editorial word fixed.
Pointer to non-false-positive bloom filter work that looks like it Pointer to non-false-positive bloom filter work that looks like it
happened after our IETF discussions documented in this doc, so happened after our IETF discussions documented in this doc, so
will not add it to doc, but here is URL for folks interested: will not add it to doc, but here is URL for folks interested:
https://ieeexplore.ieee.org/document/8486415. https://ieeexplore.ieee.org/document/8486415.
Did not change "native" to a different word for inclusivity Did not change "native" to a different word for inclusivity
 End of changes. 29 change blocks. 
67 lines changed or deleted 99 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/