Subject: Fwd: New Version Notification for draft-marques-sdnp-flow-spec-00.txt

From: Pedro Marques <[email-masked]>
Date: Mon, 10 Oct 2011 21:30:21 -0700

I posted a new draft that complements the end-system VPN proposal by
adding support for fine grain traffic classification policies.
I hope it merits your attention.

regards,
  Pedro.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Mon, Oct 10, 2011 at 9:26 PM
Subject: New Version Notification for draft-marques-sdnp-flow-spec-00.txt
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
[email-masked]

A new version of I-D, draft-marques-sdnp-flow-spec-00.txt has been
successfully submitted by Pedro Marques and posted to the IETF
repository.

Filename:        draft-marques-sdnp-flow-spec
Revision:        00
Title:           Traffic classification, filtering and redirection for
end-system IP VPNs.
Creation date:   2011-10-11
WG ID:           Individual Submission
Number of pages: 15

Abstract:
  When IP VPNs are used to interconnect end-systems
  [I-D.marques-l3vpn-end-system] it may be desirable to introduce
  traffic control rules at a finer level of granularity than an IP
  destination address.

  This document extends the end-system IP VPN specification with
  support for fine grain traffic classification, filtering and
  redirection rules.  It applies the existing BGP IP VPN flow
  specification dissemination mechanism [RFC5575] to end-system IP VPNs
  in order to provide the ability to control IP packets that match a
  specific pattern, which may include fields other than the IP
  destination address.

The IETF Secretariat

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Oct 2011 09:20:21 -0400

Pedro thanks for the update.  I have a question about your draft.  Can you explain how it differs from similar use cases that were discussed and also how it applies to the proposed architecture for SDN either in its current form or modified?

Tom

Sent from my iPad

On Oct 11, 2011, at 12:30 AM, Pedro Marques <[email-masked]> wrote:

> _______________________________________________
> SDNP mailing list
> [email-masked]
> http://lucidvision.com/mailman/listinfo/sdnp
>

---

From: Pedro Marques <[email-masked]>
Date: Tue, 11 Oct 2011 09:28:08 -0700

Tom,
In terms of fit within a broader context, my understanding is that
these proposals are largely inline with the SDN ecosystem/vision. The
following are some of the underlying assumptions which i believe are
inline with the "sdnp" documents:

  - There is the assumption that VM provisioning is performed by an
orchestration system. This orchestration system has a notion of
user/tenant and which services the tenant is allowed to access.

  - The orchestration system allocates a "sticky" IP address per VM;
when a VM  is provisioned, the (VPN IP address, vpn-name) is passed
along to the host OS.

  - There is a centralized data-base (possibly with a distributed
implementation) that contains the provisioning information regarding
vpn-names and the services they are able to access. This database
schema is standardized and signaling gateways are able to retrieve the
vpn configuration from this database. The orchestration system is most
likely the publisher.

  - Advanced functionality such as fine grain traffic policies is able
to inject rules into the network by pushing information through the
XMPP interface.

  - The network operates independently from applications and
orchestration. But the network signaling works as a "message bus" to
which the orchestration layer can push information to and also receive
information from.

  - It is important to leverage other IETF standards. For instance the
virtualized network solution should support an ALTO API for
application to access network distance information.

In my mind these proposals are one possible approach to implement what
is most likely the most immediate problem in the SDN space. It is my
belief that by reusing existing standards, that multiple interoperable
implementation can surface in a short period of time. And in my
opinion they are a natural progression of the SDN work so far. But i
do apologize in advance in case i misinterpreted the existing SDN
architecture.

regards,
  Pedro

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 11 Oct 2011 12:26:55 -0500

Include l3vpn list here (under vpn4dc topic).

> -----Original Message-----
> From: [email-masked] [mailto:sdnp-
> [email-masked]] On Behalf Of Pedro Marques
> Sent: Tuesday, October 11, 2011 1:22 PM
> To: Anton Ivanov
> Cc: [email-masked]
> Subject: Re: [Sdnp] Fwd: New Version Notification fordraft-marques-
> sdnp-flow-spec-00.txt
> 
> Anton,
> In my view the requirements for the client to server channel are:
>  - persistent sessions.
>  - mutual authentication.
>  - transport arbitrary xml schema.
>  - publish / subscribe semantics.
> 
> In my opinion, XMPP was the most reusable component out there. There
> are client libraries available, and i don't believe the developers
> would really care so much about the transport, as
> long as that transport does the job.
> 
> The APIs that are presented in the documents are targeted at the Host
> OS infrastructure software. These are not APIs targeted at the
> end-user application running on top of the guest VM. For the later,
> e.g. an ALTO API that provides access to network distance, REST would
> probably be a better choice.
> 
> That said, i believe that in the IETF choice is considered to be a
> good thing. I suspect that most people would welcome a REST API that
> has the same capabilities described in the drafts. That would allow
> implementors to decide on either or both of these APIs.
> 
> regards,
>   Pedro.
> 
> On Tue, Oct 11, 2011 at 10:04 AM, Anton Ivanov
> <[email-masked]> wrote:
> > XMPP is the only other obvious candidate for stuff like this besides
> REST.
> >
> > Personally, I think that Joe Average Developer will prefer REST. It
> is
> > something the developer's community understands and likes.
> >
> > If however, for whatever reason, we decide that REST does not fit the
> bill,
> > the next in line IMO is XMPP - it allows you to ferry structured data
> with
> > authentication, authorisation, replication, high availability, etc
> from
> > point A to point B and there are libraries and APIs for most
> platforms.
> >
> > So it is rather unsurprising that it comes up in this context.
> >
> > In any case, we can look at XMPP as a possible plugin protocol :)
> >
> > My 2c.
> >
> > Brgds,
> >
> > On 11/10/11 17:28, Pedro Marques wrote:
> >>
> >> Tom,
> >> On Tue, Oct 11, 2011 at 6:20 AM, Thomas
> Nadeau<[email-masked]>
> >>  wrote:
> >>
> >>>
> >>> Pedro thanks for the update.  I have a question about your draft.
>  Can
> >>> you explain how it differs from similar use cases that were
> discussed and
> >>> also how it applies to the proposed architecture for SDN either in
> its
> >>> current form or modified?
> >>>
> >>> Tom
> >>>
> >>> Sent from my iPad
> >>>
> >>> On Oct 11, 2011, at 12:30 AM, Pedro
> Marques<[email-masked]>
> >>>  wrote:
> >>>
> >>>
> >>>>
> >>>> From:<[email-masked]>
> > --
> >    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:  [email-masked]
> >

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Oct 2011 14:46:29 -0400

[Adding cross-post to l3vpn]

> XMPP is the only other obvious candidate for stuff like this besides REST.
> 
> Personally, I think that Joe Average Developer will prefer REST. It is something the developer's community understands and likes.
> 
> If however, for whatever reason, we decide that REST does not fit the bill, the next in line IMO is XMPP - it allows you to ferry structured data with authentication, authorisation, replication, high availability, etc from point A to point B and there are libraries and APIs for most platforms.
> 

	Yes, I agree. We need to consider other non-ReST interfaces. This was something expressed during the Bar BoF in Quebec, and is something I've heard since. 

	--Tom

>> On Tue, Oct 11, 2011 at 6:20 AM, Thomas Nadeau<[email-masked]>  wrote:
>>   
>>> On Oct 11, 2011, at 12:30 AM, Pedro Marques<[email-masked]>  wrote:
>>> 
>>>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Oct 2011 14:48:50 -0400

[Cross-post to l3vpn again. Please include this in future posts.]

> - publish / subscribe semantics.

	The other thing we need is asynchronous notification.

> probably be a better choice.

	Although please keep in mind that it is a very real possibility that some SDN
components are running on VMs, including routers/switches/NAT gateways, etc...

> implementors to decide on either or both of these APIs.

	Agreed.

	--Tom

>> Personally, I think that Joe Average Developer will prefer REST. It is
>> If however, for whatever reason, we decide that REST does not fit the bill,
>> the next in line IMO is XMPP - it allows you to ferry structured data with
>> authentication, authorisation, replication, high availability, etc from
>> point A to point B and there are libraries and APIs for most platforms.
>> 
>>>> Pedro thanks for the update.  I have a question about your draft.  Can
>>>> you explain how it differs from similar use cases that were discussed and
>>>> also how it applies to the proposed architecture for SDN either in its

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Oct 2011 14:49:53 -0400

[Cross-post to l3vpn]

On Oct 11, 2011, at 2:02 PM, Anton Ivanov wrote:

> Hi Pedro,
> 
> First, you have inserted a requirement here on the fly - "arbitrary xml schema". While that may be a good idea to describe a system or transfer structured data it is not the only one.
> 
> Second, I understand you very well. The last several times I have looked at similar problems (SDNI, etc) XMPP has always shown up as a viable candidate.
> 
> It is however still too heavy for joe average developer. So IMO we should give REST a first chance especially for the "north" API.
> 
> Brgds,
> 
> On 11/10/11 18:21, Pedro Marques wrote:
>> Anton,