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
>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
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
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
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
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
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
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.
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
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.
This is great...the kind of inputs/insights I was hoping for.
Thank you :)
Sriram
From: Mark Tinka <mark.ti...@seacom.mu>
Sent: Wednesday, June 8, 2016 9:24 AM
To: nanog-p...@rsuc.gweep.net; Sriram, Kotikalapudi (Fed)
Cc: Job Snijders; nanog@nan
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
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
13 matches
Mail list logo
