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

re, it is important to understand the > security and reliability measures that can and should be deployed to > prevent accidental or intentional routing disturbances. > ... [abstract snipped for brevity] ... > > This internet-draft aims to update RFC7454 / BCP 194. Suppo

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

quot;). Which effects this community has - or not - is up to the receiving network. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Gru

Re: [GROW] draft-fiebig-grow-bgpopsecupd-00 / Updating BCP194

ic, more a "robust operations" thing. No time yet to read through all the rest. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsrat

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

s when troubleshooting) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 1360

Re: [GROW] [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

o keep > > routing at some proper stability levels. > > just in case folk missed the last time i agreed with this sentiment, > > +1 Yep, another +1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebast

Re: [GROW] Proposed updates to GROW charter

a and/or submarine > cables would be appropriate, I think! "BGP vandalism" Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsrat

Re: [GROW] Discourage asdot+/asdot?

ASDOT to ASPLAIN. It totally wrecked my nice AS3.3 into an ugly large number, but there was strong enough pushing that I was overruled. So, documents, minutes, proposals should exist. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vor

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

h the policy object to be more useful than the AS-Set RPSL object) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Cul

Re: [GROW] Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling

Hi, On Tue, Jan 16, 2018 at 03:40:16PM +, Nick Hilliard wrote: > I wouldn't see a problem mentioning LAGs in a future -bis, but as others > have noted, there doesn't seem to be a compelling reason to pull the > document out of the rfc editor queue at this point. +1 Ger

Re: [GROW] Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling

ful for me!", cull his sessions as well, even if he could go on. thanks for bringing this up, Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsich

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

t; have time to twiddle knobs. It's better policy to provide ixp > participants with simple guidelines and a well-managed 90% solution > rather than spend all day pushing them up the hill. I like being pushed uphill :-) - but if I don't even have to *get* up that hill, even better. So, "

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

AS path lenghts seen by our customers. In other words: we asked for AS-Path transparent RSes 15 years ago, and this is still what we want today. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard J

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

"poor BGP implementations that just do not scale properly with 600+ peers on the same router"... like, "most of them") If there were only 10 other ISPs at the IXPs we connect to, we could do without route servers :-) Gert Doering -- NetMaster -- have you enabled IPv6 on som

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

t routes to the networks behind them. So, route servers are a very (very!) welcome feature. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

ew exceptions - all have the same export policy today, namely "our customer cone, except if the no-export-to-IXP community is set, prepend if prepend-to-IXP community is set") Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

an I want (I can collapse it again afterwards, but why eat up CPU etc. for no benefit). So "peer group" is exactly matching my use case. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

ot;per individual peer". So, support for that idea. On the actual implementation, I abstain, as I haven't read up on the technical details enough to make a qualified comment. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG

Re: [GROW] [Idr] operator inputs -- route leak solution

Hi, On Thu, Mar 23, 2017 at 12:08:39AM +0200, Nick Hilliard wrote: > Gert Doering wrote: > > If ISPs do not turn this *on* on their customer connections, it will not > > do anything - and given that those ISPs that *need* to turn this on are > > the ones that are not ca

Re: [GROW] [Idr] operator inputs -- route leak solution

will not do anything - and given that those ISPs that *need* to turn this on are the ones that are not caring today, I'm still not seeing why they would turn this on tomorrow. So you're adding implementation complexity which will not help anything. Gert Doering -- NetMaster -

Re: [GROW] [Idr] operator inputs -- route leak solution

care today will not add bother to add a filter on this well-known community value (... and most likely, the customer router sending out unfiltered garbage won't have "send-community" enabled either). Gert Doering -- NetMaster -- have you enabled IPv6 o

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

> ???Large communities have fixed format. There is no TLV there. ???Which > proposal was more of fixed format then large comms ??? "fixed format" and "there is no flexibily in *usage*" is not the same thing. Gert Doering -- NetMaster -- have you enabled IPv6 on some

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

ith large communities. Nobody objected to having a set of well-known communities for a well-known purpose (as can be seen by the consensus on 7999). But this is not what was discussed in large community context. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? Space

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

Hi, On Tue, Mar 14, 2017 at 04:49:10PM +0100, Job Snijders wrote: > On Tue, Mar 14, 2017 at 04:41:06PM +0100, Gert Doering wrote: > > On Tue, Mar 14, 2017 at 03:07:32PM +, bruno.decra...@orange.com wrote: > > > On a side note, I'd be interesting to know why r

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

t; 90 second (and configurable) while the former is minutes (and not > configurable). How's the IXP operator going to introduce a gshut message into a BGP session between IXP customer A and IXP customer B? Gert Doering -- NetMaster -- have you enabled IPv6 on something today..

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

e other part - knowledge of the peer operators at a typical IXP is reaching new all-time lows every year, so having something that will do the right thing on the fabric operators's side is much less work than negotiating anything exceeding basic BGP setup with 100+ peers... Gert Doering &quo

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

"the prefixes the intermediate network uses for on-link peering" (plus, maybe, fe80::). So maybe "only affect *on-link* BGP traffic"? [..] > ps. Some may point out that this is a rampant layering violation, to which I > will say: "yes". ;-) And a useful one :-)

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

ehavior of a BGP speaker when >there is no import or export policy associated with an External BGP >session." > > please have a read-through, decide if this needs more work and then speak > up on list. Still supporting it. Go for it. Gert Doering -- NetMaster -- have you

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

accordingly. There other moments where one might want to chat with the > neighbor, but those are out of scope for this document, you can always > call or email them! Sounds tremendously useful. There's rat-holing risks here (like, charset), though. Gert Doering -- NetMaster -- hav

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

ual uRPF check". Having implementations that could tack arbitrary "RPF lists" to an interface would be very nice, but this is more like "auto-generate ACLs based on prefix info" than "RPF" which stands for "reverse path filter" (not sure about the "filt

Re: [GROW] [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

treams (2914) use a very complex and strongly regionalized framework ("blackhole outside the country that this route was received in"), and they seem to be happy with 4:4:4 as well and not having "everything built-in and applied automatically", so the -large draft

Re: [GROW] [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

pace in field 3 would be needed. But the point is: this can be *signalled* using 32:32:32 just fine, and how easy it is to make policy statements out of this is a matter of flexibility of the vendors's route policy language. Gert Doering -- NetMaster -- have you enabled IPv6 on something

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

he wrong places. "Neither send nor receive prefixes" or "not bring up the session at all" are workable alternatives from an operational PoV. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bo

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

omes to mind (which among others recommends GTSM). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen

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

because it's causing problems to my infrastructure", but even then, his upstreams will not permit to do this transitively) I do not think the draft needs to be extended to say so - we only define a code point, not define a new mechanism for blackholing. Gert Doering -- NetMaster

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

cipants would still be putting > packets onto the fabric. This is what DECIX is doing: a special next-hop IP which ARPs to a special MAC address which is MAC-ACL-filtered at all ingress ports to the fabric - so the nice effect is "fabric not full" (plus "participan

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

uot;. Maybe more along the lines of This well-known advisory transitive BGP community, namely BLACKHOLE, allows an origin AS to specify that a neighboring IP network or IXP that has appropriate mechanisms in place is requested to blackhole a specific IP prefix. Gert Doering

Re: [GROW] WGLC: draft-ietf-grow-blackholing - ENDS May 20, 2016

ate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed." I'm not aware on any IPR issues touched by this document. Gert Doering -- one author -- have you enabled IPv6 on something today...? SpaceNet AG

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

updated. > > So I guess I would ask you: which way did you want to go? If this is what it takes, updating 4271 sounds like a plan. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-D

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

lanation, please")? (All the rest is obviously the right way forward, so "support!" and "BCP!") Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14

Re: [GROW] [v6ops] Deaggregation by large organizations

, while the more specific curve is growing stronger than linear. No predictions here, though. (You've propably seen this slide deck before - it's the IPv6 routing table talk numbers fed into a daily-updated cronjob) Gert Doering -- NetMaster -- have you enabled IPv6 on something today

Re: [GROW] [v6ops] Deaggregation by large organizations

, please :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen