Re: consistent policy != consistent announcements
add a peer P to your first example. if P peers with you at Point1 close to A's connection and again at a Point2 close to B's connection, then P will hear M's prefixes at Point1 as "R A M" and at Point2 as "R B M". but because the AS path length is equal, they'll still be able to do closest exit for M's prefixes. If that were happening, then we'd consisder the routes to be consistant, at least for shortest-exit purposes. What we are seeing, though, is "R A M" at Point1 and nothing at Point2, likely because Randy doesn't consider "R B M", received from one of his peers, to be a customer route. the tone of the "consistent route" policy is to keep one provider from having to carry packets cross-country in both directions: Full agreement. in this example P does not have to do that In your example, you are correct. But your example doesn't match the situation that Randy is describing. --Vince
On Thu, 13 Mar 1997, Vince Fuller wrote:
What we are seeing, though, is "R A M" at Point1 and nothing at Point2, likely because Randy doesn't consider "R B M", received from one of his peers, to be a customer route.
Ahh, now that's another story. That is something it is reasonable for a peer to object to. If you are going to advertise a route to a block at one peering point, you should be advertising a route to that block at all peering points and with the same AS length. It is not consistent policy to route to a customer through both another customer and a non-customer. That's what you can't do. Alternatively, if you do decide you must accept routes to a customer from a non-customer, you must consider those routes to be customer routes. Agree? Disagree? DS
The topology we are discussing: M / \ A B * Peer link | * | Customer link RRRRRRR Point1 * * Point2 VVVVVVV Vince Fuller said:
What we are seeing, though, is "R A M" at Point1 and nothing at Point2, likely because Randy doesn't consider "R B M", received from one of his peers, to be a customer route.
I suppose that R should change their policy, so that all routes to M get treated as customer routes, even if non-customers appear in the path between R and M. Then R would announce "R A M" to V at Point1, and would announce "R B M" to V at Point2, and V would be happy. But if A and B have other providers (P, Q), or if B peers with V, then V is likely to see some non-zero number of paths like "P A M", "P B M", "Q A M", "Q B M" or "B M" at or near Point2, and so V will not actually have to carry M's traffic all the way from Point2 to Point1. In this case, V should be happy despite R's failure to announce "R B M" at Point2. David Schwartz said:
It is not consistent policy to route to a customer through both another customer and a non-customer. That's what you can't do.
M might very well have requested R to consider the paths "R A M" and "R B M" to be equally good, and M doesn't care that A is a customer of R but B is not a customer of R. It's perfectly reasonable for R to accede to M's wishes in this regard.
Alternatively, if you do decide you must accept routes to a customer from a non-customer, you must consider those routes to be customer routes.
Agree. --apb (Alan Barrett)
M / \ A B * Peer link | * | Customer link RRRRRRR Point1 * * Point2 VVVVVVV
I suppose that R should change their policy, so that all routes to M get treated as customer routes, even if non-customers appear in the path between R and M.
How is R supposed to recognize some likely disjoint set of of what A announces to R as coming from M through B so as to recognize it as a customer prefix? Note that the paths from M to R through A and B can be longer than depicted and that M's address space may not be taken from R's, A's, or B's. randy
M / \ A B * Peer link | * | Customer link RRRRRRR Point1 * * Point2 VVVVVVV
How is R supposed to recognize some likely disjoint set of of what A announces to R as coming from M through B so as to recognize it as a customer prefix? Note that the paths from M to R through A and B can be longer than depicted and that M's address space may not be taken from R's, A's, or B's.
R could request A to provide it with a list of ASes for indirect customers behind A. (R probably already does that.) That would be sufficient information for R's router at the R/B interconnection to tag M's routes as customer routes. Essentially, when R's router at the R/B interconnection receives a route with path "B M", it could use the fact "M is an indirect customer" rather than "B is a non-customer" to tag the route appropriately. Alternatively, R could make the decision using prefixes rather than AS numbers, and could make it at the R/V[Point2] outbound announcement point rather than at the B/R inbound announcement point. --apb (Alan Barrett)
M / \ A B * Peer link | * | Customer link RRRRRRR Point1 * * Point2 VVVVVVV
[...] R could request A to provide it with a list of ASes for indirect customers behind A. (R probably already does that.) That would be sufficient information for R's router at the R/B interconnection to tag M's routes as customer routes. Essentially, when R's router at the R/B interconnection receives a route with path "B M", it could use the fact "M is an indirect customer" rather than "B is a non-customer" to tag the route appropriately.
Furthermore, R could provide sufficient incentive for A to provide a list of indirect customers by accepting only registered routes (or AS paths). (This should sound familiar.) E.g. (A) and (A M) routes would be accepted but all other (A *) would not be in this example. Alternately, R could audit routing tables at Point1 and Point2 from time to time, as I mentioned earlier. It ought to be rather simple to find routes which are in Point1 as "exportable" and Point 2 as "non-exportable", or vice-versa. The rest follows. Regards, --John
On Fri, 14 Mar 1997, Alan Barrett wrote:
The topology we are discussing:
M / \ A B * Peer link | * | Customer link RRRRRRR Point1 * * Point2 VVVVVVV
M might very well have requested R to consider the paths "R A M" and "R B M" to be equally good, and M doesn't care that A is a customer of R but B is not a customer of R. It's perfectly reasonable for R to accede to M's wishes in this regard.
M and A have no direct relationship in this picture so I don't see why M would be making requests to R. R should normally be preferring customer links to peer links. I think it's reasonable of V to demand that if R wishes to treat M in such an unusual way, R consider all of M's routes customer routes. Otherwise R cannot present a consistent picture to V because R's policy is not consistent (preferring a customer route on one side and a peer route on the other). DS
participants (5)
-
Alan Barrett -
David Schwartz -
John Scudder -
randy＠psg.com -
Vince Fuller