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
On Fri, 13 Aug 2004, Tony Hain wrote:
> Dean Anderson wrote:
> > RSVP is a idea that doesn't cut the mustard in the real world. There are
> > several show-stopper problems with RSVP.
>
> Propagating clueless FUD does not result in progress.
That is true. Lets try to keep the FUD to a minimum.
]
Subject: Re: Question about use of RSVP in Production Networks
Hi,
Were Eric's question and Dean's answer limited to RSVP strictly,
or would RSVP-TE deployments be of interest? If the latter, then
what about emerging deployments of architectures that use RSVP-TE,
such as MPLS, GMPLS, and
Dean Anderson wrote:
> RSVP is a idea that doesn't cut the mustard in the real world. There are
> several show-stopper problems with RSVP.
Propagating clueless FUD does not result in progress.
>
> 1) somewhat like multicast, anyone using RSVP is vulnerable to others
> mis-using or mis-configuri
that
approach several years before there were any such actual deployments
and have since moved on to other domains.
Cordially,
BobN
Original message
>Date: Wed, 11 Aug 2004 17:32:10 -0700
>From: "Ping Pan" <[EMAIL PROTECTED]>
>Subject: RE: Question about
ally,
BobN
Original message
>Date: Wed, 11 Aug 2004 18:37:31 -0400 (EDT)
>From: Dean Anderson <[EMAIL PROTECTED]>
>Subject: Re: Question about use of RSVP in Production Networks
>To: "Fleischman, Eric" <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>
&
Dean Anderson wrote:
RSVP is a idea that doesn't cut the mustard in the real world. There are
several show-stopper problems with RSVP.
1) somewhat like multicast, anyone using RSVP is vulnerable to others
mis-using or mis-configuring RSVP. ISPs several AS's away can really screw
up things for other
> 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
Dean,
Just limiting my reply to one point:
>That relegates RSVP to the enterprise Lan, where it usually isn't
needed.
>Remember, RSVP is only useful if you have a congestion problem and
need to
>choose which packets to discard. If you have no congestion problem,
then
>you have no need of RS
eases
true? ;-)
Cordially,
BobN
Original message
>Date: Wed, 11 Aug 2004 18:37:31 -0400 (EDT)
>From: Dean Anderson <[EMAIL PROTECTED]>
>Subject: Re: Question about use of RSVP in Production Networks
>To: "Fleischman, Eric" <[EMAIL PROTECTED]>
>Cc: [EMAIL PR
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
Do you count for RSVP-TE, that has been deployed widely in carrier
networks? Other than multicast and wild-card filtering, all other
features (and more) defined in the context of RSVP have been developed
and deployed. The number of RSVP sessions (a.k.a. MPLS LSP's) is in the
range of thousands in l
RSVP is a idea that doesn't cut the mustard in the real world. There are
several show-stopper problems with RSVP.
1) somewhat like multicast, anyone using RSVP is vulnerable to others
mis-using or mis-configuring RSVP. ISPs several AS's away can really screw
up things for other ISPs. Because of t
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
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
possible disconnect concerns me. Therefore, I would
29 matches
Mail list logo
