This PR implemented the EP-23-2 blueprint CSPF filtering capabilities. On this PR I continued the work that Marvin, David and Arturo contributed on this previous PR.
I've also explored this version on mininet with mef_eline and worked as intended since no breaking changes were expected, considering how mef_eline is currently interfacing with pathfinder, and also since it's using at most 2 paths, which was the spf_max_paths default value for now to avoid leaving too much room for high CPU usage when the graph is larger in terms of edges and nodes (which will probably be the case in production). @jab1982 @dgarc330 I think it would be neat to augment some end to end tests to indirectly test that with mef eline, and plan for it, we've got several unit and integration tests, but having the end-to-end would also be great and less biased since even though most of the tests were contributed by the previous authors, I unified some of them.
Perf
When I was exploring some larger topologies in the integration tests, I noticed in some cases, it was noticeable hanging so I decided to benchmark and the function we used to use, as it was being invoked, was exhaustively computing all the best paths, test_n_shortest_simple_paths below, and now we have the k paths being computed lazily, represented by the test_k*_shortest_simple_paths test functions, and these ones are optimal based on the k input:
I used the exact same components and layout, I'm not a front-end specialist, but one of the things we could improve in terms of UX would be to more easily to click on desired/undesired links, it's usable as it is, but maybe something to align and prioritize later on.
Open API spec preview
@ajoaoff here's the openapi spec preview, it's still backwards compatible from mef_eline's perspective, if you need help integrating this let me know. thanks.
Summary
CHANGELOG.rst
below or on this link that summarizes the changes and additions on this PR.I've also explored this version on
mininet
withmef_eline
and worked as intended since no breaking changes were expected, considering howmef_eline
is currently interfacing withpathfinder
, and also since it's using at most 2 paths, which was thespf_max_paths
default value for now to avoid leaving too much room for high CPU usage when the graph is larger in terms of edges and nodes (which will probably be the case in production). @jab1982 @dgarc330 I think it would be neat to augment some end to end tests to indirectly test that with mef eline, and plan for it, we've got several unit and integration tests, but having the end-to-end would also be great and less biased since even though most of the tests were contributed by the previous authors, I unified some of them.Perf
When I was exploring some larger topologies in the integration tests, I noticed in some cases, it was noticeable hanging so I decided to benchmark and the function we used to use, as it was being invoked, was exhaustively computing all the best paths,
test_n_shortest_simple_paths
below, and now we have the k paths being computed lazily, represented by thetest_k*_shortest_simple_paths
test functions, and these ones are optimal based on the k input:UI
I used the exact same components and layout, I'm not a front-end specialist, but one of the things we could improve in terms of UX would be to more easily to click on desired/undesired links, it's usable as it is, but maybe something to align and prioritize later on.
Open API spec preview
@ajoaoff here's the openapi spec preview, it's still backwards compatible from
mef_eline
's perspective, if you need help integrating this let me know. thanks.