|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: RS transparency survey
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" <[email protected]> wrote
>### to "North American Network Operator's Group Mailing List"
>### <[email protected]> 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 <[email protected]> ]======================+
> | 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 ]==*/
|