Re: [GROW] Working Group Call for Adoption draft-lucente-grow-bmp-rel (start 25/Oct/2023 end 08/Nov/2023)
Dear GROW, I support the adoption of the document. In particular useful are the events exposing paths being dropped due to policy configurations. Best wishes Thomas -Original Message- From: GROW On Behalf Of Job Snijders Sent: Wednesday, October 25, 2023 12:57 AM To: grow@ietf.org Subject: [GROW] Working Group Call for Adoption draft-lucente-grow-bmp-rel (start 25/Oct/2023 end 08/Nov/2023) Dear GROW, The authors of draft-lucente-grow-bmp-rel asked whether GROW working group could consider adoption of the internet-draft. This message is a request to the group for feedback on whether this internet-draft should be adopted. Title: Logging of routing events in BGP Monitoring Protocol (BMP) Abstract: The BGP Monitoring Protocol (BMP) does provision for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among the others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use-cases with affinity to alerting, reporting and on-change analysis. The Internet-Draft can be found here: https://datatracker.ietf.org/doc/draft-lucente-grow-bmp-rel/ Please share with the mailing list if you would like this work to be adopted by GROW, are willing to review and/or otherwise contribute to this draft! WG Adoption call ends November 8th, 2023. Kind regards, Job / Chris GROW co-chairs ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow smime.p7s Description: S/MIME Cryptographic Signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-fiebig-grow-bgpopsecupd-00 / Updating BCP194
Moin, > I think extended (RFC4360) communities should also be added here. Good point. Added a ticket. > Another point to add in this section is scrubbing communities from a > received route if the number of attached communities is excessively > high (e.g. > 100). Same; Also in the ticket. > I would suggest replacing the word "all" with "specific", or to add a > line explicitly clarifying not to scrub unknown transitive > attributes. I see how the text there is unclear. Added a ticket to fix this after 118. > The global limits seem to offer no real benefit in addition to > per-session limits. The referenced paper mentions Per-Origin AS > limits, not the per-Neighbor AS limits mentioned in the draft. This > also seems to be unimplementable, given that routers act > independently on prefixes they receive. I think there are two points in here: - The paper mentions per-origin, which i consider even more un- implementable than per-neighbor, which is why I restricted it to direct neighbors (similar to the idea of BCP38, that things 'should' be fine if everyone filters their downstreams.) - Your implementability point is very valid. To address both points, it might make sense to move this to a softer recommendation to "Monitoring the global number of prefixes ingested from each peer/downstream, and alerting if that number increases too quickly" or something similar; Then again, the attack in itself kind-of works; Well, not against most major operators, but as soon as it goes to tier 2-3, there quickly are funny cornercase-legacy-things around which die surprisingly quickly if there is a sudden GRT jump by 10-20k prefixes or more. It often boils down to walking on a very thin lines when it comes to how many additional routes can be ingested, basically playing constant catchup to find work-arounds for the next $month(s) until yet another device can finally be decomissioned. So, ultimately, I am not sure; More input appreciated. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-fiebig-grow-bgpopsecupd-00 / Updating BCP194
Hi Tobias, On 22/10/2023 21:34, Tobias Fiebig wrote: - Add large-communities/scrubbing I think extended (RFC4360) communities should also be added here. Another point to add in this section is scrubbing communities from a received route if the number of attached communities is excessively high (e.g. > 100). - Add MAY for scrubbing of attributes "operators MAY opt to scrub all BGP attributes known to cause service disruptions" I would suggest replacing the word "all" with "specific", or to add a line explicitly clarifying not to scrub unknown transitive attributes. - Add max-prefix limits and global limits The global limits seem to offer no real benefit in addition to per-session limits. The referenced paper mentions Per-Origin AS limits, not the per-Neighbor AS limits mentioned in the draft. This also seems to be unimplementable, given that routers act independently on prefixes they receive. Kind regards, Martin ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Working Group Call for Adoption draft-francois-grow-bmp-loc-peer (start 24/Oct/2023 end 07/Nov/2023)
Hi all, I think this is a useful idea and a good use case for what's offered by the bmp-tlv draft, so +1 on support. luuk On Tue 24 Oct 2023, 13:34, Job Snijders wrote: > Dear GROW, > > The authors of draft-francois-grow-bmp-loc-peer asked whether GROW > working group could consider adoption of the internet-draft. > > This message is a request to the group for feedback on whether this > internet-draft should be adopted. > > Title: BMP Loc-RIB: Peer address > Abstract: >BMP Loc-RIB lets a BMP publisher set the Peer Address value of a path >information to zero. This document introduces the option to >communicate the actual peer from which a path was received when >advertising that path with BMP Loc-RIB. > > The Internet-Draft can be found here: > https://datatracker.ietf.org/doc/draft-francois-grow-bmp-loc-peer/ > > Please share with the mailing list if you are think this work should be > adopted by GROW, willing to review and/or otherwise contribute to this > draft! > > WG Adoption call ends November 7th, 2023. > > Kind regards, > > Job / Chris > GROW co-chairs > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
