chris@UU.NET ("Christopher L. Morrow") writes:
There are many cases in which the backbone can't determine the 'proper' traffic an edge is sending in.
i'd like to discuss these, or see them discussed. networks have edges, even if some networks are "edge networks" and some are "backbone networks." bcp38 talks about various kinds of "loose" rpf, for example not accepting a source for which there's no corresponding nondefault route.
Not to mention the problems of filtering on an edge device with 100's or 1000's of interfaces. The proper and simple place for this filtering is as close to the end device as possible. Backbones just aren't made to filter traffic, edge networks are.
so, the problem is transitive. you might have a multihomed customer whose network spans some of the same peerography as yours, and if you both use hot potato there will be path assymetry, such that your route back to a source might be through pop A while they deliver that source's traffic to you at pop B. your only recourse is to get them to filter at their edge, which you hope is less ambiguous than yours. but they might have the same situation with their downstream. and you're not requiring them to do edge filtering as a contract/peering term, nor are you requiring them to require their downstreams to do so. this means the problem goes from "transitive" to "laundered" in about one AS hop or so. i don't consider this a healthy situation, and i'd like to hear you list the kinds of rpf you know of and why none can be used on a "backbone". -- Paul Vixie