[GROW]Re: I-D Action: draft-ietf-grow-ixp-ext-comms-00.txt
Hi, On Sat, Jun 08, 2024 at 12:04:38AM +0200, Robert Raszuk wrote: > Maybe it is out of scope. Or perhaps scope is just too narrow. > > Anyhow ... > > Imagine I an IXP client advertising a prefix to RS which I want to be > distributed only to some client's ASNs. > > So how do I signal such policy using Large Communities keeping in mind that > such prefix is an IPv6 prefix ? > > Using extended communities this is easily achievable using IPv6 Address > Specific Extended Community (value 25): Hint: RFC5701. Where exactly are large communities tied to AFIs? So, answering your question - you'd use the same large community values as for an IPv4 prefix that you only want to be distributed to the same client ASNs... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)
Hi, On Wed, Dec 06, 2023 at 04:45:20PM +0100, 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 feedback on whether this > internet-draft should be adopted. > > Title: Updated BGP Operations and Security > Abstract: > The Border Gateway Protocol (BGP) is the protocol almost exclusively > used in the Internet to exchange routing information between network > domains. Due to this central nature, 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. Support, as one of the authors of 7454. 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: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)
Hi, On Sun, Nov 26, 2023 at 04:02:31PM +0100, Robert Raszuk wrote: > Effectively to make use of this community (provided all good marking and > good will of transits) you need to have some hooks in your local BGP > implementations to allow for multipath selection when at least one received > prefix is marked with such community. The intention is not to instanciate magic handling of such in the receiving routers - it's to permit an informed choice by the receiving operator (like, "do not force your usual local-policy settings here, as it will have negative effect"). 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. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-fiebig-grow-bgpopsecupd-00 / Updating BCP194
Hi,
On Sun, Oct 22, 2023 at 09:34:24PM +0200, Tobias Fiebig wrote:
> - Consider adding a point on not using LPREF on RS sessions/honoring
> GSHUT
These are two points, though related... and we're running into this
just today (sending GSHUT + 3x prepend to IXP to drain our traffic
before a planned outage, and peers just ignoring the GSHUT and overriding
the prepend with LPREF...) - so yes, let's make this happen :-)
> - Use of MUST vs. SHOULD; Other contemporary drafts use stronger
> language; From a general standpoint I'd argue 'MUST' might be better
> under the premise of 'to follow best practices this MUST be done'
> with the caveat of 'best practices SHOULD' be followed; Still,
> currently it still uses BCP14 SHOULD for all points.
This is a bit of "my network, my rules" thing - this is all very strongly
recommended, so SHOULD, but there might be good reason why a particular
recommendation can not be followed ("something mumble mumble vendor
mumble mumble not working").
> Looking forward to hear opinions, especially on the somewhat more
> stretchy points (recommending filtering iBGP for example ;-)).
Having been bitten by a vendor that honours GSHUT on iBGP (and lowers
local-pref to 0), which causes persistent loops when other vendors in
the same iBGP mesh do not do this, indeed, a few words on "SHOULD not mess
with priorities on iBGP" would be good - though less an "BGP security"
topic, 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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)
Hi, On Sat, Nov 05, 2022 at 03:48:16PM +0100, Job Snijders wrote: > The authors of draft-wilhelm-grow-anycast-community asked whether this > working group could consider adoption of the internet-draft. Support adoption. I find this a useful feature, being able to look at a prefix and see if the originating AS intended this to be anycast or not, and a standard community makes this easier than having to look up per-AS documentation. (Our routing policy is simple enough that I might not actually have our routers *act* on it, but it's still useful when looking at BGP announcements 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: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
Hi, On Sat, Jul 25, 2020 at 02:56:14PM -0700, Randy Bush wrote: > > As said before and as reiterated by Jakob and Ketan BGP is not the > > right tool for p2p config push. We must stop adding such extensions to > > BGP like this one or BGP-LS or SR Policies if we really want to 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: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
Hi, On Sun, Nov 03, 2019 at 03:10:29PM +, Martijn Schmidt wrote: > > Maybe "BGP Deaggregation Slopping" as a working title? > Or "Scenic BGP Deaggregation", or "BGP Globetrotting", or "BGP > Castaways". If anything a connotation with the sea 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 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
Hi, On Mon, Aug 06, 2018 at 08:55:47PM +0200, Job Snijders wrote: > If people agree that a doc discouraging the use of asdot should exist, > please let me know. Nick might remember where the push came from that made "RIPE" (the community, the NCC, the RIPE DB) change from 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 Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ss-grow-rpki-as-cones-00
Hi, On Sun, May 20, 2018 at 02:41:06PM +0200, Job Snijders wrote: > I???d like to ask for a call for working group adoption for this document. At > the RIPE 76 Routing Working Group session there seemed to be interest in > this topic. I'm far from understanding all the potential implications, but for the usage scenario "I want to use RPKI to build IRR-like filters towards my customers' BGP sessions" this seems to provide me the tools. As in: - query customer policy object for as-cone - (recursively) gather ASes from as-cone object(s) - query AS policy objects to see whether the announcement is supposed to travel towards $customer->$me at all - build filter that is much more precise than "grab AS-Set from IRRDB which can contain anything" (yes, the AS-Cone can also "contain anything", so it needs to go hand in hand with 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-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
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 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling
Hi, On Tue, Jan 09, 2018 at 11:30:35AM +, Thomas King wrote: > we at DE-CIX are currently implementing BGP Session Culling and we hit the > question how to handle LAGs (e.g. LACP, Static configured). The Internet > Draft is not covering this question yet, however, from our point of view it > is worth discussing it. > > Our suggestion for handling LAGs looks like this: > Typically, a minimum number of port members can be defined for a LAG being > up. The LAG is not touched by BGP Session Culling during a maintenance unless > this number is undercut. If the number if undercut the LAG is handled by BGP > Session Culling as defined in the Internet Draft. This assumes that this is a LAG of which only *some* of the ports would be affected by a planned maintenance, right? Like, customer has 4x 10GE, and you reboot one of the switches that has 2 of these, so 20 GE remain and the customer traffic could just use these, with reduced bandwidth. So, if my reading of the scenario is right, your proposal makes sense - let customers decide what minimum bandwidth they need, and if the "4x 10GE" customer says "less than 30GE is not useful 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 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Route Server ASN stripping hiding considered harmful?
Hi, On Tue, Dec 19, 2017 at 08:14:13PM +, Nick Hilliard wrote: > yeah, but you know dealing with ixp participants is hard. IXPs are > firmly aimed at the mid- to low-end provider market, and often you're > dealing with people who just don't understand routing well or who don'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, "what Nick says". Gert Doering -- lazy ISP operator -- 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Route Server ASN stripping hiding considered harmful?
Hi, On Tue, Dec 19, 2017 at 09:53:08AM +0100, Job Snijders wrote: > Yes, route servers can be very useful, no question about it. I think > their value as a service would increase if they become visible > participants of the routing ecosystem. Not sure about that. IXP participants know where the route is coming from, and why should it be of anyone else's concern whether I have a direct peering with you, or use a RS for it? > Gert, do you think it would affect your operations if the route server > would insert its ASN into the AS_PATH? Yes. BGP works by comparing AS path lengths, you know :-) - and that would cause significant work as direct peerings would automatically have shorter AS paths than via-route-server peerings. Thus, traffic shift, which needs to compensated - like, by adding extra prepends to direct peerings - which would have consequences for the 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 Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Route Server ASN stripping hiding considered harmful?
Hi, On Tue, Dec 19, 2017 at 08:40:46AM +, Nick Hilliard wrote: > If you have the resourcing to deploy > proper automation, including dynamic filtering and session management, > then bilateral is better. To emphasize some aspect of this for the non-operators on this list: the technical bits of this are manageable. Talking to 500 other ISPs that are not responding to e-mail, do not have anyone in the same time zone, generally lack understanding of BGP, etc. - this is what really costs, and where a well-maintained route server really shines. (And then, there's "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 something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Route Server ASN stripping hiding considered harmful?
Hi, On Tue, Dec 19, 2017 at 03:06:29AM +, heasley wrote: > 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 trouble shooting could > rely upon it. Economies of scale. DECIX has over 600 active participants, and I have little interest in talking to about 550 of them - but my routers would appreciate having direct 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.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)
Hi,
On Thu, Jul 13, 2017 at 04:57:46PM +, Jakob Heitz (jheitz) wrote:
> The problem with peer-groups is that today's high end routers
> don't generate updates to peer-groups.
> Peer-groups are only a convenience for configuration.
> High end routers group peers automatically into update groups
> and generate updates to the update group.
> Even update groups have sub divisions to which the generated updates
> may or may not be copied to.
> This is done for efficient update generation with thousands of peers.
Which is an implementation detail, really.
If I configure 100 neighbours and one BMP exporter to be in "the same
peer-group" (with the same export policy), I expect them to see the same
prefixes, in general - except for those that are down, slow, and what
other per-peer things might happen that shoves one of them into a different
update groups.
If they have different export policies, I might want one "BMP exporter" per
export policy - or inheritance group, or neighbour-group, or whatever.
("100" is not an arbitrarily high number, it might actually be low, when
talking about peers at major IXPs, that - with a few 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 AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)
Hi, On Wed, Jul 12, 2017 at 12:28:55AM +, Tim Evens (tievens) wrote: > Noisy and likely duplicate/wasteful, yes??? if one configures every peer to > send Adj-RIB-Out > for peers that convey the same data, to which is likely not what folks will > do or what I would > recommend doing. The use case I have is "I want to see how routes from customer end up being sent to DECIX" - which technically is a peer-group with 100+ peers in. Monitoring a given peer is not really useful here (that peer could be down) - monitoring *all* peers will give way more data than 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. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)
Hi, On Mon, Jul 10, 2017 at 05:15:09PM -0400, Jeffrey Haas wrote: > We briefly discussed this during the bar BoF for BMP last IETF. My > apologies for not presenting text before this point. > > While there are use cases where an end-user may want per-peer rib-out state, > some applications may not quite that level of granularity of information. > In many cases, it is sufficient to know what route will be sent to the peers > that belong to the BGP's peer-group/update-group. (I'll be using peer-group > for the remainder of this e-mail.) > > In such cases, the adj-rib-out in its current form can be quite noisy. It > effectively can turn the BMP feed into trying to squeeze the entire firehose > of BGP traffic through the straw of a single session. "per peer group" would actually match our use-case for rib-out much better than "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 AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
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 caring today, I'm still not seeing why they would > > turn this on tomorrow. > > the asns unlikely to turn on a feature like this are leaf customers, > which is intentional. In a topology "Upstream1<->customer<->Upstream2" the filtering, aka the "turning on of the new feature" needs to happen at both upstreams - both need to send the new attribute downstream, and filter prefixes coming in from their customer with the new attribute. If either upstream doesn't turn this on on their session to "cutomer", the mechanism will not work (and you can't make it default, as it would break upstream/peering sessions). Please explain to me how this is going to work if "lazy upstream ISP" keeps being lazy, and does nothing. 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] operator inputs -- route leak solution
Hi, On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote: > Pre-emptive top-post in case anyone mistakes the technique proposed: This > will NOT be implemented via communities. > > The proposal is for a NEW optional transitive attribute. > > If any operators can answer the original question, this will be very > helpful. Thank you in advance to any and all operators. > > Reminder on optional+transitive logic > - If the attribute is not understood/implemented/enabled, the attribute is > passed unmodified. > - If it is understood & implemented & enabled, behavior is subject to the > applicable standards. > - Thus, optional transitives are "opt-in", by definition. It does not really matter if this is a well-known community or a new transitive attribute. 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 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 -- 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] operator inputs -- route leak solution
Hi, On Tue, Mar 21, 2017 at 06:00:36PM +, Sriram, Kotikalapudi (Fed) wrote: > >>From an operator point of view, > are you willing to place a piece of relationship info (as stated above) > in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen, > and prevents single point of failures in incremental/partial > deployment scenarios? I'm not sure it will do any good. Those ISPs that care about the garbage their customers try to inject already do prefix/as-path filtering. Those ISPs that do not 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 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi, On Fri, Mar 17, 2017 at 01:52:56PM +0100, Robert Raszuk wrote: > > > ???Not that long ago we went via tsunami ???of IDR on and offline emails > > when > > > discussing large communities which contained "operators" voice stating > > > *NO* to any well known or predefined meaning to the communities nor > > > welcomed any predefined actions associated with the communities. > > > > You're taking this out of context. We disagreed to having a fixed format > > and fixed rules what to do with large communities. > > ???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 something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi, On Fri, Mar 17, 2017 at 01:33:34PM +0100, Robert Raszuk wrote: > > ???> ??? > > The primary benefit is the use of a well-known community > > > > > ???Not that long ago we went via tsunami ???of IDR on and offline emails when > discussing large communities which contained "operators" voice stating > *NO* to any well known or predefined meaning to the communities nor > welcomed any predefined actions associated with the communities. You're taking this out of context. We disagreed to having a fixed format and fixed rules what to do with 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...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
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 reducing the impact > > > of the maintenance using gshut is not considered as worth it, while > > > it is for culling. Especially since the benefit of the latter is > > > 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? > > an IXP can't, and I am not under the impression that Bruno was > suggestion to do so. I took his comments as applicable to section 2.1 > > this is why the proposed draft contains two angles: one for IXPs and one > for ISPs, each with their different nuances. Indeed, for a direct ISP-ISP link, and the maintenance being controlled by one of the peering parties, gshut would be a useful approach (if it's known that the other party has deployed it). Since the title of the draft is "session-culling" it feels somewhat out of scope to go more into detail on gshut, but a reference might be useful. 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-iops-grow-bgp-session-culling-00
Hi, 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 reducing the impact > of the maintenance using gshut is not considered as worth it, while > it is for culling. Especially since the benefit of the latter is > 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...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-iops-grow-bgp-session-culling-00
Hi, On Mon, Mar 13, 2017 at 09:33:45AM +0100, Mikael Abrahamsson wrote: > Also, do we know why still so few use BFD on IXPs? Since all other > mechanisms apart from BFD lacked consensus (there were L2 reporting > protocol proposals I remember from 10+ years back), it would be great if > BFD was actually deployed more. Right. Speaking for ourselves: until not so long ago, our routers were just not capable of sustaining 100+ BFD sessions with usefully short timers - we now have better peering boxes, so maybe it's time to start talking to peers and spread the word. That's the 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 "disgruntled old fart..." -- 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-iops-grow-bgp-session-culling-00
Hi, On Sun, Mar 12, 2017 at 11:16:55PM +0100, Job Snijders wrote: > With this BCP Internet-Draft we hope to draw some attention to good > practises which can be applied by IP networks or IXPs to mitigate > negative impact caused by maintenance operations on lower layer > networks. The idea is to promote the concept of breaking the > control-plane in a controlled fashion, before actually breaking the > data-plane. I like the concept. Wording-wise, there is room for misunderstanding in the current version, 2.2.1: 2.2.1. Packet Filter Considerations The packet filter should be designed and specified in a way that: o only affect link-local BGP traffic i.e. forming part of the control plane of the system described, rather than multihop BGP which merely transits it says "link-local", but what it wants is not "fe80::" but "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 :-) 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)
Hi, On Sun, Mar 05, 2017 at 04:30:00PM -0500, Christopher Morrow wrote: > Howdy WG folks, > This request starts the WGLC for: > <https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-reject/> > > with abstract: > "This document defines the default behavior 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 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Hi, On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote: > Out of all the moments in the lifecycle of BGP interactions, I believe > that the 'shutdown' moment is the most critical one to decorate with > some freeform text. This is low hanging fruit and as should be treated > 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 -- 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt
Hi, On Wed, Nov 09, 2016 at 06:59:53PM +, Sriram, Kotikalapudi (Fed) wrote: > The data plane would perform the usual uRPF check: Does the SA in the data > packet > belong in a prefix in the RPF list for the interface it was received on? This, actually, is not "the usual 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 "filter" bit, though) 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)
Hi,
On Wed, Sep 21, 2016 at 12:51:30PM -0400, Matthew Ringel wrote:
> Collect enough nouns and verbs, and it follows that you can have a
> language, where the specific communities might be in a common database
> (e.g. PeeringDB*), and networks can say that they support a (yet to be
> specified) standard 10-15 verbs with some set of nouns. Most
> networks will not have a need for (say) "Export to Chile", but being
> able to construct it in a standard way is the important part.**
This is nice to have, and having a recommendation document that
shows operators "look, these are what people *typically* have been
doing with communities, and *that* is how to set the community
values to achieve things" would be a great help when building a new
policy framework.
Having this hard-coded in RFCs and code in routers is both far too
complex to implement, and far too limited at the same time (what if
I only want "North Chile" but that isn't in the implementation?) -
which is why I'm opting for the most simple approach: an opaque string
of bytes of a fixed length, displayed in 4:4:4 format, and all the
"what do I want to do with these?" flexibility and complexity goes
into the routing policy specified by the operator in their router
config.
We (AS5539) use about ~20 community values under 5539: today, and
we do not see any need for much more complex policies (we're a fairly
leafish AS and only limited regional coverage) - so, I see no need to
ask my vendors for a wide list of automatic and all-encompassing features
in their automatic community / policy handling. I want something they
can implement easily, and give me a if/match/set language to achieve
my policy, in a way that it works with 32bit ASes.
OTOH, my upstreams (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 seems to work for make small and large network operators
alike.
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)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)
Hi, On Wed, Sep 21, 2016 at 02:40:43PM +0200, Robert Raszuk wrote: > > An implementation could easily do this in their route-policy language > > > > if ( community in ( MYAS:PEERAS:([1-9]) ) ) then > > set as-path prepend MYAS times $1 > > endif > > > > with "MYAS" and "PEERAS" properly pre-defined in route-policy context. > > Are you suggesting to embed the action (here prepend) into MYAS:PEERAS > fields ? Well, the example was not ideal. The action would have to be part of the 3rd field, so the match would be more along the lines of if ( community in ( MYAS:PEERAS:1000([1-9]) ) ) then set as-path prepend MYAS times $1 endif if ( community in ( MYAS:PEERAS:20([0-9][0-9][0-9]) ) ) then set med $1 endif > Last part would be a parameter ... cool. This is what I've heard how people consider to use this, yes. > So if I need to also send different MED I would need yet one more magic > pair MYAS:PEERAS correct ? Well, since MYAS and PEERAS are the same for a given combination of "my AS" and "my peer AS", bits from the (vast!) 32 bit number space 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 today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-bgp-reject-00.txt
Hi, On Sat, Aug 13, 2016 at 06:34:12PM +0200, Job Snijders wrote: > On Tue, Feb 16, 2016 at 04:52:35PM -0500, Matthew Ringel wrote: > > The solution for BGP-sans-policy rejection shouldn't fail silently. > > > > It would be useful to add a requirement indicating that the software must > > clearly show that the reason for the session being down is due to the lack > > of policy, and one of the places it should show that indicator is in > > whatever command is used for a summary of all configured BGP sessions. > > We don't want the session down, we just want no exchange of routing > information. > > The draft lists the following two: > > "Software MUST mark any routes from an eBGP peer as 'invalid' in the > Adj-RIB-In, if no explicit policy was configured." > > "Software MUST NOT advertise any routes to an eBGP peer without the > operator configuring a policy." > > Requiring software to tear down the session is undesirable in my > opinion. Seconded. Flapping sessions due to no policy configured is counterintuitive. I could see "sessions will not be established until a policy is configured" (so it would never come up, and when queried the router would tell something akin to "PfxCt" to clearly display why it's refusing to bring up the session...) - but it shouldn't flap. That will cause operational people to go debug in all the 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. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)
Hi, On Mon, Aug 08, 2016 at 04:39:56PM +, Smith, Donald wrote: > This discusses neighboring networks, and local scope, so one would assume in > most cases these are directly connected peers (or not many hops away), I > think the security section should recommend use of GTSM on such sessions. > > Then it can't easily be spoofed outside of the local network. While the general recommendation is valid, I'm not seeing why it is particularily relevant to this draft - whether or not a neighbouring BGP session is using a well-defined or privately-agreed code point to signal BGP black holing makes no difference wrt to attacking the local TCP session... (assuming that the "privately-agreed" code point is in fact publicly documented in an IRRdb, which they usually are). Adding a general reference to BGP security best practices won't hurt, of course - 7454 comes 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 HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)
Hi, On Wed, Aug 03, 2016 at 05:06:22PM +, Smith, Donald wrote: > Note everywhere this says BHF I assumed DBHF not Source based BHFing. I > suspect SBHF is out of scope for this effort. I could be wrong. source-based blackholing in remote networks is something I do not consider viable - what customer A might consider an attacker might be an important source of information to customer B, so you can permit customer A to drop packets *to A*, but not "from X, no matter if destined to A or B" (in some case the network provider might decide "I drop all traffic from X, 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 -- 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
Hi,
On Tue, Jun 28, 2016 at 11:27:52AM -0400, Christopher Morrow wrote:
> You could make an ixp have a next-hop internal to the fabric which was the
> discard, but I dont' think that solves the larger problem of: "oh, our ixp
> fabric is full of packets :(" since the participants 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 "participant interface not
full").
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)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
Hi, On Tue, Jun 28, 2016 at 11:11:30AM -0400, Christopher Morrow wrote: > ???Perhaps Nick is reacting to language like: > "??? > This well-known advisory transitive BGP >community, namely BLACKHOLE, allows an origin AS to specify that a >neighboring IP network or IXP should blackhole a specific IP prefix. > ???"??? > > ???which could be cleaned up a bit like: > "???This well-known advisory transitive BGP >community, namely BLACKHOLE, allows an origin AS to specify that a >neighboring IP network or IXP PARTICIPANT should blackhole a >specific IP prefix." Well, the intention *is* that "if the IXP supports black-holing, please do". In implementations like DECIX', the neighbouring IXP participant does not have to do anything in particular, except "accept the prefix with the black-hole nexthop". 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 -- 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-blackholing - ENDS May 20, 2016
Hi, On Mon, Jun 13, 2016 at 11:29:22AM -0400, Christopher Morrow wrote: > "Do any of the authors have knowledge of IPR claims that would pertain to > this document?" > > The wording from the shepherd doc is: > "(7) Has each author confirmed that any and all appropriate 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 AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] draft-mauch-bgp-reject
Hi, On Fri, Nov 06, 2015 at 07:16:17AM -0500, Rick Casarez wrote: > This is interesting since it is definitely a best common practice for > operators to do points 1 and 3 on your list. Is the intention of this > document to enforce a BCP by allowing operators to point to a draft/RFC or > did you want to change how BGP works? BCPs for operators exist (RFC7454 for a start). Implementations need to change, to "fail safe" - if not configured to do so, neither accept nor send BGP prefixes on eBGP sessions. [..] > If you just want to document a BCP in draft form (eventually RFC) to use it > as a mechanism to force vendors to change their BGP code/daemons it might > work. Some vendors will have no issue conforming or adding it to their road > map. Although most can point to the fact it is really just a BCP draft and > ignore it unless there is a big surge in demand for conformance from their > customers. After all we all know some vendors who do not conform to RFCs. > > If you want to change how BGP is implemented, and be able to more > forcefully push this change to vendors, then Robert is correct and 4271 > would need to be 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-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-mauch-bgp-reject
Hi, 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. > > This is basically codifying the fact that you MUST NOT default to "bgp > unsafe-ebgp-policy??? for any BGP speaking device. There is one item I don't understand here: o Software MUST provide protection from internal failures preventing the advertisement and acceptance of routes what does that mean (in other words "more verbose explanation, 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 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation by large organizations
Hi, On Thu, Oct 16, 2014 at 05:05:07PM +0100, Nick Hilliard wrote: On 16/10/2014 16:47, Iljitsch van Beijnum wrote: Growth in IPv6 more specifics was 57% last year... 1y is an interesting data point, but shouldn't form the basis for a new policy. What does the aggregate:more-specifics ratio look like over the last 5-8 years? http://www.space.net/~gert/RIPE/weekly/2014/41/ has a breakdown last year and last 5 years of LIR exact, LIR more-specific, non-LIR (=PI), non-LIR more-specifics - look for the heading Routing Table by Class of Prefix. The LIR exact curve is fairly linear, 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...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation by large organizations
Hi, On Thu, Oct 16, 2014 at 10:45:23AM -0400, Christopher Morrow wrote: A strong message to that extent would be good :-) - coupled with some recommendations how the conflicting goals (I want all ISPs in my neighbourhood to use optimal routing vs. someone in Asia might not be interested in all in 5k routes for german municipality) could be solved. ok, perhaps iljitsch can drop some text into a document so we can get a good read going and decide whether or not GROW wants to spend cycles on it? That would be nice (as I see the problem but have no cycles to write something useful). The problem exists in v4 and v6 and likely will persist in whatever comes next. It's directly related to routing operations work on the global intertubes, so it SEEMS like GROW is the 'right place' to discuss this... we can't go anywhere without text and a draft though. It seems to be made worse by the fact that this can be done more easily with IPv6, as you just can't get enough v4 space to subdivide it into 5000 globally visible prefixes today - and those entities that discover the must have reliability! must have independence! mantra *now* will hit the v6 space... (given that I see this argument in this dimension more often from governmental structures who have been hiding behind single-IPv4-NAT so far). I get that question fairly often from largish networks, and so far, I always have to answer there is no routing police, so it's hard to say what is allowed on the Internet and what not - which is a humorous way to say there is no consensus here what consists 'good' and 'responsible'... I sort of don't want there to be 'routing police' though :( In a way this whole debate sounds like something a 'cisco training class' (or other example) would have covered, or should cover. I suppose it's fairly experiential at this point though. I *do* want a routing police, in the sense that the operator community agrees on what is considered good and bad behaviour, so end users can ask someone (me, Iljitsch, ...) what to do in their network planning, and we can tell them - if you do *this*, it's guaranteed to work - if you do *that*, you can be sure that you will be filtered while today, I have to tell them - well, today it is likely to work, but it might stop working tomorrow, and there is no document that you could show around to those that break your connectivity to show them that you are doing the right thing ISPs develop their own guidelines on prefix-length filtering, some with better understanding on what they want to achieve, others by using 10 year old example documents for never-updated filters... So, yes, guidance, 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) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpxKV_Hzxekb.pgp Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
