Opened 10 years ago

Last modified 10 years ago

#1039 new

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

Reported by: Owned by:
Priority: major Milestone:
Component: STITCHING Version: SPIRAL5
Keywords: Network Stitching Cc:, Aaron Helsinger


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.

Change History (3)

comment:1 Changed 10 years ago by

Keywords: Network Stitching added

comment:2 Changed 10 years ago by Aaron Helsinger

Cc: Aaron Helsinger added

comment:3 Changed 10 years ago by Aaron Helsinger

Owner: changed from somebody to
Note: See TracTickets for help on using tickets.