-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathdraft-ietf-idr-wide-bgp-communities-01.txt
1288 lines (833 loc) · 45.7 KB
/
draft-ietf-idr-wide-bgp-communities-01.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
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
IDR Working Group R. Raszuk, Ed.
Internet-Draft Bloomberg LP
Intended status: Standards Track J. Haas, Ed.
Expires: May 23, 2016 Juniper Networks
A. Lange, Ed.
Alcatel-Lucent
S. Amante
Apple, Inc.
B. Decraene
Orange
P. Jakma
Uni. of Glasgow
R. Steenbergen
nLayer Communications, Inc.
November 20, 2015
Wide BGP Communities Attribute
draft-ietf-idr-wide-bgp-communities-01
Abstract
Route tagging plays an important role in external BGP [RFC4271]
relations, in communicating various routing policies between peers.
It is also a very common best practice among operators to propagate
various additional information about routes intra-domain. The most
common tool used today to attach various information about routes is
through the use of BGP communities [RFC1997].
Such information is important to allow BGP speakers to perform some
mutually agreed actions without the need to maintain a separate
offline database for each tuple of prefix and associated set of
action entries.
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, carry as well as
use for execution an operator's defined set of parameters. It also
provides an extensible platform for any new community encoding needs
in the future.
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].
Raszuk, et al. Expires May 23, 2016 [Page 1]
Internet-Draft wide-bgp-communities November 2015
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 http://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 May 23, 2016.
Copyright Notice
Copyright (c) 2015 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 4
2. Wide Community Atoms . . . . . . . . . . . . . . . . . . . . 5
2.1. The Autonomous System number list atom . . . . . . . . . 6
2.2. The IPv4 and IPv6 prefix list atoms . . . . . . . . . . . 6
2.3. The Integer list atom . . . . . . . . . . . . . . . . . . 6
2.4. The IEEE Floating Point Number list atom . . . . . . . . 7
2.5. The Neighbor Class list atom . . . . . . . . . . . . . . 7
2.6. The User-defined Class list atom . . . . . . . . . . . . 7
2.7. The UTF-8 String atom . . . . . . . . . . . . . . . . . . 8
3. Wide BGP Community Attribute . . . . . . . . . . . . . . . . 8
3.1. Wide BGP Community Attribute Container Header . . . . . . 8
4. Container Type 1: Wide Community . . . . . . . . . . . . . . 10
4.1. Community Value . . . . . . . . . . . . . . . . . . . . . 10
Raszuk, et al. Expires May 23, 2016 [Page 2]
Internet-Draft wide-bgp-communities November 2015
4.2. Source AS Number . . . . . . . . . . . . . . . . . . . . 10
4.3. Context AS Number . . . . . . . . . . . . . . . . . . . . 10
4.4. Wide Community Target(s) TLV . . . . . . . . . . . . . . 11
4.5. Wide Community Exclude Target(s) TLV . . . . . . . . . . 12
4.6. Wide Community Parameter(s) TLV . . . . . . . . . . . . . 12
4.7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. The AS-4 List Generic Wide BGP Community . . . . . . . . . . 13
5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 13
6. Well Known Standard BGP Communities . . . . . . . . . . . . . 13
7. Operational Considerations . . . . . . . . . . . . . . . . . 14
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Example Wide Community Definition . . . . . . . . . . . . 14
9.2. Example Wide Community Encoding . . . . . . . . . . . . . 15
10. Security considerations . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Change History . . . . . . . . . . . . . . . . . . . . . . . 18
13. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . 19
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.1. Normative References . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
RFC 1997 [RFC1997] 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 one or more sets of 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 are to contain the Autonomous System number, with
the next two octets containing some locally defined value.
With the introduction of 4-octet Autonomous System numbers by RFC
4893 [RFC4893] it became obvious that BGP Communities as specified in
RFC 1997 will not be able to accommodate new AS encoding. In fact
RFC 4893 explicitly recommends use of four octets AS specific
[RFC5668] extended communities [RFC4360] as a way to encode new 4
octet AS numbers.
While the encoding of 4 octet AS numbers is being addressed by
[I-D.ietf-idr-as4octet-extcomm-generic-subtype], neither the base BGP
communities (standard or extended) nor as4octet-extcomm-generic
document define a sufficient level of encoding freedom which could be
of practical use. The authors believe that defining a new BGP Path
Raszuk, et al. Expires May 23, 2016 [Page 3]
Internet-Draft wide-bgp-communities November 2015
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 simple encoding will
also facilitate the delivery of new network services without a need
to define a new BGP extension each time.
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
provision for a new registry for future definitions will be contained
in a separate document.
1.1. Protocol Summary
Each Wide BGP Community consists of three main parts:
1. A Container Header. This header is defined in Section 4.
The Container Header encodes:
* Container Type. One Type is defined in this document.
* Flags to control behavior.
* Hop Count to control the degree of Community propagation
* Length
2. The Community itself, defined as a type of Container. The Type 1
Wide Community is defined in Section 4.
The Type 1 Wide Community contains:
* Community Value: This section defines the action that an
operator wishes a router to take.
* Source AS: This is the AS originating the community.
* Context AS: This its the AS context from which community
should be interpreted.
* Target(s): This is an optional list that encodes where the
community's action should be taken.
* Exclude Target(s): This is an optional list that encodes where
the community's actions should not be taken.
* Parameters: This is an optional list that encodes additional
information that the community's action needs to execute
properly.
3. Community Atoms. These are values and lists of values that are
common across community actions. They are defined in Section 2.
Raszuk, et al. Expires May 23, 2016 [Page 4]
Internet-Draft wide-bgp-communities November 2015
2. Wide Community Atoms
Wide BGP communities will act on and hence need to encode some
distinct atoms of data. These are encoded as TLVs, where each TLV
has the following format:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
The Length represents the total length of a given TLV's value field
in octets.
The Value field contains the TLV value.
Supported format of the TLVs can be:
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: Integer list
Type 5: IEEE Floating Point Number list
Type 6: Neighbor Class list
Type 7: User-defined Class list
Type 8: UTF-8 String
The semantics of a given atom will depend upon the context in which
it is used, as defined by the containing wide community.
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 Section 8.)
Raszuk, et al. Expires May 23, 2016 [Page 5]
Internet-Draft wide-bgp-communities November 2015
2.1. The Autonomous System number list atom
This atom represents a list of Autonomous System numbers, each 4
octets in size. The minimum Length of this atom is 4 octets. The
Length MUST be a multiple of 4.
For consistent treatment, all AS numbers MUST be encoded as 4 octet
values. When encoding two octet ASes, the first two octets of this
four octet value MUST be filled with zeros.
Two special values are reserved for the Autonomous System atoms:
0x00000000 - to indicate "No Autonomous Systems".
0xFFFFFFFF - to indicate "All Autonomous Systems".
2.2. The IPv4 and IPv6 prefix list atoms
This atom represents a list of IPv4 or IPv6 prefix. IPv4 and IPv6
prefix atom values are encoded in the same format used by BGP NLRI in
Section 4.3 of [RFC4271].
+---------------------------+
| Prefix Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
The Prefix Length for IPv4 prefixes must be in the range of 0..32.
The Prefix Length for IPv6 prefixes must be in the range of 0..128.
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 is considered malformed.
2.3. The Integer list atom
This atom represents a list of Integers. Integers are a fixed Length
of 4 octets and are stored in network byte order.
The minimum Length of the Integer list atom is 4 octets. The Length
MUST be a multiple of 4.
Raszuk, et al. Expires May 23, 2016 [Page 6]
Internet-Draft wide-bgp-communities November 2015
2.4. The IEEE Floating Point Number list atom
This atom represents a list of floating point numbers. Floating
point numbers are a fixed Length of 4 octets and are stored in
[IEEE.754.1985] format.
This atom represents a list of floating point numbers.
The minimum Length of the Floating Point Number list atom is 4
octets. The Length MUST be a multiple of 4.
2.5. The Neighbor Class list atom
The Neighbor Class list atom represents a classification of a BGP
peering session, each 4 octets in size. This class currently can
contain three values:
1 - Peer: This class is typically applied to sessions where a
transit-free relationship exists between two
providers.
2 - Customer: This class is typically applied to sessions where
the remote end of the session is operated by a
customer.
3 - Upstream: 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.
The Neighbor Class list atom represents a classification of a BGP
peering session.
The minimum Length of the Neighbor Class list atom is 4 octets. The
Length MUST be a multiple of 4.
2.6. The User-defined Class list atom
Similar to the Neighbor Class atom, the User-defined Class list atom
represents a classification of a network property. 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.
Examples of User-defined Class properties include geography (East,
West), continent (North America, Asia, Europe), etc. Similar to the
[RFC1997] BGP Communities, it is necessary that the Context AS
provide a registry of the value and the semantics of a given
community.
Raszuk, et al. Expires May 23, 2016 [Page 7]
Internet-Draft wide-bgp-communities November 2015
The minimum Length of the User-defined Class list atom is 4 octets.
The Length of this atom MUST be a multiple of 4.
2.7. The UTF-8 String atom
The UTF-8 String atom represents an arbitrary Unicode string in UTF-8
[RFC3629] format. The Length is required to be of sufficient size to
carry the UTF-8 string in the Value field.
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.
Implementations MUST be prepared to receive empty (zero-Length) UTF-8
String atoms as they may be used as Parameters.
3. Wide BGP Community Attribute
This document defines a new BGP Path Attribute, the Wide BGP
Community. The attribute type code is (TBA by IANA).
The Wide BGP Community Attribute is an optional, transitive BGP
attribute, and may be present only once in the BGP UPDATE message.
The attribute contains a number of typed containers. Any given
container type may appear multiple times, unless that container
type's definition specifies otherwise.
3.1. Wide BGP Community Attribute Container Header
Containers always start with the following header:
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 | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines one Type code - Type 1. See the Section 11 for
information on additional type registration policies.
Raszuk, et al. Expires May 23, 2016 [Page 8]
Internet-Draft wide-bgp-communities November 2015
+------+-------+----------------------------------------------------+
| Bit | Value | Meaning |
+------+-------+----------------------------------------------------+
| 0 | 0 | Local community value. |
| | 1 | Registered community value. |
| 1 | 0 | Do not decrement Hop Count field across |
| | | confederation boundaries. |
| | 1 | Decrement Hop Count field across confederation |
| | | boundaries. |
| 2..7 | - | MUST be zero when sent and ignored upon receipt. |
+------+-------+----------------------------------------------------+
Flags are defined globally, to apply to all wide community container
types.
Table 1: Flags
Bit 0 (aka R bit) set (value 1) indicates that the given container
carries a Wide BGP Community which is registered with IANA. When not
set (value 0) it indicates that community value which follows is
locally assigned with a local meaning.
Bit 1 (aka C bit) is used to manage the propagation scope of a given
Wide BGP Community across confederation boundaries. When not set
(value of 0), the Hop Count field is not considered at the sub-AS
boundaries. When set (value of 1), sub-AS border router follows the
same procedure regarding the handling of the Hop Count field as
applicable to ASBR at the domain boundary.
The Hop Count field represents the forwarding radius, in units of AS
hops, for the given Wide BGP Community. A Hop Count value of zero
indicates that this wide community must not cross any further AS
boundaries. At each AS boundary, when propagating a given wide
community over an EBGP session, the Hop Count field MUST be
decremented by the sending EBGP speaker.
The exact same decrement procedures described above apply also to
sub-confederation boundaries when the bit 1's flag is set to 1.
The special value of 0xFF indicates that the enclosed community may
always be propagated over an EBGP boundary. A Hop Count value of
0xFF MUST NOT be decremented during propagation.
The Length field represents the total length of a given container in
octets.
Raszuk, et al. Expires May 23, 2016 [Page 9]
Internet-Draft wide-bgp-communities November 2015
4. Container Type 1: Wide Community
The Wide BGP Community Type 1 container is of variable size (but
minimum length 12) and is encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registered/Local Community Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wide Community Target(s) TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wide Community Exclude Target(s) TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wide Community Parameter(s) TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Wide BGP Community Type 1
4.1. Community Value
Community Value: 4 octets
The Wide BGP 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 registered.
4.2. Source AS Number
Source Autonomous System Number: 4 octets
The Autonomous System number which indicates the originator of
this Wide BGP Community.
When the Autonomous System is a two octet number the first two
octets of this 4 octet value MUST be filled with zeros.
4.3. Context AS Number
Context Autonomous System Number: 4 octets
Raszuk, et al. Expires May 23, 2016 [Page 10]
Internet-Draft wide-bgp-communities November 2015
The Autonomous System number that indicates the context of the
Registered/Local Value. For Wide Community Containers that are
Locally defined, the Context Autonomous System number provides the
context for the Community Value and thus the meaning of the community
as well as any User-defined Classes for that Context AS.
For Registered Community Containers, the Context Autonomous System
number MAY be utilized to provide specific meaning for that
Registered community. When no such context is implied, this field
MUST be 0.
When the wide community is locally registered, the Context Autonomous
System Number indicates the AS that defines the format of this wide
community for the given Local Value. (In other words, value 1 will
likely refer to different formats for AS 1 vs. AS 2.)
4.4. Wide Community Target(s) TLV
The Wide Community Target(s) TLV (Type 1) contains a list of a Wide
Community atoms.
Wide Community Targets define the matching criteria for the
community. A given wide community may have a number of targets that
it applies to. The semantics of these targets will vary on a per
community basis. Depending on the definition of the community,
targets may be optional.
The value field of the Wide Community Target(s) TLV is a series of
Wide Community Atom TLVs. The semantics of any given atom TLV MUST
be part of the definition of a given Wide Community.
Typically, 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.
When no Target(s) TLV is specified, it is considered "match all".
If the semantics of a given atom is undefined for the community in
question, it MUST be ignored.
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.
Raszuk, et al. Expires May 23, 2016 [Page 11]
Internet-Draft wide-bgp-communities November 2015
4.5. Wide Community Exclude Target(s) TLV
The Wide Community Exclude Target(s) TLV (Type 2) contains a list of
a Wide Community atoms.
Wide Community Exclude Targets define criteria by which the community
is considered to NOT match. Depending on the semantics of the Wide
Community, Exclude Target(s) may be optional.
The semantic of the Wide Community Exclude Target(s) is to match all
specified Target(s) with the exception of those listed in this TLV.
The value field of the Wide Community Exclude Target(s) TLV is a
series of Wide Community Atom TLVs. The semantics of any given atom
TLV MUST be part of the definition of a given Wide Community.
If the semantics of a given atom is undefined for the community in
question, it MUST be ignored.
If the Wide Community Target(s) TLV and the Wide Community Exclude
Target(s) TLV have conflicting semantics, priority MUST be given to
the Wide Community Exclude Target(s) TLV.
When no exclude targets are required by the definition of a given
Wide Community, the Wide Community Exclude Target(s) TLV SHOULD NOT
be encoded in the community. Implementations MUST be prepared to
accept a Wide Community Exclude Target(s) TLV with an empty value
field.
4.6. Wide Community Parameter(s) TLV
The Wide Community Parameter(s) TLV (Type 3) contains a list of a
Wide Community atoms.
A given wide community may have parameters which 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.
If it is the case that a parameter for a given community is of an
unexpected type or length, the community MUST be ignored.
If it is the case that there are too many or two few parameters for a
given community, the community MUST be ignored.
Raszuk, et al. Expires May 23, 2016 [Page 12]
Internet-Draft wide-bgp-communities November 2015
When no parameters are required by the definition of a given Wide
Community, the Wide Community Paramters TLV SHOULD NOT be encoded in
the community. Implementations MUST be prepared to accept a Wide
Community Parameter TLV with an empty value field.
4.7. Usage
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.
5. The AS-4 List Generic Wide BGP Community
In standard [RFC1997] BGP Communities, a commonly deployed format is
AS:0x0000-0xFFFF. The left-hand-side AS is the context AS while the
right-hand-side represents an action intended to be taken upon that
AS. While the [I-D.ietf-idr-as4octet-extcomm-generic-subtype]
Extended Community format is intended to address the use cases where
the right-hand-side represents a semi-opaque integer value, operators
that desire to utilize the right-hand-side as an Autonomous System
Number have been unable to do so.
In the AS:0x0000-0xFFFF format, there are no explicit semantics on
the action for a given right-hand-side. The semantics are implicit
to the Autonomous System number itself. While such a format doesn't
take advantage of the more flexible semantics of Wide BGP
Communities, the format is capable of addressing this operational
need.
This document defines a Registered Wide BGP Community to address that
need.
5.1. Definition
Community Value: 1 - AS-4 List Generic Wide BGP Community
Source AS Number: <Your AS number>
Context AS Number: <Targeted AS number>
Wide Community Target(s): <MUST BE ABSENT>
Wide Community Exclude Target(s): <MUST BE ABSENT>
Wide Community Parameter(s): <Wide Community Atom Type 4>
6. Well Known Standard BGP Communities
According to RFC 1997, as well as IANA's Well-Known BGP Communities
registry, the following BGP communities are defined to have global
significance:
Raszuk, et al. Expires May 23, 2016 [Page 13]
Internet-Draft wide-bgp-communities November 2015
0xFFFF0000 planned-shut [draft-francois-bgp-gshut]
0xFFFFFF01 NO_EXPORT [RFC1997]
0xFFFFFF02 NO_ADVERTISE [RFC1997]
0xFFFFFF03 NO_EXPORT_SUBCONFED [RFC1997]
0xFFFFFF04 NOPEER [RFC3765]
This document recommends for simplicity as well as for avoidance of
backward compatibility issues the continued use of BGP Standard
Community Attribute type 8 as defined in RFC 1997 to distribute non
Autonomous System specific Well-Known BGP Communities.
For the same reason, this document does not intended to obsolete the
currently defined and deployed BGP Extended Communities.
7. Operational Considerations
Having two different ways to propagate locally assigned BGP
communities, one via the use of Standard BGP Communities and the
other one via the use of Wide BGP Communities, may seem to
potentially cause problems when considering propagation of
conflicting actions. However, even at present, an operator may
append Standard BGP Communities with conflicting information. It is
therefore recommended that any implementation, in supporting both
standard and Wide BGP communities, allow for their easy inbound and
outbound processing. The actual execution of all communities should
be treated as a union and, if supported by an implementation, their
execution permissions are to be a local configuration matter.
8. Error Handling
If any atom in a Wide Community container's Exclude Targets TLV is
unrecognized, no actions should be taken for that Wide Community.
While the Targets TLV is meant to be inclusive, the Exclude Targets
TLV is meant to be proscriptive of applying the action.
If any Wide Community container or atoms contained therein are
determined to be malformed, the Wide Community Path attribute must be
considered malformed. BGP implementations should use "treat-as-
withdraw" semantics as defined in [I-D.ietf-idr-error-handling].
9. Example
9.1. Example Wide Community Definition
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.
Raszuk, et al. Expires May 23, 2016 [Page 14]
Internet-Draft wide-bgp-communities November 2015
AS 64496 has established a registered set of values to use for its
User-defined Class:
100 - Amsterdam
101 - New York
102 - San Francisco
103 - Tokyo
104 - Moscow
Target semantics:
The Autonomous System Number list atom refers to the target peer
AS Numbers.
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.
The Targets TLV MUST contain at least one entry.
The Exclude Targets TLV MAY contain entries of the above supported
atoms.
The semantics of all other atoms are undefined for this community.
Parameter semantics:
The parameter TLV shall consist of exactly one Integer atom value
that is constrained to have a value of 2..8.
9.2. Example Wide Community Encoding
AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers marked as
Amsterdam (100) or to peers marked Moscow (104), but not to peers
in New York (101).
Use Hop Count 0 to request the receiving router to not propagate
this wide community.
Locally community value (flag bit 0 = 0).
Do not decrement Hop Count field across confederation boundaries
(0)
Local community 1 for sample AS 64496.
Raszuk, et al. Expires May 23, 2016 [Page 15]
Internet-Draft wide-bgp-communities November 2015
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Container Type 1 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
| Hop Count: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length: 57 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community: LOCAL PREPEND ACTION CATEGORY 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Own ASN 64496 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context ASN# 64496 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target TLV (1)| Length: 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN List (2) | Length: 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target ASN# 2424 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target ASN# 8888 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User List(7) | Length: 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Amsterdam 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Moscow 104 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ExcTargetTLV(2)| Length: 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User List(7) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New York 101 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param TLV (3) | Length: 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer (4) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prepend # 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Raszuk, et al. Expires May 23, 2016 [Page 16]
Internet-Draft wide-bgp-communities November 2015
10. Security considerations
All the security considerations for BGP Communities as well as for
BGP RFCs apply here.
Given the flexibility and power offered by Wide BGP communities, it
is important to consider the additional possibilities allowed by
their definition. In particular, for locally defined Wide BGP
Communities, it may be wise to restrict the range of parameters. For
registred Wide BGP Communities, the security considerations of the
document defining them MUST address issues specific to those newly
defined Wide Communities.
Security considerations specific to Wide BGP Communities will be
discussed in a later revision of this draft.
11. IANA Considerations
This document defines a new BGP Path Attribute called Wide BGP
Community Attribute. For this new type IANA is to allocate a new
value in the corresponding registry:
Registry Name: BGP Path Attributes
This document makes the following assignments for the optional,
transitive Wide BGP Communities Attribute:
Name Type Value
---- ----------
Wide BGP Community Attribute TBA
This document requests IANA to define and maintain a new registry
named: "Wide BGP Communities Attribute Container Types".
The pool of: 0x0000-0xFFFF has been defined for its allocations. The
allocation policy is on a first come, first served basis.
This document makes the following assignments for the Wide BGP
Communities Container Types values:
Name Type Value
---- ----------
Reserved 0x0000
Type 1, Wide BGP Community 0x0001
Types 2-1023 to be allocated using IETF Consensus
Types 1024-64511 to be allocated first come, first served
Types 64512-65534 are reserved for experimental use
Reserved 0xFFFF
Raszuk, et al. Expires May 23, 2016 [Page 17]
Internet-Draft wide-bgp-communities November 2015
This document requests IANA to define and maintain a new registry
named: "Wide BGP Communities Atom Types". The pool of 0x0000-0xFFFF
has been defined for its allocations.
This document makes the following assignments for the Wide BGP
Communities Atom Type values:
Name Type Value
---- ----------
Reserved 0x00
Autonomous System Number List 0x01
IPv4 Prefix list 0x02
IPv6 Prefix list 0x03
Integer list 0x04
IEEE Floating Point Number list 0x05
Neighbor Class list 0x06
User-defined Class list 0x07
UTF-8 string 0x08
Reserved 0xFF
This document requests IANA to define and maintain a new registry
named: "Registered Wide BGP Communities". The pool of
0x00000000-0FFFFFFFF has ben defined for its allocation.
This document makes the following assignments for the Registered Wide
BGP Communities:
Name Type Value
---- ----------
Reserved 0x00
AS-4 List Generic Wide BGP Community 0x01
Reserved 0xFFFFFFFF
Values 2-1023 are to be allocated using IETF Consensus. Values
64512-65534 are reserved for experimental use. All other values are
available on a first-come, first served basis.
12. Change History
Changes from -03 via -04 to -05:
Update the Introduction.