intra-AS messaging for route leak prevention

I am a co-author on a route-leak detection/mitigation/prevention draft in the IDR WG in the IETF: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03 Based on private conversations with a few major ISPs, the following common practice for intra-AS messaging (using Commu

Re: intra-AS messaging for route leak prevention

Thanks for the inputs about the inter-AS messaging and route-leak prevention techniques between neighboring ASes. Certainly helpful information and also useful for the draft (draft-ietf-idr-route-leak-detection-mitigation). However, my question was focused on "intra-AS" messaging. About conveying

Re: intra-AS messaging for route leak prevention

This is great...the kind of inputs/insights I was hoping for. Thank you :) Sriram From: Mark Tinka Sent: Wednesday, June 8, 2016 9:24 AM To: nanog-p...@rsuc.gweep.net; Sriram, Kotikalapudi (Fed) Cc: Job Snijders; nanog@nanog.org Subject: Re: intra-AS

BGP route processing speed

I am interested in measurements related to BGP route processing speed (i.e. routing engine capacity in terms of routes or updates processed per second). Folks from AMS-IX did an interesting study in 2012 in their Route Server / IXP environment. https://ams-ix.net/downloads/ams-ix-route-server-

RE: BGP route processing speed

s (e.g. Table 2, p. 38) for route servers are interesting and also consistent with the AMS-IX study in 2012 (the latter in realistic IXP scenarios). But I am still interested in any pointers to BGP router measurements in ISP/provider edge scenarios. Sriram >Sriram, Kotikalapudi (Fed

Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?

Nusenu, I also found your analysis very interesting and useful. Thanks for that. >What do you think about adding graphs that show the amount of actually >unreachable prefixes and IP space? (prefix where no alternative valid/unknown >announcement exists) I am also part of the NIST BGP team. Dou

NIST RPKI Monitor version 2.0

We (NIST) have released a new version of the NIST RPKI Monitor (v2.0): https://www.nist.gov/services-resources/software/nist-rpki-deployment-monitor We are open to adding more features and analyses based on user feedback. Your comments/suggestions are welcome. Thank you. Sriram

AS 3356 (Level 3) -- Community 3356:666

There is an old NANOG thread from 2005 that said AS 3356 (Level 3) were applying 3356:666 to indicate Peer route: https://archive.nanog.org/mailinglist/mailarchives/old_archive/2005-12/msg00280.html Also, see: https://onestep.net/communities/as3356/ Now network operators commonly use ASN:666 for

Re: AS 3356 (Level 3) -- Community 3356:666

>And it's also nice not to yank the old community in case your customers still >depend on it, even if you do also support the RFC version as an alias of that >one. That seems to be the case. Also, possibly the use of WKC 65535:666 has not picked up much. We observe that out of a total of 264,55

Re: AS hijacking (Philosophy, rants, GeoMind)

Mike, >As our canned Email stated, AS2 (and many low digit AS') get hijacked and >often go on to hijack someone's prefix. AS2 (proper) is rarely changed and >the chances of an actual prefix hijack from it is extremely low. > >So as I've asked our peers, I'll ask here: What is expected of us to be

Re: Analysing traffic in context of rejecting RPKI invalids using pmacct

Jay: >When we (as7018) were preparing to begin dropping invalid routes >received from peers earlier this year, that is exactly the kind of >analysis we did. In our case we rolled our own with a two-pass >process: we first found all the traffic to/from invalid routes by a >bgp community we gave th

Re: SP 800-189 (Draft), Resilient Interdomain Traffic Exchange

I think Doug has already pointed to this: Email for comments: sp800-...@nist.gov mentioned in the link: https://csrc.nist.gov/publications/detail/sp/800-189/draft We are thankful that many helpful comments/suggestions were received from ISPs, other organizations and individuals earlier on the

Question about mutual transit and complex BGP peering

Requesting responses to the following questions. Would be helpful in some IETF work in progress. 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)

RE: Question about the use of NO_EXPORT in BGP route announcements

s as needed for traffic engineering." Sriram [1] BCP 84 (RFC 8704) https://www.rfc-editor.org/rfc/rfc8704.pdf [2] BAR-SAV: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-bar-sav-04 From: Jeff Bartig Sent: Wednesday, September 25, 2024 1:24 PM To: Sriram, Kotikalapudi (Fed) Cc: nan

Question about the use of NO_EXPORT in BGP route announcements

For some IETF work in progress related to Source Address Validation (SAV), it is useful to know the purposes for which NO_EXPORT may be attached to routes announced in BGP, especially towards transit providers? I know it makes sense for an AS to announce an aggregate less-specific prefix to tra