[Sdnp] updated SDN problem statement draft
kgray at juniper.net
Wed Mar 14 11:22:06 EDT 2012
In section 3.1, will the architecture define:
A plug-in/modular architecture to accommodate multiple topology sources (BGP-TE, ALTO, etc)?
A plug-in/modular architecture to accommodate the multiple provisioning tools available (PCE, OF, your-brand-of-IP-tunnel, etc)?
I'm just looking for the value statement here, and one of the problems (to me) is the proliferation of options on these "interfaces" (as far as building the perfect application beast goes). So, for topology, for example … would the Service Mediator define some sort of topology abstraction at ingest that normalizes the formats of the example topology providers above …or maps provisioning capabilities per object managed to hide the syntactical/semantic differences between cross-connecting a flow with OF vs some-other-config-semantic?
Other than a platform to tie together all the elements, what will the value add be …
From: Ping Pan <ping at pingpan.org<mailto:ping at pingpan.org>>
Date: Tue, 13 Mar 2012 07:08:15 -0700
To: sdnp <sdnp at lucidvision.com<mailto:sdnp at lucidvision.com>>
Subject: Re: [Sdnp] updated SDN problem statement draft
The new draft is trying to outline:
1. What is it? An overlay architecture that presents the underlying network to the applications for monitoring and provisioning at abstraction level.
2. Architecture outline: after speaking to many and tried out quite a few solutions, here is the architecture that we believe is reasonable. (more details to follow)
3. Use cases: network slicing, virtual dc and l3 hypervisor. (more details to follow)
Please take a look, and provide comment.
(Sorry about many editing mistakes, as we are bouncing between projects)
On Tue, Mar 13, 2012 at 6:58 AM, Thomas Nadeau <tnadeau at lucidvision.com<mailto:tnadeau at lucidvision.com>> wrote:
Please review and send us comments/feedback.
SDNP mailing list
SDNP at lucidvision.com<mailto:SDNP at lucidvision.com>
More information about the SDNP