-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathdraft-ietf-idr-wide-bgp-communities.xml
1319 lines (1047 loc) · 50.4 KB
/
draft-ietf-idr-wide-bgp-communities.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
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/rfc2629.dtd"[
<!ENTITY RFC1997 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1997.xml">
<!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC3640 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3640.xml">
<!ENTITY RFC3765 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3765.xml">
<!ENTITY RFC4271 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4360 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY RFC7606 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7606.xml">
<!ENTITY RFC8092 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8092.xml">
<!ENTITY ieee-float PUBLIC '' "http://xml.resource.org/public/rfc/bibxml2/reference.IEEE.754.1985.xml">
]>
<?xml-stylesheet type='text/xsl'
href="http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629.xslt" ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?rfc rfcedstyle="yes"?>
<rfc category="std"
docName="draft-ietf-idr-wide-bgp-communities-08"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="BGP Community Container">
BGP Community Container Attribute
</title>
<author fullname='Robert Raszuk' initials='R' surname='Raszuk' role="editor">
<organization>Individual</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="J" surname="Haas" fullname="Jeffrey Haas" role="editor">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N.Mathilda Ave</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="A" surname="Lange" fullname="Andrew Lange" role="editor">
<organization>Nokia</organization>
<address>
<postal>
<street>777 E. Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene" role="editor">
<organization>Orange</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="S" surname="Amante" fullname="Shane Amante">
<organization>Apple, Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="P" surname="Jakma" fullname="Paul Jakma">
<organization>Huawei Ireland Research Centre</organization>
<address>
<postal>
<street>Georges Court, Townsend St</street>
<city>Dublin</city>
<code>D02 R156</code>
<country>Ireland</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date/>
<area>Routing</area>
<workgroup>IDR Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>IDR</keyword>
<keyword>BGP</keyword>
<abstract>
<t>Route tagging plays an important role in external BGP relations,
communicating various routing policies between peers. It
is also a very common best practice for operators to propagate
various additional route information between internal peers. The
most common tool used today to attach various information about
routes is through the use of BGP communities.</t>
<t>This document defines a new encoding which will enhance
and simplify what can be accomplished today with the use of
BGP communities. The most important addition this specification
makes over currently defined BGP communities is the ability to
specify and advertise an operator's parameters for execution
It also provides an extensible platform
for any future community encoding requirements.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC1997">RFC 1997</xref> defines the BGP
Community Attribute. This attribute is used as a tool to
carry additional information in BGP routes
which may help to automate peering administration.
The BGP Communities
Attribute consists of a set of one or more four-octet values,
where each specifies a different community. Except for
two reserved ranges, the encoding of community values mandates
that the first two octets contain the Autonomous System
number, with the next two octets containing some locally defined
value.</t>
<t>Since the introduction of <xref target="RFC1997"/>, numerous additional
mechanisms have been introduced to provide BGP Community-like functionality.
Each of these mechanisms introduce a new syntax, typically covered by its
encoding with the BGP Path Attribute that defines it, and a semantic
space.</t>
<t>The authors
believe that defining a new BGP Path Attribute, with the ability
to contain locally defined parameters will enhance the current
level of network policies, as well as simplify BGP policy
management. The proposed encoding will also facilitate
the delivery of new network services without the need to define
a new BGP extension for each new application.</t>
<t>When defining any new type of tool there is always a
unique opportunity to specify a subset of well recognized
behaviors. Lists of the current most commonly used BGP communities,
as well as creation of a new registry for future definitions
will be described in an extension-specific document.</t>
</section>
<section title="Protocol Summary">
<t>This specification defines a new BGP Path Attribute, the BGP Community
Container. It carries a series of BGP Community Container types, each
prefaced with the BGP Community Container Common Header.</t>
<t>This specification also defines the BGP Wide Community Container.</t>
<section title="BGP Community Container Common Header">
<t>The BGP Community Container Common Header permits Community-like
attributes to be grouped under a single BGP Path Attribute. This
provides hierarchy for future Community-like features. It permits
implementations without knowledge of a specific Community
Container's format to address that Community Container by its code
point. It also permits common enforcement of the Community
Container's transitivity across AS boundaries without requiring the
implementation to understand a specific Container's implementation.</t>
<t>The BGP Community Container Common Header is defined in <xref target="container_header_def"/>
and contains following encoding:
<list style="hanging" hangIndent="4">
<t hangText="Container Type:"><vspace/>
Container Type 1, BGP Wide Community
is defined in this document.</t>
<t hangText="Flags:"><vspace/>
Flags control common behavior including the transitivity of the
Container. </t>
<t hangText="Length:"><vspace/>
Length of the Container contents.
</t>
</list>
</t>
</section>
<section title="Community Containers">
<t>This document defines one Community Container with the following
encoding:</t>
<section title="Type 1: BGP Wide Community">
<t> The container type 1 "BGP Wide Community TLVs" is defined in <xref target="container_def_1"/>.</t>
<t><list style="hanging" hangIndent="4">
<t hangText="Community Value:"><vspace/>
This section defines the action that an operator
wishes a router to take.</t>
<t hangText="Source AS:"> <vspace/>
This is the AS originating the community.</t>
<t hangText="Context AS:"><vspace/>
AS that defines and provides the semantics to interpret this
Community.</t>
<t hangText="Target(s):"> <vspace/>
This is an optional list that encodes where the
community's action should be taken.</t>
<t hangText="Exclude Target(s):"> <vspace/>
This is an optional list that encodes where the
community's actions should not be taken.</t>
<t hangText="Parameters:"><vspace/>
This is an optional list of Atoms that encodes additional
information that the community's action needs to execute properly.</t>
</list></t>
</section>
<!--
<section title="Type 2: Wide Community 4:4">
<t>The container type 2 "BGP Wide Community 4:4"
is defined in <xref target="container_def_2"/> and contains the following encoding:</t>
<t><list style="symbols">
<t>Community Value: Fixed length -> 4 octet : 4 octet community</t>
</list></t>
</section>
<section title="Type 3: Wide Community Nx4">
<t>The container type 3 "BGP Wide Community Nx4" is defined in
<xref target="container_def_3"/> and contains the following encoding:</t>
<t><list style="symbols">
<t>Community Value: Variable length -> Nx4 octet community</t>
</list></t>
</section>
<section title="Type 4: Wide Community 16+Nx4">
<t>The container type 4 "BGP BGP Community 16+Nx4" is defined in <xref target="container_def_4"/> and contains the following encoding:</t>
<t><list style="symbols">
<t>Community Value: Variable length -> Fixed 16 octet field followed by
N x 4 octet community</t>
</list></t>
</section>
-->
</section>
<section title="BGP Community Container Atoms">
<t>Atoms provide data types that can be used to encode contents
of BGP Community Containers. They are in the format of TLVs and
are defined later in this document in <xref
target="atoms"/>.</t>
</section>
</section>
<section title="BGP Community Container Attribute">
<t>This document defines a BGP Path Attribute, the BGP Community
Container. The attribute type code is 34.</t>
<t>The BGP Community Container attribute is an optional, transitive BGP
attribute, and may be present only once in the BGP UPDATE message.</t>
<t>The attribute contains a set of typed containers. Any given
container type may appear multiple times, unless that container
type's definition specifies otherwise.</t>
<section title="BGP Community Container Attribute Common Header"
anchor="container_header_def">
<figure anchor="container_header" title="Common container header">
<preamble>Containers always start with the following common header:
</preamble>
<artwork align='center'>
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 | Flags |C|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>This document defines container type 1. See the <xref
target="iana_considerations"/> for information on additional type
registration policies.</t>
<texttable title="Flags" anchor='bitdefs'>
<ttcol align='center'>Bit</ttcol>
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Meaning</ttcol>
<c>T</c><c>0</c><c>Not Transitive across administrative boundaries.</c>
<c></c><c>1</c><c>Transitive across AS/administrative boundaries.</c>
<c>C</c><c>0</c><c>Not transitive across confederation boundaries.</c>
<c></c><c>1</c><c>Transitive across confederation boundaries.</c>
<c>3..7</c><c>-</c>
<c>RESERVED - MUST be zero when originated and SHOULD be ignored
upon receipt.</c>
<postamble></postamble>
</texttable>
<t>Flags are defined globally and apply to all container types.</t>
<t>Bit 0 (T bit) Transitivity bit:
<list><t>
When not set (value 0), the community in
the container is transitive across AS boundaries, but not across an
administrative boundary.</t>
<t>When set (value 1), the community in the container is
transitive across all ASes.
An administrative boundary, in this sense, is an
arbitrary set of connected ASes, possibly under control of a single entity.
How such an administrative boundary is determined is out of the scope of this
document.</t>
</list></t>
<t>Bit 1 (C bit) Confederation bit:
<list><t>The confederation bit is used to manage the propagation
scope of a given BGP Wide Community across confederation boundaries.</t>
<t>When not set (value 0) community
is not transitive across confederation sub-AS boundary.
When set (value of 1) indicates that community in a given container is
transitive across confederation boundary.</t>
</list></t>
<t>The Reserved field MUST be set to zero when originated and SHOULD be
ignored upon receipt.</t>
<t>The Length field represents the total length in octets of a given container's
contents.</t>
</section>
</section>
<section title="BGP Community Container, Type 1: BGP Wide Community" anchor="container_def_1">
<figure anchor="container1" title='Type 1, BGP Wide Community'>
<preamble>
The Type 1 BGP Community Container, the BGP Wide Community, is of variable size
(but minimum length 12). It is composed of a fixed 12-octets - containing the
Community Value, the Source AS Number, and the Context AS Number - followed
by optional TLVs:
</preamble>
<artwork align='center'>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| Community Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TLVs (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<section title="Community Value">
<t>Community Value: 4 octets</t>
<t>The Community Value indicates what set of actions a router is
requested to take upon reception of a route containing this community. The
semantics of this value depend on whether this is a private/local community
or IANA registered.</t>
<t>When the high order bit of the Community Value field - I - is set, the value
is IANA Registered and has a well defined meaning with underlying semantics.
See the documentation for each Registered BGP Wide Community for its
semantics and validation requirements.</t>
<t>When the high order bit of the Community Value field is clear, the value
is Locally defined and has semantics solely within the control of the AS
defining that community. The Context AS Number provides the namespace in
which this Community Value is interpreted. It is that AS's responsibility
to provide the semantics and validation requirements for the BGP Wide
Community.</t>
<t>See <xref target="type1_community_types"/> for code point space
partitioning.</t>
</section>
<section title="Source AS Number">
<t>Source Autonomous System Number: 4 octets</t>
<t>The Autonomous System number indicates the AS originating this BGP Wide
Community.</t>
</section>
<section title="Context AS Number">
<t>Context Autonomous System Number: 4 octets</t>
<t>This identifies the AS that provides the semantics to interpret this
Community.</t>
</section>
<section title="BGP Wide Community TLVs">
<t>Optional type 1 container TLVs are encoded in the following format:</t>
<figure anchor="type1_container_TLV" title='Type 1 Container TLVs'>
<preamble></preamble>
<artwork align='center'>
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
+-+-+-+-+-+-+-+-+
| Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<postamble></postamble>
</figure>
<t><list style="hanging" hangIndent="4">
<t hangText="Sub-Type:"><vspace/>
The sub-type of the BGP Wide Community TLV. A given Sub-Type
MUST NOT appear more than once.</t>
<t hangText="Length:"><vspace/>
Length of the "Value" field in octets.</t>
<t hangText="Value:"><vspace/>
Specific to the underlying Sub-Type.</t>
</list></t>
<section title="Sub-Type 1, BGP Wide Community Target(s) TLV">
<t>The value field of the Wide Community Target(s) TLV (Sub-Type 1) is a series
of Atom TLVs. The semantics of any given Atom TLV MUST be part of the
definition of a given Wide Community.</t>
<t>BGP Wide Community Targets define the matching criteria for the community.
A given wide community may have a number of targets to which it applies. The
semantics of these targets will vary on a per-community basis. Depending on
the definition of the community, targets may be optional.</t>
<t>Wide Community Targets consist of a series of Atoms that have
"match any" semantics. Thus, if any given target matches per the semantics of
that Atom for the community, the community is considered to match and the
action defined by the community should be executed.</t>
<t>When no Target(s) TLV is specified, it is considered "match all".</t>
<t>If the semantics of a given Atom is undefined for the community in question,
this Atom MUST be ignored.</t>
<t>When no targets are required by the definition of a given Wide Community,
the Wide Community Target(s) TLV SHOULD NOT be encoded in the community.
Implementations MUST be prepared to accept a Wide Community Target(s) TLV with an
empty value field.</t>
</section>
<section title="Sub-Type 2, BGP Wide Community Exclude Target(s) TLV">
<t>The BGP Wide Community Exclude Target(s) TLV (Sub-Type 2) contains a list of
Atoms.</t>
<t>Wide Community Exclude Targets define criteria by which the community is
considered to NOT match. Depending on the semantics of the BGP Wide Community,
Exclude Target(s) may be optional.</t>
<t>The semantic of the BGP Wide Community Exclude Target(s) is to match all
specified Target(s) with the exception of those listed in this TLV.</t>
<t>The value field of the BGP Wide Community Exclude Target(s) TLV is a
series of BGP Wide Community Atom TLVs. The semantics of any given Atom TLV
MUST be part of the definition of a given Wide Community.</t>
<t>If the semantics of a given Atom is undefined for the community in question,
this Atom MUST be ignored.</t>
<t>If the BGP Wide Community Target(s) TLV and the BGP Wide Community Exclude
Target(s) TLV have conflicting semantics, priority MUST be given to the Wide
Community Exclude Target(s) TLV.</t>
<t>When no exclude targets are required by the definition of a given BGP Wide
Community, the BGP Wide Community Exclude Target(s) TLV SHOULD NOT be encoded in
the community. Implementations MUST be prepared to accept a BGP Wide Community
Exclude Target(s) TLV with an empty value field, which MUST be ignored, if received.</t>
</section>
<section title="Sub-Type 3, BGP Wide Community Parameter(s) TLV">
<t>The BGP Wide Community Parameter(s) TLV (Sub-Type 3) contains a list of
Atoms.</t>
<t>A given BGP Wide Community may have parameters that are used as inputs for
executing actions defined for that community. These parameters, and any
constraints implied by the parameters, MUST be defined by the wide community
definition. Parameters consist of an ordered set of Atom sub-TLVs. The
semantics of any specific positional instance of an Atom MUST be defined by the
wide community.</t>
<t>Care must be taken when using Atoms with list semantics. If the desired
behavior is a single or limited number of instances of that type, this
should be documented as part of the use case of that BGP Wide Community.</t>
<t>If a parameter for a given community is of an unexpected
type or length, the BGP Wide Community MUST be ignored.</t>
<t>If there are too many or too few parameters for a given
community, the BGP Wide Community MUST be ignored.</t>
<t>When no parameters are required by the definition of a given Wide Community,
the Wide Community Parameters TLV SHOULD NOT be encoded in the community.
Implementations MUST be prepared to accept a Wide Community Parameter TLV with
an empty value field, which MUST be ignored, if received.</t>
</section>
<section title="Usage">
<t> The detailed interpretation of the targets or parameters SHALL be provided
when describing given community type in a separate document or when locally
defined by an operator.</t>
</section>
</section>
</section>
<!--
<section title="Container Type 2: BGP Wide Community 4:4" anchor="container_def_2">
<figure anchor="container2" title='BGP Wide Community Type 2'>
<preamble>The BGP Community Container type 2 is a fixed size, eight octet community, composed of two 4-octets values. It is encoded as follows:</preamble>
<artwork align='center'>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>A 4:4 Community Container begins with the Common Container Header
followed by a number of communities. Each community is 8 octets long. The length field in the header is the length of the header itself plus 8 times the number of communities after the header. </t>
<t> The Transitivity across AS boundary (T bit) or across confederation boundary (C bit) should be subject to local policy setting with default being set to 0 on both bits indicating full transitiveness. The R flag should be set indicating IANA registration. </t>
<t>The same community value SHOULD NOT appear multiple times within the same update message. If it does, then a receiving BGP speaker MAY discard the duplicates.</t>
<t>If a community container has Transitivity 0, transitive across all ASes, then a BGP speaker SHOULD be configured to strip all received transitive communities that have an unexpected Context ASN.</t>
<t>The textual representation of a 4:4 Community is A:B:C, where A is the Context ASN, B is the first 4 octets and C is the final 4 octets of the community. Each is a decimal non-negative integer without leading zeros, ranging from 0 to 4294967295. Each number must appear, even if it is 0. For example, "0:1:2" cannot be written as ":1:2".</t>
<t>Even though the Context ASN appears once in the container header, when each community is processed by the routing policy language, each community has the Context ASN individually prepended to it.</t>
</section>
<section title="Container Type 3: BGP Wide Community Nx4" anchor="container_def_3">
<figure anchor="container3" title='BGP BGP Community Type 3'>
<preamble>The BGP Community Container type 3 (aka as Nx4) contains a variable number of 4-octets value(s). It is encoded as follows:</preamble>
<artwork align='center'>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The Community Container begins with the Common Container Header
followed by a number of 4 octets values.</t>
<t>The length field in the header is the length of the header itself plus total length of 4 octet values.</t>
<t> The Transitivity across AS boundary (T bit) or across confederation boundary (C bit) should be subject to local policy setting with default being set to 1 on both bits indicating no transitiveness across administration boundary and confederation boundaries. The R flag should be set indicating IANA registration. </t>
</section>
<section title="Container Type 4: BGP Wide Community 16+Nx4" anchor="container_def_4">
<figure anchor="container4" title='BGP Wide Community Type 4'>
<preamble>The BGP Community Container type 4 (aka as 16+Nx4) contains a variable
length value. It is encoded as follows:</preamble>
<artwork align='center'>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Value 0 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Value: 16 octets followed by zero to N times 4 octets</t>
<t>The Community Container begins with the Common Container Header
followed by a single 16 octet field then optionally followed by number
of 4 octets values.</t>
<t> The length field in the header is the length of the
header itself plus total length of 4 octet values.</t>
<t> The Transitivity across AS boundary (T bit) or across confederation boundary (C bit) should be subject to local policy setting with default being set to 1 on both bits indicating no transitiveness across administration boundary and confederation boundaries. The R flag should be set indicating IANA registration. </t>
</section>
-->
<section title="BGP Community Container Atoms" anchor="atoms">
<t>Some types of BGP Community Containers, for example BGP Wide Communities,
will act on and hence need to encode some distinct Atoms of data. The use of
Atoms is solely subject to definition of the specific BGP Container type.
Atoms are encoded as TLVs, where each TLV has the following format:</t>
<figure anchor="atoms_TLV" title='Atoms TLVs'>
<preamble></preamble>
<artwork align='center'>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<postamble></postamble>
</figure>
<t>The Type field contains a value of 1-254. The values 0 and 255 are
reserved for future use. The TLV types are to be assigned and maintained by
IANA registry; see <xref target="iana_atoms"/>.</t>
<t>The Length represents the length of the "Value" field
in octets.</t>
<t>The Value field contains the TLV value.</t>
<t>Supported format of the TLVs can be:</t>
<figure><artwork>
Type 1: Autonomous System Number List.
Type 2: IPv4 Prefix (1 octet prefix length + prefix) List.
Type 3: IPv6 Prefix (1 octet prefix length + prefix) List.
Type 4: Unsigned Integer32 List.
Type 5: IEEE Floating Point Number List.
Type 6: Neighbor Class List.
Type 7: User-defined Class List.
Type 8: UTF-8 String.
</artwork></figure>
<t>The semantics of a given Atom will depend upon the context in which it is
used, as defined by the containing wide community.</t>
<t>In the following sections defining the different Atoms, validation rules for
the Length of the Atom will be presented. If the Length of the Atom does not
match the rules for that Atom, it SHALL be considered malformed. (See
<xref target="error_handling"/>.)</t>
<t>In general, Atoms of List type have the semantics of sets. Duplicate
entries SHOULD NOT be present and MAY be removed by a BGP Speaker propagating
the Lists. The presence of duplicate entries have no additional
semantics.</t>
<section title="Atom Type 1, The Autonomous System Number List">
<t>This Atom represents a list of Autonomous System numbers, each 4 octets in
size. When encoding two-octet ASes, the first two octets of this four-octet
value MUST be filled with zeros. The minimum Length of this Atom is 4 octets. The Length MUST be a
multiple of 4.</t>
<t>Two special values are reserved for the Autonomous
System Atoms:</t>
<figure><artwork>
0x00000000 - to indicate "No Autonomous Systems".
0xFFFFFFFF - to indicate "All Autonomous Systems".
</artwork></figure>
</section>
<section title="Atom Types 2 and 3, The IPv4 and IPv6 Prefix Lists">
<t>This Atom represents a list of IPv4 or IPv6 prefixes. IPv4 and IPv6 Prefix
Atom values are encoded in the same format used by BGP NLRI in Section 4.3 of
<xref target="RFC4271"/>.
</t>
<figure anchor="IP_atoms" title="IP prefix atoms"><artwork align='center'>
+---------------------------+
| Prefix Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
</artwork>
</figure>
<t>The Prefix Length for IPv4 prefixes MUST be in the range of 0..32.</t>
<t>The Prefix Length for IPv6 prefixes MUST be in the range of 0..128.</t>
<t>The Length field must be able to accommodate the list of
prefixes according to the encoding rules. If the Length cannot fully
accommodate the required number of octets to encode the Prefix Length and the
Prefix, the Atom SHALL be considered malformed. (See section <xref target="error_handling"/>
</t>
</section>
<section title="Atom Type 4, The Unsigned Integer32 List">
<t>This Atom represents a list of four-octet Unsigned Integers. These
Unsigned Integers are stored in network byte order.</t>
<t>The minimum Length of the Unsigned Integer32 list Atom is 4 octets. The Length MUST be
a multiple of 4.</t>
</section>
<section title="Atom Type 5, The IEEE Floating Point Number List">
<t>This Atom represents a list of floating point numbers. Floating point
numbers are a fixed Length of 4 octets and are stored in
<xref target="IEEE.754.1985"/> format.</t>
<t>The minimum Length of the Floating Point Number list Atom is 4 octets. The
Length MUST be a multiple of 4.</t>
</section>
<section title="Atom Type 6, The Neighbor Class List">
<t>The Neighbor Class list Atom represents a list of Neighbor classes, each 4 octets in size. Neighbor class currently can contain three values:</t>
<t><list style="hanging" hangIndent="4">
<t hangText="Peer (1):"><vspace/>
This class is typically applied to sessions where a transit-free
relationship exists between two providers.</t>
<t hangText="Customer (2):"><vspace/>
This class is typically applied to sessions where the remote end of the
session is operated by a customer.</t>
<t hangText="Upstream (3):"><vspace/>
This class is typically applied to sessions where the remote end of the
session is operated by a network from which you receive transit routes.</t>
</list></t>
<t>The minimum Length of the Neighbor Class list Atom is 4 octets. The
Length MUST be a multiple of 4.</t>
</section>
<section title="Atom Type 7, The User-defined Class List">
<t>The User-defined Class list Atom represents a list of user-defined classes,
each 4 octets in size. The exact property definition is up to the semantics of
the defining Autonomous System. The semantics governing a given User-defined
Class list are defined by the Context AS Number and the Community Value.</t>
<t>Examples of User-defined Class properties include geography (East, West),
continent (North America, Asia, Europe), etc. Similar to the
<xref target="RFC1997"/> BGP Communities, it is necessary that the Context AS
provide a registry of the value and the semantics of a given community.</t>
<t>The minimum Length of the User-defined Class list Atom is 4 octets. The
Length of this Atom MUST be a multiple of 4.</t>
</section>
<section title="Atom Type 8, the UTF-8 String">
<t>The UTF-8 String Atom represents an arbitrary Unicode string in <xref
target="RFC3629">UTF-8</xref> format. The Length is required to be of
sufficient size to carry the UTF-8 string in the Value field.</t>
<t>Implementations MUST be prepared for truncated/improperly formed UTF-8
strings. When detecting such a string, the implementation should remove
trailing octets of a multi-octet sequence in order to have a well-formed
string.</t>
<t>Implementations MUST be prepared to receive empty (zero-length) UTF-8 String
Atoms as they may be used as Parameters.</t>
</section>
</section>
<section title="Well Known Standard BGP Communities">
<t>According to RFC 1997, as well as IANA's
Well-Known BGP Communities registry, the following
BGP communities are defined to have global significance: </t>
<figure>
<preamble></preamble>
<artwork>
0xFFFF0000 planned-shut [draft-francois-bgp-gshut]
0xFFFFFF01 NO_EXPORT [RFC1997]
0xFFFFFF02 NO_ADVERTISE [RFC1997]
0xFFFFFF03 NO_EXPORT_SUBCONFED [RFC1997]
0xFFFFFF04 NOPEER [RFC3765]
</artwork>
<postamble></postamble>
</figure>
<t>This document recommends for simplicity as well as for avoidance of
backward compatibility issues that the continued use of BGP Standard Community
Path Attribute, type 8, as defined in <xref target="RFC1997"/> and
<xref target="RFC3765"/> to distribute non-Autonomous System specific
Well-Known BGP Communities.</t>
<t>For the same reason, this document does not intend to
obsolete the currently defined and deployed BGP Extended Communities.</t>
</section>
<section title="Operational Considerations">
<t>Having multiple ways to propagate locally assigned BGP Communities -
via the use of Standard, Extended or Large BGP Communities versus the use of
BGP Wide Communities - may seem to potentially cause problems when considering
propagation of conflicting actions. However, even at present, an operator may
append such Communities with conflicting information.</t>
<t>Implementations SHOULD provide mechanisms to control the order of
processing and manipulation of the varying types of BGP communities.
With such a mechanism, operators will have the ability to control the
outcome of potentially conflicting actions.</t>
</section>
<section title="Error Handling" anchor="error_handling">
<section title="General Error Handling for BGP Community Containers">
<t><xref target="RFC7606"/> "treat as withdraw" behavior is expected for any
malformed Community Containers or malformation of their contents.</t>
<t>Each Community Container type may have additional validation rules,
including permitted length of Atoms. Failure to conform to those additional
rules MUST also be treated as a malformed Community Container.</t>
</section>
<section title="BGP Wide Community Container Error Handling">
<t>If any Atom in a BGP Wide Community container's Exclude Targets TLV is
unrecognized, that Wide Community MUST NOT be considered a match and no actions
for that community should be processed. While the
Targets TLV is meant to be inclusive, the Exclude Targets TLV is meant to be
proscriptive of applying the action.</t>
</section>
</section>
<section title="Example">
<section title="Example Type 1 Wide Community Definition">
<t>An operator of an AS 64496, wishes to locally define a Wide Community
with the semantics of permitting AS_PATH prepending with targets that
include AS numbers of peer ASes and peers who have been marked with
a set of enumerated city locations. AS 64496 has selected Community Value 1
to represent this functionality.</t>
<?rfc subcompact="yes" ?>
<t>AS 64496 has established a registered set of values to use for its User-defined Class:<list>
<t>100 - Amsterdam</t>
<t>101 - New York</t>
<t>102 - San Francisco</t>
<t>103 - Tokyo</t>
<t>104 - Moscow</t>
</list></t>
<?rfc subcompact="no" ?>
<t>Target semantics:</t>
<t>
<list>
<t>The Autonomous System Number list Atom refers to the target peer AS Numbers.</t>
<t>The User-defined Class for AS 64496 has been defined elsewhere and the
values 100..104 may be used for this locally defined Wide Community.</t>
<t>The Targets TLV MUST contain at least one entry.</t>
<t>The Exclude Targets TLV MAY contain entries of the above supported Atoms.</t>
<t>The semantics of all other Atoms are undefined for this community.</t>
</list>
</t>
<t>Parameter semantics:</t>
<t><list>
<t>The parameter TLV, used to represent the number of AS_PATH
prepends that will be added by this community, shall consist of
exactly one Unsigned Integer32 Atom value that is constrained to have a value of
2..8.</t>
</list></t>
</section>
<section title="Example Type 1 BGP Wide Community Encoding">
<t>In this example, the BGP Wide Community defined above is used by
a BGP Speaker to AS_PATH prepend BGP routes containing this
community AS_PATH prepend 4 TIMES when this route is to be
distribute to any of AS 2424, AS 8888, to peers marked as
User Class