Re: [GROW] call for adoption draft-evens-grow-bmp-adj-rib-out

Good memory, Joel. I support Joel's recollection and the BMP enhancements in the proposal. Thanks, Tony On Sat, Apr 29, 2017 at 10:18 AM, joel jaeggli wrote: > On 4/28/17 7:34 PM, Randy Bush wrote: > > while i support adoption of this work, two notes: > > > > o i should declare an involvement

Re: [GROW] Route leaks

prefix, but provided transit to me anyway" > > and 4 is mostly lost to me... though I suppose it might mean: "my peer > leaked my prefix to his transits" > > The goal for this work really ought to be: > define route-leak > > Then the next follow-on is: >

Re: [GROW] Route leaks

efault and which is more resistant to breaking off? Not so compelling to me as to warrant a wholesale protocol extension. Tony > On Jul 25, 2014, at 3:12 PM, Tony Tauber wrote: > > How is this different than tagging with communities today? > In either case, the provider's correct act

Re: [GROW] Route leaks

How is this different than tagging with communities today? In either case, the provider's correct action on the semantics is needed (and can go awry through misconfiguration). Tony On Fri, Jul 25, 2014 at 1:40 PM, Doug Montgomery wrote: > The last point that Sriram made is important to the high

Re: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help

On Tue, May 20, 2014 at 5:42 PM, Christopher Morrow < christopher.mor...@gmail.com> wrote: > > There MAY be MiTM problems, but one argument is that there are > whenever a packet crosses out of your administrative control. I don't > know that the hyperbolic argument (everything is a mitm chance!)

Re: [GROW] WG Adoption call: draft-mcpherson-irr-routing-policy-considerations (END: 11/28/2012)

Yes, adopt. But "s/efficacy/effectiveness/g" :-) Tony On Wed, Nov 14, 2012 at 6:37 PM, Danny McPherson wrote: > > Authors would definitely like to see this published, and GROW seems like a > reasonable home. > > Given that we need to fix the IRRs whether RPKI-enabled BGPSEC is fully > deploye

Re: [GROW] Call for Adoption: draft-white-grow-overlapping-routes

Quick question. To my understanding "overlapping routes" seem to be what most people call more-specific routes (aka. "more-specifics"). In my experience things which are described as overlapping mean that some part of one thing is _partially_ covered by some part of some other thing. I don't see

Re: [GROW] WGLC: draft-ietf-grow-private-ip-sp-cores

Using squat/stolen space will mean ICMP messages from the SP core wouldn't be able to reach the legitimate address holder's network but neither would traffic of the customers of that SP. I don't believe that the same is true of "private" space; so there are actually _more_ problems with the "squat

Re: [GROW] WG Adoption Call for: draft-kirkham-private-ip-sp-cores

Support. On Thu, Nov 17, 2011 at 2:30 AM, Christopher Morrow < christopher.mor...@gmail.com> wrote: > Folks, > As mentioned in the WG meeting today, please take the time to > read/review/think-about the subject draft: > > > Anthon

Re: [GROW] Posted new draft of private IP in SP core

Hi, In Sec 1: "...scarcity of routeable IPv4 address space..." should read "...of unique..." or "public" because: - It's not "unroutable", of course, routers route it all the time! - It's the uniqueness that makes it scarce commodity. Ditto for other references to "routeability/routeable". Tony

Re: [GROW] Updated draft-haberman-rpsl-reachable-test available

On Mon, Dec 21, 2009 at 11:32:28AM -0500, Brian Haberman wrote: > > When you say submit the object, are you referring to the pingable > attribute or the route[6] object? The route[6] object since I read this to mean that these new attributes are mandatory like origin and mnt-by are today. Hence

Re: [GROW] Updated draft-haberman-rpsl-reachable-test available

On Mon, Dec 21, 2009 at 09:55:39AM -0500, Brian Haberman wrote: > All, > Based on feedback from the GROW list and a couple of private > e-mails, I have submitted draft-haberman-rpsl-reachable-test-02.txt. Any > additional comments/suggestions are welcome. I am discussing the best > way to