Carry component communities into an aggregate
05Aggregation combines more-specific routes into a broader route. RFC 1997 gives a conditional recommendation about the aggregate community set.
This new comparison changes the condition. RFC 1997 does not prescribe the union recommendation for this case, and it does not order the tags to be removed.
Source for this drawing: RFC 1997 · Read RFC source: Aggregation · p.4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
If the aggregate does not carry ATOMIC_AGGREGATE, RFC 1997 says it should contain all communities of the aggregated routes. The original lowercase should is not rewritten as an unconditional MUST.
- If the aggregate does not carry ATOMIC_AGGREGATE, RFC 1997 says it should contain all communities of the aggregated routes. The original lowercase should is not rewritten as an unconditional MUST.
- The worked union includes each value once: community ordering is not a preference and the same value need not be duplicated.
- When ATOMIC_AGGREGATE is present, this paragraph does not specify the same union recommendation; that does not mean communities must be stripped. Other aggregation rules and policies still apply.
Fictional routes and private AS numbers. These are bounded teaching examples, not a complete BGP implementation. Display a tag as AS:local only to help read its two 16-bit parts; the wire contains four octets.
Read the RFC section ↗