We are a group of networking researchers from UFRGS, UCLouvain and KAUST.
We are working towards an approach to make interconnection agreements
between networks more dynamic. The current approach for establishing
agreements is cumbersome, typically requiring lengthy discussions. To
accommodate the expected growth of traffic demands, network operators need
to over-provision. Even so, operators miss the ability to quickly respond
when facing unforeseen traffic demands, because agreements have static
characteristics and changes could take days or weeks to be implemented.
Dynamic agreements offer many opportunities. For example, consider
acquiring extra "bandwidth as a service" that is available on demand just
when one needs it, similarly to how one might spin up extra VMs in the
cloud to handle high loads.
We are interested in collecting some anecdotal evidence that dynamic
agreements could solve real-world problems. Has any member of the forum
faced any scenario where the kind of dynamism described above could be
helpful?
Of the total analyzed agreements, 1,347 (0.07%) were formalized in
written contracts. This is down from 0.49% in 2011. The remaining
1,934,166 (99.93%) were “handshake” agreements in which the parties
agreed to informal or commonly understood terms without creating a
written document.
This sounds something like the MEF Third Network type stuff.... I mean the ability to setup connection dynamically across network boundaries on-the-fly, via an ordering system... that has always sounded awesome to me... and I've wondered how we could actually get there one day. Sounds like a lot of initial cooperation
In computer science, all problems can be solved by adding a level of indirection.
You've now changed it from lengthy discussion about the connection, to lengthy
discussion about which dynamic agreements both sides are willing to support.
Hint: You can't discuss "bandwidth as a service" without both sides talking
about how much burst capacity might be needed, because the capacity would *still*
require over-provisioning in order to be available if needed. If both ends
of the link have 1G optics, you're not going to burst to 10G no matter how
many dynamic agreements you have.
This sounds something like the MEF Third Network type stuff.... I mean
the ability to setup connection dynamically across network boundaries
on-the-fly, via an ordering system... that has always sounded awesome
to me... and I've wondered how we could actually get there one day.
to me, this was the dream of optical switching and gmpls (which is not
mpls)
> This sounds something like the MEF Third Network type stuff.... I mean
> the ability to setup connection dynamically across network boundaries
> on-the-fly, via an ordering system... that has always sounded awesome
> to me... and I've wondered how we could actually get there one day.
to me, this was the dream of optical switching and gmpls (which is not
mpls)
And, pray tell, what is the use of me setting up "peering" between myself and a network on the other side of the world when the data still has to flow over the same connections, merely encapsulated inside a tunnel? Reminds me of the old days when you could directly connect "Chicago" to "Denver" using a direct connection over a PVC that was routed Chicago -> New York -> Miami -> Los Angeles -> Denver. Sure, it looks like a direct connection, but ...
Or will this magical interface also deploy robots to build the physical layer?
Wasn't this the initial promise of SDN? Hand wave. Magically connected endpoints. All QoS'd and bandwidth-guaranteed configuration completed perfectly every time across disparate networks/equipment.
to me, this was the dream of optical switching and gmpls (which is
not mpls)
And, pray tell, what is the use of me setting up "peering" between
myself and a network on the other side of the world when the data
still has to flow over the same connections, merely encapsulated
inside a tunnel?
>> to me, this was the dream of optical switching and gmpls (which is
>> not mpls)
> And, pray tell, what is the use of me setting up "peering" between
> myself and a network on the other side of the world when the data
> still has to flow over the same connections, merely encapsulated
> inside a tunnel?
Ok, but does this still not pre-suppose that an appropriate physical
path that has sufficient available bandwidth/slots is already present?
not *a* physical path, but a swath of paths from which sufficient
capacity can be configured. sadly, gmpls over optical has not yet
defied the laws of physics.
it's totally possible that the OP was not talking about "peering" as
interconnection (entirely) but also 'customer interconnect' as
interconnection.
So... "I have 1gbps of traffic I need to send to elbonia-telcom (today) ,
and tomorrow maybe 3?"
means provision a 10g link with 1g commit and burst at X cents/mbps... or
whatever... and that works 'today'.
Tomorrow you realized 'whoops, by 3gbps I really meant 13... err, now I
need to provision a 100g link or add another 10g and LAG... which means
90day telco turnaround on link provisioning...