Subject: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]

From: Pekka Savola <[email-masked]>
Date: Mon, 3 May 2004 22:23:25 +0300 (EEST)

Hi,

Should draft-ietf-idr-rfc2796bis-00.txt or some other document also
make RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh
routing") historic?

IDRP is at least extict, but are BGP route servers useful for the
replacement of a full mesh (anymore/at all)?

----------------------------
[..........]
>  - food for thought: should we kill two birds in one stone, and also 
>    declare RFC1863 ("A BGP/IDRP Route Server alternative to a full 
>    mesh routing") historic?  Is that useful anymore?

This is a good question. May I suggest you'll bring it up to the
IDR mailing list after we'll finish the WG Last Call on this document
(as it deserves discussion on its own).

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 3 May 2004 16:21:01 -0400

> make RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh

IMO, yes.

> replacement of a full mesh (anymore/at all)?

Route servers are still occasionally used by people for various
purposes, specifically for certain NAPs, but are largely a dead issue.
As best I know, RFC1863 does not have support by any current vendors
and never received wide deployment even when route servers were in vogue.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 3 May 2004 16:21:01 -0400

IMO, yes.

-- 
Jeff Haas 
NextHop Technologies

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 03 May 2004 14:48:34 -0700

IMHO, no.

I think Route Servers are widely used in Internet Exchange points. The 
fact that they did not get a wide vendor support is bug not a feature. 
Note that some vendors can do RS functionality today, but few use a $$$ 
box as a replacement for free soft running on linux which can do just 
fine the same thing :).

There are very new evolving applications (example CSC in 2547) which can 
not scale without vpnv4 multi context route servers. So if anything 
there is a new work required to extend/update 1863 rather then move it 
to historic status.

I am sure folks from Merit, RSNG or other RS creators can provide more 
comments here.

Rgs,
R.

 > Jeffrey Haas wrote:

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 03 May 2004 14:48:34 -0700

IMHO, no.

Rgs,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 3 May 2004 23:37:45 -0400

Robert,

1. I don't presume to even *think* about speaking for Merit.
2. That said, I was one of the last of the operators of the RSng project. :-)

On Mon, May 03, 2004 at 02:48:34PM -0700, Robert Raszuk wrote:
> I think Route Servers are widely used in Internet Exchange points.

Towards the end of the RSng project, the route servers were redeployed
as a mechanism by which to concentrate the collection of routing 
statistics for various projects.  The RIS project that RIPE is currently
doing serves many of the same purposes and there are others.

I will honestly say that by the time that I had left RSng that there
were maybe one or two total peers that were using RSD via RSng for
purposes of receiving routing data for forwarding purposes.

All of this said, there are other small exchanges that are said to
be deploying route servers, but it sounds like these are small regionals.
This observation is strictly based on a few random peering BOFs at
past NANOGs, the most recent one that I remember being the last one
in Phoenix.

> The 

Please note that RFC 1863 doesn't so much define a route server as
it does a route-reflector style mechanism for route servers.  This is
the bit that didn't get wide deployment.

> there is a new work required to extend/update 1863 rather then move it 

IMO, 1863 is a bit more complicated than what we would want these
days given modern route reflection techniques.  If a need exists to
allow multiple views to be passed around in BGP there are better ways
to go about it.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 3 May 2004 23:37:45 -0400

Robert,

-- 
Jeff Haas 
NextHop Technologies

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 4 May 2004 11:49:29 -0400

Jeff makes a very good point that bears emphasis:

>the bit that didn't get wide deployment.

For those who haven't gone and looked at 1863 before joining the 
conversation, here is the abstract.  In short, as Jeff has been 
saying, 1863 is an alternative to route reflectors:

    This document describes the use and detailed design of Route Servers
    for dissemination of routing information among BGP/IDRP speaking
    routers.

    The intention of the proposed technique is to reduce overhead and
    management complexity of maintaining numerous direct BGP/IDRP
    sessions which otherwise might be required or desired among routers
    within a single routing domain as well as among routers in different
    domains that are connected to a common switched fabric (e.g. an ATM
    cloud).

While a discussion about other things that are also called "route 
servers" may be interesting, I don't think it's germane to Pekka's 
original question which was whether RFC 1863 in specific should be 
moved to "historical."

I think it should be.  As far as I know there are no extant 
implementations and it's never been (widely? at all?) deployed.  That 
fits pretty well with my understanding of "historical."

I think a good reason not to move it to historical would be if the 
1863 mechanisms in specific are needed/wanted for some current use. 
But discussions of any old thing that happens to be called a "route 
server" misses the point of the original question.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 4 May 2004 11:49:29 -0400

--John

---

From: Paul Jakma <[email-masked]>
Date: Wed, 5 May 2004 12:46:30 +0100 (IST)

> make RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh

Is RFC1863 not historic anyway by virtue of utter lack of support?
TTBOMK there are no widely deployed BGP implementations with support
for client side of 1863, nor is there ever likely to be AFAICT.

> replacement of a full mesh (anymore/at all)?

Chicken and egg possibly. There is no good deployable route-server
solution other than the path-selecting type, which requires knowledge
of client policy and hence is operationally expensive for, eg, IXes
with many clients with diverse policy. 

That doesnt mean there would not be interest in future in some kind 
of better BGP route-server or even just 'connection concentrator' 
solution.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
	warning: do not ever send email to [email-masked]
Fortune:
It'll be a nice world if they ever get it finished.

---

From: Paul Jakma <[email-masked]>
Date: Wed, 5 May 2004 12:46:30 +0100 (IST)

regards,