[Sdnp] Example Use Case - Bandwidth on Demand for Hybrid Cloud

[Thomas Nadeau]

On Aug 9, 2011, at 10:44 AM, David Meyer wrote:

> On Tue, Aug 9, 2011 at 7:20 AM, Anton Ivanov <aivanov at sigsegv.cx> wrote:
>> On 09/08/11 15:04, Thomas Nadeau wrote:
>>> 
>>> On Aug 8, 2011, at 11:33 AM, David Meyer wrote:
>>> 
>>> 
>>>> 
>>>> Hey Dave,
>>>> 
>>>> On Sun, Aug 7, 2011 at 6:18 AM, Mcdysan, David E
>>>> <dave.mcdysan at verizon.com>  wrote:
>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I mentioned in the IETF SNDP Bar-Bof  a potential use case. Attached are
>>>>> a
>>>>> few slides on this providing more detail on this potential use case for
>>>>> SDNP -- Bandwidth On Demand (BOD) for Hybrid Cloud for your review and
>>>>> comment.
>>>>> 
>>>>> 
>>>>> OpenFlow could be used in some cases, but I believe much more is needed.
>>>>> I
>>>>> 
>>>> 
>>>> I was under the impression that OF was out of scope here.
>>>> 
>>> 
>>>        To be precise in answering Dave McDysan's question, since this is
>>> still
>>> an informal effort, what is in and out of scope is up to the people in the
>>> discussion.
>>> I think from my end, I personally don't think it is worth distracting
>>> things with
>>> discussions of replacing Openflow; IMHO OF might be a subset of the
>>> architectural picture we are drawing here, but that isn't completely set
>>> in
>>> stone, so we don't know. What I would like to do is narrow down that
>>> picture so
>>> we know precisely what components it is were are trying to make
>>> work together first.
>>> 
>> 
>> +1. I do not see a reason why a SDN  controller cannot control  a compatible
>> OF instance.
> 
> Its a matter of what a "controller" actually is/does. Since OF is an
> open interface you can of course write code to talk to it. The
> question is whether it makes sense to mix two (or more) control planes
> that as of now wouldn't know about each other; the two are the
> existing control plane and the new, OF based control plane (of course,
> you could always take a ships in the night approach, but these are
> implementation issues which aren't or shouldn't be the subject of
> standardization). In any event, since neither control  plane would
> know what the other was doing in the forwarding plane, neither would
> be able to reason about the state of the network. Hence it will be
> difficult (if not impossible) to ensure many of the properties we want
> from a control plane such as loop-free paths and the like.
> 
> So yes, you can write code to talk to an OF device (again, that much
> is trivial), but that isn't the hard part of the problem if you want
> to mix the models. So far from what I can tell programming the control
> plane (whatever that means), programming the forwarding plane (a la
> OpenFlow), configuration and management are all part of SDNP.

	Yes, indeed you don't want to have two control planes messing with the same 
device unless coordination is in place.  I wonder if the SDP "controller(s)"
could be such a thing?  That would allow independent OF controllers to 
exist within this architecture.  One option I am thinking of is to perhaps allow
certain controllers to be "in charge of" certain 'sectors' of network resources.

> Perhaps a better question at this point is "what is *not* part of SDNP?"

	That is a good point.

	--Tom


> 
> Dave
> _______________________________________________
> SDNP mailing list
> SDNP at lucidvision.com
> http://lucidvision.com/mailman/listinfo/sdnp
>