On Fri, Nov 4, 2011 at 9:21 PM, Randy Bush <[email protected]> wrote: >> I suspect that it is a case of "accidental back-up transit via a >> peer". (I have seen this personally, where it was "malicious" instead >> of "accidental".) > > and i have seen it intentional and pre-agreed. life is not just simple > customer, peer, upstream. > > randy
I think many of us have seen "special" arrangements, either first-hand, or involving our customer(s) as one or more of the parties to such an arrangement. I think if we categorize neighbors as "customer, transit, peer, special", that is still useful. Here's why: - as a general rule, "special" is negotiated between parties (two, or more-than-two, doesn't matter) - it is fine to have "customer" include "customer's customer et al", and even "customer's special neighbor" iff the customer wants - except when all the parties are part of a single "special" arrangements, "special" is non-transitive. - there can be many pools of "special", even with overlapping membership - pretty much by definition, "special" pools are contiguous - outside of that contiguous area, the boundary to that special area can be treated as a normal AS (by non-participants) - in fact, special pools could almost be treated like an AS Confederation The last two points basically say, if we ignore the goings-on within such a region, applying the simple rules (customer/transit/peer) are sufficient to prevent leaks crossing any boundary other than between region members. Take as a whole, this is more than sufficient benefit to employ, so long as it is possible for members of such regions to "remove the safeties". The exposure is strictly intra-region at that point, which is a lot better than it is today. Mechanisms for preventing route leaks don't have to necessarily be perfect to be useful, IMHO. Keeping the mechanics themselves simple, and the semantics clear, is the second most important part. Sensible defaults is the most important. Third is allowing network admins to disable them as needed. Kind of analogous to the three laws of robotics, now that I think about it... Brian _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
