Stitching slivers with Utah InstaGENI end point requires that capacity must be specified for link

[lnevers@bbn.com]

In stitching scenarios where Utah InstaGENI is the endpoint, requesting a sliver to any other remote (ex GPO IG, KY PG, etc) will result in the following create sliver failure:

 *** ERROR: vtopgen: Cannot mix trivial_ok|emulated with * bw 

This is due to not specifying capacity in the link properties when the endpoint in the stitched sliver is at InstaGENI Utah (not an issue when the endpoints are at PG Utah). This issue was reported via email and remains unresolved, so it is now being tracked.

On 5/31/13 1:00 PM, Jonathon Duerig wrote:

This seems nontrivial to me. I've cc'ed geni-dev-utah 
to see if others have input.

The problem here is transit stitching. One endpoint 
is at IG Utah, the other is at another rack and 
Utah PG sits in the middle.

If there is no specified bandwidth for the piece 
that flows across Utah PG, it doesn't seem like 
we can have a reasonable default. The enforcement 
of bandwidth limitations is at the endpoints so 
they are the ones who determine what the bandwidth is.

So we are left with either the user explicitly 
specifying bandwidth so we have some confidence 
that the endpoints are shaping it according to 
that bandwidth, or we need a behind the scenes 
agreement on defaults which seems tricky to do.

Or am I missing something? 

On 5/31/13 2:53 PM, Robert Ricci wrote:

This is probably where the mismatch lies; 
we make the assumption that limits are enforced 
by the endpoints, whereas other circuit 
services (ION comes to mind) enforce bandwidth 
limits themselves, within the network.