Re: [GROW] Question about mutual transit and complex BGP peering

Sriram, Kotikalapudi (Fed) wrote on 21/04/2024 16:53: Q1: Consider an AS peering relationship that is complex (or hybrid) meaning, for example, provider-to-customer (P2C) for one set of prefixes and lateral peers (i.e., transit-free peer-to-peer (P2P)) for another set of prefixes. Are these

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

Hi Tobias, WG, Diff from rfc7454 as follows: https://author-tools.ietf.org/iddiff?url1=rfc7454=draft-ietf-grow-bgpopsecupd-01=--html There are quite a lot of changes there and I'm going to make a bunch of specific comments about the text changes in this ID in separate emails, but want to

Re: [GROW] [Technical Errata Reported] RFC2622 (7564)

The erratum looks valid to me. "aut-num: AS1" defines a routing policy for AS1. The two peering sets specify the IP address of the local router in question (i.e. of AS1) as being 9.9.9.1.  The description in the line above example 7 states that 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 (AS2)

Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

Job Snijders wrote on 21/07/2022 10:37: In the spirit of RFC6472, any route with an AS_SET in it should not be considered valid (by ASPA-based validation). An AS_SET inside an AS_SEQUENCE only makes sense from the point of view of the organisation issuing the route wanting to do weird EBGP

Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

Sriram, Kotikalapudi (Fed) wrote on 19/07/2022 22:24: Question: Operationally, is an AS_SET ever used in the*middle* between AS_SEQUENCEs? Or, should one simply give zero credence to it? tl;dr: epsilon levels of credence. in the context of EBGP connectivity, on the internet, having an AS_SET

Re: [GROW] [Sidrops] IXP Route Server question

Sriram, Kotikalapudi (Fed) wrote on 13/03/2022 16:20: Not sure why Ben even raised that question. To me, it doesn't seem relevant. In the route leak detection procedures, the receiving/validating AS does not require information about the nature of ASes (RS or not RS) in the AS Path except for

Re: [GROW] IXP Route Server question

Ben Maddison wrote on 11/03/2022 07:23: Essential, I would think: how could a far end relying party know that an AS in the middle of a received AS_PATH is a non-transparent IXP RS in order to apply any other treatment? given that they're a shrinking rarity, would it not make sense to

Re: [GROW] IXP Route Server question

Sriram, Kotikalapudi (Fed) wrote on 10/03/2022 03:31: Nick and all, Thank you. What you all shared/discussed is very useful info. Almost all RS's are transparent these days. Usually IXPs go to lengths to ensure that the RS ASN doesn't appear in the AS path. Good to know that. Well, that

Re: [GROW] IXP Route Server question

Sriram, Kotikalapudi (Fed) wrote on 08/03/2022 19:36: This question has relevance to the ASPA method for route leak detection. Is it possible that an ISP AS A peers with a customer AS C via a non-transparent IXP AS B? IOW, the AS path in routes propagated by the ISP A for customer C's prefixes

Re: [GROW] some questions from {RC, LC, EC} analysis presentation in GROW

Sriram, Kotikalapudi (Fed) wrote on 03/08/2021 16:14: Response: We welcome any ideas that may help compile RC/LC/EC application types and their propagation requirements to perform measurements against them. Also, it is good to follow Ruediger’s suggestion and have a GROW document that provides

Re: [GROW] BGP Looking Glass Capability

Rayhaan Jaufeerally (IETF) wrote on 26/07/2021 18:54: Yes that is what I was trying to do with the router query parameter from RFC8522, and once you know which "router" or PoP to query, my assumption would be that if you peer with any ASBR in that PoP then the looking glass should, if the

Re: [GROW] BGP Looking Glass Capability

Robert Raszuk wrote on 26/07/2021 00:04: I am still not sure what is wrong using DNS for this type of discovery. If I were to tackle this problem I would start with DNS. ^^^ this, but I'm not convinced that dynamic discovery of LG endpoints is a pressing issue to start with. What's more

Re: [GROW] BGP Looking Glass Capability

Robert Raszuk wrote on 25/04/2021 16:08: Would you allow to query yr router via such API to anyone in the world ? That's a policy decision for the operator. In practice, we expose some bits of the API to the public, but other parts are kept private. For example, here's a list of bgp peers

Re: [GROW] BGP Looking Glass Capability

Rayhaan Jaufeerally (IETF) wrote on 24/04/2021 14:38: I would like to propose draft-jaufeerally-bgp-lg-cap-00 (https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a mechanism for in-band dissemination of looking glass endpoints in BGP, using a new OPEN message capability. Hi

Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt

thomas.g...@swisscom.com wrote on 08/03/2021 06:19: The BGP as-path array could be potentially be exposed with code points from the private enterprise number space. If that would be the case than same operational considerations would apply than in RFC 8549 section 7 described since BGP

Re: [GROW] [WG ADOPTION]: draft-mcbride-grow-as-path-prepend-01 - ENDS 08/12/2020 (Aug 12)

Christopher Morrow wrote on 29/07/2020 18:17: This work seems directly in the GROW wheelhouse, and it appears folk on-list agree. Let's decide with a WG Adoption call for this document and see if we should continue this work officially/etc. sounds good for adoption. Nick

Re: [GROW] AS_Path prepend BCP

Michael McBride wrote on 26/07/2020 19:42: We have submitted https://datatracker.ietf.org/doc/draft-mcbride-grow-as-path-prepend/ which is intended to be a bcp in the use of AS_Path prepend based on work of Doug Madory. As we state in the intro: AS_Path prepending is discussed in Use of BGP

Re: [GROW] grow - Requested session has been scheduled for IETF 108

"IETF Secretariat" wrote on 03/07/2020 01:20: grow Session 1 (1:40 requested) Monday, 27 July 2020, Session III 1410-1550 Is this UTC? Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Measurements on Regular, Extended, and Large Communities

Sriram, Kotikalapudi (Fed) wrote on 24/04/2020 14:14: ** Question: Any insights why we don't see any ECs at all? ** possibilities: - there are many types of EC and router config grammar is implemented inconsistently across different platforms, and there's no guarantee that the grammar is

Re: [GROW] Playing with origin validation

Robert Raszuk wrote on 12/04/2020 22:21: Pretty bad that routers have no options to distinguish one vs the other state when performing origin validation. from a practical point of view, does it matter? There are too many prefixes out there to want to bother micromanaging things. The

Re: [GROW] Playing with origin validation

Robert Raszuk wrote on 12/04/2020 19:39: As I see similar discrepancies in many global networks I would like to ask who to trust ? If RPKI data is not valid then I think we have a real problem. generally, rpki-invalid is dropped fairly early on in policy evaluation chains. This means that

Re: [GROW] Question about BGP Large Communities

Zhuangshunwan wrote on 05/02/2020 09:00: In my opinion, when we apply a new function from IANA, we will have to deploy some extra route policies to set and parse the specific function as your suggested way. With the increase of new functions, the route policies deployed will become more and

Re: [GROW] Proposed updates to GROW charter

Gert Doering wrote on 03/11/2019 19:15: 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

Re: [GROW] Proposed updates to GROW charter

Job Snijders wrote on 29/10/2019 00:10: My hope is that the proposed update aligns our description with our activities. It does, but it also aligns with lots of other things. Too generic is not a good thing. That said, GROW fulfils an important niche at IETF, not just for producing its

Re: [GROW] Proposed updates to GROW charter

Job Snijders wrote on 28/10/2019 19:21: It is entirely possible we've overlooked something, we'd love your feedback on the below charter, goals & milestones. Please share on-list or off-list withgrow-cha...@ietf.org The old goals were oddly specific; the new goals are oddly non-specific. I'm

Re: [GROW] Limiting AS path length?

Iljitsch van Beijnum wrote on 16/09/2019 22:54: In theory, yes. In practice, how does that work? Suppose I prepend 250 times, and a few hops away, routers start to explode because they hit 255 or 256 ASes in the path? How do these people debug the issue? Once they know the problem, how do they

Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

Sriram, Kotikalapudi (Fed) wrote on 07/08/2019 18:42: The authors have revised and uploaded a new version (-14). Your inputs/comments are welcome. In particular, please share any specific operational considerations/concerns you may have regarding this topic. It would be great if this were to

Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation

Brian Dickson wrote on 15/06/2019 00:42: Please take a look and, if you think this is an important problem to fix (route leaks), add your voice here. there are two things here: route leaks (important), and the proposal in draft-ietf-grow-route-leak-detection-mitigation. We can probably all

Re: [GROW] working group last call draft-ietf-grow-bmp-adj-rib-out (ends 2018.11.26)

Job Snijders wrote on 01/12/2018 17:02: We have only three (positive) responses so far, I’ll let the WGLC run December 7th to allow opportunity for more responses. lgtm. Nick ___ GROW mailing list GROW@ietf.org

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] 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

Re: [GROW] A question about RFC7854 stats report

Qing Yang wrote on 25/09/2018 18:34: Does anyone know the reason why this is a counter as versus a gauge? Notice for all other types, when the 'number of prefixes/routes' is involved (type 7, 8, 9, 10), they are all defined as gauge, which can increment or decrement, and makes sense to me, as

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

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] 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] 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

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] [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] 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)

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] 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] 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] 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] 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] 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

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

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] 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

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] [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] 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] 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] 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] 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] 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] 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] 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] 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] 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.

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] 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] [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] [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] [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] [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 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

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] 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] 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] 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] 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] 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] 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] 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] 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: > 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)

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] 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] 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] 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: > 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

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] 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

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] 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] 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

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] 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

  1   2   >