Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]

> 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 usefulness.
> 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 things.

John

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf