[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Idr] Route reflectors [was: Re: Fwd:I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt]
I've changed the subject line since we have drifted far afield from
discussion of draft-pmohapat-idr-acceptown-community-01.txt.
On Apr 30, 2008, at 7:20 PM, Brian Dickson wrote:
> John G. Scudder wrote:
>> On Apr 30, 2008, at 6:39 PM, Danny McPherson wrote:
>>> Traffic wasn't the issue. It's more CPU, memory, etc.. Just
>>> because it's available doesn't mean it's free.
>>
>> Regarding memory, it needn't be consumed for a this-is-my-own-
>> route path. (It may be, but this is an implementation decisioFrom idr-bounces at ietf.org Wed Apr 30 18:15:49 2008
Return-Path: <idr-bounces at ietf.org>
X-Original-To: idr-archive at megatron.ietf.org
Delivered-To: ietfarch-idr-archive at core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 6AD563A6A91;
Wed, 30 Apr 2008 18:15:49 -0700 (PDT)
X-Original-To: idr at core3.amsl.com
Delivered-To: idr at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 15A533A6A91
for <idr at core3.amsl.com>; Wed, 30 Apr 2008 18:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.835
X-Spam-Level:
X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=0.764,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id EHq3h8O79pCN for <idr at core3.amsl.com>;
Wed, 30 Apr 2008 18:15:46 -0700 (PDT)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177])
by core3.amsl.com (Postfix) with ESMTP id 9CB343A6BC2
for <idr at ietf.org>; Wed, 30 Apr 2008 18:15:45 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob112.postini.com
([64.18.6.12]) with SMTP; Wed, 30 Apr 2008 18:15:46 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net
with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 30 Apr 2008 18:15:10 -0700
Received: from [172.16.13.201] ([172.16.13.201])
by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m411F9x49219;
Wed, 30 Apr 2008 18:15:09 -0700 (PDT) (envelope-from jgs at juniper.net)
Message-Id: <80344ED8-5C18-48A7-ABDA-2063A63DEBCB at juniper.net>
From: "John G. Scudder" <jgs at juniper.net>
To: Brian Dickson <briand at ca.afilias.info>
In-Reply-To: <4818FEC1.4050308 at ca.afilias.info>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 21:15:07 -0400
References: <20080425213001.4EB133A69E7 at core3.amsl.com> <64E4CA6A-B8E4-4390-BDA6-39EF28E95AEA at tcb.net> <7000E71D8C525042A815432358B2F1240138D45E at paul.adoffice.local.de.easynet.net> <DE879141-E245-4051-A04D-9FF5CF97F892 at bgp.nu> <39074353-26E5-4239-A193-E4DD84AE75A0 at tcb.net> <014A2382-C5CE-4657-B4DA-FC84D7772359 at bgp.nu><4686A93B-EF16-48DC-9775-1BD241575360 at tcb.net><4818D897.3070804 at cisco.com><DC5EBA07-BBE5-4D6D-9F3E-C40C66ACE34B at tcb.net><4818DB47.8040002 at cisco.com><82B7CFF7-86CB-4DC7-BE53-29004128B5CB at tcb.net><4818DCFC.70001 at cisco.com> <8D3C8A4B-B80B-4983-8DC7-A142FFA4B41C at tcb.net> <4818ECF1.1030909 at juniper.net> <157A9EDC-B512-4C05-A257-72D70DFB44FA at tcb.net>
<E41B60B6-6B6C-4EF1-9170-BDAAE23B9D7E at bgp.nu>
<4818FEC1.4050308 at ca.afilias.info>
X-Mailer: Apple Mail (2.919.2)
X-OriginalArrivalTime: 01 May 2008 01:15:10.0268 (UTC)
FILETIME=[CCC6C7C0:01C8AB28]
Cc: idr idr <idr at ietf.org>, Danny McPherson <danny at tcb.net>
Subject: [Idr] Route reflectors [was: Re:
Fwd:I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt]
X-BeenThere: idr at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr at ietf.org>
List-Help: <mailto:idr-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces at ietf.org
Errors-To: idr-bounces at ietf.org
I've changed the subject line since we have drifted far afield from
discussion of draft-pmohapat-idr-acceptown-community-01.txt.
On Apr 30, 2008, at 7:20 PM, Brian Dickson wrote:
> John G. Scudder wrote:
>> On Apr 30, 2008, at 6:39 PM, Danny McPherson wrote:
>>> Traffic wasn't the issue. It's more CPU, memory, etc.. Just
>>> because it's available doesn't mean it's free.
>>
>> Regarding memory, it needn't be consumed for a this-is-my-own-
>> route path. (It may be, but this is an implementation decision.)
>
> n.)
>
> You need to be careful about steady-state memory usage vs high-water-
> mark memory usage.
> Processing updates chews memory *prior* to installation of entries
> in various RIBs/FIBs, and
> unless you have an excess of CPU power (and can handle line-rate
> packets in the slow path),
> it isn't possible to feasibly pre-filter without degrading
> performance.
>
> And not pre-filtering means memory gets hit on the transient prior
> to discarding this-is-my-own-route.
I have in-depth familiarity with several well-known BGP
implementations, and I haven't the slightest idea what you're talking
about.
>> Regarding CPU, remember that you want to optimize the bottleneck,
>> nothing else matters really. In most cases, the RR is the control
>> plane bottleneck. Loading it up more to protect the CPUs of non-
>> bottleneck devices seems like an odd design decision.
>
> The red flag has gone up. Using the term "*the* bottleneck" means
> you don't understand the nature
> of complex systems.
Tempting though it may be to pick up the gauntlet and enter into a
full scale flame war, I hope you won't mind if I try to confine myself
to the substance of your remarks rather than their tone.
> Yes, there will *always* be a bottleneck. However, solving for one
> bottleneck
> will *always* move the bottleneck to some other place. It may be
> acceptable for a stable state with
> several equally-pernicious bottlenecks affecting the system, or to
> move the bottleneck to a portion of
> the solution space that scales best (e.g. one that scales as O(n log
> n) vs one that scales as O(n^2).
Yes, this is algorithms 101. I was making a rather simple point
regarding networks as systems, viz the fact that if you've got one RR
feeding a large number of clients, the RR usually needs to process a
lot more stuff than the clients do. It has N >> 1 peers (the clients
and non-client peers); they have M << N peers (the RR, likely a
redundant RR, and probably a smaller number of external peers).
Granted that this isn't universally true, but one has to design to
something and this would seem to be the common case.
It's rather grandiose to describe the issue under discussion (which,
I'll remind you, is a tangent having to do with route reflection and
the differences between RFC 1966 and RFC 2796) as an attempt to "solve
for [the] bottleneck". While a "solution" would be nice, I think most
would settle for just increasing the bottleneck's diameter. :-) In
any event, this is water which ran under the bridge a long time ago.
> The two other points I'd like to make, are, that:
> (1) saying "in most cases" is the same as saying "it's not always
> the case".
Well, yeah.
> Solving for one case without
> considering other cases is very short-sighted and can cause
> unforseen consequences.
Thank you for this insight, I will strive to bear it in mind.
> It is much better
> to *consider* those cases, explicitly, and discuss whether and to
> what degree they would get affected; and
Please feel free to redesign route reflection to be optimal in all
cases if you have the time to spare! Absent a really interesting
point being raised, I'll probably refrain from further discussion of
this topic myself though, since as I mentioned, this is water under
the bridge.
> (2) keep in mind - an RR is *strictly* control plane. It is possible
> for it to reside on a device that also does
> data plane stuff. However, if RR performance is a huge deal,
> throwing *computer* hardware at it, rather
> than *router* hardware at it, is an entirely feasible solution -
> with likely higher (by orders of magnitude)
> ceiling on performance that can be bought, and likely at much lower
> price point than equivalent router vendor
> RR solutions. RR can achieve equivalent topological solutions (and
> thus avoid topological variance versus
> router-based RR's) by sitting as a one-armed device hanging off a
> core router.
OK.
> There is something to very much consider, however:
> RR's are fundamentYou need to be careful about steady-state memory usage vs high-water-
> mark memory usage.
> Processing updates chews memory *prior* to installation of entries
> in various RIBs/FIBs, and
> unless you have an excess of CPU power (and can handle line-rate
> packets in the slow path),
> it isn't possible to feasibly pre-filter without degrading
> performance.
>
> And not pre-filtering means memory gets hit on the transient prior
> to discarding this-is-my-own-route.
I have in-depth familiarity with several well-known BGP
implementations, and I haven't the slightest idea what you're talking
about.
>> Regarding CPU, remember that you want to optimize the bottleneck,
>> nothing else matters really. In most cases, the RR is the control
>> plane bottleneck. Loading it up more to protect the CPUs of non-
>> bottleneck devices seems like an odd design decision.
>
> The red flag has gone up. Using the term "*the* bottleneck" means
> you don't understand the nature
> of complex systems.
Tempting though it may be to pick up the gauntlet and enter into a
full scale flame war, I hope you won't mind if I try to confine myself
to the substance of your remarks rather than their tone.
> Yes, there will *always* be a bottleneck. However, solving for one
> bottleneck
> will *always* move the bottleneck to some other place. It may be
> acceptable for a stable state with
> several equally-pernicious bottlenecks affecting the system, or to
> move the bottleneck to a portion of
> the solution space that scales best (e.g. one that scales as O(n log
> n) vs one that scales as O(n^2).
Yes, this is algorithms 101. I was making a rather simple point
regarding networks as systems, viz the fact that if you've got one RR
feeding a large number of clients, the RR usually needs to process a
lot more stuff than the clients do. It has N >> 1 peers (the clients
and non-client peers); they have M << N peers (the RR, likely a
redundant RR, and probably a smaller number of external peers).
Granted that this isn't universally true, but one has to design to
something and this would seem to be the common case.
It's rather grandiose to describe the issue under discussion (which,
I'll remind you, is a tangent having to do with route reflection and
the differences between RFC 1966 and RFC 2796) as an attempt to "solve
for [the] bottleneck". While a "solution" would be nice, I think most
would settle for just increasing the bottleneck's diameter. :-) In
any event, this is water which ran under the bridge a long time ago.
> The two other points I'd like to make, are, that:
> (1) saying "in most cases" is the same as saying "it's not always
> the case".
Well, yeah.
> Solving for one case without
> considering other cases is very short-sighted and can cause
> unforseen consequences.
Thank you for this insight, I will strive to bear it in mind.
> It is much better
> to *consider* those cases, explicitly, and discuss whether and to
> what degree they would get affected; and
Please feel free to redesign route reflection to be optimal in all
cases if you have the time to spare! Absent a really interesting
point being raised, I'll probably refrain from further discussion of
this topic myself though, since as I mentioned, this is water under
the bridge.
> (2) keep in mind - an RR is *strictly* control plane. It is possible
> for it to reside on a device that also does
> data plane stuff. However, if RR performance is a huge deal,
> throwing *computer* hardware at it, rather
> than *router* hardware at it, is an entirely feasible solution -
> with likely higher (by orders of magnitude)
> ceiling on performance that can be bought, and likely at much lower
> price point than equivalent router vendor
> RR solutions. RR can achieve equivalent topological solutions (and
> thus avoid topological variance versus
> router-based RR's) by sitting as a one-armed device hanging off a
> core router.
OK.
> There is something to very much consider, however:
> RR's are fundamentally reqally required
If you are going to insist on precision in the use of language, you
should be careful with expressions like "fundamentally required".
> to achieve suitable scaling on big non-VPN networks.
> Please keep those networks in mind when messing about with core BGP
> protocols.
I have some familiarity with the networks you are speaking of. And to
repeat one more time lest the confusion continue, the draft originally
under discussion isn't about route reflection other than tangentially.
> (Never mind that I'm working on something to *really* mess with
> those same core BGP protocols...
Yes, the first draft was interesting and I look forward to seeing the
next draft.
> but with good reason. :-) )
That remains to be proven though it's an intriguing hypothesis.
--John
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr
uired
If you are going to insist on precision in the use of language, you
should be careful with expressions like "fundamentally required".
> to achieve suitable scaling on big non-VPN networks.
> Please keep those networks in mind when messing about with core BGP
> protocols.
I have some familiarity with the networks you are speaking of. And to
repeat one more time lest the confusion continue, the draft originally
under discussion isn't about route reflection other than tangentially.
> (Never mind that I'm working on something to *really* mess with
> those same core BGP protocols...
Yes, the first draft was interesting and I look forward to seeing the
next draft.
> but with good reason. :-) )
That remains to be proven though it's an intriguing hypothesis.
--John
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr