Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt

From: Joel jaeggli <[email-masked]>
Date: Mon, 12 Mar 2012 23:42:13 -0700

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:[email-masked]?subject=help>
> List-id: Secure Interdomain Routing <sidr.ietf.org>
> List-post: <mailto:[email-masked]>
> List-subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:[email-masked]?subject=subscribe>
> List-unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:[email-masked]?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