BGP for BIER-TE Path
draft-chen-idr-bier-te-path-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Huaimo Chen , Mike McBride , Ran Chen , Gyan Mishra , Aijun Wang , Yisong Liu , Yanhe Fan , Lei Liu , Xufeng Liu | ||
| Last updated | 2021-07-11 | ||
| Replaced by | draft-ietf-idr-bier-te-path | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-idr-bier-te-path-00
Network Working Group H. Chen
Internet-Draft M. McBride
Intended status: Standards Track Futurewei
Expires: January 12, 2022 R. Chen
ZTE Corporation
G. Mishra
Verizon Inc.
A. Wang
China Telecom
Y. Liu
China Mobile
Y. Fan
Casa Systems
L. Liu
Fujitsu
X. Liu
Volta Networks
July 11, 2021
BGP for BIER-TE Path
draft-chen-idr-bier-te-path-00
Abstract
This document describes extensions to Border Gateway Protocol (BGP)
for distributing a Bit Index Explicit Replication Traffic Engineering
(BIER-TE) path. A new Tunnel Type for BIER-TE path is defined to
encode the information about a BIER-TE path.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Chen, et al. Expires January 12, 2022 [Page 1]
Internet-Draft BIER-TE Path July 2021
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of BGP for BIER-TE Path . . . . . . . . . . . . . . 4
3.1. Example BIER-TE Topology with BGP . . . . . . . . . . . . 4
3.2. BIER-TE BIFT on a BFR . . . . . . . . . . . . . . . . . . 6
3.3. Distributing Path to Ingress . . . . . . . . . . . . . . 7
4. Extensions to BGP . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Extensions to PMSI_TUNNEL Attribute . . . . . . . . . . . 9
4.1.1. New Tunnel Type for BIER-TE . . . . . . . . . . . . . 9
4.1.2. Sub-TLVs for BIER-TE Path . . . . . . . . . . . . . . 11
4.2. Extensions to Tunnel Encapsulation Attribute . . . . . . 13
4.2.1. New Tunnel Type for BIER-TE . . . . . . . . . . . . . 14
4.2.2. Traffic Description Sub-TLVs . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
[I-D.ietf-bier-te-arch] introduces Bit Index Explicit Replication
(BIER) Tree Engineering (BIER-TE). It is an architecture for per-
packet stateless explicit point to multipoint (P2MP) multicast path/
Chen, et al. Expires January 12, 2022 [Page 2]
Internet-Draft BIER-TE Path July 2021
tree, which is called BIER-TE path, and based on the BIER
architecture defined in [RFC8279].
A Bit-Forwarding Router (BFR) in a BIER-TE domain has a BIER-TE Bit
Index Forwarding Table (BIFT). A BIER-TE BIFT on a BFR comprises a
forwarding entry for a BitPosition (BP) assigned to each of the
adjacencies of the BFR. If the BP represents a forward connected
adjacency, the forwarding entry for the BP forwards the multicast
packet with the BP to the directly connected BFR neighbor of the
adjacency. If the BP represents a BFER (i.e., egress node) or say a
local decap adjacency, the forwarding entry for the BP decapsulates
the multicast packet with the BP and passes a copy of the payload of
the packet to the packet's NextProto within the BFR.
A Bit-Forwarding Ingress Router (BFIR) in a BIER-TE domain receives
the information or instructions about which multicast flows/packets
are mapped to which BIER-TE paths that are represented by
BitPositions or say BitStrings. After receiving the information or
instructions, the ingress node/router encapsulates the multicast
packets with the BitPositions for the corresponding BIER-TE paths,
replicates and forwards the packets with the BitPositions along the
BIER-TE paths.
This document proposes some procedures and extensions to BGP for
distributing a BIER-TE path to the Bit-Forwarding Ingress Router
(BFIR) of the path. It specifies a way of encoding the information
about a BIER-TE path in a BGP UPDATE message, which can be
distributed to the BFIR of the path.
2. Terminologies
The following terminologies are used in this document.
BIER: Bit Index Explicit Replication.
BIER-TE: BIER Tree Engineering.
BFR: Bit-Forwarding Router.
BFIR: Bit-Forwarding Ingress Router.
BFER: Bit-Forwarding Egress Router.
BFR-id: BFR Identifier. It is a number in the range [1,65535].
BFR-NBR: BFR Neighbor.
BFR-prefix: An IP address (either IPv4 or IPv6) of a BFR.
Chen, et al. Expires January 12, 2022 [Page 3]
Internet-Draft BIER-TE Path July 2021
BIRT: Bit Index Routing Table. It is a table that maps from the BFR-
id (in a particular sub-domain) of a BFER to the BFR-prefix of
that BFER, and to the BFR-NBR on the path to that BFER.
BIFT: Bit Index Forwarding Table.
P-tunnel: A multicast tunnel through the network of one or more SPs.
PMSI: Provider Multicast Service Interface. PMSI is an abstraction
that represents a multicast service for carrying packets. A
PMSI is instantiated via one or more P-tunnels.
I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route.
S-PMSI A-D route: Selective PMSI Auto-Discovery route.
x-PMSI A-D route: A route that is either an I-PMSI A-D route or an
S-PMSI A-D route.
3. Overview of BGP for BIER-TE Path
This section briefs the BGP for BIER-TE path and illustrates some
details through a simple example BIER-TE topology.
3.1. Example BIER-TE Topology with BGP
An example BIER-TE domain topology using SDN controllor with a BGP to
distribute BIER-TE path is shown in Figure 1. There are 8 nodes/BFRs
A, B, C, D, E, F, G and H in the domain. Nodes/BFRs A, H, E, F and D
are BFIRs (i.e., ingress nodes) or BFERs (i.e., egress nodes). The
controller has a BGP session with each of the edge nodes in the
domain, including BFIRs (i.e., ingress nodes A, H, E, F and D), and
each of the non edge nodes in the domain (i.e., nodes B, C and G).
Note that some of connections and the BGP on each edge node are not
shown in the figure.
Chen, et al. Expires January 12, 2022 [Page 4]
Internet-Draft BIER-TE Path July 2021
+------------------------------------+
| SND controller with BGP |
+------------------------------------+
/ ... \ \
/ \ \
/ 4' \ 17' 18' \
/ /-----------( G )----------( H )
/ / 19'\_______ 12'/4
/ / _______)____/
/ / / (_____
/ /3' / \
/ 1' 2' / 5' 6' /11' 13' 20'\
(CE) --- ( A )--------( B )------------( C )------------( D )
5 \7' \15' 14' 1
\ \
\8' 9' 10' \16'
( E )------------( F )
3 2
Figure 1: Example BIER-TE Topology with Controller
Nodes/BFRs D, F, E, H and A are BFERs (or BFIRs) and have local decap
adjacency BitPositions 1, 2, 3, 4, and 5 respectively. For
simplicity, these BPs are represented by (SI:BitString), where SI = 0
and BitString is of 8 bits. BPs 1, 2, 3, 4, and 5 are represented by
1 (0:00000001), 2 (0:00000010), 3 (0:00000100), 4 (0:00001000) and 5
(0:00010000) respectively.
The BitPositions for the forward connected adjacencies are
represented by i', where i is from 1 to 20. In one option, they are
encoded as (n+i), where n is a power of 2 such as 32768. For
simplicity, these BitPositions are represented by (SI:BitString),
where SI = (6 + (i-1)/8) and BitString is of 8 bits. BitPositions i'
(i from 1 to 20) are represented by 1'(6:00000001), 2'(6:00000010),
3'(6:00000100), 4'(6:00001000), 5'(6:00010000), 6'(6:00100000),
7'(6:01000000), 8'(6:10000000), 9'(7:00000001), 10'(7:00000010), . .
. , 16'(7:10000000), 17'(8:00000001), 18'(8:00000010), . . . ,
20'(8:00001000).
For a link between two nodes X and Y, there are two BitPositions for
two forward connected adjacencies. These two forward connected
adjacency BitPositions are assigned on nodes X and Y respectively.
The BitPosition assigned on X is the forward connected adjacency from
Y to X. The BitPosition assigned on Y is the forward connected
adjacency from X to Y.
For example, for the link between nodes B and C in the figure, two
forward connected adjacency BitPositions 5' and 6' are assigned to
Chen, et al. Expires January 12, 2022 [Page 5]
Internet-Draft BIER-TE Path July 2021
two ends of the link. BitPosition 5' is assigned on node B to B's
end of the link. It is the forward connected adjacency from C to B.
BitPosition 6' is assigned on node C to C's end of the link. It is
the forward connected adjacency from B to C.
3.2. BIER-TE BIFT on a BFR
Every BFR in a BIER-TE domain has a BIER-TE BIFT. For the BIER-TE
topology in Figure 1, each of 8 nodes/BFRs A, B, C, D, E, F, G and H
has its BIER-TE BIFT for the topology.
The controller sends each BFR all its BitPositions including its
local decap adjacency BitPosition and forward connected adjacency
BitPositions after the BitPositions are determined and assigned in
the controller. For example, the controller sends BFR A BitPosition
1 and BitPosition 2', where the former is A's local decap adjacency
BitPosition and the latter is A's forward connected adjacency
BitPosition from A to B. The controller sends BFR B BitPositions 1',
4', 6' and 8', which are B's forward connected adjacency BitPositions
from B to A, G, C and E respectively.
When a BFR (i.e., the BGP running on the BFR) receives its
BitPositions from the controller, it creates its BIER-TE BIFT based
on them. For example, when BFR A receives its BitPositions, it
creates its BIER-TE BIFT, which is shown in Figure 2. There are two
forwarding entries in the BIFT.
The 1st forwarding entry in the BIFT will locally decapsulate a
multicast packet with BitPosition 5 and pass a copy of the payload of
the packet to the packet's NextProto.
The 2nd forwarding entry in the BIFT will forward a multicast packet
with BitPosition 2' to B.
+------------------+--------------+------------+
| Adjacency BP | Action | BFR-NBR |
| (SI:BitString) | | (Next Hop) |
+==================+==============+============+
| 5 (0:00000005) | local-decap | |
+------------------+--------------+------------+
| 2' (6:00000010) | fw-connected | B |
+------------------+--------------+------------+
Figure 2: BIER-TE BIFT on BFR A
When BFR B receives its BitPositions 1', 4', 6' and 8', it creates
its BIER-TE BIFT, which is shown in Figure 3. There are four
forwarding entries in the BIFT.
Chen, et al. Expires January 12, 2022 [Page 6]
Internet-Draft BIER-TE Path July 2021
The 1st forwarding entry in the BIFT will forward a multicast packet
with BitPosition 1' to A.
The 2nd forwarding entry in the BIFT will forward a multicast packet
with BitPosition 4' to G.
The 3rd forwarding entry in the BIFT will forward a multicast packet
with BitPosition 6' to C.
The 4-th forwarding entry in the BIFT will forward a multicast packet
with BitPosition 8' to E.
+------------------+--------------+------------+
| Adjacency BP | Action | BFR-NBR |
| (SI:BitString) | | (Next Hop) |
+==================+==============+============+
| 1' (6:00000001) | fw-connected | A |
+------------------+--------------+------------+
| 4' (6:00001000) | fw-connected | G |
+------------------+--------------+------------+
| 6' (6:00100000) | fw-connected | C |
+------------------+--------------+------------+
| 8' (6:10000000) | fw-connected | E |
+------------------+--------------+------------+
Figure 3: BIER-TE BIFT on BFR B
3.3. Distributing Path to Ingress
This section describes how the SDN controller distributes a BIER-TE
path to its ingress node.
There are two scenarios for distributing the BIER-TE path
information. In the first scenario, the ingress node is directly
connected to the controller. The path information should not be
propagated beyond the ingress node. In the second scenario, the
ingress node is not directly connected to the controller. The path
information should be propagated throughout the domain until it
reaches the ingress node.
Suppose that node A in Figure 1 wants to have a BIER-TE path from
ingress node A to egress nodes H and F. The path satisfies a set of
constraints. The controller obtains the request from an application
or user configuration. It finds a BIER-TE path satisfying the
constraints and distributes the path to ingress node A.
If A is directly connected to the controller (e.g., as the example
network in Figure 1), then the controller sends A the information
Chen, et al. Expires January 12, 2022 [Page 7]
Internet-Draft BIER-TE Path July 2021
about the path in a Update message in one of two ways. In one way,
the controller sends each of its BGP peers, including the BGP peer
running on node A, a Update message about the explicit path, with a
route target matching the BGP identifier of ingress node A, and
NO_ADVERTISE community. Ingress node A accepts this message from the
controller and installs a forwarding entry for the BIER-TE path, but
will not advertise it to any peer. All the other peers do not accept
the message.
In another way, the controller sends A a Update message directly
through the local session between them, but does not send the message
to any other peers, which contains the information about the path, a
route target matching the BGP identifier of ingress node A (the route
target may be optional), and the NO_ADVERTISE community. Ingress
node A accepts this message from the controller and installs a
forwarding entry for the BIER-TE path, but will not advertise it.
If A is not directly connected to the controller, then the controller
distributes the information about the explicit path to the ingress
node A across the network. To achieve this, the controller
advertises a BGP Update message to all its BGP peers, where the
message contains the information about the path, a route target
matching the BGP identifier of ingress node A, but does not have
NO_ADVERTISE community. Each of the BGP peers advertises the
received Update to its BGP neighbors according to normal BGP
propagation rules. Eventually, ingress node A accepts this message
and installs a forwarding entry for the BIER-TE path, which imports
the packets to be transported by the path into the path.
For example, assume that the BIER-TE path computed by the controller
traverses the link/adjacency from A to B (indicated by BP 2'), the
link/adjacency from B to G (indicated by BP 4') and the link/
adjacency from B to C (indicated by BP 6'), the link/adjacency from G
to H (indicated by BP 18'), and the link/adjacency from C to F
(indicated by BP 16'). This path is represented by {2', 4', 6', 16',
18', 2, 4}, where BitPositions 2 and 4 indicate egress nodes F and H
respectively. The Update message distributed to the BGP on node A by
the controller contains the path represented by {2', 4', 6', 16',
18', 2, 4}.
After receiving the BIER-TE path, the ingress node installs a
forwarding entry for the path. For any packet from CE to be
transported by the path, the ingress node encapsulates the packet
with the BitPositions representing the path and forwards the packet
according to its BIFT.
For example, when ingress node A receives the path represented by
BitPositions {2', 4', 6', 16', 18', 2, 4}, it installs a forwarding
Chen, et al. Expires January 12, 2022 [Page 8]
Internet-Draft BIER-TE Path July 2021
entry for the path. Node A encapsulates a packet to be carried by
the path with a BIER header containing BitPositions {2', 4', 6', 16',
18', 2, 4} using the entry and forwards the encapsulated packet along
the path according to its BIFT.
A forwards the packet to B according to the forwarding entry for BP
2' in its BIFT.
After receiving the packet from A, B forwards the packet to G and C
according to the forwarding entries for BPs 4' and 6' in B's BIFT
respectively. The packet received by G has path {16', 18', 2, 4}.
The packet received by C has path {16', 18', 2, 4}.
After receiving the packet from B, G sends the packet to H according
to the forwarding entry for BP 18' in G's BIFT.
After receiving the packet from B, C sends the packet to F according
to the forwarding entry for BP 16' in C's BIFT.
Egress node H of the BIER-TE path receives the packet with
BitPosition 4. It decapsulates the packet and pass the payload of
the packet to the packet's NextProto.
Egress node F of the BIER-TE path receives the packet with
BitPosition 2. It decapsulates the packet and pass the payload of
the packet to the packet's NextProto.
4. Extensions to BGP
This section specifies two options for extensions to BGP. One option
defines a new Tunnel Type for BIER-TE path under Tunnel Encapsulation
Attribute. The other defines a new Tunnel Type under PMSI_TUNNEL
Attribute.
4.1. Extensions to PMSI_TUNNEL Attribute
This section defines a new Tunnel Type (or TLV) for BIER-TE path/
tunnel under the PMSI_TUNNEL Attribute (PTA) defined in [RFC6514].
It describes a couple of new sub-TLVs encoding the information about
a BIER-TE path.
4.1.1. New Tunnel Type for BIER-TE
The PMSI Tunnel attribute carried by an x-PMSI A-D route identifies
P-tunnel for PMSI. For the PTA with Tunnel Type BIER-TE, the PTA is
constructed by the SDN controller and distributed to the ingress node
of the BIER-TE tunnel.
Chen, et al. Expires January 12, 2022 [Page 9]
Internet-Draft BIER-TE Path July 2021
The format of the PMSI_TUNNEL Attribute with the new Tunnel Type
(TBD) for BIER-TE is shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr Flags | Attr Type(22) | Length(1/2 byte) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag |TunnelType(TBD)| MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label | Tunnel Identifier (11/23 bytes) |
+-+-+-+-+-+-+-+-+ +
| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PTA with Tunnel Type for BIER-TE
For BIER-TE tunnel/path, the fields in the PTA are set as follows:
o Tunnel Type: It is set to be TBD, indicating BIER-TE tunnel.
o Tunnel Identifier: It contains:
* sub-domain-id (1 octet): It is id of the sub domain through
which the BIER-TE tunnel crosses.
* BFR-id (2 octets): It is the BFR-id of the BFIR of the
BIER-TE tunnel.
* Tunnel-ID (4 octets): It is a number uniquely identifying a
BIER-TE tunnel within the BFIR and sub domain.
* BFR-prefix (4/16 octets): It is a BFR-prefix of the BFIR of
the BIER-TE tunnel. It occupies 4 octets for IPv4 and 16
octets for IPv6.
o sub-TLVs: It contains a Path BitPositions sub-TLV encoding an
explicit BIER-TE path. It may include a Path Name sub-TLV for
the name of the BIER-TE path.
o Others: The other fields are set according to [RFC6514].
Chen, et al. Expires January 12, 2022 [Page 10]
Internet-Draft BIER-TE Path July 2021
4.1.2. Sub-TLVs for BIER-TE Path
This section describes two sub-TLVs for a BIER-TE path: Path
BitPositions sub-TLV for encoding the path and Path Name sub-TLV for
the name of the path.
4.1.2.1. Path BitPositions Sub-TLV
The bit positions of a BIER-TE path are encoded in a Path
BitPositions sub-TLV. The format of the sub-TLV is illustrated
below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length (variable) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI-Len | BitStringLen | sub-domain-id | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id-1 | RSV | SI-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString-1 ~
| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id-n | RSV | SI-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString-n ~
| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Path BitPositions Sub-TLV Format
Type: Its value (TBD1) is to be assigned by IANA.
Length: It is variable.
Reserved/RSV: MUST be set to zero by the sender and MUST be ignored
by the receiver.
SI-Len (SI Length) - 8 bits: The length in bits of the SI field.
BitStringLen (Bit String Length) - 8 bits: The length in bits of the
BitString field according to [RFC8296]. If k is the length of the
BitString, the value of BitStringLen is log2(k)-5. For example,
Chen, et al. Expires January 12, 2022 [Page 11]
Internet-Draft BIER-TE Path July 2021
BitStringLen = 1 indicates k = 64, BitStringLen = 7 indicates k =
4096.
sub-domain-id: Unique value identifying the BIER sub-domain within
the BIER domain.
MT-ID: Multi-Topology ID identifying the topology that is associated
with the BIER sub-domain.
BIFT-id, SI, BitString tuple: Each BIFT-id-i, SI-i and BitString-i
(i = 1, 2, ..., n) tuple represents/encodes a set of bit positions
on the BIER-TE path with a BIFT ID. All the BIFT-id, SI and
BitString tuples in the sub-TLV represent/encode the BIER-TE path
(i.e., all the bit positions of the BIER-TE path).
For example, when SI-Len = 8 and BitStringLen = 1 (indicating
BitString is of 64 bits), each BIFT-id, SI and BitString tuple has a
BIFT-id of 20 bits, a SI of 8 bits and a BitString of 64 bits. For
simplicity, BitString of 8 bits and BIFT-id of 16 bits are used
below. The BitPositions for a BIER-TE path are sorted in descending
order before they are put into a BIER-TE Path BitPositions sub-TLV.
For BIER-TE path {2', 4', 6', 16', 18', 2, 4}, when its BitPositions
are sorted, it is {18', 16', 6', 4', 2', 4, 2}, which is
{18'(8:00000010), 16'(7:10000000), 6'(6:00100000), 4'(6:00001000),
2'(6:00000010), 4 (0:00001000), 2 (0:00000010)}. The BitPositions
with the same SI are stored in one BitString. For example,
6'(6:00100000), 4'(6:00001000) and 2'(6:00000010) are stored in
(SI:BitString) = (6:00101010), where SI = 6. BIER-TE path {18', 16',
6', 4', 2', 4, 2} is encoded in the Path BitPositions sub-TLV in the
figure below. The path uses four tuples of BIFT-id, SI and
BitString.
Chen, et al. Expires January 12, 2022 [Page 12]
Internet-Draft BIER-TE Path July 2021
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length = 13 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI-Len = 8 | BitStringLen |sub-domain-id=0| MT-ID = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id-1 = 100 | SI-1 = 8 |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id-2 = 200 | SI-2 = 7 |1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id-3 = 300 | SI-3 = 6 |0 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id-4 = 400 | SI-4 = 0 |0 0 0 0 1 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Path BitPositions sub-TLV for a BIER-TE Path
4.1.2.2. Path Name Sub-TLV
The name of a BIER-TE path is encoded in a Path Name sub-TLV. The
format of the sub-TLV is illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD2) | Length (variable) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Path Name String //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Path Name Sub-TLV Format
Type: Its value (TBD2) is to be assigned by IANA.
Length: It is variable.
Reserved: MUST be set to zero by the sender and MUST be ignored by
the receiver.
Path Name String: It represents/encodes the name of the BIER-TE path
in a string of chars.
4.2. Extensions to Tunnel Encapsulation Attribute
This section define a new Tunnel Type (or say TLV) for BIER-TE path/
tunnel under Tunnel Encapsulation Attribute.
Chen, et al. Expires January 12, 2022 [Page 13]
Internet-Draft BIER-TE Path July 2021
4.2.1. New Tunnel Type for BIER-TE
A new Tunnel Type (or say TLV), called BIER-TE Path or Tunnel, is
defined under Tunnel Encapsulation Attribute in [RFC9012]. Its
codepoint is to be assigned by IANA. This new TLV with a number of
new sub-TLVs encodes the information about a BIER-TE path.
The structure encoding the information about a BIER-TE path is shown
below.
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type (TBD): BIER-TE Path
Path BitPositions sub-TLV
Path Name sub-TLV
Traffic Description sub-TLV
Where:
o Tunnel Type (TBD) is to be assigned by IANA.
o Path BitPositions sub-TLV encodes the bit positions of the BIER-TE
path. It is defined in the previous section.
o Path Name sub-TLV encodes the name of a BIER-TE path. It is
defined in the previous section.
o Traffic Description sub-TLV encodes the multicast traffic that is
transported by the BIER-TE path.
4.2.2. Traffic Description Sub-TLVs
A Traffic Description Sub-TLV describes the traffic to be imported
into a BIER-TE path. Two Traffic Description Sub-TLVs are defined.
They are multicast traffic sub-TLVs for IPv4 and IPv6.
The multicast traffic sub-TLVs for IPv4 and IPv6 are shown in
Figure 8 and Figure 9 respectively.
Chen, et al. Expires January 12, 2022 [Page 14]
Internet-Draft BIER-TE Path July 2021
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD3) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|G| Src Mask Len | Grp Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (up to 4 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Multicast Address (up to 4 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Multicast Traffic for IPv4 Sub-TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD4) | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|G| Src Mask Len | Grp Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address ~
~ (up to 16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address ~
~ (up to 16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Multicast Traffic for IPv6 Sub-TLV
The address fields and address mask lengths of the two Multicast
Traffic sub-TLVs contain source and group prefixes for matching
against packets noting that the two address fields are up to 32 bits
for an IPv4 Multicast Traffic and up to 128 bits for an IPv6
Multicast Traffic.
The Reserved field MUST be set to zero and ignored on receipt.
Two bit flags (S and G) are defined to describe the multicast
wildcarding in use. If the S bit is set, then source wildcarding is
in use and the values in the Source Mask Length and Source Address
fields MUST be ignored. If the G bit is set, then group wildcarding
is in use and the values in the Group Mask Length and Group multicast
Address fields MUST be ignored. The G bit MUST NOT be set unless the
S bit is also set: if a Multicast Traffic sub-TLV is received with S
bit = 0 and G bit = 1 the receiver MUST respond with an error
(Malformed Multicast Traffic).
Chen, et al. Expires January 12, 2022 [Page 15]
Internet-Draft BIER-TE Path July 2021
The three multicast mappings may be achieved as follows:
(S, G): S bit = 0, G bit = 0, the Source Address and Group multicast
Address prefixes are both used to define the multicast traffic.
(*, G): S bit = 1, G bit = 0, the Group multicast Address prefix is
used to define the multicast traffic, but the Source Address
prefix is ignored.
(*, *): S bit = 1, G bit = 1, the Source Address and Group multicast
Address prefixes are both ignored.
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. References
7.1. Normative 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>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
Chen, et al. Expires January 12, 2022 [Page 16]
Internet-Draft BIER-TE Path July 2021
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
7.2. Informative References
[I-D.ietf-bier-te-arch]
Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering
for Bit Index Explicit Replication (BIER-TE)", draft-ietf-
bier-te-arch-09 (work in progress), October 2020.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
Authors' Addresses
Huaimo Chen
Futurewei
Boston, MA
USA
Email: huaimo.chen@futurewei.com
Mike McBride
Futurewei
Email: michael.mcbride@futurewei.com
Ran Chen
ZTE Corporation
Email: chen.ran@zte.com.cn
Chen, et al. Expires January 12, 2022 [Page 17]
Internet-Draft BIER-TE Path July 2021
Gyan S. Mishra
Verizon Inc.
13101 Columbia Pike
Silver Spring MD 20904
USA
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn
Yisong Liu
China Mobile
Email: liuyisong@chinamobile.com
Yanhe Fan
Casa Systems
USA
Email: yfan@casa-systems.com
Lei Liu
Fujitsu
USA
Email: liulei.kddi@gmail.com
Xufeng Liu
Volta Networks
McLean, VA
USA
Email: xufeng.liu.ietf@gmail.com
Chen, et al. Expires January 12, 2022 [Page 18]