(aside: ugh, your mail client doesn't wrap lines properly... or gmail isn't re-wrapping properly)
On Wed, Nov 7, 2012 at 2:02 PM, Danny McPherson <[email protected]> wrote: > > On Nov 7, 2012, at 1:42 PM, Christopher Morrow wrote: > >> The draft you reference up-thread isn't actually helpful, it doesn't >> show how to know that the leak is a leak and not another backup path >> coming to light for other reasons in the system. > > The fact that even folks here were confused where RPKI/BGPSEC would be > helpful and would NOT highlights the disconnect about what problems they're > trying to solve for us in SIDR. The draft was written as an attempt to help > minimize confusion and it may have missed the mark but I'm told some have > found it helpful. > > How about this: "We need a way to show how to know that the leak is a > leak and not another backup path coming to light for other reasons in the > system" (that might sound familiar :-). The solution doesn't presuppose > it's codified in BGP on the wire, and shouldn't preclude simply improving > existing tooling and systems, of which many operators already employ > (e.g., IRRs and static [persistent] AS path and prefix lists). sure, with resource certification in place (rpki?) you can go fix up irr data and go to town. that'd solve the problem, provided people actually filter. evidence suggests they don't... and won't no matter how 'simple' it seems. could we have something in the protocol to do this for us as well? for the cases of the operators who don't filter or won't filter or can't filter or ? could we have something in the protocol to tell a remote asn if this is a leak or not? not putting it in bgp is ok, but it seems like that limits things a bit, no? > With the hyper-focus on publication of standard-based RPKI/BGPSEC in > this WG I do concur that it's likely not the right place. However, I would > note > that if I can solve most of the real problems above without BGP changes or > any new systems then I may not need RPKI/BGPSEC work at all. That you'd need rpki, or resource-certification, which is all rpki is... right? I don't think any 'make better filters' solution works without resource certification. > said, I would hate to see SIDR be Standards-Track and "legislated" and not > solve problems as fundamental as this, while the lower hanging fruit is > steam-rolled by efforts here. -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
