consistent policy != consistent announcements

Mailman List Mirror (Read Only)
1

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

2

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

3

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)

4

                    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

5

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

6

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