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

From: Paul Jakma <[email-masked]>
Date: Fri, 3 Oct 2003 13:49:30 +0100 (IST)

Hi,

I'm wondering about RFC1863 and how widely it is supported. In 
particular support for the client-mode aspects of the RFC, in 
particular the 2 following details:

- 1863 specifies that a Route-Server (RS) can withdraw a specific 
announcement by sending the full announcement to the client but with 
the next-hop address in the next-hop attribute set to one of the 
addresses of the client.

- presumably the RS-client can use the Advertiser attribute (which an
RFC1863 RS should include in updates), or any other (if included), to
discriminate between which announcements for that prefix the
withdrawal was referring to.

How many BGP implementations support these 2 things? Ie recognition 
of advertiser attribute and of next-hop-self withdrawal? (and can 
they properly discriminate withdrawals?)

It seems 1863 is the only thing out there for route-serving which 
does not require policy to be defined on the RS itself. However, i 
can find no mention of support for this RFC in the documentation of 
major BGP implementations, other than in the RFC citations.

Thanks in advance.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
	warning: do not ever send email to [email-masked]
Fortune:
It's a naive, domestic operating system without any breeding, but I
think you'll be amused by its presumption.

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

---

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.

---

From: Ian Campbell <[email-masked]>
Date: Mon, 6 Oct 2003 15:33:37 +0100

Thanks for that Manav,
	Very interesting, shows I should check this list a little more
often! I can see how this could be useful for creation of route server
clusters (which are calculating best path for clients) as well as the
original intended application. The reason for clusters in our case is to
provide a way of scaling numbers of peers up by distributing CPU resources
(for best path calculation), as well as to a limited extent memory
resources. 

I can also see how our present software might be modified to allow peers
greater control of their own policy by using the draft attributes as you
intend (not too much of a jump!). Has there been any other interest shown so
far?

Regards,

Ian Campbell
Band-X Ltd.

-----Original Message-----
From: Manav Bhatia [mailto:[email-masked]]
Sent: 06 October 2003 14:02
To: Ian Campbell
Cc: [email-masked]
Subject: Re: [Idr] rfc1863 - route-server rfc support

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: 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)

---

From: Ian Campbell <[email-masked]>
Date: Tue, 7 Oct 2003 16:24:21 +0100

Of course there are problems a bit like this on route server based ethernet
based networks as well ;) Perhaps the most important one that I have come
across so far is the disconnection of ARP and switch MAC address tables when
asymmetric traffic flows are created - which is common enough in BGP. This
can cause traffic to be broadcast to all ports.

On the redundancy / co-ordination question. We currently dual session
everything in our exchange structure and have no links between our redundant
route server pairs - this of course means sending everything to client peers
twice. But IMHO lack of memory of peers is much less of a problem than it
may have been in the past. Most people have sufficient resources on their
boxes.

Regards,

Ian Campbell
Band-X Ltd.

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

On Tue, Oct 07, 2003 at 03:41:36PM +0100, Paul Jakma wrote:
> eek yes. though, could one not regard this problem as one of an 
> IGP / network architecture nature. (make sure there are multiple, 
> robust paths between peering addresses). A lot of IXes these days 
> seem to be 100 or GigE based anyway - not ATM.

The issue is a more general one.  If you receive a route from someone
else and they are not in the forwarding path, you are much less
sure that the route will not be a blackhole.  This is true even of
several third-party nexthop scnenarios.

Admittedly, most of this was caused by ATM issues and a broadcast
media would be less prone to the problem.

> Yeah, co-ordination between route-servers would be a killer. So just 
> dont do it is what I'd say. Let the client cope with and discard 
> duplicates. :)

Depends on the problem you are wanting to solve.  You want all the
route instances, others want to proxy their policy.

-- 
Jeff Haas 
NextHop Technologies

---

From: Ian Campbell <[email-masked]>
Date: Tue, 7 Oct 2003 16:24:21 +0100

Regards,

Ian Campbell
Band-X Ltd.

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

-- 
Jeff Haas 
NextHop Technologies