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

From: Ian Campbell <[email-masked]>
Date: Tue, 7 Oct 2003 11:44:19 +0100

Hello Paul,
	I would imagine in operation a route server like the one you have
defined would properly operate with in an environment where policy is held
in a mix of locations, that is some broad policy on the route server and
some more detailed policy for traffic control on the client router(s). This
would allow the expression of the kind of configurations that are used in
public IX today where some parties would not want certain parties to receive
their routes - usually for commercial reasons. Any solution would need to be
able to fully replicate all the features of direct BGP session based peering
as well as offer the advantages of route servers.

I have to confess to not having looked at RFC1863 since starting with the
development of our route server... however I had a bit more of a look at it
when this thread came up. However, I think that Manav's draft offers exactly
enough of a solution to what you/we are looking for; certainly it could be
added to our implementation without too much trouble to allow a pure mode
(where all announcements are sent) like you suggest or the mixed mode (some
announcements sent based on broad policy) mentioned above.

Regards,

Ian Campbell
Band-X Ltd.

-----Original Message-----
From: Paul Jakma [mailto:[email-masked]]
Sent: 07 October 2003 10:52
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: [Idr] rfc1863 - route-server rfc support

On Mon, 6 Oct 2003, Jeffrey Haas wrote:

> A route-server is generally meant to be a proxy-routing
> concentrator.

Well, there's 2 types, AIUI:

- 'policy aware/path selecting': ie does path-selection on behalf of
the client (in accordance with its policies). This tends to require
keeping a seperate table for each client. Ie policy must be applied
/before/ path selection.

(to apply policy afterwards may mean the path-selected is not 
applicable due to client policy. however, there may be other paths 
which /are/ applicable.)

This type of RS needs no modifications to client BGP implementations. 
The RS never needs to have more than announcement outstanding to a 
client at any one time. (ie to the client the RS is a normal eBGP 
peer).

- 'announcement reflector': One that passes on all announcements to 
peers without doing any kind of best-path selection, possibly, but 
not neccesarily applying policy before sendign announcement to the 
client. 

The latter is what I understand 1863 to provide. However, given the
impossiblity of discriminating between multiple previous
announcements when withdrawing a prefix in BGP, the latter is not
possible without some additional mechanisms (eg the NEXT_HOP set to
client address mechanism + ADVERTISER attribute described in 1863).

AIUI anyway. :)

> If you aren't having it carry out your policy for you, you're just
> looking for something that can send multiple route instances. (See
> other e-mails on this thread for examples.)

Yes, but its not possible with how BGP implementations stand today.

> Based on my conversations with others, I believe there was one or
> two implementations of 1863, but it was not widely deployed.

Shame. It seems an OK RFC. (except for the LIST message and the
RS-Cluster stuff - which i think would be impossible to implement
reliably.  Never mind unneccessary - clients could just put up with
receiving the same announcement from multiple RSes).

> The most widely deployed route server environment to my knowledge
> was Merit's RSng project (http://www.rsng.net for some archives)
> and its predecessor project (which I have no documentation or
> history for).

Indeed, AFAICT, RSng is of the 'policy aware' or 'path selecting' 
type.

However, I believe many operators would like to see a mechanism that 
allows an RS to be implemented that does /not/ require the RS to be 
policy-aware. Ie because of the overhead of keeping RSes configured 
with client policy, and, possibly more important, because policy can 
be commercially sensitive and many operators of potential RS-client 
peers do not wish to have to register their policy with a 3rd party 
(eg an IX operating an RS).

So it would be nice to have some means to allow implementing an RS
that was 'dumb' and simply reflected on /all/ announcements and
withdrawals.

I'll have a look at Manav's ECMP_NEXT_HOP draft and offer comment.

thanks!

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
	warning: do not ever send email to [email-masked]
Fortune:
Running Windows on a Pentium is like having a brand new Porsche but only
be able to drive backwards with the handbrake on.
(Unknown source)

_______________________________________________
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: Wed, 08 Oct 2003 17:37:04 +0530

Hi Badri,

It seems that people are now comfortable with my draft and are looking at
it for solving some of their existing problems.

Things are beginning to finally take shape. Francious and Gargi (both from
Cisco) and myself are working on a unified draft to come out with a
combined solution. It should be out by early next year. Very few things
remain which need to be sorted out.

Just to keep you in loop.

Manav

----- Original Message ----- 
From: "Ian Campbell" <[email-masked]>
To: "'Paul Jakma'" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 07, 2003 4:14 PM
Subject: RE: [Idr] rfc1863 - route-server rfc support

> defined would properly operate with in an environment where policy is
held

[clipped]

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 08 Oct 2003 17:37:04 +0530

Hi Badri,

Manav

----- Original Message ----- 
From: "Ian Campbell" <[email-masked]>
To: "'Paul Jakma'" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 07, 2003 4:14 PM
Subject: RE: [Idr] rfc1863 - route-server rfc support

[clipped]

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 08 Oct 2003 18:59:15 +0530

Hi,

Apologies. This mail wasn't intended for the IDR WG.

Regards,
Manav

----- Original Message ----- 
From: "Manav Bhatia" <[email-masked]>
To: "Ian Campbell" <[email-masked]>; "'Paul Jakma'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 08, 2003 5:37 PM
Subject: Re: [Idr] rfc1863 - route-server rfc support

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 08 Oct 2003 18:59:15 +0530

Hi,

Regards,
Manav

----- Original Message ----- 
From: "Manav Bhatia" <[email-masked]>
To: "Ian Campbell" <[email-masked]>; "'Paul Jakma'"
<[email-masked]>
Cc: <[email-masked]>