Flexibility and Expandability of BGP
BGP was designed to be flexible so that it can accommodate the dynamic changes of the Internet. Indeed, new attributes were introduced into BGP and found their way into the deployment. For example, the BGP community attribute was introduced in RFC 1997, and is widely used in the Internet today.
Given the importance of BGP for the Internet, and its complexity to implement and operate, it would be a good idea to keep the focus of BGP on inter-domain routing and resist the temptation to overload BGP with functions not related to inter-domain routing. The reasons are twofold:
Unrelated functions will unnecessarily increase the complexity of BGP.
Using BGP will unnecessarily increase the complexity of other functions.
A primary example of such "unnecessary" overloading of BGP is its application on virtual private networks (VPN). Many proposals exist in the IETF approaches for using BGP to support Multiple Protocol Label Switching (MPLS)based VPNs. Several examples are listed below:
Use BGP to distribute VPN routes.
Use BGP to carry MPLS label information.
Use BGP for VPN membership auto-discovery.
Use BGP to carry Layer 2 VPN information, such as VLAN tag.
Needless to say, these proposed new applications of BGP required the introduction of new attributes into the BGP protocol. RFC 2547 defines a new address family VPN-IPv4 for the purpose of distributing VPN-specific IPv4 routes between BGP peers, and a new "route target" attribute is used to determine whether a particular VPN routes should be installed on the router. Policy filters must be put in place to make sure that routes of different VPNs are not installed on the same virtual routing function.