-
Notifications
You must be signed in to change notification settings - Fork 79
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
Support Intra-Domain Topology for ASes #177
Comments
Thanks a lot for the suggestion. This feature is something that I really want to pursue. Right now I don't have man power to look into this. Hopefully this will change starting this Fall, so we can follow up on this, as well as on the other good suggestions that you made. Thanks. |
@kevin-w-du could you please at least briefly confirm my observation that two concurrent routing-daemons (FRR & BIRD ) operating next to each other on the same node, just because a particular feature can't be realised with BIRD alone, is a bit of a smell. With your reassurance I could start working out a solution. My proposed approach would be a RoutingProvider strategy-object responsible for SetUp and configuration of routers. As of now, for a layer that is about to be rendered , there is no means to detect, if a given desired protocol X is within the capabilities of the routing software , already installed on the router node so far.1 Eventually the layer will detect, that another one is needed. But anyway it can't be the responsibility of the layer to set up the routing software2, required for its operation, on the router node itself. Rather it should merely have to delegate to the Provider to "please install yourself on this node". 3 My point is that unless this relation of layers , their utilised protocols and the requirements they put on the enabling/implementing software, is formalised and captured in an interface, many layers will end up as a hack. Footnotes |
@magicnat Can you respond to this? You are more knowledgeable on this part. Thanks. |
Thank you very much for the comment and the suggestion. I like the idea of We initially went with BIRD as the goal was only to emulate BGP IPv4 unicast routing. We also wanted the students to get some idea on how to configure BGP (e.g., peering, filtering, doing hijacks, etc.) as part of a lab. I used BIRD as I found that the declarative style of its config is easier to work with and to explain (vs. the more "procedural" style of the FRR/Cisco-like config). MPLS at the time was more of a proof-of-concept (and EVPN support is incomplete) so I just "hacked" FRR on top of that to provide LDP support. For brnode/rnode mentioned in #20, I'm unsure if this can be easily added without needing to fix all the current |
@magicnat @kevin-w-du Could you please review #181 (comment) |
@magicnat I've had a few thoughts about how to implement different routing daemons. Could you please have a look at it and give your opinion if its feasible or desirable at all ...
|
Hi @amdfxlucas - thank you so much for all the contributions. I really appreciate the help. However I just recently moved to a new country and started a new job - and I am still sorting out all the logistics. I will take a closer look once I am more settled down. |
@kevin-w-du
realistic network simulations require a realistic topology, so most simulators allow to read it from file.
There are various formats output by different topology generators i.e. :
Here is an attempt to support this with SEED as well.
The text was updated successfully, but these errors were encountered: