Re: New addresses for b.root-servers.net
Mark Andrews wrote: The commitment to maintain service for 1 year after the new LACNIC addresses are switched in to the root.hints from IANA does not mean that this is a cutoff date and that we intend to turn off service on the older addresses after a year. We currently have no plans to do so for the foreseeable future. In fact, the possibility has not even been suggested or discussed at all. Such total lack of advance and public discussion and preparation on a substantial change on critical infrastructure is a serious problem, I'm afraid. I'm curious about what more discussion you want to happen than has happen in the past. Over the last 20 years there have been lots of address changes. If such changes are performed without proper transition plans even after DNS became critical infrastructure (when?), they also are serious problems. None of them have caused operational problems. Thank you for a devil's proof. That you haven't noticed any problem does not mean there actually was no problem. Masataka Ohta
Re: 365 Datacenters Tampa AC Failure
Hello all, >From our side (365 Data Centers) We saw the issue start at a little after 6:30 >PM yesterday. We had a component failure and we saw a rise in temperature. We >brought additional capacity online while we were working with our vendors on >getting replacement hardware. The hardware has now been replaced and the system is back online. This unit and others in this suite are on the block for replacement this year as we add cooling capacity to our various spaces within the Franklin Exchange building. On a side note, this was not related to the issue mentioned from earlier in the month. This was a straight component failure and replacement. Any customers impacted can reach out to the 365 Customer Service Center for details and documentation. Thank you, James Ashton VP Network Engineering 365 Data Centers From: "NANOG mailing list" To: "George Herbert" Cc: "NANOG mailing list" Sent: Monday, June 12, 2023 8:03:10 PM Subject: Re: 365 Datacenters Tampa AC Failure Issue started a little after 2am, I was hard down till about 11:30am (servers did a high temp shutdown) On Jun 12, 2023 8:01 PM, Michael Spears wrote: Yep there's issues over there. They had some compressors go down. Should be getting back to normal now... Hasn't been a good month for them in regards to cooling.. On Jun 12, 2023 7:15 PM, George Herbert wrote: BQ_BEGIN Oof. Get ready to replace all spinning media you may have there. -George Sent from my iPhone > On Jun 12, 2023, at 4:06 PM, Nick Olsen wrote: > > > Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently seeing > floor temps of ~105F as reported by equipment. Started yesterday at ~5:30PM > eastern. 2nd AC failure in the last 30 days. They have not sent any advisory > notices as of yet. BQ_END
Re: 365 Datacenters Tampa AC Failure
Is this the building with the lizard mural? On Mon, Jun 12, 2023 at 4:03 PM Nick Olsen wrote: > Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently > seeing floor temps of ~105F as reported by equipment. Started yesterday at > ~5:30PM eastern. 2nd AC failure in the last 30 days. They have not sent any > advisory notices as of yet. > -- -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
What is going on with BGP
A brief overview of developments happening in the IETF working groups related to BGP evolution. The view is current as of mid-2023, in the timeframe between IETF meetings 116 and 117, and looking back several years to cover the recently published documents. The overview is given from the perspective of development of the protocol mechanics and recommended operational considerations, and is not directly related to specific implementation aspects of specific platforms – for that you would need to consult your vendors’ documentation. It is not expected that all of the functionality described here will be universally productized, as well as there will be specific deviations and extensions to functionality implemented by different vendors as seen required by the market. This is not an end to end overview of BGP, instead it focuses on specific protocol changes and therefore it is assumed that a reader has a sufficient understanding of foundations of BGP and its supporting machinery. It is a high level overview and does not go deep into the specifics, pointers to documents are provided for further and more detailed view into the topics under the discussion. This part covers the core protocol part and mechanisms specific to IPv4 unicast and IPv6 unicast AFs. Deprecation of AS path aggregation sets (draft-ietf-idr-deprecate-as-set-confed-set). When aggregating multiple prefixes with different ASNs into a shorter covering prefix, besides other aggregation related path attributes, the ASN identifiers of component prefixes are contained in an unordered structure which has a different type than the ordered ASN sequence of the AS path attribute. The need for such a structure is to avoid possible propagation loops due to missing information on which ASNs the update has traversed previously. However such an approach obfuscates the real origin and prefix lengths of component prefixes and as a result is directly incompatible with the developments in global routing security mechanisms. Also it is yet another influencing aspect into possible attribute packing conflicts due to different interpretations of what an unordered set of ASNs in fact means. Therefore aggregation resulting in generation of ASN sets (AS_SET and AS_CONFED_SET segments in AS path attribute) is deprecated and should not be used. Receipt of an update carrying such segments should be treated as a withdraw due to a recoverable error (RFC7606), and no announcements carrying ASN set segments can be advertised. This does not deprecate the aggregation of component prefixes as such, but only the generation of ASN set segments. Both aggregation within an AS and proxy aggregation can be deployed as designed, and the fact of aggregation is indicated by the AGGREGATOR path attribute carrying the ASN and RID of the node that performed the aggregation – same as before, just omitting the addition of ASN set segment. The loop avoidance is ensured by controlling the advertisement of the resulting covering aggregate prefix – it must not be advertised to any of the origins of component prefixes. Overall this is not a new concept, RFC6472 recommended against advertising ASN sets but did not change the behaviour of the receiving side. The amount of ASN sets seen in the global routing system is small enough (such cases do exist, but they are a clear exception or simply a neglect to clean the configuration up) to justify a more strict set of rules that would remove the ambiguity of interpretation of prefix origin. Extended messages (RFC 8654). BGP message size is limited to 4096 octets (PDU size should not be confused with link and packet layer MTU sizes and transport window size), and that might not be enough in some cases. BGP PDUs do not have any mechanism for fragmentation, and therefore a set of path attributes that does not fit into the message cannot be advertised at all. In addition, attribute packing is an efficient way of speeding up the convergence of BGP, and the PDU size limitation puts an upper bound on the balance of how many NLRIs can be advertised together with the path attributes. New address families may carry larger NLRI elements and contain more or larger attributes, and therefore 4K octet limit may be not enough. BGP message encoding allows for a larger size, it is a historical limit that is now being lifted. Extended messages mechanism defines a new capability that needs to be configured and exchanged between the peers and if both sides agree, they can use messages up to 65535 octets for BGP signalling. Open message is excluded for backwards compatibility reasons, and a large keepalive message just does not make practical sense. Update, notification, refresh signalling, and potentially other newly defined messages may use this mechanism for exchanging both larger size objects and larger amounts of objects. Of particular note is the handling of notification message – while the overall size of the message now may be larger, so can be the size of notif
Re: 365 Datacenters Tampa AC Failure
Issue started a little after 2am, I was hard down till about 11:30am (servers did a high temp shutdown)On Jun 12, 2023 8:01 PM, Michael Spears wrote:Yep there's issues over there. They had some compressors go down. Should be getting back to normal now... Hasn't been a good month for them in regards to cooling..On Jun 12, 2023 7:15 PM, George Herbert wrote:Oof. Get ready to replace all spinning media you may have there. -George Sent from my iPhone > On Jun 12, 2023, at 4:06 PM, Nick Olsen wrote: > > > Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently seeing floor temps of ~105F as reported by equipment. Started yesterday at ~5:30PM eastern. 2nd AC failure in the last 30 days. They have not sent any advisory notices as of yet.
Re: 365 Datacenters Tampa AC Failure
Yep there's issues over there. They had some compressors go down. Should be getting back to normal now... Hasn't been a good month for them in regards to cooling..On Jun 12, 2023 7:15 PM, George Herbert wrote:Oof. Get ready to replace all spinning media you may have there. -George Sent from my iPhone > On Jun 12, 2023, at 4:06 PM, Nick Olsen wrote: > > > Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently seeing floor temps of ~105F as reported by equipment. Started yesterday at ~5:30PM eastern. 2nd AC failure in the last 30 days. They have not sent any advisory notices as of yet.
Re: 365 Datacenters Tampa AC Failure
Oof. Get ready to replace all spinning media you may have there. -George Sent from my iPhone > On Jun 12, 2023, at 4:06 PM, Nick Olsen wrote: > > > Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently seeing > floor temps of ~105F as reported by equipment. Started yesterday at ~5:30PM > eastern. 2nd AC failure in the last 30 days. They have not sent any advisory > notices as of yet.
Re: BGP routing ARIN space in APNIC region
> I've seen it at recent RIPE and LACNIC conferences. Supposedly all of > the big geolocation providers support it or are planning on supporting > it. Possibly relevant there: https://geolocatemuch.com/ -- Hugo Slabbert On Sun, Jun 11, 2023 at 10:56 AM Randy Bush wrote: > > Everyone should check out Massimo Candela's presentation "Geolocation > > problems: Do we have a solution?" for how to provide your own > > geolocation data... > > > > https://www.netnod.se/sites/default/files/2023-03/Massimo_Webpage.pdf > > > > I've seen it at recent RIPE and LACNIC conferences. Supposedly all of > > the big geolocation providers support it or are planning on supporting > > it. > > we're working on an small update. see > >https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/ > > randy >
Re: Do ISP's collect and analyze traffic of users?
>> As a decent sized north American ISP I think I need totally agree with this >> post. There simply is not any economically justifiable reason to collect >> customer data, doing so is expensive, and unless you are trying to traffic >> shape like a cell carrier > They shape? News to me... You can find this in their respective network management disclosures. Most typically it is bitrate shaping of OTT video traffic. JL
365 Datacenters Tampa AC Failure
Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently seeing floor temps of ~105F as reported by equipment. Started yesterday at ~5:30PM eastern. 2nd AC failure in the last 30 days. They have not sent any advisory notices as of yet.
