Jake's comments on RS transparency relate directly to a discussion in the Routing Policy Specification working group. I would hope that all interested parties define a consistent approach to the problem.

From my rough notes for RPS:

There was extensive discussion of mechanisms to split route advertisements among specific routers rather than an AS-wide basis. Sue Hare described to problem of wanting to send half the traffic on one router, and half the traffic on another. It was observed that such a policy should be stored in registries, but the current language does not describe this policy. There was discussion whether registries should stay at the AS level, or go down to the interas-in/out level. It was also observed that traffic policies may be outside the scope of the RPS WG. For the case AS1-------+ | | AS4------>AS2 (RS) Cengiz proposed adding a "via" option to the AS-IN statement, as: as-in: from AS1 via AS4 5 accept AS1 Where AS4 is the route server, it might have full routes where true AS1 does not. What is difference between accept from AS4 (the RS) and accept from AS1 via AS4? It was suggested this might be a local preference This allows specification of the source of the route advertisement. Allows taking from RS rather than drectly peering. Route server does not insert himself into path where peering normally would do so. Sue cited a case where half the policies are in the RS and half in the originating [transit] AS BGP speaker. This raised a more basic question: is a route server transparent? Filtering down to router is more specific, but AS filtering provides a higher level of abstraction. Sue prefers to support an AS filtering need Abecause that has been seen with real customers while router solution has not been seen. The discussion did not reach a complete conclusion. Several emails were sent to the group between the two RPS WG meetings: Jerry Scharf said, There was a discussion that happened after the meeting that made things much clearer to me, and might help others as well. We have mixed two things together. One is what routes are seen in the receiving AS, which is the routing policy. The second is whether the route server will send those routes along. The second one can not be cleanly expressed by policy, since even to the receiving AS this can not be seen in any table (only the BGP session byte counts would be different.) Cengiz responded with the model AS2 AS1 | | -|---|-----|- | AS4 While aut-num: AS2 as-in: from AS1 via AS4 accept AS1 can be written as as-in: from AS4 accept AS1 AND <^AS4 AS1> (assuming we make RS's AS visible in this fashion), the following can not: aut-num: AS1 as-out: to AS2 via AS4 announce AS1 (as-out: to AS4 announce AS1 does not tell who the route server can pass AS1's routes). Anyway, I will look into alternate ways of doing this. Perhaps a routeserver specific solution is the best.

### On Wed, 06 Mar 1996 22:01:52 -0500, "Jake Khuon" <khuon@Merit.Net> wrote ### to "North American Network Operator's Group Mailing List" ### <nanog@Merit.Net> concerning "RS transparency survey":

JK> Some of you may have noticed that the RSes have stopped injecting their ASN JK> into the ASPath expression. This was a feature I have just recently turned JK> on to meet the original design goals of the project. As per specification, JK> the RSes were to be transparent in its operation. JK> JK> I realise I may have erred by doing this without asking the community first. JK> Therefore, I would like to take a poll as to what everyone prefers. I can JK> turn the ASN injection back on in a peer-by-peer basis if necessary. I JK> sincerely apologise if this has caused any confusions and/or problems.

I will be rolling back transparency status of the RS to all peers with exception of those who have responded saying they like not seeing the RS's AS in the ASPath. I will turn on transparency in the future for anyone who wishes it. Simply send me a request.

Additionally, I've updated the peering request template (http://www.ra.net/.peering.template.html) allowing you to specify whether or not you wish to have the RS peer transparently.

-- /*===================[ Jake Khuon <khuon@Merit.Net> ]======================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | VOX: (313) 763-4907 FAX: (313) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/