IBM Cloud global outage caused by "incorrect" BGP routing
https://www.bleepingcomputer.com/news/technology/ibm-cloud-global-outage-caused-by-incorrect-bgp-routing/ -Hank Note: the views expressed above are my own and do not necessarily reflect the views of my employer
Re: six pages for rov issues
On Sat, 13 Jun 2020, Arnold Nipper wrote: > On 13.06.2020 21:20, Randy Bush wrote: > > chris at the ever fantastic six has done a stunning bit of work to let > > six members see rpki/irr announcement issues > > > >https://www.seattleix.net/rs-drops > > > Nice work! Very well done, Chris! > > You may also want to have a look at this article [0] where DE-CIX' > LGis explained. And it also provides a nice API. > views are different: SIX gives a good summary what happens on which RS, in particular wrt to filtering reasons. and the view of historic data is also beneficial. cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl
Re: six pages for rov issues
On 13.06.2020 21:20, Randy Bush wrote: > chris at the ever fantastic six has done a stunning bit of work to let > six members see rpki/irr announcement issues > >https://www.seattleix.net/rs-drops > Nice work! Very well done, Chris! You may also want to have a look at this article [0] where DE-CIX' LGis explained. And it also provides a nice API. Cheers Arnold [0] https://www.de-cix.net/de/resources/looking-glass -- Keep calm, keep distance, keep connected! Arnold Nipper email: arn...@nipper.de mobile: +49 172 2650958 signature.asc Description: OpenPGP digital signature
Re: ARIN
--- nanog@nanog.org wrote: I had to do several things in ARIN. The support has team was very quick responding, very useful with their recommendations to my questions, and had a great attitude towards solving problems. thank you all ARIN support desk -- I mentioned this the last time we had this conversation, but I want to say it again. As mentioned, folks are quick to complain and slow to compliment. So, I want to add a +1 to the original email. I am having my first dealings with them since about 10 years ago. And now, just like then, the support folks are stellar in their interaction with me. Thanks a LOT! :) scott
Re: ARIN
Well said my friend. Support often not gets the respect they deserve, when it comes to ARINthiugh a big shout out! Always outstanding. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jun 12, 2020, at 18:11, John Sweeting wrote: > > Thank you for taking time out to recognize the great team in RSD Mehmet! > The fact is they go above and beyond each and every day and it’s great to see > that pointed out. Lisa and her team are amazing. Thank you again. > > Sent from my iPhone > >>> On Jun 12, 2020, at 6:45 PM, Mehmet Akcin wrote: >>> >> >> hey there, >> >> I just wanted to share my experience dealing with ARIN support this week. I >> think it's not very common to see people taking the time to write something >> like this but I personally think we should do more often. >> >> It has been long time since I had to deal with RIRs and this week I had to >> do several things in ARIN. The support has team was very quick responding, >> very useful with their recommendations to my questions, and had a great >> attitude towards solving problems. I can certainly say they went above and >> beyond when I opened a ticket with wrong request type and they asked me if >> they can close it and open a new one for me? I mean.. this is called going >> Above and Beyond! >> >> thank you all ARIN support desk and especially Lisa Liedel for this great >> experience. and @John Curran please accept this sincere thanks on your >> team's behalf! >> >> Mehmet smime.p7s Description: S/MIME cryptographic signature
Re: six pages for rov issues
Thank you Randy -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jun 13, 2020, at 14:21, Randy Bush wrote: > > chris at the ever fantastic six has done a stunning bit of work to let > six members see rpki/irr announcement issues > > https://www.seattleix.net/rs-drops > > randy smime.p7s Description: S/MIME cryptographic signature
six pages for rov issues
chris at the ever fantastic six has done a stunning bit of work to let six members see rpki/irr announcement issues https://www.seattleix.net/rs-drops randy
Re: [c-nsp] LDPv6 Census Check
On 13/Jun/20 08:00, Saku Ytti wrote: > > ECMP appears to be your main pain point, the rich features are not > relevant, and you mentioned commodity hardware being able to hash on > IPIP. I feel this may be a very special case where HW can do IPIP hash > but not MPLSIP hash. Out of curiosity, what is this hardware? Jericho > can do MPLSIP, I know JNPR's pipeline offering, Paradise, can. Or > perhaps it's not even that the underlaying hardware you have, cannot > do, it's that the NOS you are being offered is so focused on your > use-case, it doesn't do anything else reasonably, then of course that > use-case is best by default. One of the biggest challenges we found of leveraging commodity hardware was locating a suitable OS that is not only fit-for-purpose in our service provider environment, but that could also leverage the hardware at its disposal to its fullest potential. It's hard enough for one vendor to get both their own hardware and software right most of the time. We posited it would be doubly hard for an operator to marry hardware and software vendors that do not necessarily co-ordinate with one another, if your goal is to run a profit-oriented operational network. Sure, the idea is great on paper, but there aren't that many shops that can throw warm bodies at this problem like some of the more established content and cloud folk. If it was easy, I certainly wouldn't have started this thread in the first place :-). Mark.
Re: [c-nsp] LDPv6 Census Check
On Fri, 12 Jun 2020 at 23:25, David Sinn wrote: > > Should we design a rational cost-efficient solution, we should choose > > the lowest overhead and narrowest working keys. > > In the abstract, sure. But if you want a practical, deployable, production > network, it's multi-dimensioned. We have probably largely converged to the same place. Your vantage point sees practical offerings where IPIP may make more sense to you than MPLS, my vantage point definitely only implements the rich features I need in MPLS tunnels (RSVP-TE, L2 pseudowires, FRR, L3 MPLS VPN, all of which technically could be done of course with IPIPIP tunnels) And the theory we agree that less is more. ECMP appears to be your main pain point, the rich features are not relevant, and you mentioned commodity hardware being able to hash on IPIP. I feel this may be a very special case where HW can do IPIP hash but not MPLSIP hash. Out of curiosity, what is this hardware? Jericho can do MPLSIP, I know JNPR's pipeline offering, Paradise, can. Or perhaps it's not even that the underlaying hardware you have, cannot do, it's that the NOS you are being offered is so focused on your use-case, it doesn't do anything else reasonably, then of course that use-case is best by default. -- ++ytti
