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

From: Tulip Rasputin <[email-masked]>
Date: Tue, 4 May 2004 07:48:49 -0400 (EDT)

Jeff,

[..] 
> 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.

I would not agree to this! There is this european internet exchange association (euro-ix) where
europe's leading ISPs connect to permit the exchange of network information. I am aware of most of
them using route servers (though not the ones like defined in 1863).

> > The 
> > fact that they did not get a wide vendor support is bug not a feature. 
> 
> 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.

Am sure IXPs would love to have better ways to implement route servers. If there are any IXPs
here, they could probably second me!

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

Like how?

Rasputin.

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 4 May 2004 10:51:43 -0400

> them using route servers (though not the ones like defined in 1863).

I was unable to find any reference to this on euro-ix.net.
Are they actually using route servers for routing proxy (views) or
are they simply providing a route collector/looking glass?

I would suspect that it is the latter.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 May 2004 17:58:11 +0300 (EEST)

> them using route servers (though not the ones like defined in 1863).

Route collectors or route servers used for other debugging purposes 
are an entirely different thing from route servers used to replace 
iBGP mesh, right?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 4 May 2004 10:51:43 -0400

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 May 2004 17:58:11 +0300 (EEST)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 4 May 2004 17:14:05 +0200

> them using route servers (though not the ones like defined in 1863).

As the current chair of Euro-IX...

yes there is a lot of interest in route servers and I think the two 
most widely used are at two out of the four largest IXPs in Europe.

> here, they could probably second me!

I think 'it depends'. I don't think IXPs per se care, the customers of 
the IXPs do and the IXPs try to serve them as best as possible. And I 
do think there is need for it, and also a need for updated 
documentation.

- - kurtis -

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 4 May 2004 11:18:30 -0400

> are an entirely different thing from route servers used to replace 

And an even stronger distinction:

If you're going to do iBGP mesh, a route reflector is usually a better
solution.

Route servers are generally designed to serve as route proxies to
create view-based policy.  At the least, this is the design for RSd.

-- 
Jeff Haas 
NextHop Technologies

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 4 May 2004 17:14:05 +0200

- - kurtis -

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 4 May 2004 11:18:30 -0400

-- 
Jeff Haas 
NextHop Technologies

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 4 May 2004 14:04:43 -0400

>them using route servers (though not the ones like defined in 1863).

Does Euro-IX have any documentation on the route servers it does use?

It sounds to me as if 1863 itself may need to be made Historic, but 
there may be a need for several new, more focused documents:

     1. Use of route servers for information collection.  This might actually
        be a subset of 1863, but perhaps with updates or crossreferences to
        such things as the new data collection communities.

     2. BCP for production use such as Euro-IX.

     3. Possibly something informational about L3 exchanges where
        an exchange-operated router is there primarily for routing
        information exchange. ISTR a Cisco workshop describing such
        techniques as a first step to high-capacity L2 exchanges, and
        I've seen this done both in small North American exchanges and
        reports on Asia-Pacific initial exchanges.

As an aside, this does get into the increasingly blurred area about 
how much the IETF RFC process is appropriate for principally 
operational documents. There have been a number of 
suggestions/volunteers that NANOG might provide a document function, 
but it seems reasonably clear that the Merit people don't have room 
on their plate for this.  Whether Euro-IX, RIPE, or RIPE-NCC are 
possible sponsors for operational documents, or if there needs to be 
a specific group spun off for this, is another question. Obviously, 
IDR alone can't answer that question, but I mention it here because 
many relevant people see this discussion.

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 4 May 2004 14:13:40 -0400

>create view-based policy.  At the least, this is the design for RSd.

I hope this isn't getting too far afield, but let me share a concept 
that I use in teaching, and, to some extent, we considered in the 
BMWG BGP convergence work.  This idea grew out of the Internet Growth 
panel that Sue, Frank and I did at the Stockholm ISOC.

We have real-world problems with the scalability of actual BGP 
routers (as distinct from the scalability of the overall routing 
system).  One of the limiting factors is the number of peering 
sessions per box.

I argue that we have several techniques for improving scaling by 
reducing the number of sessions.  Route reflection is an obvious 
technique for iBGP scalability.  I tend to think of confederations in 
two ways:  an adjunct to iBGP scalability, but also a way to 
implement finer-grained policies.  I've tended to use RR's for 
service provider implementations, but more often have used 
confederations for enterprises with complex multihoming and internal 
flow policies.

In my experience, newbies better understand all of the scalability 
methods if one adds the idea of the "classic" or "historic" RsD-style 
route server as an _e_BGP scalability technique. SO to come back to 
Jeff's comment, a route server replaces/reduces full eBGP mesh at 
exchange points.

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 4 May 2004 14:04:43 -0400

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 4 May 2004 14:13:40 -0400

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 4 May 2004 14:52:18 -0400

Note: I haven't been doing this stuff anywhere near as long as some
of the members of this forum.  This said, here is my opinion based
on some second and third hand stories.

> Jeff's comment, a route server replaces/reduces full eBGP mesh at 

In the beginning of the Internet, route servers served a useful role
in reducing the routing table traffic load on the hosts at an exchange
point to levels within the capacity available to the boxes at the time.

Apparently, the window of time where this was necessary was 
"reasonably small".  

When routers were deployed that could handle the number of eBGP views
at a typical exchange point, the route servers were only useful 
(for route reduction purposes) for protecting smaller boxes.  I think
it is likely today that most exchange points will typically find boxes
deployed that are capable of handling the relevant full or partial
mesh that the business model that XP operates under can use.

The route servers often caused more problems than they were worth in
environments where reachability to the route server didn't imply
reachability to the actual router advertising the routes.  

In the era when boxes are thought to be capable of handling a pretty
serious routing load, the route server model excels at one thing - 
proxying policy.  "I ask for X set of destinations, I only want to
send you Y destinations".  Configure it in a database, run RtConfig
and let it rip.

Nothing stops a bgp speaker from doing similar things with RtConfig
at their edges.  However, when you start doing it for a reasonable
number of peers, your policy tends to get huge.  Some boxes deal
with huge policy better than others.

If you wish to contemplate how route servers scale, remember that
a route server is much the same case as a 2547 PE router.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 4 May 2004 14:52:18 -0400

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 04 May 2004 15:12:11 -0400

> Jeff's comment, a route server replaces/reduces full eBGP mesh at 

We need more di-lithium crystals captain.  Or whatever they make those
processors out of these days.

Multiple processors responsible for the adjacency processing has
helped the "too many peers" problem in some routers.

So what does any of this have to do with RFC1863?  John Scudder
summarized things quite well.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 04 May 2004 15:12:11 -0400

Curtis

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 5 May 2004 14:17:55 +0200

> Does Euro-IX have any documentation on the route servers it does use?

Euro-IX is an association of exchange points. Euro-IX does not operate 
either route servers or exchage points.

>        such things as the new data collection communities.

Agreed.

>     2. BCP for production use such as Euro-IX.

Sitting in the EIX meeting at the current RIPE meeting, I will bring 
this up. A lot of the Euro-IX memebers that use route-servers are 
there. I will drop the idea in here to see if there is any interest.

> but it seems reasonably clear that the Merit people don't have room on 
> their plate for this.  Whether Euro-IX, RIPE, or RIPE-NCC are possible 
> sponsors for operational documents, or if there needs to be a specific 
> group spun off for this, is another question. Obviously, IDR alone 
> can't answer that question, but I mention it here because many 
> relevant people see this discussion.

The EIX WG at RIPE is in the process of updating the "switch wishlist" 
and Euro-IX is working on a BCP. Perhaps those are better forums for 
BCPs on route servers.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 5 May 2004 14:17:55 +0200

Agreed.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 5 May 2004 14:24:15 +0200

(I think we are getting off-topic here)

> mesh that the business model that XP operates under can use.

I think route-servers are in use at IXPs simply to simplify the process 
of setting up peers. If you look look at AMS-IX/Linx type of exchanges 
with 150-200 members, and you have an open peering policy, you will 
have quite a lot of work with just configuring the peers.

But, maybe this is more a topic for grow or RIPE / Nanog etc.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 5 May 2004 14:24:15 +0200

- - kurtis -