Hi Lorenzo, Lorenzo Colitti said the following on 3/17/2006 7:35 PM:
Samantha Lo wrote:
Thank you so much for your prompt reply and the suggested setup. I think the setup should be adequate for our experiments, except that for a given prefix we generally need to advertise the prepended routes to some (e.g., 1) upstream ASs and unprepended routes to others. Can the setup that you suggested enable us to do that (through an access list, or different peer sessions, or community but which is not supported by the announcer you provided, or peer to more than one RRC)?
Unfortunately, it seems to me that this cannot be done as I suggested. The announcer is flexible enough to announce different AS-paths for different peers. However, since these routes will be announced to the same RRC, it doesn't matter what you announce, because the RRC will perform route selection and only announce one AS-path to all its upstreams.
I have been trying to think of a solution that does not require modifying the RRC's configuration in a non-trivial way, but the only thing that comes to mind is that you do the different prepending with two different prefixes, which is not particularly realistic.
We could of course set up multiple IBGP peerings between you and multiple RRCs, but the problem with that are that the RRCs are in different locations and have different transit providers. I don't know if this is adequate for your experiments.
What would you suggest?
I suggest that we can have multiple RRCs with different upstream providers (better no overlaps). I think the location would not be a problem in our measurement. We can further investigate the response of the upstreams to the prepending in different situations, e.g. locations (but I don't think location would have any effect to the response. Instead, the policies of the upstreams would be affected. That's why I would like to know the policies of your upstreams.)
In the meantime, we will set up a BGP speaker here with the announcer. But if the announcer is not adequate for announcing prefixes with different prepending lengths to different upstream ASs, we may need to use some software routers.
Unfortunately, the announcer is not the problem here because it doesn't peer directly with our upstreams but would go through the RRC, which performs route selection. What did you have in mind? So, your announcer would be perfectly fit in our measurement. But I am still not very sure how to set up an iBGP section from my university network to the RRCs.Would you give me more details?
We are planning to submit a paper to the IMC conf, and the deadline is late May. If you are interested, you are welcome to join our work.
I would definitely be interested to know what you have in mind. I have read the two-page abstract, but I don't really understand, for example, how this is different from the work you presented at NOMS 2004? (I was in the same session, presenting IPv6-in-IPv4 tunnel discovery...)
The paper presented in NOMS 2004 is my supervisor's work. It is another approach compared with this one but the objectives are quite similar. The one presented in NOMS 2004 is in an "Black box" approach. It only gets back the ping responses from the top senders (from the netflow data) but doesn't check out the AS Paths after performed prepending. As a result, we can only observe the change of the inbound traffic (ping responses changed from one link to another) but cannot understand why the traffic has been changed. My approach is "open the black box" to check the AS paths from the looking glasses and route servers. So, after the prepending, we get the AS Paths and check that whether the best paths have been changed. In fact, we have performed this in my 2-page abstract and observed some phenomenon, e.g. prepending invariant sub-paths, and how the best paths are propagated. We want to further investigate them in other ASes to see if the responses are similar such that we may predict the result of AS path prepending. i.e. How long the prepending length should be in order to shift an amount of traffic? Also, if it is possible, we can check out the performance of the the new path after performed prepending, e.g. available BW. I have already prepared a script (written by perl) to get the AS paths from about 100 looking glasses automatically. I am looking into the updates in routeviews of the archives that we performed the measurement and find out some patterns after I performed the prepending. But because we only used one prefix in the previous measurement, we cannot conclude that some of the events may be caused by prepending only.
Regards, Lorenzo
What do you think? I may not explain very clearly here but I can further provide you details. We can further discuss it. I am looking forward to your favorable reply. Best regards, Samantha http://www.comp.polyu.edu.hk/~cssmlo/ cssmlo@comp.polyu.edu.hk Phone: +852-27764901 Fax: +852-27740842