Re: NCC#2006021124 [RIS Lease-A-Beacon Request]
RIS Beacon Request User wrote:
We are studying properties of AS Path Prepending which is a popular inbound traffic engineering method. We propose an active measurement method to measure the impact of ASPP method under different prepending lengths and strategies. [...] pattern : We would like prefix to have the following A/W pattern: Set1 (prepending on the link to AS20483) Day1 A: 00:00 : prepending length =0 W: 02:00 A: 04:00 : prepending length=1 W: 06:00 A: 08:00 : prepending length=2 W: 10:00 [...]
Dear Samantha, apologies for the delay in replying, we have been busy with other cases. We are discussing this internally and should be able to give you an answer early next week. Regards, Lorenzo -- Lorenzo Colitti lorenzo@ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net
Dear Lorenzo, Thank you for your kind consideration. We are looking forward to your favorable reply. Best regards, Samantha Lorenzo Colitti said the following on 3/9/2006 10:50 PM:
RIS Beacon Request User wrote:
We are studying properties of AS Path Prepending which is a popular inbound traffic engineering method. We propose an active measurement method to measure the impact of ASPP method under different prepending lengths and strategies. [...] pattern : We would like prefix to have the following A/W pattern: Set1 (prepending on the link to AS20483) Day1 A: 00:00 : prepending length =0 W: 02:00 A: 04:00 : prepending length=1 W: 06:00 A: 08:00 : prepending length=2 W: 10:00 [...]
Dear Samantha,
apologies for the delay in replying, we have been busy with other cases. We are discussing this internally and should be able to give you an answer early next week.
Regards, Lorenzo
Samantha Lo wrote:
Dear Lorenzo,
Thank you for your kind consideration. We are looking forward to your favorable reply.
Hi Samantha, we have looked into this and we have determined that we do not have the resources to do what you have requested. However, we would like to suggest an alternative. We can set up an IBGP peering session between a BGP speaker of your choice and one of our RRCs (RRC07). You would thus be inside AS12654. You could then announce the two prefixes 84.205.73.0/24 and 84.205.89.0/24, which are RIS beacons, with AS-paths of the form "12654 <AS path of your choice> i". These paths will be announced to the transit peers of RRC07. Note that if you use your own AS in the AS-path, it might get filtered out since our peers might filter on origin AS. However, you could prepend AS 12654 multiple times. If you do not have software to generate IBGP announcements, you can use the "announcer" tool [1] to do this. I wrote this tool and have used it successfully for other research work [2]. Combined with a cron script, it should be sufficient for your needs. (If it's not, let me know what it's missing!). If you think this would be useful to you, please provide us with a few lines describing your experiment and what kind of paths you will announce so that we can inform our upstream peers. If our peers agree, we can then discuss the dates on which we will set up the peering and on which you will perform your experiments. Regards, Lorenzo [1] http://www.dia.uniroma3.it/~compunet/bgp-probing/announcer/ [2] Colitti et al., "Investigating prefix propagation through active BGP probing", to appear in Proceedings of IEEE ISCC 2006. -- Lorenzo Colitti lorenzo@ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net
Hi Lorenzo, 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)? 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. 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. Best regards, Samantha Lorenzo Colitti said the following on 3/13/2006 11:19 PM:
Samantha Lo wrote:
Dear Lorenzo,
Thank you for your kind consideration. We are looking forward to your favorable reply.
Hi Samantha,
we have looked into this and we have determined that we do not have the resources to do what you have requested. However, we would like to suggest an alternative.
We can set up an IBGP peering session between a BGP speaker of your choice and one of our RRCs (RRC07). You would thus be inside AS12654. You could then announce the two prefixes 84.205.73.0/24 and 84.205.89.0/24, which are RIS beacons, with AS-paths of the form "12654 <AS path of your choice> i". These paths will be announced to the transit peers of RRC07.
Note that if you use your own AS in the AS-path, it might get filtered out since our peers might filter on origin AS. However, you could prepend AS 12654 multiple times.
If you do not have software to generate IBGP announcements, you can use the "announcer" tool [1] to do this. I wrote this tool and have used it successfully for other research work [2]. Combined with a cron script, it should be sufficient for your needs. (If it's not, let me know what it's missing!).
If you think this would be useful to you, please provide us with a few lines describing your experiment and what kind of paths you will announce so that we can inform our upstream peers. If our peers agree, we can then discuss the dates on which we will set up the peering and on which you will perform your experiments.
Regards, Lorenzo
[1] http://www.dia.uniroma3.it/~compunet/bgp-probing/announcer/ [2] Colitti et al., "Investigating prefix propagation through active BGP probing", to appear in Proceedings of IEEE ISCC 2006.
(Internal reply)
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.
Sounds like a good idea, but I like to see the paper before it is submitted. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400. Watch this space...
Hi Lorenzo, 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)? 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. 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. Best regards, Samantha http://www.comp.polyu.edu.hk/~cssmlo/ cssmlo@comp.polyu.edu.hk Phone: +852-27764901 Fax: +852-27740842 Lorenzo Colitti said the following on 3/13/2006 11:19 PM:
Samantha Lo wrote:
Dear Lorenzo,
Thank you for your kind consideration. We are looking forward to your favorable reply.
Hi Samantha,
we have looked into this and we have determined that we do not have the resources to do what you have requested. However, we would like to suggest an alternative.
We can set up an IBGP peering session between a BGP speaker of your choice and one of our RRCs (RRC07). You would thus be inside AS12654. You could then announce the two prefixes 84.205.73.0/24 and 84.205.89.0/24, which are RIS beacons, with AS-paths of the form "12654 <AS path of your choice> i". These paths will be announced to the transit peers of RRC07.
Note that if you use your own AS in the AS-path, it might get filtered out since our peers might filter on origin AS. However, you could prepend AS 12654 multiple times.
If you do not have software to generate IBGP announcements, you can use the "announcer" tool [1] to do this. I wrote this tool and have used it successfully for other research work [2]. Combined with a cron script, it should be sufficient for your needs. (If it's not, let me know what it's missing!).
If you think this would be useful to you, please provide us with a few lines describing your experiment and what kind of paths you will announce so that we can inform our upstream peers. If our peers agree, we can then discuss the dates on which we will set up the peering and on which you will perform your experiments.
Regards, Lorenzo
[1] http://www.dia.uniroma3.it/~compunet/bgp-probing/announcer/ [2] Colitti et al., "Investigating prefix propagation through active BGP probing", to appear in Proceedings of IEEE ISCC 2006.
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?
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?
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...) Regards, Lorenzo -- Lorenzo Colitti lorenzo@ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net
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
Samantha Lo wrote:
What would you suggest?
I suggest that we can have multiple RRCs with different upstream providers (better no overlaps).
This is possible: we can set up multiple IBGP peerings to multiple RRCs and have those RRCs provide transit. For determining which RRCs are best to use in order not to have overlap between upstreams, perhaps you could use the RIS looking glass to see who provides transit for the beacon prefix of each RRC. That gives you an easy way to check who provides transit for each RRC and thus who would provide transit for your prefix if you were to announce it from that RRC. A list of the beacon prefixes announced by each RRC is here: http://www.ripe.net/projects/ris/docs/beaconlist.html Here you can also see where each RRC is located.
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.)
As far as I know, when we request transit for a beacon prefix, the agreement is "treat this prefix exactly as though we were a stub customer of yours". The routing policies of our upstreams are another matter, but perhaps once you know better which RRCs and thus which upstreams you will be using you can look up this information in the RIPE routing database (Or perhaps we can try to confirm this with them directly. Note, however, that this is likely proprietary information that cannot be published.)
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?
Once we know more about the setup you want to use, e.g. which RRCs you want to use, which prefixes you want to announce and where, I can configure IBGP sessions between an IP address you give me and the RRCs and give you the info you need to set up the peering on your side. Depending on the RRC, we might need to do other things like open the firewall. Cheers, Lorenzo -- Lorenzo Colitti lorenzo@ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net
Lorenzo Colitti said the following on 3/22/2006 6:01 PM:
Samantha Lo wrote:
What would you suggest?
I suggest that we can have multiple RRCs with different upstream providers (better no overlaps).
This is possible: we can set up multiple IBGP peerings to multiple RRCs and have those RRCs provide transit.
For determining which RRCs are best to use in order not to have overlap between upstreams, perhaps you could use the RIS looking glass to see who provides transit for the beacon prefix of each RRC. That gives you an easy way to check who provides transit for each RRC and thus who would provide transit for your prefix if you were to announce it from that RRC.
A list of the beacon prefixes announced by each RRC is here:
http://www.ripe.net/projects/ris/docs/beaconlist.html
Here you can also see where each RRC is located.
I am looking into them now. Let me get back to you in these two days. I think I need to look into those providers' policies in RIPE and determine which RRCs we would use. But I find that many of them have overlaps. I
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.)
As far as I know, when we request transit for a beacon prefix, the agreement is "treat this prefix exactly as though we were a stub customer of yours". The routing policies of our upstreams are another matter, but perhaps once you know better which RRCs and thus which upstreams you will be using you can look up this information in the RIPE routing database (Or perhaps we can try to confirm this with them directly. Note, however, that this is likely proprietary information that cannot be published.)
I understand that. Our previous measurement which submitted to IMC has this problem also. We cannot disclose the information of the AS.
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?
Once we know more about the setup you want to use, e.g. which RRCs you want to use, which prefixes you want to announce and where, I can configure IBGP sessions between an IP address you give me and the RRCs and give you the info you need to set up the peering on your side. Depending on the RRC, we might need to do other things like open the firewall.
I see. Thank you very much!
Cheers, Lorenzo
Best regards, Samantha Lo http://www.comp.polyu.edu.hk/~cssmlo/ cssmlo@comp.polyu.edu.hk Phone: +852-27764901 Fax: +852-27740842
participants (3)
-
Henk Uijterwaal -
Lorenzo Colitti -
Samantha Lo