[Sdnp] Proposed SDN BOF charter
anton.ivanov at kot-begemot.co.uk
Tue Sep 20 09:22:41 EDT 2011
>> Apologies, but unless I am mistaken, signalling a TE LSP is not done
>> based on an application request, does not require authentication,
>> authorization and accounting and you are not going to bill for it on
>> on/off basis, right? Or I am missing something?
If I put my developer hat on, you just got a dull look and I went
elsewhere. To amazon probably which gives me an interface which I can
In that case I invoke something I understand, using a framework I
understand an API I understand and I get a result I understand (with my
developer hat on).
Taking my developer's hat off this is limited to RSVP and RSVP semantics.
1. A reservation is not the only thing an app may want from a network.
2. You need per-app authentication not per neighbout
3. You need authentication different from shared key and it must be
4. You must have the usual non-repudiation and so on on the request to
be able to bill for it.
N. Most importantly you must have something which Joe Average Developer
will accept, use and understand.
>>> I think this WG would be most useful to determine the language
>>> application or host talks to the network as today there is very little
>>> done in this area.
>>> The closest is abandoned RSVP Intserv due to the state overload of
>>> micro-flow reservations.
>> Not necessarily. The closest from the perspective of a developer which
>> you pull off the street today will be something from the realm of Amazon
>> web services. If you tell him to program RSVP he will give you a dull
>> look and go somewhere else.
> I am not resurrecting RSVP. I am just trying to inject a little bit of
> pragmatism here. Controllers do not exist. PCE and ALTO does.
I beg to differ. Most telecoms network has a controller. It is called
OSS. Also, in most it does not care about PCE and ALTO and cares only
about its internal state.
Similarly, if there is an interface open to developers it hooks up at
that level and that is for a reason - billing and inventory. Interfaces
hooking up at a lower level are more often an exemption, not the rule.
> And it is true that both PCE and ALTO have today problem of keeping up
> to the moment decent accuracy of real network state. So all of this is
> sort of guessing from the knowledge of the past not present network
> Putting more controllers will not solve it.
It does not need to. The role of the controller is presentation and
abstraction of the API which allows the application to ask for things in
a manner which is understandable to Joe Average Developer.
> Application should just call a function and should not care if first
> hop router knows how to handle it itself or if it queries some other
True. Spot on.
This in reality however means:
Case A. You put support for your underlying network protocol in every OS
and every router out there and applications can rely on that to ask for
Case B. You put an "over-the-top" method which speaks a language which
is already in the runtimes of all major application frameworks out
there. This in this day and age means REST or to a lesser extent web
You can fight Case A. My guess is that you will probably lose.
Let's face it - we live in a day and age when the dominant software OS
vendor has announced that it is removing global file access and direct
database access from its next OS and leaving only per-app abstract local
storage and web services as your way to talk to the world (that is part
of the Windows 8 preview announcement by the way, I am not joking here).
Did anyone bat an eyelid? Not really. Pitching a new (or extended, but
not fully supported) protocol against that is going to be a tough call.
Tom initially clearly put the goalpoint at "Case B" by putting the words
REST(like) in it. My opinion is +1 because this is what makes the idea
viable. If we continue gunning for protocols which have been around for
15+ years and have been ignored by developers throughout their whole
lifetime we are least likely to succeed.
Cheers, my 2p.
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: anton.ivanov at kot-begemot.co.uk
More information about the SDNP