Subject: RE: [Idr] rfc1863 - route-server rfc support

From: Ian Campbell <[email-masked]>
Date: Mon, 6 Oct 2003 09:45:43 +0100

Hello Paul,
	Saw this thread and couldn't resist replying to it as I have been
down this road already!

Using the standard protocol there is no way to selectively withdraw a
prefix, as there is no way to associate a withdraw message with a set of
attributes. That is even if you could get the end implementation to not
overwrite the current attribute information for a prefix (from a particular
peer) on update. 

The only way to achieve something like this would be to use something like
the RFC2547 standard for VPNs and change it to carry an appropriate
discriminator for the particular update/withdraw combination. I have
actually looked at this for our route server implementation as way of
generating a clustering solution for route server systems. 

However to talk to a standard implementation the route server really needs
to calculate path selection on its client peers behalf. This is exactly what
our route server implementation does, in fact our implementation has a
separate RIB for each connected peer so as to allow for complete
flexibility.

I hope this helps.

Regards,

Ian Campbell
Band-X Ltd.

-----Original Message-----
From: Paul Jakma [mailto:[email-masked]]
Sent: 06 October 2003 01:55
To: Manav Bhatia
Cc: Inter-Domain Routing List
Subject: Re: [Idr] rfc1863 - route-server rfc support

Hi Manav,

On Fri, 3 Oct 2003, Manav Bhatia wrote:

> Hi Paul,
> 
> There are severe scaling problems with RFC 1863 and hence you wont find
> many implementations supporting this (Path Attributes 12 and 13).

Ah, ok. Out of curiosity: what are the scaling problems?

Then my next question is:

- is there any portable way to announce a prefix multiple times to a 
peer and be able to withdraw a /specific/ announcement? (implicit 
withdraw?)

Essentially, is it possible to create a transparent route-server 
which does /not/ have to do path-selection on behalf of client ebgp 
peers (which requires the route-server to be configured with all 
client peers policies). Ie a route-server which simply passes on 
all announcements received to all 'client' peers? Passing on the 
announcements of prefixes isnt a problem, but i'm not sure how an RS 
would discriminate withrawals (without withdrawing a prefix then 
reannouncing remaining valid announcements - but that is not feasible 
because of stability).

thanks in advance,

> Regards,
> Manav

PS: I'm not receiving mail from this list, though I thought I had 
subscribed.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
	warning: do not ever send email to [email-masked]
Fortune:
The difference between a career and a job is about 20 hours a week.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 06 Oct 2003 18:32:08 +0530

Ian,

> overwrite the current attribute information for a prefix (from a
particular

You can do this with
http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-00.txt

To see how it may do that refer to
http://www.ietf.org/proceedings/03jul/slides/idr-4/index.html

http://www.ietf.org/proceedings/03jul/slides/idr-4/sld13.HTM
shows how one may selectively withdraw a prefix associated with a set of
Path Attributes.

Regards,
Manav

[clipped]

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 06 Oct 2003 18:32:08 +0530

Ian,

You can do this with

Regards,
Manav

[clipped]