Hi Randy,
Thanks for participating in that discussion with me earlier.
My feeling now is that I'd rather not see RPKI-related standards
cluttered with this. If that means that the 10.0.0.0/8 folks have
some homework to do prior to publishing a ROA for 10.0.0.0/8 itself,
then so be it.
(While this topic did come up just recently in another venue, I have
not been requesting it or even wishing it were so -- just
acknowledging that some of us providers will have some work to do.)
Thanks.
Jay B.
Randy Bush writes:
> jay, i sent you this a couple of months back and you said to wait. but
> i hear you have raised it again, so here it is, finally leaving my emacs
> edit buffer
>
> randy
>
> ---
>
> this is absolutely not for now, but for the next generation of the
> protocols once we have some experience under our belts. i.e. something
> to think about to keep you from being bored.
>
> an ops friend said that they have 10.0.0.0/8 with a lot of bgp customers
> below it. it will take a long time to get roas out for those customers.
> in the meantime they would like to protect 10.0.0.0/8 and maybe the two
> /9s below it.
>
> i am not sure i really support this idea as it defeats the basic
> protections against hole punching which we want. and it really just
> supports the lazy who are unable to simply run code against their
> back-end db to gen the roas. and if they don't have the back-end db,
> wuzza wuzza. but here is a hack which i think could do it.
>
> use max-len==0 to denote marking the exact prefix/len as valid, but not
> invalidating covered prefixes from other asns. i.e. issuing roas for
>
> 10.0.0.0/8-0 42
> 10.0.0.0/9-0 42
> 10.128.0.0/9-0 42
>
> would cause the marking of the following as valid
>
> 10.0.0.0/8 42
> 10.0.0.0/9 42
> 10.128.0.0/9 42
>
> and the following as notfound
>
> 10.42.0.0/24 42
> 10.42.0.0/16 666
> 10.77.0.0/24 666
>
> but would cause the marking of the following as invalid
>
> 10.0.0.0/8 666
> 10.0.0.0/9 666
> 10.128.0.0/9 666
>
> the friend realizes that 10.x.0.0/10 could be hole-punched to death. if
> he wants to stop that, he should not use max-len==0.
>
> randy
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
--
Jay Borkenhagen [email protected] AT&T Internet Services
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
