Routing instability can result in poor end-to-end network per- formance and degrade the overall efficiency of the Internet in- frastructure. In this section, we present some guidelines for net- work operators to avoid the routing instability caused by dis- tributed prepending actions. In these guideline, we assume that all ASes are deploying the popular routing policy, i.e., selective announcement and typical local preference.
Guideline 1 If only stub ASes are performing prepending on
their local provider links, these prepending actions will not result in routing instability.
This has been stated as Observation 5. Note that this guide- line does not allow transit ASes to perform any prepending, hence it is quite restrictive. A less restrictive guideline is as follows:
Guideline 2 If no AS performs prepending except on the routes
originated by itself, these prepending actions will not result in routing instability.
Proof: In order to prove this guideline, we want to put all
CHAPTER 3. INTERDOMAIN TRAFFIC ENGINEERING 72
“levels”. Let V0 be the lowest level such that it contains all stub
ASes only. Let V1, V2. . . be the successively higher levels. An
AS v belongs to Vi if all its customers come from levels Vj, where
j < i.
Under Guideline 2, prepending actions of an AS can only af- fect traffic destined to itself. This traffic will not traverse any inbound provider links of a lower or same level AS because all AS paths should be “valley free” based on the selective announce-
ment export policy. Therefore, any prepending by an AS will
not affect the prepending decision of another AS at the same level or a lower level, even under load-dependent AS prepending scenario. Let us call this property 1.
Now we can prove the convergence by induction. Suppose at some time ti, all ASes in levels from 0 to i have completed their
prependings and will not do any more prepending. Therefore, ASes in level (i + 1) will do their prependings without being affected by any prepending actions from these lower level ASes. Based on property 1, we know prepending actions from ASes at the same or higher level cannot affect the prepending decisions of ASes in this level i + 1 either. So there must exist some time
ti+1 so that all ASes in levels from 0 to i + 1 will have completed
their prependings and will not change any more.
Again from property 1, we know ASes in level 0 cannot be affected by any prepending actions of ASes from the same or higher level. Therefore, there must exist a time t0 that they
complete their prepending without further change. Since there are finite number of levels in the Internet, the whole process must converge. This completes our proof by induction.
Basically, we propose that ASes should not do prepending on the transit traffic. In practice, transit ASes may lose business (i.e. transit traffic) due to their prepending actions. Since they would like to induce more transit traffic to make more money,
ASPP is not a suitable approach for them to do traffic engi- neering to some extent. However, the measurement study in [18] shows many transit ASes are performing ASPP, hence we present the following relaxed guideline:
Guideline 3 If every prefix in the network has only one owner,
and only the owner can do prepending on routes to the prefix, the distributed prepending actions will not result in routing in- stability.
We suggest that one AS must announce its ownership of the prefix before it uses the traffic to this prefix for traffic engineer- ing, and the AS can announce its ownership only when the prefix does not have an owner. In this way, only one AS may prepend this route. Therefore, we can follow the proof of guideline 2 and prove this new relaxed guideline. Under this guideline, ASes can do prepending on their transit traffic if downstream ASes do not announce ownership for the prefixes. Clearly, ASes near the origin AS should have a higher priority than ASes far away from the origin AS to be the owner of the prefix, since provider ISPs should respect their customer ISPs.
Here, we assume transit ASes are able to do prefix-based prepending, while the first two guidelines focus on AS-based prepending and destination-based prepending. Our measure- ment study in [18] shows more than 65% multihomed tran- sit ASes are deploying prefix-based prepending currently. This makes the third guideline feasible in the Internet.
In order to implement this guideline, we can define some special “community” attribute values for global coordination in ASPP practice. An AS needs to signal its use of certain prefixes for traffic engineering by associating them with the designated community attribute value. This then prevents other ASes from using the same prefix for traffic engineering. However, the global distribution and synchronization of those community attribute
CHAPTER 3. INTERDOMAIN TRAFFIC ENGINEERING 74
are still problems.