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

On 17/11/2011 07:30, Christopher Morrow wrote: As mentioned in the WG meeting today, please take the time to read/review/think-about the subject draft: http://tools.ietf.org/html/draft-kirkham-private-ip-sp-cores-07 In fact, this ID is now at revision -08.

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

On 01/12/2011 15:14, internet-dra...@ietf.org wrote: This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in

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

On 13/04/2012 21:24, Tony Li wrote: This may be a nit, but I think it's important to recall that UPDATE messages include withdrawn routes. These MUST NOT be ignored by the receiver. Doing so will simply result in forwarding loops or black holes. I'm trying to figure out which is worse:

Re: [GROW] Comments on draft-ietf-grow-va-06

On 17/05/2012 13:21, Russ White wrote: The first thing to note is this draft specifically attacks FIB table size without modifying the routing table size. Since I'm not convinced that FIB size, as opposed to the on-the-wire table size, is a problem that needs to be addressed, I'm not certain

Re: [GROW] draft-ietf-grow-private-ip-sp-cores

On 17/05/2012 17:11, Ronald Bonica wrote: Thanks for introducing this document! I would like to bring the authors' attention to the following documents that are working in OPSEC: - draft-behringer-lla-only - draft-baker-opsec-passive-ip-address To some extent, draft-grow and

Re: [GROW] WGLC: draft-ietf-grow-private-ip-sp-cores

On 08/06/2012 18:08, Christopher Morrow wrote: would be nice if more folk would chime in, however, in either the positive or negative. +1 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow

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

On 31/08/2012 17:02, Noel Chiappa wrote: On the actual subject of the document, I too agree it would be good to have a document which looks in detail at aggregation in destination-vector routing architectures; there are indeed some interesting 'issues' when you try and automatically start

Re: [GROW] Fwd: I-D Action: draft-mcpherson-irr-routing-policy-considerations-01.txt

On 04/09/2012 20:17, Danny McPherson wrote: FYI, may be able to find a home here in grow if folks are interested. Encourage feedback from all... Danny, regarding section #4, Accuracy and Integrity of Data, you've missed the most important part of all - the tie between the resource and the end

Re: [GROW] RouteLeaks - problem or not?

On 15/11/2012 00:02, Christopher Morrow wrote: one clarifying point, the RPKI doesn't actually say anything at all about 'path' data. I merely says which origin-as(es) should be able to announce a prefix. i'm being slack about my usage of the term rpki here, and should have referred to bgpsec

Re: [GROW] RouteLeaks - problem or not?

, cheap and practical methods (or hammers) that would accomplish the same goal. In fact, any entity trying to use RPKI as a hammer I would say that it is very badly advised (to said the least). Regards, as snip On 14/11/2012 21:52, Nick Hilliard wrote: From a non-technical point

Re: [GROW] WG Adoption call: draft-mcpherson-irr-routing-policy-considerations (END: 11/28/2012)

oops, is it too late to add a hum in favour of this ID from here? Nick On 14/11/2012 22:35, Christopher Morrow wrote: Grow Folks, the authors of: draft-mcpherson-irr-routing-policy-considerations http://tools.ietf.org/html/draft-mcpherson-irr-routing-policy-considerations-01 have

Re: [GROW] comments on draft-lapukhov-bgp-routing-large-dc-06

On 06/09/2013 03:45, Jon Mitchell wrote: We would like to solicit any further comments on draft-lapukhov-bgp-routing-large-dc-06. Originally this draft was presented by Petr in Vancouver in both IDR and GROW and we feel this draft is useful to the IETF community as it documents a working

[GROW] Fwd: [iab-ch...@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, Technical Considerations for Internet Service Blocking and Filtering]

should grow people consider whether to comment on this? Nick Original Message Subject: [iab-ch...@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, Technical Considerations for Internet Service Blocking and Filtering] Date: Wed, 5 Feb 2014 14:17:27 -0500

Re: [GROW] Fwd: [iab-ch...@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, Technical Considerations for Internet Service Blocking and Filtering]

/~rnc1/ignoring.pdf www.cl.cam.ac.uk/~rnc1/ignoring.pdf http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf Thomas Mangin Sent from my iPad On 5 Feb 2014, at 23:21, Nick Hilliard n...@inex.ie mailto:n...@inex.ie wrote: should grow people consider whether to comment on this? Nick

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

On 20/05/2014 02:11, Jared Mauch wrote: Is there a need for this to be explicitly documented within the IETF? I certainly agree there is a problem, but this feels like operational guidance or perhaps a BCP or similar document? (eg: Filter your peer ASNs from your other peers).

Re: [GROW] WGLC draft-ietf-grow-filtering-threats-02

On 21/05/2014 14:34, Peter Schoenmaker wrote: I would like to call a second working group last call on draft-ietf-grow-filtering-threats-02. we issued a previous one in december but received no comments. The document is ready to publish, and now is your last time to support or comment.

Re: [GROW] I-D Action: draft-ietf-grow-irr-routing-policy-considerations-05.txt

larger issues which acted as disincentives to IRRDB routing policy management - rpsl is poorly specified - rpsl didn't keep up to date with technologies. - https://lists.isc.org/pipermail/irrtoolset/2011-April/000736.html - it may be useful to see some discussion on the state of the IRRDB

Re: [GROW] Deaggregation by large organizations

On 15/10/2014 13:29, Iljitsch van Beijnum wrote: There seem to be two types of organizations that do this: geographically dispersed ones that advertise subprefixes in different locations, such as multinationals, and organizations with very independent subunits but with more limited geographical

Re: [GROW] Deaggregation by large organizations

On 15/10/2014 13:43, Iljitsch van Beijnum wrote: Although I wouldn't expect an organization to deaggregate down to hundreds or thousands of more specifics just for traffic engineering. probably not no, but on the basis of visibility into IXP announcements with prefix analysis to see what's

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

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? Nick

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

On 16/10/2014 17:26, Iljitsch van Beijnum wrote: I haven't checked, but obviously the percentage growth was large and the absolute growth small. not obvious: please post data. Nick ___ GROW mailing list GROW@ietf.org

Re: [GROW] Deaggregation by large organizations

On 16/10/2014 17:53, Enno Rey wrote: not sure to what extent $RIRs act accordingly (have been involved in requesting resources from all five of them in the past and can tell you 1st hand that there's quite some encouraging $LARGE_ENTERPRISES to become LIRs, in one way or the other). there must

Re: [GROW] [v6ops] Deaggregation data

On 18/10/2014 10:06, Robert Raszuk wrote: You can't *mandate* anything in BGP until you have a way to effectively enforce it regardless if this is v4 or v6 or v9. it's a common misconception that bgp is a stick to beat people with, and that the RIRs are the routing police. Nick

Re: [GROW] [v6ops] Deaggregation data

On 20/10/2014 22:58, Christopher Morrow wrote: NOTE: why don't v6 allocations in that file have 'ALLOCATED PA' in their entries? because there are only two types of v6 blocks: ALLOCATED PA and ASSIGNED PA. The assignments aren't in that document and for v4, there are several types of status:

Re: [GROW] [v6ops] Deaggregation data

On 20/10/2014 23:41, Randy Bush wrote: there seems to be a lot of deagg because of the perception that it reduces the threat of mis-origination of one's routes. asia/pac is the poster child for this but the competition is keen, see geoff's reports. this could be highly entertaining in the

Re: [GROW] RtgDir review: draft-ietf-grow-ix-bgp-route-server-operations-03.txt

On 21/10/2014 19:22, John G. Scudder wrote: where where in the the spring cut-n-paste typo. Not present in the .txt. I agree with all that. However I think the point at which DFZ size becomes the upper bound is well below the point at which a practical problem rears its ugly head. the

Re: [GROW] A new bgpdump tool

On 20/03/2015 06:48, Claudio Jeker wrote: OpenBGPD's bgpctl is able to read mrt dump files as well. Currently only table dumps are supported though. - openbgpd bgpctl written in C. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpctl/ Hi Claudio, Are there any plans to support

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

On 02/11/2015 04:18, 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

Re: [GROW] New Version Notification for draft-ymbk-grow-bgp-collector-communities-01.txt

On 18/09/2015 15:28, Jeffrey Haas wrote: > What seems to be needed more than a standard as to what communities everyone > should use is a method of exchanging the mappings for a given provider. that would be difficult, as there is no way of exchanging exact semantics. I.e. one provider's opinion

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

On 05/12/2015 19:10, John G. Scudder wrote: > Hi Nick, Randy and Stephen, > > If I understand you correctly, the proposition is: > > - The IPSec option I offered and the TLS option you offered are > semantically identical from the perspective of their security > properties. > - TLS would be

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

On 05/12/2015 14:23, Jeffrey Haas wrote: > So... who is willing to sign your network up for this grand experiment at > securing your BMP? bcp61 exists because we are no longer living in a world where it's ok to ship sensitive data around the internet in a format which is open to compromise. The

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

The IESG wrote: > The IESG has received a request from the Global Routing Operations WG > (grow) to consider the following document: > - 'BLACKHOLE BGP Community for Blackholing' >as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments

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

Job Snijders wrote: > Follow-up question: without section 3.4 - would you still object? I don't think that IXPs should be mentioned anywhere in this document. For the general case of blackholing, an IXP is a clearing house so should not get involved in the business of dropping its participants'

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

Job Snijders wrote: > I feel that this is not the appropiate forum to define what IXPs can, > can't, should and shouldn't in context of legal enforcement agencies. I wasn't suggesting it was. What I said was two things: 1. regarding everything except section 3.4: if two organisations decide to

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

Job Snijders wrote: > Thank you for your time and reiew! I'm responding to your first in this > thread, in context of the wealth of information provided as follow-ups > to this email. are these changes published anywhere, e.g. ietf datatracker or github? Nick

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

Job Snijders wrote: > Nick understands the intent of the draft very well: honoring this > community is optional and usually (but not always) part of a commercial > supplier-customer agreement. > > We changed the text to the following: > >""" BGP speakers in a bilateral peering relationship

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

heasley wrote: > Sat, Aug 13, 2016 at 01:18:20PM +0100, Nick Hilliard: >> The second adds a note to say that both the receiving and the sending >> party should explicitly filter out more-specifics unless they're tagged >> with BLACKHOLE. I would be in favour

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

Job Snijders wrote: > Maybe I am misunderstanding the intention of your proposed change - can > you elaborate? Are you sure that the problem case you describe isn't > already covered by the existing text? The intention is to document that if there is an existing policy to filter at max prefix

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

joel jaeggli wrote: > sure l3 acls can be applied to l2 ports. > > most ixps are going to have a set of filters that prevent certain kinda > of activity, e.g. spanning tree PDUs, router-advertisement, proxy-arp > and so on. these are all within the technical capabilties of most >

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

Would it be possible to add a clause to mention that accepting + honouring bh prefixes is not mandatory? At the moment the text sort-of implies that it might be. Eg "although it is NOT REQUIRED for bgp speakers in a peering relationship to accept and honor BGP announcements carrying the

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

> On 3 Aug 2016, at 19:02, Christopher Morrow > wrote: > doesn't look new to me, no. and 'worse', today someone COULD just (if they > are in the right place and can do bgp packet creation,etc) just tag all of > your announcments to your provider(s) with the local

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

Job Snijders wrote: > To address the latest concerns, draft-ietf-grow-blackholing-02 has been > posted. > > Executive summary: > > - Changed intended status from STD to INFO > - Added section 4 "Vendor Implementation Recommendations" > - Simplify the security section > - Clarify

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

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 scary warnings in the security considerations section. It needs

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

Christopher Morrow wrote: > first noting that it'd be helpful if you have concerns to suggestions > that you send text that might be used to address them. Playing 'bring me > a rock' is not fun for anyone. "bring me a rock" was not intended. Also, email is a terrible medium for communication

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

Job Snijders wrote: > I believe this update addresses the concerns raised in this phase of the > document. yes, thanks, it addresses these concerns, and the document is a lot better as a result. The second major area of concern I have about this proposal is the transitive nature of the bgp

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

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 > for BLACKHOLE'ed prefixes? I would have said the opposite, i.e. that any traffic tagged with this prefix is dropped via e.g.

Re: [GROW] AS:nn community format and 32-bit ASNs

iljit...@muada.com wrote: > I'm all for a permanent solution, but routers just don't get updated > with new features all that often. Extended communities have been around for years. Peoples' lack of inclination to properly maintain their infrastructure is not a good reason to introduce additional

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

Robert Raszuk wrote: > ​The problem with 16:16 and now with endorsing 32:32:32 is that it still > requires an external oracle to manually translate encoded magic number > into set of actions. I'm struggling to understand how and why this is relevant to adopting large as-is. Operators are free

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

Sriram, Kotikalapudi (Fed) wrote: >> right, ok - I misunderstood. So you're suggesting that the control >> plane correlates asns to interfaces and does something like >> creating a higher cost alternative path out each candidate source >> interface (based on ASN, as determined in the control

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

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 >Communities. > > should be adopted as a WG draft in GROW. This call ends

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

Job Snijders wrote: >>From an operational perspective it is really useful if you can drop a > line in the peer's syslog which covers why you shutdown a BGP session. > A common use case is to provide a reference between the shutdown event > and an emailed maintenance notification, or maybe you want

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

Robert Raszuk wrote: > Just to be clear: I am also OK with free form text with the few well > known and easy to machine parse keywords (in it). the field should either be fully structured or free-form, and the explicit intent of this draft is free form, utf8. Having a half-way house is in

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

joel jaeggli wrote: > The case where routine maintance creates temporary blackholes is > basically ubiquitious were you attempting to use urp strict. oh indeed - I've been at the receiving end of exactly this type of blackholing. Very annoying. But I just wonder if urpf is the best tool to

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

Neil J. McRae wrote: > I just wish I thought we had the luxury of lazy operations like this! there are more places in heaven and earth, Neil, including many places where automation makes no sense and many other places where unstructured text would be a useful tool in the operator's box. Just

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

Neil J. McRae wrote: > I just wish I thought we had the luxury of lazy operations like this! to clarify my previous email, it's a matter of simple economics: automation needs scale to work properly, and in particular, bgp session management automation only makes sense for a relatively small

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

Neil J. McRae wrote: > I would be deploying automation to take care of network > problems/issues/whatever whether I worked at BT or I was the admin of > a network with four and a half nodes. For sure. e.g. we've automated the hell out of INEX (which has more than 4.5 nodes btw). The point is

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

Sriram, Kotikalapudi (Fed) wrote: > This work has been submitted to OPSEC WG. > Posting here also since it may be of interest to GROW WG members as well. > Comments/suggestions on this draft are welcome -- here or on the OPSEC list. > Thank you. Sriram, this looks difficult to implement and easy

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Marco Marzetti wrote: > Why RPKI can't be part of that? tl;dr: route servers and rpki are an uncomfortable fit. rpki can be part of that, but it's problematic because the route server is running the routing decision engine on the part of the client. RPKI is a relatively fine-grained tool in the

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Matthias Waehlisch wrote: > the current discussion makes clear that documentation of > origin-validation-signaling in IXP context is needed rpki is conceptually no different to any other type of signaling mechanism: it's simply another input into the BGP decision engine process, just like

Re: [GROW] Proposed change to BMP registry policies

John G. Scudder wrote: > Registration policies have to be changed by an RFC, so if this > proposal sounds good to the WG I volunteer to write a short Internet > Draft to make it so. Before going to the effort i wanted to solicit > feedback though. this looks sensible. The justification is sound

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

Christopher Morrow wrote: > Howdy folks! > There were 3 people, 4 if you include me, that had something to say here... > > it'd be nice if a few more folk had read through and agreed/disagreed :) violent support for this. This is something that should have been in bgp on day one, and its

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

heasley wrote: > Ignoring support or opposition for the topic of the thread, why should > the ietf concern itself with programming (and testing) incompetency of > this magnitude? The RFCs should document the procedure to negotiate > the capability, not endeavor to design for every possible

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

Susan Hares wrote: > This email is to make you aware of the discussion on the Extended > Messages draft (draft-ietf-idr-bgp-extended-messages-21). Do you > want the message size extended for all BGP messages or just UPDATE > messages? This probably is more important if you want to have a >

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

r from this issue as the check is currently performed on > ALL messages as currently specified including the OPEN. > > So I would suggest to just change the wording to include all message type > but OPEN, and leave it as an exercise to the reader to write another draft > allowing

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

Will Hargrave wrote: > With a 30 minute cull window, there is substantial concern that an > operator will begin to debug the ‘problem’, discover ICMP PING works but > TCP/179 doesn’t work, and get very annoyed at this strange behaviour. I > think we should operate on a principle of least surprise

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

Tore Anderson wrote: > By the way, as an IXP operator, you also have the possibility to simply > shut down your members' interfaces prior to performing maintenance, > instead of doing culling. Doing so would be completely analogous to the > directly connected BGP speakers scenario discussed in

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

Tore Anderson wrote: > In other words: in my opinion, BGP session culling should be considered > a BCP even in situations where link state signaling and/or BFD is used. > IP-transit providers should perform culling towards their customers > ahead of maintenance works. Direct peers, likewise.

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

Susan Hares wrote: > If Quagga, Bird, or GoBGP have been run against test devices (IXIA, > etc), the testers used to test against these cases. Most of these took > their initial code from open-source GateD which had this feature. The > open-source GateD was distributed into many different

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

Job Snijders wrote: > At this moment I'm inclined to consider such 'staggered gradual > restoration' recommendations out of scope for this BCP. Mainly because I > am not aware of a generic, currently in-use recommendations and the > problem space might be somewhat undefined. I'd suggest that ixp

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

Stewart Bryant wrote: > Guessing is horrible, but if that is what you do, that is what you do, > and if the risks are the accepted norm in the BGP > community I am fine. there's a general understanding out there that if you're directly connect to $asn, you can somewhat believe $asn:* or $asn:*:*

Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

New ID submission, as below. This is to solve a real world problem. Comments welcome. Nick internet-dra...@ietf.org wrote: > A new version of I-D, draft-hilliard-grow-no-export-via-rs-00.txt > has been successfully submitted by Nick Hilliard and posted to the > IETF repository.

Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

d. > > From the route server client perspective it may also be simpler if there > is just one “no export function” community instead of multiple. > > Why is there no consensus amongst route server operators on what the > correct behavior is? Can you provide a citation? > >

Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

Job Snijders wrote: > OK, but you are not explaining to me why the current set of RFC's can't > be updated to encourage different NO_EXPORT behaviour on route servers > (compared to the rest of the BGP speakers), but instead a new community > is required. it's because there is no consensus in the

Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

Wolfgang Tremmel wrote: > From my reading of RFC1997 and RFC7947 the ambiguity is not really one: > > RFC1997 states that any community-aware BGP speaker MUT NOT advertise > prefixes received with NO_EXPORT > --> a route server is a BGP speaker > --> it is community aware > > RFC7947 uses

Re: [GROW] working group last call draft-ietf-grow-bgp-session-culling

Job Snijders wrote: > On Wed, Sep 06, 2017 at 09:29:52AM -0400, Christopher Morrow wrote: >> Obligatory: "Are there any IPR claims outstanding by the authors?" > > I am not aware of any IPR. I am also not aware of any outstanding IPR claims. Nick ___

Re: [GROW] [Gen-art] Genart last call review of draft-ietf-grow-bgp-session-culling-04

Dale R. Worley wrote: > Section 3.1.1 seems to be uniquely short. I would favor adding a list > of the "multiple ways an Operator can accomplish that." Even just > listing the *names* of the methods that might be used is a useful guide > -- a novice operator can use search engines to find

Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

Wolfgang Tremmel wrote: > just reading your draft, a few remarks, speaking as a private internet > citizen: > > "If a route server client announces a prefix tagged with both the > NO_EXPORT and NO_EXPORT_VIA_RS communities to a route server, the > route server MUST ignore the NO_EXPORT

Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

Job Snijders wrote: > * A few Internet Exchange RS operators need to deploy a new routing > policy. Then you should speak directly to the IXPs who disagree with your opinions and talk them into changing their opinions. As I said, this has already been tried and it didn't work, but

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

Job Snijders wrote: > Right now some IXPs are using the IETF RFCs as a justification to not > hide their ASN in the AS_PATH - and unfortunately some of them gloss > over the recommendations to apply ingress filters. the two RS RFCs are split: one is a specification of what BGP must do, and the

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

Job Snijders wrote: > It is common practise for route server operators to configure their > route server in such a way that the route server does not append its own > ASN to the AS_PATH attribute. Many IXPs view this practise as > justifiable because it gives them a competitive advantage over

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

Job Snijders wrote: > After the gazillionth routing incident in which an IXP route server > amplified the problem, I think it is time we explore mechanisms to > improve accountability, auditability & make debugging easier. you missed the term "misconfigured" or "malconfigured" when describing the

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

Jeffrey Haas wrote: > On Mon, Dec 18, 2017 at 01:04:03PM +0000, Nick Hilliard wrote: >> It's also common practice for transit providers to use a single ASN >> spanning the globe e.g. 174, 2914, 3356, etc. What you're describing >> here is an aspect of the fact that that as

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

Jared Mauch wrote: > I know that Job has been pushing for the above, perhaps not in your view > but in the view of others here. definitely. It's been incredibly productive work, and his efforts have produced major results in terms of pushing IXPs towards filtering. This needs to be continued.

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

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 announcement passed through RS AS XYZ' other than > communities.

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

Christopher Morrow wrote: (who hopes to one day have better answers for this than: "err, ask the customer / peer which irr they use?" congrats, you just stood on the trust model dog turd. Right now we have the lolz model (anyone can put anything in any non-authoritative IRR and it will be

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

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. Has the IETF looked at how to work around this problem? If so, who is dealing with it? If

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

This errata report isn't wrong, but belongs to a bigger category of problems relating to how the IETF handles third party references in RFCs. It's unlikely that the researchgate url will be persistent in the longer term, at least any more than any other URL. Nick RFC Errata System wrote:

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

Job Snijders wrote on 11/06/2018 21:59: Please take a moment to read and evaluate the document and let the working group know whether you'd like to continue work on this document as working group or not. yep, sounds good, but what will this do to the vendors' two main weapons, fear and

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

Randy Bush wrote on 12/06/2018 19:12: job sugggested to add a clause recommending that operators not use 'set' at all to remove communities, but do it explicitly. the authors would appreciate comments on that. it strikes me as being a latter day "Go To Statement Considered Harmful" sort of

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

Randy Bush wrote on 13/06/2018 16:18: it strikes me as being a latter day "Go To Statement Considered Harmful" sort of thing. goto is harmful! just like many of the best things in life. am i supposed to replace set 666:42 with remove *:* add 666:42 like that's not gonna be

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

Thomas King wrote: > Hi Job, > > to be clear, my suggestion covers MC-LAGs and more importantly LAGs. reading between the lines, in the case of single-device LAGs, I'm guessing that you're talking about LAGs deployed over different line cards on larger chassis based network devices. On devices

Re: [GROW] Discourage asdot+/asdot?

Job Snijders wrote on 06/08/2018 20:35: I'm not the biggest fan of that philosophy. Especially because in the milions of objecst that exist in the combined IRR databases, it appears only four of them have something with ASDOT in the wrong place. right, you didn't mention that the 4 affected

Re: [GROW] Discourage asdot+/asdot?

Gert Doering wrote on 06/08/2018 23:08: It totally wrecked my nice AS3.3 into an ugly large number, but there was strong enough pushing that I was overruled. asdot was something that seemed like a good idea until the day that someone tried to use it in production :-| Nick

Re: [GROW] Discourage asdot+/asdot?

Job Snijders wrote on 06/08/2018 14:22> RFC 5396 https://tools.ietf.org/html/rfc5396 described the "asdot+" and "asdot" representation formats for AS numbers. I'd personally prefer a single canonical way to represent ASNs (asplain), and while RFC 5396 proposes the adoption of a decimal value

Re: [GROW] Discourage asdot+/asdot?

Daniel Shaw wrote on 10/08/2018 08:29: I think that on closer examination you may find the AFRINIC whois also changed around the same timeframe, perhaps a year later. It seems that there may be one (or possibly some other very small number of) test objects that did not get converted/clean-up.

Re: [GROW] I-D Action: draft-ietf-grow-rpki-as-cones-00.txt

This probably doesn't suck as an idea. One of the shortcomings of as-sets in RPSL was that there was no forward security when including as-sets. In other words, anyone could include any other AS or as-set in their own as-set. This allowed a good degree of flexibility, but could also create

Re: [GROW] WGLC: draft-ietf-grow-wkc-behavior - ENDS: Nov 27, 2018 (11/27/2018)

Christopher Morrow wrote on 06/11/2018 04:34: Please have a read/review/comment and let's see if we can close out and move forward by the end of the month. no comments to add. please publish. Nick ___ GROW mailing list GROW@ietf.org

Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

Jeffrey Haas wrote on 04/10/2018 20:51: Based on the primary use case for loc-rib (avoid the need for a parallel BGP session to your BMP rib-in session), I suspect what's intended is "send the route that's eligible to be sent to BGP". probably yes, although this may give an obscure view about

Re: [GROW] Making BMP registries FCFS

LGTM. No issues with waving this through with minimal bureaucracy. Nick Christopher Morrow wrote on 20/09/2018 21:33: Hello Grow Folks, This seems like a sane plan ... I or Job can either unilaterally accept this, or ask for adoption... If there's enough immediate call to avoid the 2wk

Re: [GROW] A question about RFC7854 stats report

Qing Yang wrote on 25/09/2018 19:53: But the 'rejected prefix due to a policy' really is a function of two entity: the incoming *updates*, and the policy itself. Let us say, you receive 10 prefixes from a peer, and the policy is rejecting 5, and you show the counter as 5. Later on, you change

  1   2   >