headers
Brian Dickson | 1 May 01:20

Re: Fwd:I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

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.)
>
>   

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.

> 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.
>
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Raszuk | 1 May 01:30
Favicon

Re: Fwd:I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

Hi Danny,

>  > It is very cheap and easy to drop the unneeded route on inbound 
>  > while it is very CPU intensive to build separate updates to each peer.
> 
> Really?  Where's the line drawn?  What about when there are
> one million updates being dropped?  I could probably make a
> case for this today?  What about legit updates queued behind
> these?

Let me address your concerns one by one ...

* The line is drawn when you have 100s of PEs to send the same 
information to.

* The milion updates to be dropped .... Clearly you must be talking 
about VPN routes. If so there are hardly single PE with milion routes to 
  make such a case today. Total number of routes yes but this draft is 
orthogonal to this. You are complaining about the 2796 case again here.

* Each PE can today receive only legit updates with or without of this 
draft including RRs support for 2796. There are well know standard based 
technics for this example: rfc4684.

Can you tell us how your argument holds when you support rfc4684 ?

>  > With current link bandwith the amount of traffic generated due to that
>  > is just white noise.
> 
> Traffic wasn't the issue.  It's more CPU, memory, etc..  Just
(Continue reading)

Permalink | Reply | 1 comment |
headers
Danny McPherson | 1 May 01:52

Re: Fwd:I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt


Regarding all your other text, I don't have any new points
to make and haven't changed my position, so I'll avoid
further discussion on that.

> Recently we have had hussars bashing "BGP overload" ... now in 2008
> perhaps we see a new trend "routing hygiene". So can you spell what is
> so unhygienic in this draft ? All points you have brought so far talk
> about solved issue (in the VPN space) if reflecting unneeded routes to
> PEs ... but non of your points refer to this draft. Can you put in
> points how this draft make this any worse ?

It's "be liberal in what you accept, conservative in what you
send", NOT "be liberal in what you send because others
are liberal in what they accept" :-)

I understand the utility of your proposal, I understand why
you selected the mechanism you did.  My concern is that all
these tweaks have system-wide implications, and we all
need to be cognizant of that when proposing solutions to
problems operators have.

-danny

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
(Continue reading)

Permalink | Reply | 0 comments |
headers
John G. Scudder | 1 May 03:15
Favicon

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 decision.)
>
> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Dickson | 1 May 04:52

Re: Route reflectors [was: Re: Fwd:I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt]

John G. Scudder wrote:
> 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:
>>>
>>
>> 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.
>

Thanks. My comment was using "you" in the sense of "one", rather than 
you personally. No flame war was intended. :-)

>> 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).
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Jakma | 1 May 12:51
Picon

Re: Fwd: New Version Notification for draft-scudder-idr-rfc3392-bis-

Hi John,

Could it be made slightly clearer that it means the same parameter 
type? (Yeah, seems obvious once you think about it, but it could 
perhaps make a difference to tired readers :) ). E.g. something like:

On Wed, 30 Apr 2008, John G. Scudder wrote:

> Enke,
>
> Would adding this paragraph at the end of section 4 cover your point?
>
>    The Capabilities Optional Parameter SHOULD only be included in the
>    OPEN message once.  If the BGP speaker wishes to include multiple
>    capabilities in the OPEN message, it SHOULD do so as discussed above,
>    by listing all those capabilities within the same Capabilities
>    Optional Parameter.  However, for backward compatibility a BGP
>    speaker MUST be prepared to receive an OPEN message which contains
>    multiple Capabilities Optional Parameters, each of which contains one
                                               ^
                                            for a given type

>    or more capabilities.  The set of capabilities should be processed
>    the same in either case, whether the it is listed within a single
>    Capabilities Optional Parameter, or within multiple.
                                                        ^
                                                    , for a given type

regards,
--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
John G. Scudder | 1 May 16:51
Favicon

Re: Fwd: New Version Notification for draft-scudder-idr-rfc3392-bis-

Hi Paul,

The paragraph actually refers to the "Capabilities Optional Parameter"  
itself within the OPEN message, i.e. OPEN parameter type 2.  RFC 4271  
and its predecessors don't fully specify the handling of OPEN optional  
parameters, and in specific are silent as to whether a given OPEN  
optional parameter can appear more than once, so Enke's suggestion  
amounts to doing that here, which seems reasonable under the  
circumstances.

Here's a revised paragraph, see if it's clearer:

   The Capabilities Optional Parameter (OPEN parameter type 2) SHOULD
   only be included in the OPEN message once.  If the BGP speaker wishes
   to include multiple capabilities in the OPEN message, it SHOULD do so
   as discussed above, by listing all those capabilities as TLVs within
   a single Capabilities Optional Parameter.  However, for backward
   compatibility a BGP speaker MUST be prepared to receive an OPEN
   message which contains multiple Capabilities Optional Parameters,
   each of which contains one or more capabilities TLVs.  The set of
   capabilities should be processed the same in either case, whether it
   is enumerated within a single Capabilities Optional Parameter of the
   OPEN message, or split across multiple.

Thanks for the feedback!

--John

On May 1, 2008, at 6:51 AM, Paul Jakma wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Haas | 3 May 19:33

Re: Fwd: New Version Notification for draft-scudder-idr-rfc3392-bis-

On Wed, Apr 30, 2008 at 06:33:04AM -0700, Yakov Rekhter wrote:
> There is a request (see attached) to accept draft-scudder-idr-rfc3392-bis
> as an IDR WG item. Please send your comments to the list. The deadline
> for comments is May 14.

I support making this a WG work item.

-- Jeff
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Jeffrey Haas | 3 May 19:34

Re: Fwd: New Version Notification for draft-scudder-idr-rfc3392-bis-

On Wed, Apr 30, 2008 at 05:31:11PM -0400, John G. Scudder wrote:
> On Apr 30, 2008, at 10:02 AM, Danny McPherson wrote:
> > One minor comment..   I think we should rename "Unsupported  
> > Capability"
> > to "Required Capability Missing", and given that the codepoint itself
> > isn't
> > changing, just the descriptor, there should be no issues here.
> 
> Clearly this is OK by me if the WG is happy with it.

I would strongly support this.  I found the original naming very
confusing when working through this in implementation some years ago.
The usual method of consulting the archives only confused matters
further as the feature evolved from capabilities *negotiation* into
advertisement.

-- Jeff
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 2 comments |
headers
Brian Dickson | 4 May 00:04

Re: Fwd: New Version Notification for draft-scudder-idr-rfc3392-bis-

Jeffrey Haas wrote:
> On Wed, Apr 30, 2008 at 06:33:04AM -0700, Yakov Rekhter wrote:
>   
>> There is a request (see attached) to accept draft-scudder-idr-rfc3392-bis
>> as an IDR WG item. Please send your comments to the list. The deadline
>> for comments is May 14.
>>     
>
> I support making this a WG work item.
>   

+1

I also support this being a WG item.

Brian Dickson
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |

Gmane