Subject: Re: [forces] [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 10 Apr 2013 07:41:59 -0400

Hi Med,

I am finally going to answer the original email you posted instead of
talking about IETF liasons ;-> Since i am consuming excellent brew
of coffee, I will try to tone it down ;->

On Wed, Mar 20, 2013 at 11:40 AM,  <[email-masked]> wrote:
> Dear all,
>
> We submitted this new I-D.
>
> Comments and inputs are welcome.

while the title is very specific/descriptive, it was a little hard to
extract the
central message upfront.  If i was to sum up your message:
This document provides an _operator perspective_ on what SDN needs are;
and also serves to offer advice to network operators?
The document injects a dose of pragmatism about inter-working with
existing infrastructre.
It took me a re-read to understand your draft is pushing an SDN theme of
automation as the desired end goal.
Did i get this right?
Maybe your doc needs to break down what programmability aspect is needed from
an operator perspective (CLI aka netconf, Policy management, service management,
control-datapath separation etc).  And, sorry, who is deploying COPS out there?
Or perhaps your text on COPS was intended to emphasizw the point that nothing is
new here? why not mention SS7 then (which is still in deployment)?

Overall, I think theres a lot of words of wisdom as well as a good measure
of cynicism against some of the over-marketing of SDN(which i empathize with).
Thanks for pointing out that OF is not the end-all-be-all and that
Control-datapath separation is merely infrastructure requirement in the
larger picture (and, yes ForCES falls under the same umbrella).
I have to say i was a little disappointed on the number of bytes you
allocated to ForCES on this document. Mentioning ForCES in the same breath
as RFC 1383 is rather harsh!

from your sections 1 and 2 (it was hard to extract this):
The (operator) "network is getting more complex"; ATAWAD is making it worse
then you talk about desire from operator perspective is to create and
deliver services
despite the presence of such complexities in a manner which "evolves
easily, remains scalable, robust and available (even in presence of DOS
attacks)"
But also you ask for "cost effectiveness".

1) On the issue of complexity, an interesting sample was illustrated by slide 6
from D. Meyer here:
http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-0.pdf

2) And if i was to correlate Dave's slide to some food analogy:
Equipment vendors are in the business of selling cookies (chocolate-chip,
vanilla, ginger, etc of different sizes and shapes, etc) created via some
well understood "factory" assembly line. Look at all those cookies in the slide.

I am reading your view to be: the existing cookie-cut approach is _ok_ as long
as the vendors provide you ways to automate and hide that complexity.
But if that is the case, isnt it contradictory to also ask for
(what i am assuming to be capital) cost effectiveness? more cookies will
cost more, no?  And more smart people figuring ways to give you atkins
diet using cookies is also gonna cost you more.

My view of the power of SDN is ability to be able to inject new
Network Functions and be able to elongate life times of existing equipment
(and all network functions become programmable). i.e in the ideal
scenario I should be able to inject a new network function in an existing
box without playing acrobatics with how to hack some tables in a distributed
system. Whats your view of NFV?

One thing you left out as an operator desire is "vendor lock-in". Is this
not an important detail to you or it is taboo to talk about?

On some of the expressed cynicsm in the document that i disagree with:
I think you are under-valuing the control-data separation standardization
such as the one pushed forward by ForCES  in section 3.1. "tautology"
by stating that vendors have been doing for years software based control etc.
The SDN emphasis is:
a) the control-data path separation is proprietary in those boxes
b) tends to run on these tiny cpus (to which you are locked until you
buy the next GodBox).

My coffee-defined-energy is still high and I could say more - but i think i
threw in a lot of text there...

cheers,
jamal

---

From: <[email-masked]>
Date: Wed, 10 Apr 2013 14:23:49 +0200

Hello Jamal,

Many thanks for your detailed feedback. I'll let my fellow colleague further comment, but here's a first shot of responses from my side - inline. 

[snip]
while the title is very specific/descriptive, it was a little hard to extract the central message upfront.  If i was to sum up your message:
This document provides an _operator perspective_ on what SDN needs are; and also serves to offer advice to network operators?

CJ: it's mostly a provider's perspective on current SDN hype (and beyond). I think the "advice" wording is a bit strong - the draft is rather meant to list a few things one should not forget when considering the use of SDN techniques to improve network service delivery procedures.

The document injects a dose of pragmatism about inter-working with existing infrastructre.
It took me a re-read to understand your draft is pushing an SDN theme of automation as the desired end goal.
Did i get this right?

CJ: automation is a means, not a goal per se. We believe automation is a key benefit that can be brought by the activation of SDN techniques. The automation of complex service delivery is clearly an attractive feature, for the sake of cost reduction.

Maybe your doc needs to break down what programmability aspect is needed from an operator perspective (CLI aka netconf, Policy management, service management, control-datapath separation etc).  And, sorry, who is deploying COPS out there?

CJ: you'd be surprised by the number of networks that use COPS-PR implementations for the sake of bandwidth management in the access...This is a protocol (along with the related SPPI-formatted information) that is supported by at least a couple of vendors and which is deployed in the operational field (at least a couple of networks operated by some of Orange's affiliates). As for your suggestion, I'm not sure what you mean as we see programmability as a feature.

Or perhaps your text on COPS was intended to emphasizw the point that nothing is new here? why not mention SS7 then (which is still in deployment)?

CJ: I certainly recognize there are plenty of functional components that have been specified and standardized (for some of them) for quite some time. And I also recognize we may have not listed your favorite tool :-) 

Overall, I think theres a lot of words of wisdom as well as a good measure of cynicism against some of the over-marketing of SDN(which i empathize with).

CJ: thank you! That said, the point of the draft is certainly not to adopt a cynical position towards SDN techniques - beyond the SDN wording, we are true "SDN believers", provided we keep in mind a few things like this is not a one-size-fits-all solution, performance and scalability must be taken into account as a function of the number and the nature of services to be delivered and that the major technical challenges reside in the ability to combine the 4 meta-functional blocks that we briefly introduce in the document. That is, for example, take the results of a (CCP-based) negotiation of service parameters between the customer and the service provider as an input that could gracefully feed a path computation module.

Thanks for pointing out that OF is not the end-all-be-all and that Control-datapath separation is merely infrastructure requirement in the larger picture (and, yes ForCES falls under the same umbrella).
I have to say i was a little disappointed on the number of bytes you allocated to ForCES on this document. Mentioning ForCES in the same breath as RFC 1383 is rather harsh!

CJ: ha, ha! Well again, we don't mean to be rude or cynical - there are interesting approaches aout there that are probably part of the global SDN landscape. It's up to us to pick the technology that suits best.

from your sections 1 and 2 (it was hard to extract this):
The (operator) "network is getting more complex"; ATAWAD is making it worse then you talk about desire from operator perspective is to create and deliver services despite the presence of such complexities in a manner which "evolves easily, remains scalable, robust and available (even in presence of DOS attacks)"
But also you ask for "cost effectiveness".

CJ: right.

1) On the issue of complexity, an interesting sample was illustrated by slide 6 from D. Meyer here:
http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-0.pdf

CJ: indeed.

2) And if i was to correlate Dave's slide to some food analogy:
Equipment vendors are in the business of selling cookies (chocolate-chip, vanilla, ginger, etc of different sizes and shapes, etc) created via some well understood "factory" assembly line. Look at all those cookies in the slide.

CJ: and the factory assembly is precisely where it gets really tricky.

I am reading your view to be: the existing cookie-cut approach is _ok_ as long as the vendors provide you ways to automate and hide that complexity.

CJ: not exactly. We do not deny complexity, as long as it is hidden to our *customers*.

But if that is the case, isnt it contradictory to also ask for (what i am assuming to be capital) cost effectiveness? more cookies will cost more, no?  And more smart people figuring ways to give you atkins diet using cookies is also gonna cost you more.

CJ: I don't think there is a single answer to your comment. Let me give you an example: within the context of our current inter-domain VPN service offering, we need to request PE resources with peering partners, in a bilateral fashion. The corresponding negotiation remains paper- and fax- (yes fax)based, and I can tell you it takes quite some time the get the proprer resources right, let alone the CE-PE connection (especially in a dual homign context, depending on the location of the PE routers and the customer premises). Based upon an apporpriately-formatted CPP template, we believe that the inherent complexity should be adequately balanced by a dramatic improvement of the time-to-deliver the service, from several weeks to a few days, if not hours. This will have a dramatic impact on the overall cost.

My view of the power of SDN is ability to be able to inject new Network Functions and be able to elongate life times of existing equipment (and all network functions become programmable). i.e in the ideal scenario I should be able to inject a new network function in an existing box without playing acrobatics with how to hack some tables in a distributed system. Whats your view of NFV?

CJ: NFV is part of the global SDN landscape from my perspective. This is why we see information models and data (including policy provisioning information) as a key component of what you call NFV. That said, I'm not convinced NFV can be applied to each and every network capability you could think of, depending on the nature of the service and the impact on the amount of (configuration information) traffic that needs to be exchanged between the control and the data planes, for example.

One thing you left out as an operator desire is "vendor lock-in". Is this not an important detail to you or it is taboo to talk about?

CJ: that's certainly important, this is clearly not a taboo, but this is also something tht is not SDN-specific (at least as far asFT Orange is concerned).

On some of the expressed cynicsm in the document that i disagree with:
I think you are under-valuing the control-data separation standardization such as the one pushed forward by ForCES  in section 3.1. "tautology"
by stating that vendors have been doing for years software based control etc.
The SDN emphasis is:
a) the control-data path separation is proprietary in those boxes
CJ: correct.
b) tends to run on these tiny cpus (to which you are locked until you buy the next GodBox).
CJ; right, but we were actually discussing the fuzz around separated control and forwarding planes. We understand the SDN approach, but we'd appreciate a more specific/accurate wording for the sake of undertsnadability.

My coffee-defined-energy is still high and I could say more - but i think i threw in a lot of text there...

CJ: thanks again for this interesting discussion. We're looking forward to hearing from you all!

Cheers,

Christian.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Wed, 10 Apr 2013 14:26:29 +0200

Re-sending, first mail was bounced.

-----Message d'origine-----
De : JACQUENET Christian OLNC/OLN 
Envoyé : mercredi 10 avril 2013 14:24
À : 'Jamal Hadi Salim'; BOUCADAIR Mohamed OLNC/OLN
Cc : [email-masked]; [email-masked]
Objet : RE: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt

Hello Jamal,

[snip]

CJ: right.

CJ: indeed.

Cheers,

Christian.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 10 Apr 2013 10:14:43 -0400

Hi Christian,

On Wed, Apr 10, 2013 at 8:23 AM,  <[email-masked]> wrote:

> CJ: it's mostly a provider's perspective on current SDN hype (and beyond). I think the
>"advice" wording is a bit strong - the draft is rather meant to list a few things one should
>not forget when considering the use of SDN techniques to improve network service
>delivery procedures.
>

;-> So it is advice. I think it will make the draft stronger if you
invite other providers
to co-author. My view of what  a provider needs is shaped by some
presentation i saw
a while back - the emphasis there was on the theme that "each network
is different,
and SDN allows us to build our network the way we want it without
worrying about the boxes".

> CJ: automation is a means, not a goal per se. We believe automation is a key benefit that can be brought by the activation of SDN
> techniques. The automation of complex service delivery is clearly an attractive feature, for the sake of cost reduction.

It may help to describe how such cost effectiveness is achieved.
I am assuming getting rid of the genius who knows the network is one
effective cost-saving.
Is fostering competition among vendors another?

> CJ: you'd be surprised by the number of networks that use COPS-PR implementations for the sake of bandwidth management in
>the access...This is a protocol (along with the related SPPI-formatted information) that is supported by at least a couple of vendors
>and which is deployed in the operational field (at least a couple of networks operated by some of Orange's affiliates). As for your
>suggestion, I'm not sure what you mean as we see programmability as a feature.
>

ok, i take that back.
I know COPS went through a lot of battles at IETF and seemed defeated.

> CJ: I certainly recognize there are plenty of functional components that have been specified and standardized (for some of them)
>for quite some time. And I also recognize we may have not listed your favorite tool :-)
>

Agreed. My intention was to point out relevance. From a historical perspective
SS7 was doing data/control separation before half the IETF population
was born ;->
Whereas i had no clue COPS was being used.

> CJ: thank you! That said, the point of the draft is certainly not to adopt a cynical position towards SDN techniques - beyond the
> SDN wording, we are true "SDN believers", provided we keep in mind a few things like this is not a one-size-fits-all solution,

I dont think there will ever be a one size fits all.

>performance and scalability must be taken into account as a function of the number and the nature of services to be delivered and
>that the major technical challenges reside in the ability to combine the 4 meta-functional blocks that we briefly introduce in the
>document. That is, for example, take the results of a (CCP-based) negotiation of service parameters between the customer and the
>service provider as an input that could gracefully feed a path computation module.
>

Indeed interesting idea.

> CJ: ha, ha! Well again, we don't mean to be rude or cynical - there are interesting approaches aout there that are probably part of the global SDN landscape. It's up to us to pick the technology th…

True - but you are writing a generic draft, so I just wanted you to be fair;->
We have enough of the big gorilla marketing machine like ONF that is
ignoring the facts.
It is not even an orange apple comparison to put ForCES and RFC 1383
in the same basket.
ForCES is a generic datapath/control separation _architecture_ unlike
the basic RFC 1383
specific feature; or OF with a specific datapath or COPS with a
specific bandwidth enforcement
domain perspective etc.

> CJ: not exactly. We do not deny complexity, as long as it is hidden to our *customers*.

That is very interesting perspective.

> CJ: I don't think there is a single answer to your comment. Let me give you an example: within the context of our current inter-
>domain VPN service offering, we need to request PE resources with peering partners, in a bilateral fashion. The corresponding
>negotiation remains paper- and fax- (yes fax)based, and I can tell you it takes quite some time the get the proprer resources right,
>let alone the CE-PE connection (especially in a dual homign context, depending on the location of the PE routers and the customer
>premises). Based upon an apporpriately-formatted CPP template, we believe that the inherent complexity should be adequately
>balanced by a dramatic improvement of the time-to-deliver the service, from several weeks to a few days, if not hours. This will
>have a dramatic impact on the overall cost.
>

Agreed above example as a clear use case with an obvious win. It was
eye-opening for me to read.

> CJ: NFV is part of the global SDN landscape from my perspective. This is why we see information models and data (including >policy provisioning information) as a key component of what you call NFV. That said, I'm not convinced NFV can be applied to >each and every network capability you could think of, depending on the nature of the service and the impact on the amount of
>(configuration information) traffic that needs to be exchanged between the control and the data planes, for example.

I doubt it can be applied to every network capability, but:
One thing i didnt comment on earlier was the 5 year "centralized
control"  plan ;-> I saw somewhere that in data centres
it is 1-2 year  before hardware is replaced. I would suspect this
would affect your approach to "cost customization"
would be very different compared to data centres.
Wouldnt it then be logical you want your boxes from vendors to allow
you to inject more
network functions over their lifetime?  This is what NFV is suggesting.

> CJ: that's certainly important, this is clearly not a taboo, but this is also something tht is not SDN-specific (at least as far asFT >Orange is concerned).
>

So you dont mind being locked-in as long as the vendor meets those
requirements you specify?

Vendor lock-in has been considered an SDN motivation from a sales perspective.
The arguement  goes something like this (at least for ForCES):
allow an architecture that is _standard_ to evolve. It means you can
buy different
part from different competing vendors (instead of a mainframe from IBM you buy
a PC chasis from Vendor X, VGA card from Y, OS from Z, etc); the
consumer being you
benefits from cost reduction and no specific lock in (not entirely
100% given some OS
vendors could still lock you in).

> CJ; right, but we were actually discussing the fuzz around separated control and forwarding planes. We understand the SDN approach, but we'd appreciate a more specific/accurate wording for the sake…

I think the way you expressed then sounded like you were dismissing
the value of standardizing that part.

cheers,
jamal