A.1) BGP practical notions within an ISP
As a reminder, the following points are essential, and need to be taken into consideration strongly, even for the most basic design of a network running BGP within an ISP. These notions are useful when traffic engineering using BGP is implemented.
1. When a customer advertises its prefixes to an ISP:
a. The customer will allow IP-packets flows from the ISP (or the Internet) to its networks. We can say that the customer downloads IP-packets from the ISP (and reciprocally we can say that the ISP uploads IP-packets to the customer).
b. By advertising its prefixes, a customer controls its inbound/ingress/download IP-packets traffic.
2. When a customer receives routes from its ISP:
a. The customer will be able to send IP-packets from its network to the ISP (and so the Internet). So the customer uploads IP-packets to the ISP (and reciprocally it is the same as the ISP downloads IP-packets from the customer).
b. By receiving prefixes or routes, a customer controls its outbound/egress/upload IP-packets traffic.
3. Let’s simply memorize that routes announcements allow IP-packets stream/flow from networks in the opposite way:
a. advertising routes means receiving/download IP-packets,
b. receiving prefixes or routes allows sending/upload IP-packets.
4. To influence upload-paths for Internet routes, the BGP local-preference attribute will be manipulated at the gateway router of the given traffic class. A higher local-preference is preferred. The default value local-preference being 100, the local-preference of routes coming in from the less preferred neighbors will be set to less than 100(e.g. 90).
5. Policy Based routing could be also used to influence upload/outbound traffic. “IP next-hop” instructions could be required to set more granular traffic engineering when it is required.
6. To influence the download path for Internet routes, the BGP as-path attribute can be manipulated at the gateway of the traffic class of interest.A shorted as-path is preferred over longer ones. As-prepend operations could come handy for that. As such, ISP-A’s as-number shall be prepended for updates of the given class to all neighbors apart from the one through which traffic download is preferred.
7. BGP Communities can also be used to influence return traffic flow. Particularly, some ISPs allow the customer to set the local-preference of their announced networks within the ISP’s as-number, this through the use of communities. Thus, the customer can manipulate how the ISP uploads packets to the customer’s networks, and so influences its ingress traffic.
8. BGP communities are not only limited to influence ingress traffic for a customer. According to each ISP, many other operations could be done. It is advised for a customer to ask always the communities’ specs to its ISP.
9. As there are numerous scenarios when configuring traffic engineering, an attempt at considering all possible of occurrences would not be practical (e.g. what would happen to class-B traffic if RT-B or any upstream link was to fail). We recommend that all fallback options to be looked into on a case-by-case basis once an event has occurred.
10. Bad manipulation of controlling ingress traffic can provoke a loss of revenue additionally. If traffic destined to a particular customer is coming not through the correct link, but another one, additional bandwidth is used and by so fees, making the other link unused to its role of providing the customer. For more information, please check paragraph A.2.c).