Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

look.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&data=04%7C01%7CMatthias.Arnold%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h

Re: [GROW] is TCP the right layer for BMP session resumption?

A primary use-case of the BMP data is to provide information to a route collector/optimizer to determine what feasible paths may be sent to a router by these offline computational systems. This requires a reliable transport where messages are delivered in order. I understand others may be fine

Re: [GROW] BGP deaggregation

> On Nov 3, 2019, at 5:42 PM, Christopher Morrow > wrote: > > Where does it no longer make sense to deaggregate? Isn't that a bunch related > to what problem the initial announcement is trying to solve? I’m looking to get rid of some of our more specifics in 2020 which should help reduce th

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

> On Oct 2, 2019, at 7:45 PM, Rob Foehl wrote: > > On Thu, 26 Sep 2019, Jeffrey Haas wrote: >>> On Sep 26, 2019, at 6:43 PM, Warren Kumari wrote: >>> >>> This is nice, but what would make it more useful would be if it also >>> reported if there are *useful* AS_SETS / if the AS_SET means anyth

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

> On Sep 25, 2019, at 11:32 PM, Sriram, Kotikalapudi (Fed) > wrote: > > Jared, > >> (Obviously my search in e-mail today went afoul, I see it’s adopted.. > > Yes, the draft was adopted. You can see the discussion here: > https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&q=WG%20adoption%20

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

(Obviously my search in e-mail today went afoul, I see it’s adopted.. but like I said.. there’s a lot more AS_SETs that appeared in BGP announcements since this was posted). - Jared > On Sep 25, 2019, at 8:13 PM, Jared Mauch wrote: > > (I didn’t see any follow-up) but I suspect t

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

(I didn’t see any follow-up) but I suspect the intent was adoption. I did notice after this a few more BGP announcements with AS_SET occurring on a very regular basis. I suspect someone is doing some research on it, perhaps someone reading this e-mail :-) - Jared > On Aug 7, 2019, at 12:23 PM

Re: [GROW] Limiting AS path length?

Operator here. We have limitations around 128 to avoid some vendor bugs. I suspect we could remove them but people with mental histories of pain always worry about that change. Sent from my iStarship > On Sep 16, 2019, at 12:42 PM, Jeffrey Haas wrote: > > Speaking as a vendor: > > >> On

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

I support adoption. Sent from my iCar > On Jul 26, 2019, at 2:57 AM, > wrote: > > I support adoption as an upcoming co-author. > > Thanks, > Thomas > > > From: GROW On Behalf Of Paolo Lucente > Sent: Thursday, July 25, 2019 8:06 PM > To: grow@ietf.org grow@ietf.org > Subject: [GROW]

Re: [GROW] Value of timestamps in BMP header for local-rib monitoring

> On Jun 13, 2019, at 12:02 PM, Tim Evens (tievens) wrote: > > Thanks Mukul. I'll also update this one as noted. Tim, Sorry, are you saying you’re updating it to proposal #1 or #2 ? (I would want #2) - Jared > > On 6/13/19, 8:16 AM, "GROW on behalf of Mukul Srivastava" > wrote: > >

Re: [GROW] BMP loc-rib Peer-Type behavior

> On Dec 13, 2018, at 2:12 PM, Jakob Heitz (jheitz) wrote: > > Wait, a BMP server is not a BGP peer. It does not replicate a routing table. > It is a logger/processor of information. It doesn't "delete" older > information, > just because some newer information arrived. > Its purpose it to te

Re: [GROW] Making BMP registries FCFS

I would also support adoption on the part of the WG if the chairs were to ask for it. Jared Mauch On Sep 20, 2018, at 4:26 AM, Randy Bush wrote: >> A while ago we talked about this. I finally wrote a draft for it, >> https://www.ietf.org/id/draft-scudder-grow-bmp-registries-c

Re: [GROW] draft-ss-grow-rpki-as-cones-00

> On May 23, 2018, at 1:24 PM, Brian Dickson > wrote: > > Sorry for the top-reply: > > I think the fundamental problem with AS-SETs in IRR is the unilateral aspect > of "control" of what amounts to assertion of a relationship. > > Given the basic mechanisms already in play for RPKI (keys, s

Re: [GROW] Route Server ASN stripping hiding considered harmful?

> On Dec 18, 2017, at 12:38 PM, Nick Hilliard wrote: > > Job Snijders wrote: >> You and Martijn appear to argue that the 'best path selection' >> component should not be fiddled with, which leaves me wondering >> whether we have any other methods to implement a track record ala >> 'this path an

Re: [GROW] [Idr] Review of draft-ietf-grow-bgp-reject-05

> On Apr 19, 2017, at 9:53 AM, Alvaro Retana (aretana) > wrote: > > My bigger issue with 9.1.1 is that it is the first step of the decision > process – the intent, as I understand it, is for the routes not to even reach > that point. I’m not in agreement here as it’s well within the power of

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

making until Tues (3/21/2017)... read and respond pls :) I have read this and support it :-) - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

Re: [GROW] [IPFIX] [OPSAWG] WG adoption poll fordraft-li-opsawg-ipfix-bgp-community-02

On Thu, Feb 16, 2017 at 07:53:23PM +0800, 李振强 wrote: > Thank you P.J. Aitken. > > The length of IPFIX message is sufficient for BGP standard communities, since > the length of standard community is 4 octets. But the sizes of extended > community, large community and wide community are bigger tha

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

ons established 1; dropped 0 Last reset 2d03h, due to BGP Notification sent: code/text here Time since last notification sent to neighbor: 2d03h Error Code: appropriate code goes here Notification data received (or sent): UTF-8 string goes here -- Jared Mauch | pgp key available

Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

I support adoption of this document. > On Nov 15, 2016, at 10:03 PM, Christopher Morrow > wrote: > > Howdy gentle folk, > Let's take a few minutes to discuss and digest whether or not the subject > draft with abstract: > Examples and inspiration for operators on how to use Large BGP >Com

Re: [GROW] I-D Action: draft-ietf-grow-bgp-reject-00.txt

> On Aug 13, 2016, at 1:53 PM, Gert Doering wrote: > > "Neither send nor receive prefixes" or "not bring up the session at all" > are workable alternatives from an operational PoV. I’m ok with implementors doing what XR does by default without "unsafe-ebgp-policy” set. There’s no reason in 20

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

> On Jun 29, 2016, at 5:10 PM, Nick Hilliard wrote: > > Job Snijders wrote: >> Do you have any more comments or concerns queued up? > > I don't think the draft is well specified in terms of its intended > semantics. This is a problem with a standards track document, > particularly one with big

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

Snark not intended, I am generally concerned and want to ensure a properly functioning network like everyone else. I do seek guidance here if this is adopted by the WG. Perhaps off list? Jared Mauch > On Nov 5, 2015, at 4:07 PM, Jeffrey Haas wrote: > > >> On Nov 5, 2015, at

Re: [GROW] draft-mauch-bgp-reject

> On Nov 2, 2015, at 4:37 AM, Gert Doering wrote: > On Sun, Nov 01, 2015 at 11:18:55PM -0500, Jared Mauch wrote: >> I plan on covering this briefly in the GROW meeting today and uploaded the >> revised text that has been sitting in my output queue since August. >&g

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

> On Nov 2, 2015, at 2:04 AM, Jeffrey Haas wrote: > > I suggest it be considered for BCP status. Why BCP? Because operators > already have to go do this for the safety of their network and are doing so > via configuration template. How do we get the implementors to adhere to this BCP? - Ja

[GROW] draft-mauch-bgp-reject

I plan on covering this briefly in the GROW meeting today and uploaded the revised text that has been sitting in my output queue since August. This is basically codifying the fact that you MUST NOT default to "bgp unsafe-ebgp-policy” for any BGP speaking device. - Jared

Re: [GROW] WGLC: draft-ietf-grow-bmp - ENDS: 8/7/2015 (aug 7 2015)

I also support publication of draft-ietf-grow-bmp. -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ GROW mailing list GROW@ietf.org https

Re: [GROW] Route leaks

Communities are not sent by default (eg Cisco). Route leaks come for free on Cisco too. Jared Mauch > 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 action on the semanti

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

On May 19, 2014, at 9:12 PM, Danny McPherson wrote: > > Where else would it be documented? If the IETF is designing protocols that > operators will have to deploy, should this not be here? I thought that was > the point of an “operations” working group? Not all operational practices are do

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

On May 19, 2014, at 9:02 PM, Danny McPherson wrote: > Good point Sandy, this was definitely meant to serve as more of a motivation, > illustrating a real problem that smart people should focus on because it > happens all the time and some real heavy solutions being consider wholly > ignore it

Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

On Nov 26, 2013, at 4:24 PM, Geoff Huston wrote: > I reviewed the mailing lists of all three WGs from November last year, when > this came up. > and I was searching for a proposed methodology of defining requirements, > proposing mechanisms > and standardising one of more candidate technologie

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 9:33 PM, Jeff Wheeler wrote: >> Non-sequitur. Cyclic resets are orthogonal to treat-as-withdraw. As >> enumerated above, ignore-bad-message is harder to implement and is more >> dangerous. > > No, ignore-bad-message is not harder to implement. To say so is simply a lie.

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 6:34 PM, Brian Dickson wrote: > > > On Thu, Jan 3, 2013 at 5:54 PM, Smith, Donald > wrote: > >-Original Message- > >From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf Of > >Tony Li > >Sent: Thursday, January 03, 2013 3:31 PM > >To: Jeff Wheeler >

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 5:01 PM, Jeff Wheeler wrote: > On Thu, Jan 3, 2013 at 4:28 PM, Jared Mauch wrote: >> Also, if you're seeing some problem, I'm sure that some other set of >> people out there will be seeing it as well. The shared pain/cost will >> exist.

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 4:19 PM, Jeff Wheeler wrote: > On Thu, Jan 3, 2013 at 3:18 PM, Robert Raszuk wrote: > > How are you going to clean the NLRIs in your network (both transit or > > stub) which were withdrawn in the messages your BGP implementation > > declared "bad" and decided to ignore ? > >

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 2:35 PM, Michael Long wrote: > > On Jan 3, 2013, at 10:00 AM, Tony Li wrote: >> >> >> All of the marketing that you're doing here is positioning this as a >> 'solution'. It's not. Yes, it will stop the flap, but it does NOTHING to >> fix or deal with the underlying bug.

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jeff, On Jan 3, 2013, at 11:51 AM, Jeff Wheeler wrote: > On Wed, Jan 2, 2013 at 12:56 PM, Tony Li wrote: >> While we can do SOME things to decrease session resets, we cannot fix all >> cases and simply treating things as a withdraw and walking away is wholly >> unacceptable, as some of you wil

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 1, 2013, at 12:27 PM, Chris Hall wrote: > It is a truth universally acknowledged (AFAICS), that if NLRI in a > broken UPDATE are treated-as-withdraw, that is no worse than > session-reset and much to be preferred. > > So, treat-as-withdraw is a reasonable thing for any implementation to >

Re: [GROW] MRT

On Nov 27, 2012, at 12:58 PM, Christopher Morrow wrote: > On Tue, Nov 27, 2012 at 11:43 AM, Mattia Rossi > wrote: >> (http://jon.oberheide.org/projects/pybgpdump/) which is very nice for a >> quick analysis of MRT dumps. > > sadly jon's tool is ... not very well updated :( or gives me lots and

Re: [GROW] RouteLeaks - problem or not?

On Nov 14, 2012, at 6:52 PM, Nick Hilliard wrote: > On 14/11/2012 22:18, Christopher Morrow wrote: >> 1) What is a 'route leak' (perhaps the above draft identifies one >> examplar to be used in that definition) > > dunno really. Some foo which involves prefixes being sent to places where > th

Re: [GROW] RouteLeaks - problem or not?

On Nov 14, 2012, at 5:18 PM, Christopher Morrow wrote: > 1) What is a 'route leak' (perhaps the above draft identifies one > examplar to be used in that definition) > 2) Are 'route leaks' a problem that Operations folks care about Side comment: I fixed two problems in the tool in the past d

Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes

On Oct 3, 2012, at 10:21 AM, Russ White wrote: >> >> The problem as I see it is many of those that operate in the BGP/DFZ don't >> know what they are doing. > > ??? > > Then they shouldn't be using this technique. Or perhaps even running > BGP. Protocols provide rope. It's choice whether you

Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes

On Oct 2, 2012, at 5:23 PM, Russ White wrote: >>> >>> - Path information is lost. While this doesn't impact loop prevention, this >>> information is operationally useful. >> >> +1. Reachability data optimisation is highly desirable and may one day be >> necessary, but this is one of the wro

Re: [GROW] Repeated Errors in BGP - draft-ietf-grow-ops-reqs-for-bgp-error-handling

On Apr 16, 2012, at 7:50 AM, Jakob Heitz wrote: > This should not overwhelm a router. > However, a more serious consequence is a lot of flapping routes. > Serious enough to consider. We could dust off some dampening code for it. > > Note the previous discussion was about repeated "treat as withd

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

Support - Jared On Nov 17, 2011, at 2:33 AM, Arturo Servin wrote: > > Support. > > .as > > On 17 Nov 2011, at 15:30, Christopher Morrow wrote: > >> Folks, >> As mentioned in the WG meeting today, please take the time to >> read/review/think-about the subject draft: >>

Re: [GROW] Mail regarding draft-ietf-grow-mrt

so I'm interested in something in this space, or similar to draft-ietf-grow-bmp as well. We really need a good method for getting data in/out of the devices so our vendors can replicate real network issues. - Jared On Feb 11, 2011, at 2:17 PM, Ronald Bonica wrote: > Sorry, > > I meant to se

Re: [GROW] dampening

This may also provide further guidance. http://www.ietf.org/mail-archive/web/idr/current/msg01128.html - Jared On Nov 10, 2009, at 8:14 PM, Seiichi Kawamura wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > http://www.ripe.net/ripe/docs/ripe-378.html > > I think this is what Jared