|
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
|
Inter-Domain Routing A. Retana
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track R. White
Expires: October 22, 2015 Ericsson
April 20, 2015
BGP Custom Decision Process
draft-ietf-idr-custom-decision-06
Abstract
The BGP specification defines a Decision Process for installation of
routes into the Loc-RIB. This process takes into account an
extensive series of path attributes, which can be manipulated to
indicate preference for specific paths. It is cumbersome (if at all
possible) for the end user to define policies that will select, after
partial comparison, a path based on subjective local (domain and/or
node) criteria.
This document defines a new Extended Community, called the Cost
Community, which may be used in tie breaking during the best path
selection process. The end result is a local custom decision
process.
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 October 22, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Retana & White Expires October 22, 2015 [Page 1]
Internet-Draft BGP Custom Decision Process April 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. The BGP Cost Community . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Cost Community Point of Insertion Registry . . . . . 7
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 8
B.1. Changes between the -00 and -01 versions. . . . . . . . . 8
B.2. Changes between the -01 and -02 versions. . . . . . . . . 8
B.3. Changes between the -02 and -03 versions. . . . . . . . . 8
B.4. Changes between the -03 and -04 versions. . . . . . . . . 8
B.5. Changes between the -04 and -05 versions. . . . . . . . . 9
B.6. Changes between the -05 and -06 versions. . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
There are a number of metrics available within the BGP decision
process [RFC4271] which can be used to determine the exit point for
traffic, but there is no metric, or combination of metrics, which can
be used to break a tie among generally equal paths.
o LOCAL_PREF: The LOCAL_PREF is an absolute tie breaker near the
beginning of the decision process. There is no way to configure
the LOCAL_PREF such that the MED, IGP metric, and other metrics
are considered before breaking a tie.
o MED: The MULTI_EXIT_DISC is an indicator of which local entrance
point an AS would like a peering AS to use; MED isn't suitable to
break the tie between two equal cost paths learned from two peer
Retana & White Expires October 22, 2015 [Page 2]
Internet-Draft BGP Custom Decision Process April 2015
ASes. MED is also compared before the IGP metric; there is no way
to set the MED so a path with a higher IGP metric is preferred
over a path with a lower IGP metric.
o IGP Metric: It is possible, using the IGP metric, to influence
individual paths with otherwise equal cost metrics, but only by
changing the next hop towards each path, and configuring the IGP
costs of reaching each next hop. This method is cumbersome, and
prone to confusion and error.
The BGP specification defines a Decision Process for installation of
routes into the Loc-RIB. This process takes into account an
extensive series of path attributes, which can be manipulated to
indicate preference for specific paths. It is cumbersome (if at all
possible) for the end user to define policies that will select, after
partial comparison, a path based on subjective local (domain and/or
node) criteria.
This document defines a new Extended Community, called the Cost
Community, which may be used in tie breaking during the best path
selection process. The end result is a custom decision process.
2. 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 [RFC2119].
3. The BGP Cost Community
The BGP Cost Community is an Opaque Extended Community [RFC4360]
defined as follows:
Type Field:
The value of the high-order octet of this Opaque Extended
Community is 0x03 or 0x43. The value of the low-order octet of
the extended type field for this community is 0x01.
Value Field:
The Value field contains three distinct sub-fields, described
below:
Retana & White Expires October 22, 2015 [Page 3]
Internet-Draft BGP Custom Decision Process April 2015
+------------------------------+
| Point of Insertion (1 octet) |
+------------------------------+
| Community-ID (1 octet) |
+------------------------------+
| Cost (4 octets) |
+------------------------------+
The Point of Insertion sub-field contains the value of the path
attribute *after* which this community MUST be considered during
the best path selection process.
The BGP decision process includes some steps that do not
correspond to any path attribute; the following values are
defined:
128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be
considered as the first step in determining the Degree of
Preference of a path.
129 IGP_COST - Indicates that the Cost Community MUST be
considered after the interior (IGP) distance to the next-hop
has been compared.
130 EXTERNAL_INTERNAL - Indicates that the Cost Community MUST
be considered after the paths advertised by BGP speakers in
a neighboring autonomous system (if any) have been selected.
131 BGP_ID - Indicates that the Cost Community MUST be
considered after the BGP Identifier (or ORIGINATOR_ID
[RFC4456]) has been compared.
The Community-ID sub-field contains an identifier to distinguish
between multiple instances of the Cost Community. The high-order
bit is reserved to indicate that the Cost Community MUST replace
the path attribute specified by the Point of Insertion during the
best path selection process.
The Cost sub-field contains a value assigned by the network
administrator and that is significant to the local autonomous
system. The lower cost MUST be preferred. The default value is
0x7FFFFFFF (half the maximum value).
Retana & White Expires October 22, 2015 [Page 4]
Internet-Draft BGP Custom Decision Process April 2015
4. Operation
The network administrator may use the Cost Community to assign a
value to a path originated or learned from a peer in any part of the
local domain. The Point of Insertion MUST also be specified using
the values defined in Appendix A.
If a BGP speaker receives a path that contains the Cost Community, it
SHOULD consider its value at the Point of Insertion specified, when
calculating the best path [RFC4271].
If the Point of Insertion is not valid for the local best path
selection implementation, then the Cost Community SHOULD be silently
ignored. Paths that do not contain the Cost Community (for a valid,
particular Point of Insertion) MUST be considered to have the default
value.
Multiple Cost Communities may indicate the same Point of Insertion.
In this case, the Cost Community with the lowest Community-ID is
considered first. In other words, all the Cost Communities for a
specific Point of Insertion MUST be considered, starting with the one
with the lowest Community-ID.
If a range of routes is to be aggregated and the resultant aggregate
path attributes do not carry the ATOMIC_AGGREGATE attribute, then the
resulting aggregate SHOULD have an Extended Communities path
attribute which contains the set union of all the Cost Communities
from all of the aggregated routes. If multiple Cost Communities for
the same Point of Insertion (and with the same Community-ID) exist,
then only the ones with the highest Cost SHOULD be included.
If the non-transitive version of a Cost Community is received across
an Autonomous System boundary, then the receiver MUST strip it off
the BGP update, and ignore it when running the selection process.
5. Deployment Considerations
The mechanisms described in this document may be used to modify the
BGP path selection process arbitrarily. It is important that a
consistent path selection process be maintained across the local
Autonomous System to avoid potential routing loops. In other words,
if the Cost Community is used, all the nodes in the AS that may have
to consider this new community at any Point of Insertion SHOULD be
aware of the mechanisms described in this document.
Retana & White Expires October 22, 2015 [Page 5]
Internet-Draft BGP Custom Decision Process April 2015
6. Security Considerations
This document introduces no new security concerns to BGP or other
specifications referenced in this document.
7. IANA Considerations
IANA is asked to assign the type values indicated in Section 3 to the
Cost Community in the BGP Opaque Extended Community registry
[BGP_EXT].
Section 3 also defines a series of values to be used to indicate
steps in the best path selection process that do not map directly to
a path attribute. IANA is expected to maintain a registry for the
Cost Community Point of Insertion values. Values 1 through 127 are
to be assigned using the "Standards Action" policy or the Early
Allocation process [RFC7120]. Values 128 through 191 are to be
assigned using the "IETF Consensus" policy. Values 192 through 254
are to be assigned using the "First Come First Served" policy.
Values 0 and 255 are reserved for future use and SHOULD NOT be used.
All the policies mentioned are documented in [RFC5226].
Some of the values in this new registry match the values assigned in
the BGP Path Attributes registry [BGP_PAR]. It is RECOMMENDED that
an effort be made to assign the same values in both tables when
applicable. The table in Appendix A shows the initial allocations
for the new Cost Community Point of Insertion registry.
8. Acknowledgements
There have been many people who have shown their support and provided
valuable input, comments and implementations -- the authors would
like to thank all of them! We would like to also thank Dan Tappan
for the Opaque Extended Community type.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Retana & White Expires October 22, 2015 [Page 6]
Internet-Draft BGP Custom Decision Process April 2015
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014.
9.2. Informative References
[BGP_EXT] Internet Assigned Numbers Authority, "BGP Extended
Communities", 2010, <http://www.iana.org/assignments/
bgp-extended-communities>.
[BGP_PAR] Internet Assigned Numbers Authority, "BGP Parameters",
2010, <http://www.iana.org/assignments/bgp-parameters/>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006.
Appendix A. Cost Community Point of Insertion Registry
The tables below document the initial Cost Community Point of
Insertion Registry
+---------+-------------------------+
| Range | Registration Procedure |
+---------+-------------------------+
| 0 | Reserved |
| 1-127 | Standards Action |
| 128-191 | IETF Consensus |
| 192-254 | First Come First Served |
| 255 | Reserved |
+---------+-------------------------+
Registration Procedure
Retana & White Expires October 22, 2015 [Page 7]
Internet-Draft BGP Custom Decision Process April 2015
+--------+-------------------+--------------------------------+
| Value | Code | Reference |
+--------+-------------------+--------------------------------+
| 1 | ORIGIN | RFC4271 |
| 2 | AS_PATH | RFC4271 |
| 3 | Unassigned | |
| 4 | MULTI_EXIT_DISC | RFC4271 |
| 5 | LOCAL_PREF | RFC4271 |
| 6-25 | Unassigned | |
| 26 | AIGP | draft-ietf-idr-aigp |
| 27-127 | Unassigned | |
| 128 | ABSOLUTE_VALUE | draft-ietf-idr-custom-decision |
| 129 | IGP_COST | draft-ietf-idr-custom-decision |
| 130 | EXTERNAL_INTERNAL | draft-ietf-idr-custom-decision |
| 131 | BGP_ID | draft-ietf-idr-custom-decision |
+--------+-------------------+--------------------------------+
Point of Insertion Codes
Appendix B. Change Log
B.1. Changes between the -00 and -01 versions.
o Updated authors' contact information.
o Editorial changes in the "Operations" and "Acknowledgement"
sections.
B.2. Changes between the -01 and -02 versions.
o Updated authors' contact information.
o Added text to replace a step in the selection process.
o Minor edits.
B.3. Changes between the -02 and -03 versions.
o No changes; just a refresh.
B.4. Changes between the -03 and -04 versions.
o Updated authors' contact information.
Retana & White Expires October 22, 2015 [Page 8]
Internet-Draft BGP Custom Decision Process April 2015
B.5. Changes between the -04 and -05 versions.
o Updated authors' contact information.
B.6. Changes between the -05 and -06 versions.
o Updated RFC 7120 reference (from RFC 4020).
Authors' Addresses
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Email: aretana@cisco.com
Russ White
Ericsson
Email: russw@riw.us
Retana & White Expires October 22, 2015 [Page 9]
|
|
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
|
Inter-Domain Routing A. Retana
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track R. White
Expires: April 28, 2016 Ericsson
October 26, 2015
BGP Custom Decision Process
draft-ietf-idr-custom-decision-07
Abstract
The BGP specification describes a Decision Process for selecting the
best route. This process uses a series of steps, made up of path
attributes and other values, to first determine the Degree of
Preference of a route and later as tie breakers. While existing
mechanisms may achieve some of the same results described in this
document, they can only do so through extensive configuration such as
matching communities to explicit policy and/or route preference
configurations present on each BGP speaker within their
administrative domain (autonomous system). Implementing some
specific fine grained policies through such mechanisms is cumbersome,
if even possible.
This document defines a new Extended Community, called the Cost
Community, which may be used as part of the Decision Process. The
end result is a local Custom Decision Process.
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 April 28, 2016.
Retana & White Expires April 28, 2016 [Page 1]
Internet-Draft BGP Custom Decision Process October 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. The BGP Cost Community . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. Cost Community Point of Insertion Registry . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9
A.1. Changes between the -00 and -01 versions. . . . . . . . . 9
A.2. Changes between the -01 and -02 versions. . . . . . . . . 10
A.3. Changes between the -02 and -03 versions. . . . . . . . . 10
A.4. Changes between the -03 and -04 versions. . . . . . . . . 10
A.5. Changes between the -04 and -05 versions. . . . . . . . . 10
A.6. Changes between the -05 and -06 versions. . . . . . . . . 10
A.7. Changes between the -06 and -07 versions . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The BGP specification defines a Decision Process [RFC4271] for
selecting the best route. This process uses a series of steps, made
up of path attributes and other values, to first determine the Degree
of Preference of a route and later as tie breakers. While existing
mechanisms may achieve some of the same results described in this
document, they can only do so through extensive configuration such as
matching communities to explicit policy and/or route preference
Retana & White Expires April 28, 2016 [Page 2]
Internet-Draft BGP Custom Decision Process October 2015
configurations present on each BGP speaker within their
administrative domain (autonomous system). Implementing some
specific fine grained policies through such mechanisms is cumbersome,
if even possible. For example:
o Local Preference: The LOCAL_PREF is an attribute used to calculate
the Degree of Preference in the Decision Process. There is no
secondary degree of preference indicator available that can be
considered after the MED, IGP metric, or other attributes.
o Multi-Exit Discriminator (MED): The MULTI_EXIT_DISC is an
indicator of which local entrance point an AS would like a peering
AS to use. As the MED is compared before the IGP metric, there is
no way to set the MED so a route with a higher IGP metric is
preferred over one with a lower IGP metric.
o IGP Metric: It is possible, to influence individual routes, but
only by changing the next hops, and configuring the IGP metric for
reaching them. This method is cumbersome and prone to confusion
and error.
This document defines a new Extended Community [RFC4360], called the
Cost Community, which may be used as part of the Decision Process.
The end result is a local Custom Decision Process.
2. 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 [RFC2119].
3. The BGP Cost Community
The BGP Cost Community is an Opaque Extended Community [RFC4360]
defined as follows:
Type Field:
The value of the high-order octet is determined by provisioning
[RFC4360]. IANA has assigned the codepoint value 0x01 to 'Cost
Community' in both the Transitive Opaque Extended Community Sub-
Types registry and the Non-Transitive Opaque Extended Community
Sub-Types registry.
Value Field:
Retana & White Expires April 28, 2016 [Page 3]
Internet-Draft BGP Custom Decision Process October 2015
The Value field contains three distinct sub-fields, described
below:
+------------------------------+
| Point of Insertion (1 octet) |
+------------------------------+
| Community-ID (1 octet) |
+------------------------------+
| Cost (4 octets) |
+------------------------------+
The Point of Insertion (POI) sub-field indicates *after*, or
*instead of*, which step in the Decision Process the Cost
Community MUST be considered.
The value of the POI may reference a path attribute used in the
Decision Process. In this case the Cost Community is
considered after, or instead of, the step where the path
attribute is considered.
The Decision Process includes some steps that do not correspond
to any path attribute; the following values are defined:
128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be
considered as the first step in determining the Degree of
Preference of a route (Section 9.1.1 of [RFC4271]). If two
routes have the same Cost, then the rest of the Calculation
of Degree of Preference is to be followed.
129 IGP_COST - Indicates that the Cost Community MUST be
considered after the interior (IGP) distance to the next-hop
has been compared.
130 EXTERNAL_INTERNAL - Indicates that the Cost Community MUST
be considered after Paragraph d of Section 9.1.2.2 of
[RFC4271].
131 BGP_ID - Indicates that the Cost Community MUST be
considered after the BGP Identifier (or ORIGINATOR_ID
[RFC4456]) has been compared.
This document creates a new Cost Community Point of Insertion
Registry (Section 7.1) that includes the relevant path
attributes and these other values.
The Community-ID sub-field contains an identifier to distinguish
between multiple instances of the Cost Community. The high-order
Retana & White Expires April 28, 2016 [Page 4]
Internet-Draft BGP Custom Decision Process October 2015
bit indicates that the Cost Community MUST replace the step
indicated by the POI in the Decision Process.
If the high-order bit is set, the Cost in the Cost Community
may replace the value of a path attribute at a specific step in
the Decision Process, but not the attribute itself. For
example, if the high-order bit is set with the AS_PATH POI, the
AS_PATH attribute would still be used for loop prevention
[RFC4271], but the Cost would replace its length in the
Decision Process.
The high-order bit MUST be ignored when used with the
ABSOLUTE_VALUE POI.
If the Accumulated IGP Metric Attribute (AIGP) [RFC7311] is
used such that the "AIGP-enhanced interior cost" replaces the
"interior cost" tie breaker in the Decision Process, and the
high-order bit is set with the IGP_COST POI, then the Cost
Community SHOULD be ignored in favor of the process described
in Section 4.2 of [RFC7311].
The Cost sub-field is a 32-bit unsigned integer. It contains a
value assigned by the network administrator that is significant to
their administrative domain. The default Cost is 0x7FFFFFFF (half
the maximum).
If the Cost Community is inserted after a step in the Decision
Process, and is therefore only compared to other Cost
Communities, the lower Cost MUST be preferred.
If the Cost Community replaces a step in the Decision Process,
it MUST be treated exactly as the value it is replacing would
be treated. It is up to the network administrator to select
the appropriate Cost to use when replacing a specific step; the
method to do that is outside the scope of this document.
4. Operation
The network administrator may use the Cost Community to assign a Cost
to a route originated, or learned from a peer, in any part of their
administrative domain. The POI MUST also be specified.
If a BGP speaker receives a route that contains the Cost Community,
it MUST consider its Cost at the POI specified, during the Decision
Process.
If the POI is not valid for the local Decision Process
implementation, then the Cost Community SHOULD be silently ignored.
Retana & White Expires April 28, 2016 [Page 5]
Internet-Draft BGP Custom Decision Process October 2015
Multiple Cost Communities may indicate the same POI. All the Cost
Communities for a specific POI MUST be considered starting with the
one(s) with the lowest Community-ID. If multiple Cost Communities,
for the same POI, with the same Community-ID are received for the
same route from the same peer, then all except the one with the
lowest Cost MUST be silently ignored.
Routes that do not contain the Cost Community (for a valid,
particular POI), or a Community-ID present in a route from another
peer, MUST be considered to have the default Cost.
If a range of routes is to be aggregated and the resultant aggregate
path attributes do not carry the ATOMIC_AGGREGATE attribute, then the
resulting aggregate SHOULD have an Extended Communities path
attribute which contains the set union of all the Cost Communities
from all of the aggregated routes. If multiple Cost Communities for
the same POI (and with the same Community-ID) exist, then only the
ones with the highest Cost SHOULD be included.
If the non-transitive version of a Cost Community is received across
an Autonomous System boundary, then the receiver MUST strip it off
the BGP update, and ignore it during the Decision Process.
5. Deployment Considerations
The mechanisms described in this document may be used to modify the
Decision Process arbitrarily. It is important that a consistent
Decision Process be maintained across the local Autonomous System to
avoid potential routing loops. In other words, all the nodes in the
AS that may have to consider the Cost Community at any POI MUST
support the mechanisms described in this document.
Any mechanism which allows the modification of the Decision Process
is capable of forming persistent routing loops in the control plane.
Network administrators deploying the Cost Community MUST ensure that
each impacted router in the network supports them, including the POIs
deployed within their network. This is similar in scope to a network
administrator who uses communities [RFC1997] combined with filters or
other policies to modify the Decision Process of BGP speakers.
Consistency must be enforced at an administrative level.
6. Security Considerations
This document defines a new Extended Community, called the Cost
Community, which may be used to customize the Decision Process. As
such, the considerations outlined in [RFC4360] and [RFC4271] do not
change.
Retana & White Expires April 28, 2016 [Page 6]
Internet-Draft BGP Custom Decision Process October 2015
To minimize the potential of creating routing loops (Section 5) or
otherwise affecting the Decision Process in unintended ways, the
propagation of Cost Communities MUST be disabled by default and MUST
be explicitly enabled by the network administrator. Furthermore, all
transitive Cost Communities received across an Autonomous System
boundary without explicit configuration MUST be stripped off the BGP
update, and ignored during the Decision Process.
An ill-designed policy deployment using the Cost Community (e.g. one
where there is no consistent POI support throughout the AS) may
result in persistent routing loops that could result in loss of
traffic. The design and implementation of policies for best route
selection are outside the scope of this document.
7. IANA Considerations
IANA has assigned the codepoint value 0x01 to 'Cost Community' in
both the Transitive Opaque Extended Community Sub-Types registry and
the Non-Transitive Opaque Extended Community Sub-Types registry.
Section 3 also defines a series of values to be used to indicate
steps in the Decision Process that do not map directly to a path
attribute. IANA is expected to maintain a registry for the Cost
Community POI values.
o Values 1 through 127 are to be assigned using the "Standards
Action" policy or the Early Allocation process [RFC7120].
o Values 128 through 191 are to be assigned using the "IETF
Consensus" policy.
o Values 192 through 254 are to be assigned using the "First Come
First Served" policy.
o Values 0 and 255 are reserved.
All the policies mentioned are documented in [RFC5226].
The table in Section 7.1 shows the initial allocations for the new
Cost Community Point of Insertion registry.
7.1. Cost Community Point of Insertion Registry
The tables below document the initial Cost Community Point of
Insertion Registry
Retana & White Expires April 28, 2016 [Page 7]
Internet-Draft BGP Custom Decision Process October 2015
+---------+-------------------------+
| Range | Registration Procedure |
+---------+-------------------------+
| 0 | Reserved |
| 1-127 | Standards Action |
| 128-191 | IETF Consensus |
| 192-254 | First Come First Served |
| 255 | Reserved |
+---------+-------------------------+
Registration Procedure
+--------+-------------------+--------------------------------+
| Value | Code | Reference |
+--------+-------------------+--------------------------------+
| 1 | ORIGIN | RFC4271 |
| 2 | AS_PATH | RFC4271 |
| 3 | Unassigned | |
| 4 | MULTI_EXIT_DISC | RFC4271 |
| 5 | LOCAL_PREF | RFC4271 |
| 6-25 | Unassigned | |
| 26 | AIGP | RFC7311 |
| 27-127 | Unassigned | |
| 128 | ABSOLUTE_VALUE | draft-ietf-idr-custom-decision |
| 129 | IGP_COST | draft-ietf-idr-custom-decision |
| 130 | EXTERNAL_INTERNAL | draft-ietf-idr-custom-decision |
| 131 | BGP_ID | draft-ietf-idr-custom-decision |
+--------+-------------------+--------------------------------+
Point of Insertion
8. Acknowledgements
There have been many people who have shown their support and provided
valuable input, comments and implementations -- the authors would
like to thank all of them! We would like to also thank Dan Tappan
for the Opaque Extended Community type. Bruno Decraene and Eric
Rosen thoroughly reviewed this document and helped improved its
quality significantly.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Retana & White Expires April 28, 2016 [Page 8]
Internet-Draft BGP Custom Decision Process October 2015
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
"The Accumulated IGP Metric Attribute for BGP", RFC 7311,
DOI 10.17487/RFC7311, August 2014,
<http://www.rfc-editor.org/info/rfc7311>.
9.2. Informative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<http://www.rfc-editor.org/info/rfc4456>.
Appendix A. Change Log
This section is to be removed before publication.
A.1. Changes between the -00 and -01 versions.
o Updated authors' contact information.
o Editorial changes in the "Operations" and "Acknowledgement"
sections.
Retana & White Expires April 28, 2016 [Page 9]
Internet-Draft BGP Custom Decision Process October 2015
A.2. Changes between the -01 and -02 versions.
o Updated authors' contact information.
o Added text to replace a step in the selection process.
o Minor edits.
A.3. Changes between the -02 and -03 versions.
o No changes; just a refresh.
A.4. Changes between the -03 and -04 versions.
o Updated authors' contact information.
A.5. Changes between the -04 and -05 versions.
o Updated authors' contact information.
A.6. Changes between the -05 and -06 versions.
o Updated RFC 7120 reference (from RFC 4020).
A.7. Changes between the -06 and -07 versions
o The review from Bruno Decraene and Eric Rosen resulted in several
important changes related to the clarity and consistency of the
document.
o Added considerations for co-existence with AIGP.
o Security Considerations.
Authors' Addresses
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Email: aretana@cisco.com
Retana & White Expires April 28, 2016 [Page 10]
Internet-Draft BGP Custom Decision Process October 2015
Russ White
Ericsson
Apex, NC 27539
USA
Email: russw@riw.us
Retana & White Expires April 28, 2016 [Page 11]
|