Subject: [Sdn] FW: please send charter comments to the list

From: "WRIGHT, STEVEN A" <[email-masked]>
Date: Thu, 15 Nov 2012 15:34:01 +0000

From: WRIGHT, STEVEN A
Sent: Sunday, November 11, 2012 11:25 AM
To: David Meyer
Subject: RE: [Sdn] please send charter comments to the list

The charter would benefit from having one or more succinct problem statement(s). While a taxonomy, framework and use cases can help explore a subject space, a problem statement provides a focus for the work, and some means to evaluate whether a particular piece of work is in scope, or is progressing the topic towards solution of the problem. It would be desirable to have the problem statement in the charter, though as a research group, it could also be a deliverable.

The current charter draft hints at several different problems e.g. network agility, service velocity, network operation, network debugging are difficult. While these might all be commercially interesting problems, it is not necessarily clear that there is a single solution to all of them.

A succinct problem statement would also be helpful in clarifying who has the problem at the focus of the group's work. Is this a problem space for equipment designers? Network operators? General internet users? This clarification would help those researchers constrained to work on commercially relevant problems to engage appropriately.

Steven Wright, MBA, PhD, JD.
Lead Member of Technical Staff

AT&T Services Inc.
Strategic Standards
1057 Lenox Park Blvd NE, STE 4D28
Atlanta, GA 30319
P: 404.499.7030

[email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of David Meyer
Sent: Thursday, November 08, 2012 12:13 PM
To: SDN IRTF list
Subject: [Sdn] please send charter comments to the list

Folks,

I want to sharpen up the charter with your ideas/comments so please send them to the list and I'll rev the charter.

Thnx,

--dmm

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 15 Nov 2012 10:17:05 -0800

+1

Wassim H.

On Nov 15, 2012, at 7:34 AM, WRIGHT, STEVEN A wrote:

> A succinct problem statement would also be helpful in clarifying who has the problem at the focus of the group’s work. Is this a problem space for equipment designers? Network operators? General internet users? This clarification would help those researchers constrained to work on commercially relevant problems to engage appropriately.
> 
>  
> [email-masked]
> From: [email-masked] [mailto:[email-masked]] On Behalf Of David Meyer
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn

---

From: Sharon <[email-masked]>
Date: Thu, 15 Nov 2012 12:41:25 -0800

What brought about the strong interest in SDN are problems associated with connecting compute and storage virtualization. The fact that virtualized endpoints move is one aspect that makes traditional network virtualization (VLANS, VPNs, VP/VC) insufficient (tied to interfaces). 
However a key other aspect often referred to is the need for better Programability.

Why better? Because the network is required to perform additional functions - dynamically linking (compiler was a term also used in the atlanta session) virtualized functional components into cloud solutions. That's new. 

Bellow is a link to a carrier cloud problem statement published by key providers.
This problem can benefit greatly from better network Programability. https://www.dropbox.com/s/t1irp2nhoz131xy/NFV_White_Paper.pdf

In short the problem statement can be about new requirements brought about by cloud networking that can be addressed by an additional, software-defined networking layer,
on top of IPvN, controlled by programable flows based on global-software awareness.

On Nov 15, 2012, at 10:17, Wassim Haddad <[email-masked]> wrote:

+1

Wassim H.

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 15 Nov 2012 12:51:15 -0800

comments inline:

On Thu, Nov 15, 2012 at 12:41 PM, Sharon <[email-masked]> wrote:

>
> What brought about the strong interest in SDN are problems associated with
> connecting compute and storage virtualization. The fact that virtualized
> endpoints move is one aspect that makes traditional network virtualization
> (VLANS, VPNs, VP/VC) insufficient (tied to interfaces).

I disagree with this characterization.  This is certainly a member of the
SDN problem set, but by no means the only or even the primary use case.
Look at RCP, ethane, others.

>
> Why better? Because the network is required to perform additional
> functions - dynamically linking (compiler was a term also used in the
> atlanta session) virtualized functional components into cloud solutions.
> That's new.
>

You don't actually need to have this level of sophistication to reap real
benefits from being able to program ephemeral state (but it sure would be
nice ;).

> This problem can benefit greatly from better network Programability.
> https://www.dropbox.com/s/t1irp2nhoz131xy/NFV_White_Paper.pdf
>
> In short the problem statement can be about new requirements brought about
> by cloud networking that can be addressed by an additional,
> software-defined networking layer,

s/the problem statement/a problem statement/

> The charter would benefit from having one or more succinct problem
> statement(s). While a taxonomy, framework and use cases can help explore a
> subject space, a problem statement provides a focus for the work, and some
> means to evaluate whether a particular piece of work is in scope, or is
> progressing the topic towards solution of the problem. It would be
> desirable to have the problem statement in the charter, though as a
> research group, it could also be a deliverable.
>
>
> The current charter draft hints at several different problems e.g. network
> agility, service velocity, network operation, network debugging are
> difficult. While these might all be commercially interesting problems, it
> is not necessarily clear that there is a single solution to all of them.
>
>
> A succinct problem statement would also be helpful in clarifying who has
> the problem at the focus of the group’s work. Is this a problem space for
> equipment designers? Network operators? General internet users? This
> clarification would help those researchers constrained to work on
> commercially relevant problems to engage appropriately.
>
>
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of David Meyer
>
> I want to sharpen up the charter with your ideas/comments so please send
> them to the list and I'll rev the charter.
>
>
> Thnx,
>
>
> --dmm
>
>

---

From: Sharon <[email-masked]>
Date: Thu, 15 Nov 2012 21:31:57 -0800

Think I get the point .. too constrictive..

Perhaps look at the "problem" statement differently -

1) there is now a capability (programable merchant silicon) and a trend to decouple network control from packet forwarding  
2) this trend opens up an opportunities to think about network control planes in an out of the forwarding box manner, enable new innovation in solving age old networking challenges (manageability, mass customization, services ...)  and also take on new ones (cloud etc.)
3) this trend also has the risk of wiping out years of accumulated work in build control structures that scale and re-inventing lots of old wheels under new named .. the hard way ..

The goal therefore is to define a structure and architecture that can open up network control to software defined innovation in a way that extends existing capabilities and fixes only what's broken in an incremental and modular manner, guided by proven ietf processes & practices

On Nov 15, 2012, at 12:51, Edward Crabbe <[email-masked]> wrote:

comments inline:

> However a key other aspect often referred to is the need for better Programability.

I disagree with this characterization.  This is certainly a member of the SDN problem set, but by no means the only or even the primary use case.   Look at RCP, ethane, others. 
 
> Why better? Because the network is required to perform additional functions - dynamically linking (compiler was a term also used in the atlanta session) virtualized functional components into cloud…

You don't actually need to have this level of sophistication to reap real benefits from being able to program ephemeral state (but it sure would be nice ;).