On Tue, 24 Aug 2004, Bob Braden wrote:
> *> - RSVP doesn't have "network indication of support": the nodes keep
> *> spewing RSVP messages to the network even if every router is happily
> *> ignoring them, and the destination node does not support them.
>
> Well, actually, that's not true
*>
*> - RSVP doesn't have "network indication of support": the nodes keep
*> spewing RSVP messages to the network even if every router is happily
*> ignoring them, and the destination node does not support them.
*>
Pekka,
Well, actually, that's not true. RSVP does have mechanisms
[[ I was hoping there would be more follow-ups on this thread, but
apparently not... ]]
Combining two messages in one:
On Thu, 12 Aug 2004 18:00:50 -0500 "James M. Polk" <[EMAIL PROTECTED]>:
> Humor me (and a few others here) with a few listed mistakes you believe
> RSVP made in its design, with
> 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 r
Pekka,
>
> I really really hope that there has been a problem statement...
>
Here is an old draft on RSVP issues:
http://www1.cs.columbia.edu/~pingpan/papers/draft-pan-nsis-rsvp-transpor
t-01.txt
> Further point where you can use path-coupled signalling, you mean?
> Not really, as there se
Pekka
While it is clear your distaste for RSVP, you haven't stated anything other
than handwave why RSVP is so bad ("in the first place"). You mention there
were mistakes and a BB will fix them, but you don't list a set of mistakes
RSVP made for folks to digest. I don't know if you think they ar
Inline..
On Thu, 12 Aug 2004, David R Oran wrote:
> > I question the usefulness of path-coupled signalling beyond a certain
> > point in the network. Dean Anderson voiced them pretty well in the
> > original thread about RSVP -- it just doesn't seem to make any sense
> > beyond a very closed envi
Inline,
On Thu, 12 Aug 2004, Bob Braden wrote:
> *> As for the alternatives:
> *> 1) for first-hop only, there's really little need for a router alert,
> *> any protocol would do, as you already know who your routers are :-)
> *> 2) for hops beyond the first-hop router, I'd consider set
*> As for the alternatives:
*> 1) for first-hop only, there's really little need for a router alert,
*> any protocol would do, as you already know who your routers are :-)
*> 2) for hops beyond the first-hop router, I'd consider setting up a
*> single server which would be responsible
On Thursday, August 12, 2004, at 10:49 AM, David R Oran wrote:
What about discovery of the furthest point. Do you not find that a
persuasive use case?
There are actually a number of instances in which some kind of topology
exposure is necessary for some widely-used functions to work properly.
Cert
I question the usefulness of path-coupled signalling beyond a certain
point in the network. Dean Anderson voiced them pretty well in the
original thread about RSVP -- it just doesn't seem to make any sense
beyond a very closed environment (like the first hop) -- and in that
case, you should be abl
Thanks for the responses so far. Trying to answer in general...
On Wed, 11 Aug 2004, Martin Stiemerling wrote:
[Pekka:]
> | I'd be interested about this as well, but also in more general.
> |
> | I'd be in favor of deprecating the IP router alert option completely.
> | Effectively this affects RS
On Aug 11, 2004, at 7:58 AM, Pekka Savola wrote:
On Tue, 10 Aug 2004, Fleischman, Eric wrote:
I am aware of some use of RSVP in labs but I am not aware of any use
of RSVP in production networks (i.e., real life networks people
connect to the Internet with). Simultaneously, I am encountering
I-Ds an
Florian,
At 11:51 AM 08/11/2004, Florian Weimer wrote:
* Pekka Savola:
> The justification is simple: any "magic" packets which all routers on
> the path must somehow examine and process seems a very dubious concept
> when we want to avoid DoS attacks etc.
Any packet with IP options is more or less
* Pekka Savola:
> The justification is simple: any "magic" packets which all routers on
> the path must somehow examine and process seems a very dubious concept
> when we want to avoid DoS attacks etc.
Any packet with IP options is more or less in that category right now,
so it's a very long way
--On Mittwoch, 11. August 2004 14:58 Uhr +0300 Pekka Savola
<[EMAIL PROTECTED]> wrote:
| On Tue, 10 Aug 2004, Fleischman, Eric wrote:
|> I am aware of some use of RSVP in labs but I am not aware of any use
|> of RSVP in production networks (i.e., real life networks people
|> connect to the Inter
Pekka Savola wrote:
> I'd be in favor of deprecating the IP router alert option completely.
> Effectively this affects RSVP and MLD *). I'd want to similarly do
> away with the IPv6 Hop-by-Hop options. At the very least, I'd like to
> prevent further standardization of these options.
Multicas
On Tue, 10 Aug 2004, Fleischman, Eric wrote:
> I am aware of some use of RSVP in labs but I am not aware of any use
> of RSVP in production networks (i.e., real life networks people
> connect to the Internet with). Simultaneously, I am encountering
> I-Ds and other work planning to use RSVP. This p
18 matches
Mail list logo
