The next attribute we will look at is the BGP community. BGP communities are described in RFC 1997. The communities are a transitive attribute and they're optional. So you don't have to set them and indeed several operators make no use of BGP communities whatsoever. But in fact BGP communities, of all the attributes, is probably one of the most useful and most powerful attributes when it comes to implementing BGP policies on the internet today. And we will be looking at communities in much more depth later on in this series. BGP community is a 32-bit attribute. But is commonly represented today on the internet as two 16-bit integers. There was a supporting RFC, RFC1998 which was written by a network operator describing how they used the early BGP community when it first appeared in router implementations and they represented it as two 16-bit integers really because two 16-bit integers were easier for us humans to understand than one long 32-bit integer was. So the common format used is, inserting your local AS number then a colon and then another 16-bit integer which is used to represent your local policy. It's not a standard format but it's the commonly used convention today as we'll see. There are a range of reserved communities in traditional IETF fashion, the first 65,000 and the last 65,000 are reserved. Now communities are used to group destinations and each destination can be a member of multiple communities. The destinations are defined by the network operator. There are no standard defined destinations, as such it's entirely up to the network operator what these destinations are. And as I hinted at, these are really useful for applying policies within and between autonomous systems. Let's have a look at an example just to show how they work. So in the days before BGP communities, a network operator would be connecting BGP customers or even normal standard statically connected customers. Every time they'd connect a customer, they would have to set up a BGP filter, to allow that BGP announcement into the network. We've got AS 300 here in the diagram, customer AS 100 announcing a prefix, so we set up an incoming filter to allow 160.10.0.0/16 inbound. That's all fine. But we want to give AS 100 transit to our upstream provider in AS 400. So we have to update the filter in our border router, router E, to allow 160.10.0.0/16 out. That's fine as well. Certainly in the early Internet days, in the 90s, we had very few BGP features to let us do this without actually doing it in a maintenance period. Nowadays it's much easier. And indeed when BGP communities arrived it made it much easier as well. In the early days, before communities, we would have to shut down BGP on router E, the border router, and then bring it back up again. And that of course is disruptive, in the early internet days it was less of an issue as the internet was not mission critical for many organizations and end users. Nowadays it's unimaginable to shut down any connection just to update a configuration. So imagine what happens when a second customer comes along, 170.10.0.0/16, we have to update our incoming filter to allow that prefix in and update our outbound filter to let that prefix out. Which usually would mean another shutdown BGP, bring it up again and all the disruption that that caused. And it's also the management of BGP filters, I've only shown one border router to one upstream. What if you had more upstreams? What about if you had peers? What filters would we have to update to manage all this? And for a sizable network this became really complicated to manage. Every time you add a customer you have to make sure you update border filters everywhere across the network or at least in the places across the network you wanted to allow this new prefix to have access to. So we ended up with a management and manageability problem, never mind a scaling problem. So when BGP communities came along, can you imagine how this all changed? If we look at the diagram again now with communities in place, prefix comes in from AS 100 on to router C. Sure we still have our inbound prefix filter, but now what we do, we also tag the prefix with a community and I've chosen 300:1. 300 is our AS number and 1 means, transit customer perhaps. We go to router E and all we do now is, we set up a filter that says: "Let any member of community 300:1 out." So we don't look at the prefixes anymore we just say: "Is the prefix a member of community 300:1? If so, let it out." So when a new customer comes along, we just drop them into community 300:1 and they automatically get announced out to the internet without any recycling of the BGP session. And now we can set up all the configuration on all the border routers, whether with our peers or with our transits, to do the filtering based entirely on communities. In fact, throughout my career with helping network operators almost the first thing I've done, is done a good analysis of all the filters and all the border routers whether to upstreams and to peers, and we've replaced the static prefix filters with BGP communities, because this makes the network much easier to manage and much much more scalable. And of course, usually when operators have discovered the power of communities, they all implement big projects to migrate away from static outbound prefix lists to using bgp communities instead as they discover the great flexibility and scalability that they offer.