Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adapting the MED to use geographical positions #1

Open
gregbo opened this issue Feb 2, 2021 · 1 comment
Open

adapting the MED to use geographical positions #1

gregbo opened this issue Feb 2, 2021 · 1 comment

Comments

@gregbo
Copy link

gregbo commented Feb 2, 2021

I noticed in set_med_coord.c, euclidean_distance() makes the following call:

ebpf_sqrt((a * a) + (b * b), 6)

whereas in compare_med.c, the difference of the squares of a and b is used. The former looks correct to me, but not the latter, based on my understanding of Euclidean distance.

Also, from reading the documentation in libxbgp/docs/source/rfc_implementing.rst, it seems you are using the latitude and longitude of the routers in question. I think computing the spherical distance, instead of Euclidean distance, would yield more accurate results.

As an aside, I have concerns about using geographical data in general for making network management decisions. At the very least, I hope you will add some text to the documentation advising users of this feature of the risks involved.

@twirtgen
Copy link
Collaborator

twirtgen commented Feb 3, 2021

Hi @gregbo,

Thank you for reporting this.

Actually, the MED use case is really too simple and only shows an example of plugin that involves a pretty large number of insertion points. First you need to add a new attribute to any BGP Update message, then you have to make the serialization and the decoding step and eventually alter the BGP decision process to reflect the new meaning of the MED value.

libxbgp is modular and we could imagine to completely revise this use case to lower the risk of using geographical distance to make routing decisions. Also, we can write a new plugglet which will compute the spherical distance. In this way, the user can be convinced that both methods (spherical/euclidean) are fully valid in xBGP and that the MED can reflect any value it computes.

To date, I am aware that the documentation is really poor, un-maintained and contains many errors. Furthermore, I completely refactored libxbgp and a lot of sections are now obsolete or need strong improvements.

I plan to revise the documentation soon to allow people to easily use the different parts of xBGP. I will also put a small explanation of each plugin/use case to better highlight their purpose and why we are implementing such a plugin.
Also, I will warn users if some plugins are risky for BGP (convergence, security, etc.) as you suggested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants