[Sdnp] Proposed SDN BOF charter

[Anton Ivanov]

[snip]

>> 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?
>
> http://tools.ietf.org/html/rfc4804

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 
understand.

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 
strong cryptographically.
4. You must have the usual non-repudiation and so on on the request to 
be able to bill for it.
5...
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.
>>
>> Exactly.
>>
>>> 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 
> state.
>
> 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 
> components.

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 
resources.

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 
services.

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.

[snip]

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