sorry I normally follow sidr on the archive... > To: sidr wg list <sidr at ietf.org> > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt > From: Randy Bush <randy at psg.com> > Date: Tue, 13 Mar 2012 08:35:57 +0900 > Delivered-to: sidr at ietfa.amsl.com > In-reply-to: <20120312232702.17194.34028.idtracker at ietfa.amsl.com> > List-archive: <http://www.ietf.org/mail-archive/web/sidr> > List-help: <mailto:sidr-requ...@ietf.org?subject=help> > List-id: Secure Interdomain Routing <sidr.ietf.org> > List-post: <mailto:sidr@ietf.org> > List-subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, > <mailto:sidr-requ...@ietf.org?subject=subscribe> > List-unsubscribe: <https://www.ietf.org/mailman/options/sidr>, > <mailto:sidr-requ...@ietf.org?subject=unsubscribe> > References: <20120312232702.17194.34028.idtracker at ietfa.amsl.com> > User-agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) > i have two serious disagreements with this draft. > > o a prefix against which validation has not been run (no validation at > all or some knob turned off) should not be marked Valid. that would > be a lie. it should be marked NotFound.
So this this seems to be a split between how we intend to treat unvalidated prefixes and their state. E.G today we'd accept them because the alternative is a rather empty table. tomorrow maybe not. not marking prefixes valid unless they've been validated seems like the least surprise approach. > o routes learned by ibgp and routes originated on this router should > be checked and marked. i do not want to hear from a neighboring noc > that i am originating or propagating garbage. the ibgp case is > particularly egregious in partial deployment, where my ibgp peer may > not be validating at all. not all IBGP sources are under the same domain of control in a big AS, so just as I apply extensive policy controls to routes that I accept from a datacenter for example I imagine myself validating routes that I revived from an ibgp peer at some point if, perhaps not anytime soon. In any event I imagine what gets validated being a product of policy rather than source. > some vendor engs do not seem to realize how extensively ops apply policy > to ibgp. the example i like is that we are driven to it by droids who > sell both local peering and global transit to the same bgp peer. maz > also gave a nice example in a workshop we did here a few years back > <http://www.attn.jp/maz/p/c/bgpworkshop200904/>. > > randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
