You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 26, 2022. It is now read-only.
See the attached picture for diagrams. We would like the topology embedding algorithm to extend to the following cases:
connecting a broadcast link in one rack to a broadcast link in another. Right now this can be emulated by using node groups, but a more general solution would allow for heterogeneous nodes to be attached to a bcast link, then linked to another one in another rack.
2.Dealing with two stitchoports in a request that come from the same stitchport URL, but different vlan tags. This likely requires introducing a virtual port in the request (so it propagates into the manifest).
Being able to attach stitchport(s) to a bcast link. Probably similar to 1 and 2 above.
Being able to not specify the VLAN tag on a stichport, instead having Net AM return the selected tag out of the available range. This supports GENI stitching (tag 'any' in RSpec).
Be able to attach storage to broadcast links.
For shared storage, do not create extra interfaces (and assigned extra IP addresses) to a node that attaches to multiple ISCSI volumes from the same site.
The text was updated successfully, but these errors were encountered:
Item 1 resolved as abstracted embedding where the user specifies what needs to be connected, not how. This is done through 'generalized nodegroups' concept where each node can be treated as a node group attached to a broadcast link. The embedding takes care of figuring out when to use point-to-point vs. multipoint connections
Item 2 above has been confirmed to work for GENI stitching. Introduced virtual stitchports to support this.
Here is a corner case that probably should work somehow, or at least generate an error eg_renci_pub.txt. In it there is a slice with two VMs in one rack that are connected to a shared VLAN (907 at RCI in this case) in that rack and both have links to a VM in another site (BBN). The resulting slice ignores the static VLAN and does not generate an error.
Either we don't handle it, or we handle it (by, perhaps requiring that there is inDomain statement in the shared VLAN to make embedder's job easier) or by inferring that if all VMs connected to a link have the same domain and a specific tag is being asked for, it MUST be the shared tag. Or something else. Anyway, interesting case.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
See the attached picture for diagrams. We would like the topology embedding algorithm to extend to the following cases:
2.Dealing with two stitchoports in a request that come from the same stitchport URL, but different vlan tags. This likely requires introducing a virtual port in the request (so it propagates into the manifest).
The text was updated successfully, but these errors were encountered: