Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)

Wed, Dec 06, 2023 at 11:05:41AM -0500, Jeffrey Haas: > On Dec 6, 2023, at 10:45 AM, Job Snijders > wrote: > > The author of draft-fiebig-grow-bgpopsecupd asked whether the > > GROW working group could consider adoption of their internet-draft. > > > > This message is a request to the group for

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

I support adoption. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposing a well-known BGP community for Anycast

Sat, Jul 09, 2022 at 09:32:51PM +0200, Robert Raszuk: > And here comes I think need for authors to clarify something. They said > that such marking is going to be used along with NO-EXPORT. no, you might have misread that; with no-export is possible but not necessary. Eg: several (perhaps all

Re: [GROW] Proposing a well-known BGP community for Anycast

Fri, Jul 08, 2022 at 05:13:37PM +0200, Robert Raszuk: > > I do not understand Robert's issues with this community. > > Let me say that I like it from operational perspective. > > However from routing perspective I have doubts on how this community is > going to be originated and how it is going

Re: [GROW] Proposing a well-known BGP community for Anycast

Thu, Jul 07, 2022 at 12:21:27PM -0400, Jeffrey Haas: > > > > On Jul 7, 2022, at 11:50 AM, Robert Raszuk wrote: > > But most if not all of those do not affect intradomain traffic engineering > > rules. > > > > So I think Jeff's point is how much trust is needed to overwrite your own > >

Re: [GROW] BGP Looking Glass Capability

Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow: > (as normal netizen) > > On Mon, Apr 26, 2021 at 3:33 PM Randy Bush wrote: > > > > Place LG info in peeringdb.com & peeringdb's api. > > > > +1 > > > > huh,I had thought this was already actually included in peeringdb? > >Looking

Re: [GROW] BGP Looking Glass Capability

Mon, Apr 26, 2021 at 01:16:55AM +0200, Rayhaan Jaufeerally (IETF): > > Consistent API that serves RIB data > > Initially I tried to avoid defining the exact API of the looking glass by > pointing to https://tools.ietf.org/html/rfc8522, but unfortunately it does > not strictly define the response

Re: [GROW] BGP Looking Glass Capability

Sun, Apr 25, 2021 at 03:07:29PM +0100, Nick Hilliard: > what we need from routers is a consistent API endpoint which serves RIB > data, that can be consumed by client apps. isnt that called net/restconf? ___ GROW mailing list GROW@ietf.org

Re: [GROW] AS_Path prepend BCP

Tue, Aug 04, 2020 at 03:36:18PM -0700, Greg Skinner: > Out of curiosity, were people unhappy that 7908 called attention to the > organizations involved in the route leak incidents? Also, arguably, the > mistakes called attention to in the AS_Path prepend draft have been > “memorialized”

Re: [GROW] Limiting AS path length?

Mon, Sep 16, 2019 at 10:36:59PM +0200, Claudio Jeker: > > And what if I make it 675 ASes instead and watch sparks fly as a few > > hops away routers hit the 4096-byte BGP message size? > > > > Or I make it 700 ASes with only a 16-bit AS path or a truncated 32-bit > > AS path, so the first 32-bit

Re: [GROW] Limiting AS path length?

Mon, Sep 16, 2019 at 10:18:09AM -0500, David Farmer: > Furthermore, excessively long paths will use more memory Not significantly. It is not length that represents large consumption by AS-PATHs, its variance of paths in the RIB. ie: no sane implementation copies the path to every RIB entry, its

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

he origin case handled by sidr? and the transit case by proposed path validation? > Or do you see that even that has some limitations which may require extra > solutions ? If so pls elaborate on what those limitations are. > > Thx. > R. > > > > On Wed, Mar 13, 2019 at

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk: > Each decently managed AS today has strong EBGP ingress policy permitting > only specific prefixes with specific AS-PATH which is applied in ingress to > ISP network. No more enhancement to this policy is required. I'm NOT speaking in support

Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt

Mon, Jan 21, 2019 at 01:51:50PM +0100, Job Snijders: > > On the other side, the sentence "Vendors SHOULD share the behavior of > > their implementations" perhaps can be made stronger by replacing the > > SHOULD with a MUST. And perhaps remove the phrase "for inclusion in this > > document".

Re: [GROW] Comments on draft-sa-grow-maxprefix

Fri, Dec 28, 2018 at 03:52:39PM +0800, Tim: > Soft limit: > > 1) Alert only: Only alert triggered, neighbor is not impacted > > 2) Alert + Stop receiving route: Alert triggered, no extra route accepted. unless it repeats the alert for every bgp packet received with announcement nlri (log

Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26

Mon, Jun 11, 2018 at 08:59:39PM +, Job Snijders: > Dear working group, > > The authors of draft-ymbk-grow-wkc-behavior [1] requested the chairs to > consider issuing a call for working group adoption. Here is the > abstract: > > "Well-Known BGP Communities are manipulated inconsistently

Re: [GROW] [Technical Errata Reported] RFC7948 (5366)

Thu, May 24, 2018 at 01:49:17PM +0100, Nick Hilliard: > Sandra Murphy wrote: > > A university abandoning publication of its research and, at least > > right now, not even sustaining the archive of its former > > publications. Ugh. > > Long term document storage is hard. caching copies (with

Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13

Thu, Jan 18, 2018 at 11:10:38AM -0500, Jay Borkenhagen: > [resend - apologies for any dupes] > > Distro cut *way* down. > > Regarding the suggestion for "logging knobs": > > - if it's just logging that a gshut action was taken, that's a local > implementation decision -- no need to mention it

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

Mon, Dec 18, 2017 at 04:36:56PM +0100, Job Snijders: > pressure to set up bilateral sessions. Is that negative? Why not encourage ASes to have direct relationships and stop maintaining route servers? They should develop those relationships and it might even be suggested that security and

Re: [GROW] draft-ietf-grow-bgp-gshut

Fri, Jun 30, 2017 at 03:26:08PM +, bruno.decra...@orange.com: > > From: heasley [mailto:h...@shrubbery.net] > Sent: Thursday, June 29, 2017 > > 8:28 PM > > > > Tue, Jun 27, 2017 at 01:14:34PM +, bruno.decra...@orange.com: > > > > > > >

Re: [GROW] draft-ietf-grow-bgp-gshut

Tue, Jun 27, 2017 at 01:14:34PM +, bruno.decra...@orange.com: > > > > From: heasley [mailto:h...@shrubbery.net] > Sent: Monday, June 26, 2017 > 7:07 PM > > To: DECRAENE Bruno IMT/OLN > > Cc: grow@ietf.org > > Subject: Re: [GROW] draft-ietf-grow-bg

Re: [GROW] draft-ietf-grow-bgp-gshut

Mon, Jun 26, 2017 at 05:39:12PM +0200, Job Snijders: > > As for my requirements, I'm considering that our ASes have the > > knowledge of the backup path. Hence I don't need for the extra > > coverage. Regarding the extra cost, I agree that one can hardly > > consider this unacceptable since this

Re: [GROW] draft-ietf-grow-bgp-gshut

Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com: > > Suggestions: > > > > OLD Abstract: > >This draft describes operational procedures aimed at reducing the > >amount of traffic lost during planned maintenances of routers or > >links, involving the shutdown of

Re: [GROW] Benoit Claise's No Objection on draft-ietf-grow-large-communities-usage-07: (with COMMENT)

Thu, May 11, 2017 at 05:19:53AM -0700, Benoit Claise: > Benoit Claise has entered the following ballot position for > draft-ietf-grow-large-communities-usage-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC

Re: [GROW] Suresh Krishnan's No Objection on draft-ietf-grow-large-communities-usage-07: (with COMMENT)

Tue, May 09, 2017 at 07:20:26PM -0700, Suresh Krishnan: > Suresh Krishnan has entered the following ballot position for > draft-ietf-grow-large-communities-usage-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC

Re: [GROW] Genart last call review of draft-ietf-grow-large-communities-usage-06

Tue, Apr 18, 2017 at 06:41:15AM -0700, Stewart Bryant: > 5. Security Considerations > >Operators should note the recommendations in Section 11 of BGP >Operations and Security [RFC7454]. > > SB> You do not address the question of whether there are new > considerations, or considerations

Re: [GROW] draft-iops-grow-bgp-session-culling-00

Mon, Mar 13, 2017 at 02:07:21AM +0100, Alejandro Acosta: > What do you think in including also some suggestions when bringing up > the BGP sessions?. Sometimes it´s good idea to bring them up one by one > or something like that, the idea is to make the device to fill out the > forwarding table,

[GROW] Code nannies (Re: Do you want BGP to extend the message size for all BGP messages or just UPDATES.)

Thu, Mar 09, 2017 at 12:20:43PM +, Nick Hilliard: > First, it's not guaranteed > that some badly coded bgp stack wouldn't crash with a 4097 byte OPEN > message, and secondly, you're not guaranteed that just because the stack > supports 4097 bytes on open due to e.g. unintentional coding

Re: [GROW] ietf 97 agenda

Am 14.11.2016 um 23:52 schrieb Exa : > > Hello Jeff, > > Thank you very much for this document which present ever eloquently one of > the issues with the current development process. > > It is however not how I would propose to move forward. As a individual >

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

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 which the neighboring network is

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

Wed, Aug 03, 2016 at 12:02:36PM -0400, Christopher Morrow: > > (2) IIUC, this proposal envisages BGP speakers commonly > > telling others to blackhole specific /32's or /128's. And > > of course as the draft says BGP doesn't provide us with a > > way to "prevent the unauthorized modification of >

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

Wed, Jun 29, 2016 at 05:22:44PM -0400, Jared Mauch: > > 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.

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

Wed, Jun 29, 2016 at 10:54:30PM +0200, Job Snijders: > On Wed, Jun 29, 2016 at 09:46:15PM +0100, Nick Hilliard wrote: > > Job Snijders wrote: > > > Should it be somehow clarified that router vendors are not supposed to > > > implement mechanisms, which are by default enabled, that discard traffic

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-16: (with DISCUSS and COMMENT)

Sat, Dec 05, 2015 at 02:51:17AM +, John Scudder: > On Dec 4, 2015, at 9:48 PM, Randy Bush wrote: > > >> Where the security considerations outlined above are a concern, users > >> of this protocol should use IPsec [RFC4303] in tunnel mode with > >> preshared keys. > > >

Re: [GROW] Working Group Adoption Call: draft-petrie-grow-mrt-add-paths

Mon, Nov 02, 2015 at 05:27:15PM +0900, Jeffrey Haas: > > Please consider this the start of a 3 week Adoption call for the noted > > draft who's abstract is: > > "This document updates the Multi-threaded Routing Toolkit (MRT) export > > format for Border Gateway Protocol (BGP) routing

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)

Wed, Oct 14, 2015 at 05:09:14PM -0400, Jeffrey Haas: > On Wed, Oct 14, 2015 at 08:47:17PM +0000, heasley wrote: > > For debugging purposes, I'd perfer to see ALL protocols have a "cleartext" > > option - not for normal runtime, for debugging. its darwinian, if someone

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)

Wed, Oct 14, 2015 at 09:04:33PM +0100, Stephen Farrell: > > I'd be happy to see the addition of TLS support in a future document. I > > also do not want TLS use to be required and I would like to see this > > draft move forward without TLS. > > My non-blocking comment asks about the why of that,

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

Thu, Jan 03, 2013 at 02:31:16PM -0800, Tony Li: As I've said before, errors can be reasonably classified into two groups: syntactic and semantic. A syntactic error would be any inconsistency of length fields, incompatibility between a type and a length, or any other error that would

Re: [GROW] ixp jumbo frames doc

Thu, Nov 17, 2011 at 04:23:03PM -0800, Martin J. Levy: Hence ... There is MSS negotiation; hence there is value; but I believe I should only note this fact within the document and not make in any way a requirement to tune or change the BGP or TCP knobs to take advantage of the large MTU

Re: [GROW] ixp jumbo frames doc

Thu, Nov 17, 2011 at 06:46:12PM -0500, Jakob Heitz: BGP uses TCP. Differing MTU has no impact on update generation in BGP. BGP today has a maximum message size of 4096 bytes. TCP slices and dices that into IP packets of its own choosing. i was about to reply with the same, then it occured to

Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt

Thu, Dec 16, 2010 at 06:27:54PM -0800, John Scudder: On Dec 16, 2010, at 8:08 PM, Stephen Stuart wrote: I think it defeats a lot of use cases. Perhaps this subtle difference should be discussed more before we proceed any further with this document. This was discussed before, if I