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). 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 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. -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
