Re: [GROW] Request WG Adoption for draft-lucente-bmp-tlv

2019-08-20 Thread Marco Marzetti
I do support adoption. By adding TLVs we'd make the protocol more flexible and thus more easily inter-operable with all the possible use cases. Regards On Thu, Jul 25, 2019 at 8:06 PM Paolo Lucente wrote: > > Dear GROWers, > > We would like to request WG adoption for >

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

2017-01-17 Thread Marco Marzetti
On Tue, Jan 17, 2017 at 12:10 AM, joel jaeggli <joe...@bogus.com> wrote: > On 1/15/17 6:35 AM, Marco Marzetti wrote: >> On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli <joe...@bogus.com> wrote: >>> On 1/14/17 3:58 AM, Marco Marzetti wrote: >>>> Joel,

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

2017-01-15 Thread Marco Marzetti
On Sun, Jan 15, 2017 at 3:49 PM, Job Snijders <j...@instituut.net> wrote: > On Sun, Jan 15, 2017 at 03:39:37PM +0100, Marco Marzetti wrote: >> On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush <ra...@psg.com> wrote: >> > [ first, i do not use route serves (b

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

2017-01-15 Thread Marco Marzetti
On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush wrote: > [ first, i do not use route serves (because of the data/control non- > congruence), so my opinion here is worth even less than it normally > is. ] > >> An ixp route-server is not a transit provider, all of the nexthops >>

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

2017-01-15 Thread Marco Marzetti
On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli <joe...@bogus.com> wrote: > On 1/14/17 3:58 AM, Marco Marzetti wrote: >> Joel, >> >> So you don't want your upstreams to honor RPKI just because they're >> 3rd parties between you and the other end? > > An ixp

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

2017-01-14 Thread Marco Marzetti
, 2017 at 11:53 PM, Christopher Morrow <christopher.mor...@gmail.com> wrote: > > > On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti <ma...@lamehost.it> wrote: >> >> Christopher, >> >> I have to admit that i am not aware of the ongoing work on sidrops, so >&g

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

2017-01-14 Thread Marco Marzetti
On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli <joe...@bogus.com> wrote: > On 1/13/17 1:54 PM, Marco Marzetti wrote: >> >> Every time one suggests a change related to the IXPs world we spend >> days arguing if it affects the neutrality and how. >> Do we really nee

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

2017-01-13 Thread Marco Marzetti
Every time one suggests a change related to the IXPs world we spend days arguing if it affects the neutrality and how. Do we really need that? Anyway, i can't see why IXPs can blackhole traffic (if the destination requests it), but cannot do the same with prefixes. After all if a prefix is

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

2016-11-19 Thread Marco Marzetti
Robert, This is a wonderful easy to use solution to send informational messages to your neighbor for a very specific case (sesssion shutdown) It is so easy that i wonder why we're discussing for so lo long. Changing operational patterns or having well-formatted messages is out of the scope and

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

2016-11-19 Thread Marco Marzetti
Robert, So you're suggesting to include recommendation for the formatting? That could help (as long as it's not mandatory). Regards On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae wrote: > I personally think this is a really bad idea but understand why some might > want this

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

2016-11-19 Thread Marco Marzetti
rchive/web/grow/current/msg03713.html > > Sriram > > ____ > From: Marco Marzetti <ma...@lamehost.it> > Sent: Tuesday, November 15, 2016 7:17 AM > To: Sriram, Kotikalapudi (Fed) > Cc: Montgomery, Douglas (Fed); Nick Hilliard; grow@i

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

2016-11-15 Thread Marco Marzetti
Siriam, I misunderstood. My apologize. Now i get what you're suggesting. How do you handle scenarios in which one ASn have two upstreams and announces its prefixes to only one of them, but send packets through both? For instance what if AS1 sends announces its prefixes to AS2 only, but sends

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

2016-11-13 Thread Marco Marzetti
On Sun, Nov 13, 2016 at 5:19 PM, Marco d'Itri <m...@linux.it> wrote: > On Nov 13, Marco Marzetti <ma...@lamehost.it> wrote: > >> Carriers cannot do that as they cannot drop ALL the traffic from a >> certain source if the request is not coming from the owner. > Th

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

2016-11-08 Thread Marco Marzetti
Hello, I am not sure if anyone would ever deploy such mechanism. For contents it's useless as they have to filter DDoSes before they reach their network. For carriers is poorly scalable as they'd have to configure thousands of prefixes. It could make sense for eyeballs but they hardly would drop

Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

2016-08-04 Thread Marco Marzetti
On 2016-08-04 07:34, heasley wrote: Wed, Aug 03, 2016 at 10:11:46PM -0400, Christopher Morrow: So, back to your discuss though: "BGP speakers SHOULD only accept and honor BGP announcements carrying the BLACKHOLE community if the announced prefix is covered by a shorter prefix for

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

2016-07-02 Thread Marco Marzetti
On 2016-06-29 14:30, Nick Hilliard wrote: Job Snijders wrote: I believe this update addresses the concerns raised in this phase of the document. yes, thanks, it addresses these concerns, and the document is a lot better as a result. The second major area of concern I have about this