Subject: SDN charter and work items

From: Pedro Marques <[email-masked]>
Date: Wed, 2 Nov 2011 16:25:08 -0700

Dear colleagues,
It has become a common methodology within the IETF to start with a top
level discussion on problem statement and architectural frameworks and
them move discuss solutions. In the specific case of the SDN work that
is being proposed, it is my opinion that the IETF should initially
focus on building a small number of solutions such that they yield at
least two interoperable implementations, before generalizing into
architectural frameworks.

The field of programmable interfaces to network information is new,
and so is the data-center network virtualization area. Without testing
concrete solutions and learning from experience, it is rather unlikely
that there would be no way to resolve between different opinions of
what the abstract architecture should be and should include. The
overall experience in these topics in the whole industry and the IETF
in particular is shallow.

There is a very considerable interest at the moment in DC centric
solutions for network virtualization. For reasons of development
agility a large number of parties in this space have gravitated
towards proprietary solutions. There is a small window of opportunity
for those that believe in building open and interoperable ecosystems
to attempt to work with these more nimbler players, as long as that is
achieved in reasonable timescales. Does standardization mean an
interminable bureaucratic process or does it actually lead to creating
an eco-system in which many players can trive ?

In the spirit of "running code and rough consensus" i believe the SDN
effort should focus on building a small number of "test" solutions and
then iterate from there.

While i will proceed to "peddle" one proposal that i've been working
on by no means i want to suggest that it is sufficient to explore that
specific proposal in order to be able to determine what the "D" in SDN
really means. But i would like to suggest that the way to go about it
is by experimentation.

As one possible vision of what  SDN could mean i would like to submit:
  - A proposal for DC VPNs:
http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02
  - The document in attachement which proposes a possible interface
between an orchestration system and a routing
infrastructure such as the one above.

Both these documents follow a very incremental approach and attempt to
deliver the desired functionality without reinventing components which
are known to work correctly today. The underlying protocols that are
being reused are fully documented and standardized and multiple
implementations exist from which is possible to quickly build the
proposed extensions.

It is at least a data point. My humble suggestion is that the IETF
collects several distinct data points before it attempts to engage in
a broader top-down architectural approach.

thank you for your attention,
  Pedro.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 03 Nov 2011 08:36:06 +0100

Hi Pedro,

> in particular is shallow.
+
> really means. But i would like to suggest that the way to go about it

I must say that I very much agree with the above approach ie to get 
experience in learning what SDN really is by experimentation with sample 
set of applications of it.

>                        IF-MAP schema for IP VPNs.
>                    draft-marques-sndp-l3vpn-schema-00

Few questions on this one ...

- How are you define choice of PE-CE routing protocol used to exchange 
reachability information ?

- How do you envision scale of MAP server ? How about communication 
between MAP servers especially in case of distributed ones ?

- How about discussion of MAP server failure cases ?

- How one would go about negotiating with given VPN instance various per 
VPN security parameters (vrf-route-limit, prefix-limit etc ...)

- Do you expect MAP server to be used to manage just single 
administrative domain leaving any form of inter-as or inter-provider out 
of scope (manual provisioning) ?

>    A MAP server implementation SHOULD support access controls on a per
>    metadata element basis such that it is possible to restrict write
>    access to a set of metadata elements to a specific list of
>    certificates.

This perhaps leaves a door a bit open to allow customer management of 
their VPN instance. That is great. However how do you envision possible 
extranets provisioning when applicable ?

Thx,
R.