generated from martinthomson/internet-draft-template
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-fluechter-bier-bierte-subset-tunneling.txt
431 lines (341 loc) · 19.3 KB
/
draft-fluechter-bier-bierte-subset-tunneling.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
Bit Indexed Explicit Replication M. Flüchter
Internet-Draft M. Menth
Intended status: Informational University of Tuebingen
Expires: 24 April 2025 T. Eckert
Futurewei USA
21 October 2024
Extensions to BIER Tree Engineering (BIER-TE) for Large Multicast
Domains and 1:1 Protection
draft-fluechter-bier-bierte-subset-tunneling-latest
Abstract
BIER-TE extends BIER with tree engineering capabilities and can be
supported by almost the same hardware. However, a bitstring in BIER-
TE hold bits for BFERs and links, which effects that the size of
supportable topologies in terms of BFERs is smaller for BIER-TE than
for BIER. While for BIER, subsets can be utilized to improve scaling
to large multicast domains, this mechanism requires adaptation for
BIER-TE. In this document, requirements for BIER-TE subsets are
defined, a mechanism is described for how BIER-TE packets can reach
their subsets using tunneling, and 1:1 protection for the entire
BIER-TE multicast tree is explained. The concept utilizes egress
protection for reaching a subset when the ingress BFIR of the subset
fails.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://uni-tue-
kn.github.io/draft-bier-bierte-subset-tunneling/draft-fluechter-bier-
bierte-subset-tunneling.html. Status information for this document
may be found at https://datatracker.ietf.org/doc/draft-fluechter-
bier-bierte-subset-tunneling/.
Discussion of this document takes place on the Bit Indexed Explicit
Replication Working Group mailing list (mailto:[email protected]), which
is archived at https://mailarchive.ietf.org/arch/browse/bier/.
Subscribe at https://www.ietf.org/mailman/listinfo/bier/.
Source for this draft and an issue tracker can be found at
https://github.com/uni-tue-kn/draft-bier-bierte-subset-tunneling.
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
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 24 April 2025.
Copyright Notice
Copyright (c) 2024 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction
1.1. Terminology
1.1.1. Abbreviations
2. BIER-TE Subsets
3. Subset Tunneling
4. 1:1 Protection
4.1. Subset Tunneling Protection
4.2. Subset Ingress Protection
4.3. Intra-Subset Protection
5. Examples
5.1. Subset Tunneling
5.2. Ingress Protection with MPLS Tunneling
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Authors' Addresses
1. Introduction
Bit Index Explicit Replication with Traffic Engineering (BIER-TE) was
introduced in [RFC9262] as an extension to the BIER archtecture,
offering enhanced capabilities through traffic engineering, or "tree
engineering" in this context. In BIER-TE, the forwarding and
replication of multicast traffic is guided by the BIER-TE header that
includes bits representing Bit Forwarding Egress Routers (BFERs) and
links. As a result, the entire multicast distribution tree is
encoded directly within the packet header. This encoding leads to
scalability challenges, particularly in large networks, which are
similar as in BIER. However, BIER-TE encodes more information in the
bistring and thus scales worse than BIER for large networks.
BIER-TE inherits the concept of subsets from BIER where the network
domain can be partitioned into smaller sub-topologies. A BIER-TE
subset is a partition of the BIER-TE domain with a unique Set
Identifier (SI). The SI containing the destination BFERs of a packet
is indicated in the BIER-TE header as a bitstring. Further, the
bitstring addresses only links and BFERs in that subset.
In this document, requirements for BIER-TE subsets are defined, a
mechanism is described for how BIER-TE packets can reach their
subsets using tunneling. Further the application of 1:1 protection
for the entire multicast tree is explained. With these extensions,
BIER-TE can scale to large multicast domains. The extensions depend
on well established technologies and do not require any changes to
the BIER header or forwarding logic.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.1.1. Abbreviations
This document makes use of the terms defined in [RFC9262] and in
[RFC8679].
Further abbreviations used in this document:
+==============+======================================+===========+
| Abbreviation | Meaning | Reference |
+==============+======================================+===========+
| S-BFIR | Subset Bit Forwarding Ingress Router | This |
| | | document |
+--------------+--------------------------------------+-----------+
Table 1: Abbreviations.
2. BIER-TE Subsets
BIER subsets can be constructed by selecting a number of arbitrary
BFERs within the BIER domain. The number of BFERs of each subset
must not exceed the bitstring length and the BFERs of all subsets
should cover all BFERs of the entire domain. This rather
unconstraint selection of BFERs works well because a packet sent by a
BIER BFIR reaches any BFER over the routing underlay, no matter which
subset the BFER belongs to.
In contrast, with BIER-TE, a BFER can be reached over a path that is
encoded in the bitstring. Therefore, also links need to be part of
the subset. Moreover, within a very large ring or a line, a BFIR may
be so far away from a BFER that the links of the subset do not
suffice to define a path from the BFIR to that BFER.
Therefore, a different approach is needed for subsets in BIER-TE.
First, a subset also needs links in additions to BFERs which are
encoded in the bitstring. The number of BFERs and links within the
subset MUST NOT exceed the size of the bitstring. Moreover, links
and BFERs need to be connected so that a BIER-TE packet at a source
of any link in the subset can reach all BFERs within the subset. The
BFRs belonging to the links are also part of the subset but are not
represented by a bit in the bitstring unless they constitute BFERs.
Thus, a subset needs to be one-connected. That is, the mentioned
property is fulfilled unless one link or BFR fails. A BFIR may need
to send a packet to a specific BFER, but it does not need to be part
of the subset the BFER belongs to. It can however use unicast
tunneling to direct packets to some BFR within the subset. That BFR
is denoted as S-BFIR (subset BFIR). There may be one or many S-BFIRs
for a subset.
Subsets for BIER-TE with 1:1 protection have to be at least two-
connected, i.e., the remaining subset is one-connected if a link or
BFR fails. That is, in case of a failure, there is still a path from
any BFR to any BFER within the subset. Further, for every S-BFIR in
the subset, one or more backup S-BFIRs have to be assigned. When an
S-BFIR fails, the backup S-BFIRs serve as alternative ingress to the
subset and ensure that the packets reach the BFERs.
A domain may be one- or two connected, but it may be difficult or
even impossible to find a desired number of subsets with that
property. Then, virtual links may be defined as tunnels whose paths
extend over links outside the subset.
3. Subset Tunneling
Any BFIR reaches each subset by tunneling packets to any S-BFIR in
the subset. To that end, the BFIR forwarding logic has to be
slightly modified from the one defined in [RFC8279]. When a BFIR
receives an IPMC packet, it determines the destination BFERs and
their subsets as with standard BIER-TE. The BFIR clones the packet
for each subset and adds the corresponding BIER-TE header to each
packet. The BIER-TE bitstring contains the multicast tree from
S-BFIR to the BFERs in the same subset. Then, the BFIR adds an outer
tunneling header that reaches one of the S-BFIRs of the destination
subset.
| MPLS Tunnel | BIER-TE Subset |
| | |
BFIR ───A─── LSR ───B─── S-BFIR ───0─── BFR ───1─── BFER
|
2
|
BFR ───3─── BFER
Figure 1: Example BIER-TE network with a one-connected BIER-TE
subset, S-BFIR, and MPLS tunnel.
When an S-BFIR receives such a tunneled packet, it removes the tunnel
header and applies BIER-TE forwarding. The tunneling protocols used
SHOULD support path steering, e.g., MPLS TE or SRv6. Further, they
SHOULD support FRR and egress protection mechanisms for 1:1
protection.
4. 1:1 Protection
The protection of BIER-TE with subsets is split into three sections:
during tunneling, at the subset ingress, and within the subset.
4.1. Subset Tunneling Protection
The tunnel between BFIR and S-BFIR may be protected using existing
FRR 1:1 protection mechanisms. RSVP-TE with FRR [RFC8796] can be
used for MPLS and [I-D.draft-ietf-rtgwg-segment-routing-ti-lfa] for
FRR protection in SRv6.
4.2. Subset Ingress Protection
When an S-BFIR fails, the packet has to be rerouted to a backup
S-BFIR. To protect against this failure, the tunneling protocol must
support an egress protection mechanism. If MPLS is used for the
tunnel, then the MPLS Egress Protection Framework [RFC8679] can be
used. For SRv6 egress protection there is a similar draft
[I-D.draft-ietf-rtgwg-srv6-egress-protection].
When the penultimate tunneling hop detects the failure of the S-BFIR,
it becomes the PLR. On a detected failure, the PLR determines a
backup S-BFIR of the same subset. If there are multiple backup
S-BFIR, the PLR may select a backup S-BFIR based on different
criteria, e.g., the closest backup S-BFIR. The PLR uses the egress
protection mechanism of the tunneling protocol to reroute the packet
to the backup S-BFIR.
/ ───C─── S-BFIR ───0─── \ / ──3── BFER
/ (Backup) \ /
/ \ /
BFIR ───A─── LSR ───B─── S-BFIR ───1─── BFR ───2─── BFER
Figure 2: MPLS example of a backup S-BFIR and a one-connected subset.
The backup S-BFIR recognizes its role as backup ingress based on the
tunneling protocol header. It removes the tunneling header and
applies BIER-TE FRR [I-D.draft-eckert-bier-te-frr] with node
protection. This ensures that the packet is forwarded to the correct
next hops of the failed S-BFIR. It also modifies the BIER-TE
bitstring to prevent loops in the subset. After the backup S-BFIR
processing, standard BIER-TE forwarding is applied.
4.3. Intra-Subset Protection
Protection against failures inside a subset is achieved with existing
BIER-TE FRR mechanisms. There are currently two drafts for BIER-TE
FRR [I-D.draft-eckert-bier-te-frr] and [I-D.draft-chen-bier-te-frr].
Both define mechanisms for link and node protection and propose BIER-
TE-in-BIER-TE tunneling to reroute packets around a failure.
Therefore, either of these drafts may be used for the FRR protection
mechanisms.
5. Examples
In this section, we present two exemplary scenarios. One for the
subset tunneling and one for the ingress protection mechanism.
5.1. Subset Tunneling
An example topology using BIER-TE subset tunneling is illustrated in
Figure 3. The BFIR determines that the packet needs to be delivered
to BFERs 1 and 2. It recognizes that the two BFERs lie within two
different subsets and clones the packet. The first packet receives a
BIER-TE header with the bits set for link 0 and BFER 1 and is
tunneled to the S-BFIR of subset 1. The second packet receives a
BIER-TE header with the bits set for link 1 and BFER 2 and is
tunneled to subset 2. When the packet arrives at each S-BFIR, the
S-BFIR removes the MPLS tunnel header. For subset 1, it then matches
the BIER bitstring and forwards the packet over link 0. The S-BFIR
of subset to forwards the packet over link 1.
BFIR
|
A
SI:1 | SI:2
S-BFIR ───B── LSR ───C─── S-BFIR
| | \
0 1 2
| | \
BFER 1 BFER 2 BFER 3
Figure 3: Example BIER-TE network with two subsets and S-BFIRs.
5.2. Ingress Protection with MPLS Tunneling
Figure 4 illustrates the concept of ingress protection with MPLS.
When the tunneled BIER-TE packet arrives at the LSR B, it detects
that S-BFIR A failed. Using MPLS egress protection, the PLR (LSR B)
switches the label to the context label C' which indicates the backup
path to S-BFIR'. S-BFIR' recognizes its role as protector by
matching the context label to the failed ingress node. Then, it
applies the BIER-TE FRR node protection handling, unsets the bit for
link 1 and sets the bit for link 0. This way, the packet reaches the
BFR and can be forwarded with standard BIER-TE.
| BIER-TE domain |
| BIER-TE subset (SI:1)|
/--C'-- S-BFIR' -- 0 -- \
/ \
/ \
BFIR ───A─── LSR A ───B─── LSR B ───C─── S-BFIR ───1─── BFR
(PLR)
Figure 4: Example BIER-TE network with a single subset and two
S-BFIRs.
6. Security Considerations
The security issues discussed in [RFC8279], [RFC9262], and [RFC8679]
apply to this document.
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[I-D.draft-chen-bier-te-frr]
Chen, H., McBride, M., Liu, Y., Wang, A., Mishra, G. S.,
Fan, Y., Liu, L., and X. Liu, "BIER-TE Fast ReRoute", Work
in Progress, Internet-Draft, draft-chen-bier-te-frr-07, 28
March 2024, <https://datatracker.ietf.org/doc/html/draft-
chen-bier-te-frr-07>.
[I-D.draft-eckert-bier-te-frr]
Eckert, T. T., Cauchie, G., Braun, W., and M. Menth,
"Protection Methods for BIER-TE", Work in Progress,
Internet-Draft, draft-eckert-bier-te-frr-03, 5 March 2018,
<https://datatracker.ietf.org/doc/html/draft-eckert-bier-
te-frr-03>.
[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/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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/rfc/rfc8279>.
[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
Engineering for Bit Index Explicit Replication (BIER-TE)",
RFC 9262, DOI 10.17487/RFC9262, October 2022,
<https://www.rfc-editor.org/rfc/rfc9262>.
8.2. Informative References
[I-D.draft-ietf-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
17, 5 July 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rtgwg-segment-routing-ti-lfa-17>.
[I-D.draft-ietf-rtgwg-srv6-egress-protection]
Hu, Z., Chen, H., Toy, M., Cao, C., and T. He, "SRv6 Path
Egress Protection", Work in Progress, Internet-Draft,
draft-ietf-rtgwg-srv6-egress-protection-16, 1 February
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
rtgwg-srv6-egress-protection-16>.
[RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H.,
Michel, C., and H. Chen, "MPLS Egress Protection
Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019,
<https://www.rfc-editor.org/rfc/rfc8679>.
[RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A.,
Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute
Extensions for Label Switched Path (LSP) Tunnels",
RFC 8796, DOI 10.17487/RFC8796, July 2020,
<https://www.rfc-editor.org/rfc/rfc8796>.
Authors' Addresses
Moritz Flüchter
University of Tuebingen
Tuebingen
Germany
Email: [email protected]
Michael Menth
University of Tuebingen
Tuebingen
Germany
Email: [email protected]
Toerless Eckert
Futurewei USA
Email: [email protected]