-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathdraft-ietf-grow-bmp-tlv.xml
605 lines (568 loc) · 24.5 KB
/
draft-ietf-grow-bmp-tlv.xml
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
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I-D.ietf-grow-bmp-peer-up SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-bmp-peer-up.xml">
<!ENTITY IANA_RM_CODE_BGP_PDU "TBD1">
<!ENTITY IANA_RM_CODE_GROUP "TBD2">
<!ENTITY IANA_RM_CODE_VRF "TBD3">
<!ENTITY IANA_RM_CODE_SP "TBD4">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-grow-bmp-tlv-16"
ipr="trust200902" submissionType="IETF"
updates="7854">
<front>
<title abbrev="BMP TLV">
BMP v4: TLV support for BMP Route Monitoring and Peer Down Messages
</title>
<author fullname="Paolo Lucente" initials="P" surname="Lucente">
<organization>NTT</organization>
<address>
<postal>
<street>Veemweg 23</street>
<city>Barneveld</city>
<code>3771</code>
<region>MT</region>
<country>NL</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Yunan Gu" initials="Y" surname="Gu">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<region></region>
<country>China</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2025"/>
<area>General</area>
<workgroup>Global Routing Operations</workgroup>
<keyword>BGP</keyword>
<keyword>BMP</keyword>
<keyword>tlv</keyword>
<abstract>
<t>
Most of the message types defined by the BGP Monitoring Protocol (BMP)
make provision for data in TLV format. However, Route Monitoring
messages (which provide a snapshot of the monitored Routing Information
Base) and Peer Down messages (which indicate that a peering session was
terminated) do not. Supporting (optional) data in TLV format across
all BMP message types allows for a homogeneous and extensible structure
that would be useful for the most different use-cases that need to
convey additional data to a BMP station. While it is not intended
for this document to cover any specific utilization scenario, it defines
a consistent and simple way to support TLV data in all message types.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="Introduction">
<t>
The BGP Monitoring Protocol (BMP) version 3 is defined in <xref target="RFC7854">RFC 7854</xref>.
</t>
<t>
The Route Monitoring message consists of:
<list style="symbols">
<t>Common Header</t>
<t>Per-Peer Header</t>
<t>BGP Update PDU</t>
</list>
</t>
<t>
The Peer Down Notification message consists of:
<list style="symbols">
<t>Common Header</t>
<t>Per-Peer Header</t>
<t>Reason</t>
<t>Data (only if Reason code is 1, 2 or 3)</t>
<t>TLV (only if Reason code is 6)</t>
</list>
</t>
<t>
This means that both Route Monitoring and Peer Down messages have
a non-extensible format (except for the specific case of Peer Down
Reason Code 6 as <xref section="5.3" sectionFormat="of"
target="RFC9069"/>). In the Route Monitoring case, this prevents
the transmission of characteristics of transported NLRIs (e.g. to
help with stateless parsing), status of a path after being
processed by the BGP process or of vendor-specific data. In the
Peer Down case, this prevents matching with TLVs previously sent
with the Peer Up message. The proposal of this document is to:
<list style="symbols">
<t>Bump the BMP version for all message types defined in
<xref target="RFC7854">RFC 7854</xref> for backward compatibility</t>
<t>Change the structure of Route Monitoring message type so that the BGP
Update PDU is enclosed in a TLV. The BGP Message PDU TLV is mandatory</t>
<t>Allow all defined BMP message types to make provision for optional
TLV data.</t>
</list>
</t>
</section>
<section title="Terminology">
<t>
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 <xref target="RFC2119">RFC 2119</xref>
<xref target="RFC8174">RFC 8174</xref> when, and only when, they
appear in all capitals, as shown here.
</t>
</section>
<section title="Message version">
<t>
For an exporter to flag a receiver that it does comply with this document, the
Version field of the Common Header, documented in <xref target="RFC7854">
Section 4.4 of</xref>, MUST be set to 4. This applies to every BMP message
type.
</t>
</section>
<section title="TLV encoding">
<t>
The TLV data type is already defined in <xref target="RFC7854">Section 4.4 of</xref>
for the Initiation and Peer Up message types. A TLV consists of:
</t>
<t>
<list style="symbols">
<t>
2 octets of TLV Type,
</t>
<t>
2 octets of TLV Length,
</t>
<t>
0 or more octets of TLV Value.
</t>
</list>
</t>
<figure anchor="BMP-TLV-header" align="center">
<artwork align="center">
<![CDATA[
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 (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
TLVs SHOULD be sorted by the sender by their code point. Multiple
TLVs of the same type can be repeated as part of the same message,
and it is left to the specific use-cases whether all, any, the
first or the last TLV should be considered as well as whether
ordering matters and repeating is allowed.
</t>
<t>
Route Monitoring messages may require per-NLRI TLVs, that is, there may
be a need to map TLVs to NLRIs contained in the BGP Update message, for
example, to express additional characteristics of a specific NLRI. For
this purpose specifically, TLVs in Route Monitoring messages MUST be
indexed, with the index starting at one (1) to refer to the first NLRI.
Index zero (0) specifies that a TLV does apply to all NLRIs contained in
the BGP Update message. The Index field is 2 bytes long of which the
top-most bit, G-bit, is reserved to flag a Group Index (more in <xref
target="GroupTLVinRM"/>).
In general TLVs of the same type and with the same index can be repeated
as part of the same message, unless specified otherwise by the definition
of the specific TLV. Indexed TLVs are encoded as in the following figure:
</t>
<figure anchor="BMP-indexed-TLV-header" align="center">
<artwork align="center">
<![CDATA[
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 (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G| Index (15 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
Indexed TLVs SHOULD be sorted by the sender by their code point and
index value. Also in indexed TLVs, the reported length refers to the
total encoded TLV value (ie. it does exclude the length of the index
field).
</t>
<t>
A decoder can properly match indexed TLVs to the corresponding NLRI
only if - or as long as - NLRIs are decoded successfully. In case of
any parsing or error condition that prevents full decoding of the BGP
PDU, the decoder MUST stop matching indexed TLVs to NLRIs.
</t>
<t>
Of the BMP message types defined so far, indexed TLVs apply only to
Route Monitoring messages and, for example, they do not apply to Route
Mirroring messages because the sender may not be aware of the payload
of the transported BGP Update message.
</t>
</section>
<section title="BMP Message Format">
<section title="Common Header" anchor="CommonHeader">
<t>
<xref section="4.1" sectionFormat="of" target="RFC7854"/> defines
the Common Header. While the structure remains unaltered, the
following two definitions are changed:
<list style="symbols">
<t>
Version: Indicates the BMP version. This is set
to '4' for all message types defined in
<xref target="RFC7854">RFC 7854</xref>.
</t>
<t>
Message Length: Total length of the message in
bytes (including headers, encapsulated BGP Message
PDU TLV and optional TLV data).
</t>
</list>
</t>
</section>
<section title="TLV data in Route Monitoring" anchor="TLVinRM">
<t>
The Route Monitoring message type is defined in <xref section="4.6"
sectionFormat="of" target="RFC7854"/>. The consistency model
selected by this document to extend encoding of such message type
with TLVs is with the Route Mirroring type defined in <xref
section="4.7" sectionFormat="of" target="RFC7854"/> where the
Per-peer header is being followed by mandatory and optional TLVs.
</t>
<t>
The BGP Update PDU <xref section="4.3" sectionFormat="of"
target="RFC4271"/> is encoded itself as part of a BGP Message TLV
with code point &IANA_RM_CODE_BGP_PDU; and index set to zero. A Route
Monitoring message MUST contain one BGP Message TLV which may be
preceeded and/or followed by other optional TLV data.
</t>
<t>
Corollary, in BMPv4 the BGP Update PDU is not just encoded as part
of the message as it was the case for BMPv3 but it is rather enclosed
in a TLV.
</t>
<section title="Group TLV" anchor="GroupTLVinRM">
<t>
In a Route Monitoring message where the BGP Update PDU carries N
NLRIs, indexed TLVs do allow to handle the cases of 1:1 and N:1
relationship among TLVs and NLRIs (ie. one TLV applies to one
NLRI, N TLVs apply to one same NLRI). The cases of 1:N and M:N
relationships (ie. one TLV applies to N NLRIs, M TLVs apply to
N NLRIs) can benefit by a form of grouping. This is the context
to define a Group TLV to achieve this with the aim to limit both
verbosity and repetitions.
</t>
<t>
The TLV value MUST contain:
<list style="symbols">
<t>A 2 bytes Group Index where the top-most bit, G-bit or Group
Bit MUST be set to one (1). The full 2 bytes value, that is
including the G-bit, MUST be unique to the message</t>
<t>Two or more 2 bytes NLRI indexes whose values MUST be less
or equal to the amount of NLRIs packed in the BGP Update PDU.</t>
</list>
A NLRI index can be listed as part of multiple Group TLVs within
the same message. NLRI indexes within a Group TLV SHOULD be sorted
by the sender. A Group Index can not reference an NLRI index 0.
A Group TLV MUST NOT include its own or another Group Index.
Multiple non-Group TLVs can point to the same Group Index, ie. a
group can be reused within the same Route Monitoring message.
</t>
<t>
The Group TLV code point is &IANA_RM_CODE_GROUP;. It is recommended
that this TLV is encoded first in order to ease parsing of the
Route Monitoring message at the BMP station side.
</t>
</section>
<section title="VRF/Table Name TLV" anchor="VrfTLVinRM">
<t>
The Information field contains a UTF-8 string whose value MUST
be equal to the value of the VRF or table name (ie. RD instance
name) being conveyed. The string size MUST be within the range
of 1 to 255 bytes.
</t>
<t>
The VRF/Table Name TLV code point is &IANA_RM_CODE_VRF;
</t>
</section>
<section title="Stateless parsing TLV" anchor="SpTLVinRM">
<t>
Stateless parsing helps scaling the amount of Route Monitoring
messages that can be processed at collection time, avoiding to
have to correlate them to BGP capabilities received as part of
the Peer Up message, for example.
</t>
<t>
Some BGP capabilities are not per AFI/SAFI, like 4-bytes ASN
<xref target="RFC6793">RFC 6793</xref>, and hence these can be
part of the BMP Peer flags section of a Route Monitoring message.
Those that are, instead, per AFI/SAFI require finer granularity
and hence the need to use an indexed TLV.
</t>
<t>
The Stateless Parsing TLV code point is &IANA_RM_CODE_SP; and
its Value is organized as follows:
<list style="symbols">
<t>Capability Type, 1 byte</t>
<t>AFI, 2 bytes</t>
<t>SAFI, 1 byte</t>
<t>Capability Value, variable length</t>
</list>
</t>
<t>
The Capability Type field encodes a code point from the <xref
target="IANA-BCC">BGP Capabilities Codes</xref> registry defined
by <xref target="RFC5492">RFC 5492</xref>.
</t>
<t>
The length of the Capability Value field can be inferred by
subtracting the fixed component of the Stateless Parsing TLV
Value from the TLV length. The value encoded MUST be the same
as the one encoded by the capability in the original BGP Open
message.
</t>
<t>
The index of the Stateless Parsing TLV MUST be set to zero.
</t>
<t>
If the Stateless Parsing TLV is not present in a Route Monitoring
message, the receiver MUST fall back to use capabilities present
in the BGP Open PDU contained in the relevant BMP Peer Up message
in order to properly parse BGP Update PDUs.
</t>
<t>
It is recommended that the Stateless Parsing TLV is encoded
preceeding the BGP Message TLV in order to ease parsing of the
Route Monitoring message at the BMP station side.
</t>
</section>
<section title="Wire-format example" anchor="TLVexample">
<t>
The diagram in <xref target="BMP-RM-TLVs"/> shows an example of a
Route Monitoring message carrying a BGP UPDATE containing 10
NLRIs. The TLVs are comprised of:
<list style="numbers">
<t>
a Group TLV with index 0x000b, pointing to NLRI 1, 2, 3
and 10
</t>
<t>
a Group TLV with index 0x000c, pointing to NLRI 4, 5 and
6
</t>
<t>
a Stateless Parsing TLV with index 0x0000
</t>
<t>
a TLV pertaining to NLRI 7
</t>
<t>
a TLV pertaining to the NLRIs listed in the Group TLV
defined in 1
</t>
<t>
a TLV pertaining to the NLRIs listed in the Group TLV
defined in 2
</t>
</list>
</t>
<t>
<figure anchor="BMP-RM-TLVs" align="center">
<artwork align="center">
<![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Header + Per-Peer Header (6 + 42 bytes) ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=TBD2 | length=0x0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| index=0x000b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value={0x0001, 0x0002, |
| 0x0003, 0x000a} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=TBD2 | length=0x0006 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| index=0x000c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value={0x0004, 0x0005, |
| 0x0006} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=TBD4 | length=0x0005 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| index=0 | afi=1 |
| safi=1 | cap=69 | value=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=TBD1 | length=X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| index=0 | value=$BGP_UPDATE_PDU{ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ ~
~ NLRI_1 .. NLRI_10 ~
~ } |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=SomeTlvX | length=0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| index=0x000b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value={4 bytes} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=SomeTlvY | length=0x0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| index=0x000c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value={8 bytes} ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=SomeTlvZ | length=0x0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| index=0x0007 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value={8 bytes} ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section title="TLV data in Peer Down" anchor="TLVinPD">
<t>
The Peer Down Notification message type is defined in
<xref section="4.9" sectionFormat="of" target="RFC7854"/>.
The consistency model selected by this document to extend encoding
of such message type is with the Peer Up type defined in
<xref section="4.10" sectionFormat="of" target="RFC7854"/> where
optional TLVs are placed at the end of the message.
</t>
<t>
This means for Reason codes 1 or 3, a BGP Notification
PDU follows; the PDU MAY be further followed by optional
TLV data. For Reason code 2, a 2-byte field follows to
provide additional FSM info; this field MAY be followed
by optional TLV data. For all other Reason codes, optional
TLV data MAY follow the Reason field.
</t>
</section>
<section title="TLV data in other BMP messages" anchor="TLVinOther">
<t>
All other message types defined in <xref target="RFC7854">RFC7854</xref>
do already provision for TLV data. It is RECOMMENDED that
all future defined BMP message types will also provide for
optional TLV data following a consistency model for encoding
with existing message types.
</t>
</section>
</section>
<section title="Error handling">
<t>
It is worth nothing that <xref target="RFC8654">RFC8654</xref>
permits BGP Update and other messages to grow to a length of
65535 octets. This may cause a BMP PDU that attempts to encapsulate
such long messages to overflow.
</t>
</section>
<section title="Security Considerations">
<t>
It is not believed that this document adds any additional
security considerations.
</t>
</section>
<section title="Operational Considerations">
<t>
In Route Monitoring messages, the number of TLVs can be bound to
the amount of NLRIs carried in the BGP Update message. This may
degrade the packing of information in such messages and have
specific impacts on the memory and CPU used in a BMP implementation.
As a result of that it should always be possible to disable such
features to mitigate their impact.
</t>
</section>
<section title="IANA Considerations">
<t>
This document requests the renaming of the "Peer Up TLVs" registry defined by
<xref target="I-D.ietf-grow-bmp-peer-up">BMP Peer Up Message Namespace</xref>
into "Peer Up and Peer Down TLVs" and the definition of one new registry "BMP
Route Monitoring TLVs". As part of the "BMP Route Monitoring TLVs" registry,
the following new TLV types are defined (<xref target="TLVinRM"/>):
<list style="symbols">
<t>
Type = &IANA_RM_CODE_BGP_PDU;: Support for BGP Message TLV. The value
field is defined in <xref target="TLVinRM"/>
</t>
<t>
Type = &IANA_RM_CODE_GROUP;: Support for grouping of TLVs. The value
field is defined in <xref target="GroupTLVinRM"/>. The recommended
value for this TLV is 0.
</t>
<t>
Type = &IANA_RM_CODE_VRF;: Support for VRF/Table Name TLV. The value
field is defined in <xref target="VrfTLVinRM"/>
</t>
<t>
Type = &IANA_RM_CODE_SP;: Support for Stateless Parsing TLV. The value
field is defined in <xref target="SpTLVinRM"/>. The recommended value
for this TLV is 1.
</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC8174;
<?rfc include="reference.RFC.4271.xml"?>
<?rfc include="reference.RFC.7854.xml"?>
<?rfc include="reference.RFC.6793.xml"?>
<?rfc include="reference.RFC.7911.xml"?>
<?rfc include="reference.RFC.8277.xml"?>
<?rfc include="reference.RFC.8654.xml"?>
<?rfc include="reference.RFC.9069.xml"?>
&I-D.ietf-grow-bmp-peer-up;
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5492.xml"?>
<reference anchor="IANA-BCC" target="https://www.iana.org/assignments/capability-codes/">
<front>
<title>
Capabilities Codes
</title>
<author>
<organization>
IANA
</organization>
</author>
<date year="2025" />
</front>
</reference>
</references>
<section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
<t>
The authors would like to thank Jeff Haas, Camilo Cardona, Thomas Graf,
Pierre Francois, Ben Maddison, Tim Evens, Luuk Hendriks, Maxence Younsi,
Ahmed Elhassany, Colin Petrie, Dhananjay Pakti and Shunwan Zhuang for
their valuable input. The authors would also like to thank Greg Skinner
and Zongpeng Du for their review.
</t>
</section>
</back>
</rfc>