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

Tue Aug 9 14:14:47 EDT 2011

On Aug 9, 2011, at 12:05 PM, Anton Ivanov wrote:

> On 09/08/11 15:49, Thomas Nadeau wrote:
>> 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.
>>   
> 
> Indeed. In the last slideset (at least the way I read it) there is nothing in particular to prescribe that the south side of the controller directly controls the forwarding plane which IMO is one of the key differences compared to OF.
> 
> A SDN controller can control other SDN controllers using the same SDN interface. A SDN controller can pick out the bits relevant to itself and talk to another controller responsible for another admin domain as an SDN client and so on. This is a natural result of using REST for communications. You can have one entity taking REST on one side and happily talking REST on the other.

	This is precisely the refinement we've worked into the current working version of the architecture: SDN only talks to control plane "controllers". If they happen to talk to a data plane under the hood, that is up to them. This keeps a clear line between OF and SDN.   If we happen to make the OF NB API integrate well with SDN, then we have a bonus situation.

> Unless I am mistaken, I did not see anything in the last slidesets (and discussion) which put these explicitly out of scope and it will be good to keep them in-scope as they naturally deal with "multi-domain" and "multi-tenant" use cases without us having to do anything specific about them.

	We definitely were not precluding it originally. 

	--Tom

> 
> Brgds,
> 
> -- 
>    Humans are allergic to change. They love to say, "We've always
> done it this way." I try to fight that. That's why I have a clock
> on my wall that runs counter-clockwise.   -- R.A. Grace Hopper
> 
> A. R. Ivanov
> E-mail:  anton.ivanov at kot-begemot.co.uk
> 
> _______________________________________________
> SDNP mailing list
> SDNP at lucidvision.com
> http://lucidvision.com/mailman/listinfo/sdnp
> 