Of course. Then why this wasn't the first thing NSIS did after going
for on-path signalling, or didn't I just manage to find it?
NSIS was specifically charged to by the Transport ADs to work on on-path
signaling. There is an analysis document being reviewed by the IESG right now
I really really hope that there has been a problem statement...
Why? I've generally found that problem statement documents have limited
Further point where you can use path-coupled signalling, you mean?
Not really, as there seems to be something seriously broken if you
need set up priorization except in well-defined points in the network.
And to achieve that, you could use a "bandwidth broker": either it's
able to set up the required bandwidth (it's in the same site, or at a
site your site has a roaming agreement with), or it isn't and the
approach is going to fail in any case, because the sites out in the
Internet don't want outsiders to request bandwidth allocations.
As you know from IPv6 discussions, people's view of what constitutes a site
is very different. It is not a well defined term. NAT & FW traversal is very
difficult, especially for signalling incoming connections. We have
documentation, if you are interested.
Also, there is no standard bw broker. Hoping that there was doesn't help.
Currently deployed bw brokers have scalability problems, especially if they are
meant to scale Internet-wide.
True enough, I had my operator hat on ;-). My mind just boggled when
I started to realize that some part of the IETF is still in denial on
why RSVP didn't go through, and is now in the process of reinventing
it .. wasting a lot of time and effort that could be much better spent
on making an operationally more feasible system to provide these
reservations in a well-defined, constrained points of the network.
Interestingly enough, there are operators involved in the NSIS discussions.
Also, some of the protocoö mechanisms of RSVP are suprisingly robust, but not
all of the design criteria of RSVP hold today.
What I can't figure why this is happening. I guess the IESG must have
been asleep, or the most people just thought, "well.. let them waste
their energy on that.. at least they don't bother us while they are
bashing the heads in the wall.."
Before passing such judgements on the IESG, reading the charter would be
recommended. If you find yourself nearby Helsinki, I'd be happy to explain
Ietf mailing list