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

[Thomas Nadeau]

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. 

> In any
> event, it looks like there is a kind of super-controller (we should
> probably stop using that terminology) that talks to the enterprise
> cloud's orchestration layer (e.g., OpenStack or whatever) to program
> the forwarding on the cloud's edge? The point here is that the layer
> in the SP that you drew could use OF to control the private cloud
> edge; that would have to be coordinated with the private cloud
> orchestration layer.

	Yes, I agree. That function is precisely what I think "glues" together the different service elements we have been discussing, and acts as a center point of contact for applications wishing to interact with the infrastructure.


>> believe this use case could fit within the SNDP framework and would
>> require the following:
>>  - Northbound API
>>  - Interface to a number of classes of devices/software (switches,
>> routers, Virtual machine orchestration, storage management)
>>  - Interface to existing IETF/IEEE standardized network functions (e.g.,
>> control of Multi-Segement PWs)
> 
> One of the problems I've been struggling with in this work is what
> exactly the model that  such a "northbound API" would expose. This is
> pretty difficult to think about without a clean model of what the
> abstractions provided by the black box ("controller") are. We don't
> have that for SDNP (it seems that the model might include
> "everything"). Another question is whether or not this northbound
> overlaps with what the ONF's northbound WG is defining (it really
> hasn't spun up yet so its hard to know), and if so, what that means.

	Indeed. That is "clouding" things for me as well. It would be useful if the ONF NB API was basically the same as SDNP (or a subset).

> BTW, we should probably s/API/interface, since there is not
> necessarily an API defined there, but rather an interface. Here I'm
> defining an "interface" to be an information model, an application
> layer protocol (ALP), and a transport protocol. Example: OpenFlow is
> an interface that has as its information model the simple switch model
> (MAT), an ALP  (the OpenFlow wire format + message formats), and a
> transport protocol (TLS). For netconf, the information model is the
> yang model of the switch capabilities (etc), the ALP is XML-RPC, and
> the transport protocol is ssh.

	Agreed, all 3 parts are needed. I think that was discussed during the bar bof as well.

	--Tom



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