On 27 mrt 2009, at 3:43, Shane Amante wrote:
Re: your comment on breaking groupwise processing ... don't RR's
already have to account for not sending updates to a specific peer
(or, set of peers) based on various ORF types they've received from
that peer (assuming ORF's are enabled)? Why
On Mar 30, 2009, at 7:39 AM, Iljitsch van Beijnum wrote:
Yes, a router thinks its own eBGP route is best--but the RR wouldn't
necessarily agree. Suppose 4 eBGP routers and an RR, the average
backreflection would be 25%. Now maybe it's 85% for one and 5% for
the three others, but the
-Original Message-
From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf Of
Iljitsch van Beijnum
Sent: Monday, March 30, 2009 9:43 AM
To: Shane Amante
Cc: grow@ietf.org grow@ietf.org
Subject: Re: [GROW] RR reflection to clients
On 27 mrt 2009, at 3:43, Shane Amante wrote
Hi Danny,
3) client processing of updates results in placement of ALL
updates in [serialized?] BGP input processing queue with ALL
other updates {m, 1..n}
*Input processing queue typically scheduled in round robin model
4) if n is sufficiently large, many of these updates may
very well still
On Mar 26, 2009, at 12:09 PM, Christopher Morrow wrote:
Today's WG meeting brought out some contentious discussion around this
presentation. The summary for a portion of the discussion was that
local optimizations in BGP mechanisms can often lead to system wide
systemic issues. One comment was
: grow-boun...@ietf.org [grow-boun...@ietf.org] On Behalf Of Danny
McPherson [da...@tcb.net]
Sent: Thursday, March 26, 2009 11:19 AM
To: Christopher Morrow
Cc: grow@ietf.org
Subject: [GROW] RR reflection to clients
On Mar 26, 2009, at 12:09 PM, Christopher Morrow wrote:
Today's WG meeting brought
Danny,
On Mar 26, 2009, at 2:30 PM, Danny McPherson wrote:
But it is relevant because it employs that function.
As I said below:
IF ACCEPT_OWN was a function of the RR, and the
routes were only reflected back to the client IF
that community was presented, I'd be perfectly
fine with it.
I
In the interest of historical accuracy:
On Mar 26, 2009, at 2:19 PM, Danny McPherson wrote:
In RFC 1966 the RRs did not reflect the route back the client
because the client didn't know it was a client, and for
incremental deployment it was required that the RRs not reflect
it back or a routing
On Mar 26, 2009, at 12:31 PM, Gargi Nalawade wrote:
Disclaimer : Im not taking a stance on whether it is good or bad for
an RR to advertise
a client's routes back to it. Want to make some observations on the
pros and cons that
go into the advertise or not-to-advertise decision.
If the RRs
On Mar 26, 2009, at 12:27 PM, Robert Raszuk wrote:
Please note that tt is perfectly feasible not to reflect back to the
client for one AFI/SAFI and still reflect back for other AFI/SAFIs.
Sure, one could do that, I don't think I said anything to
the contrary.
If your main point complains
On Mar 26, 2009, at 12:37 PM, Robert Raszuk wrote:
But in all of this we could still if there is a valid need reflect
back to the originating PE vpnv4 routes.
Yes, with the if there is a valid reason being the fulcrum.
-danny
___
GROW mailing
Danny,
I already pointed out that we have rt-constrain which based on pushing
RTs precisely addresses that problem in the context of VPNv4.
Note is works equally well for customer VPNs routes or for the Internet
routes in the VRFs.
Cheers,
R.
On Mar 26, 2009, at 12:27 PM, Robert Raszuk
On Mar 26, 2009, at 1:06 PM, John G. Scudder wrote:
I think the comment in quotes above demonstrates that at worst,
ACCEPT_OWN is tangential to your RR beef.
Unless implementations change their behavior to support this,
which is why I keep associating it. But yes, in general, I
agree.
John,
The fact is that some RFC 1966 (and pre RFC 1966) RR implementations
*did* reflect routes back to the client, and relied on the client to
suppress them, because of this:
A BGP speaker SHALL NOT install a route with itself as the next hop.
Isn't the below quote you cite talks about
On Mar 26, 2009, at 3:41 PM, Robert Raszuk wrote:
John,
The fact is that some RFC 1966 (and pre RFC 1966) RR implementations
*did* reflect routes back to the client, and relied on the client to
suppress them, because of this:
A BGP speaker SHALL NOT install a route with itself as the next
] On Behalf Of Danny
McPherson [da...@tcb.net]
Sent: Thursday, March 26, 2009 6:23 PM
To: Iljitsch van Beijnum
Cc: grow@ietf.org grow@ietf.org
Subject: Re: [GROW] RR reflection to clients
On Mar 26, 2009, at 4:24 PM, Iljitsch van Beijnum wrote:
Then again, this is only an issue for the prefixes
16 matches
Mail list logo
