Does anyone have a sales contact at Google Fiber, looking for Dark fiber in
Pflugerville, TX back to Datafoundry TX1
Thanks
Rob
[photo]
[https://s3.amazonaws.com/images.wisestamp.com/symbols/frames/frame_bubble_left_top_part.png]
Robert DeVita
Managing Director, Mejeticks
95% sure that Google Fiber only sells access, not point to point or wave
services.
On Tue, Jul 9, 2019 at 9:30 AM Robert DeVita wrote:
> Does anyone have a sales contact at Google Fiber, looking for Dark fiber
> in Pflugerville, TX back to Datafoundry TX1
>
>
>
> Thanks
>
>
>
> Rob
>
>
>
>
>
> At a previous employer (AOL, doing VoIP for customer service / call
> centers, ~2004) we had a number of contractual agreements with
> multiple providers to honor our QoS markings -- as far as I could tell
> (marking test traffic under congestion events) only one of about seven
> did anything
On 9/Jul/19 16:01, Tom Beecher wrote:
>
>
> But if that language was inserted into the contracts, and you can
> demonstrably prove it's not being done, enforcing contract terms
> should always be done. Depending on the strength of the remedy, could
> have been a lot of free service, enough
On 9/Jul/19 16:08, Joe Yabuki wrote:
> Hi all,
>
> Thanks for your replies,
>
> I'll rephrase just to clarify, our aim is to do QoS within our
> extended LAN (From remote sites to the Datacenter using the MPLS
> provider as transit) - and we can't use DIA for a security reasons...
>
> So
On 9/Jul/19 01:00, Keith Medcalf wrote:
> Using Orifice 342 will hurt you.
Can't choose what my customers like :-).
Mark.
To quote from that URL:
QoS only works as expected when implemented on all links between
callers. If you use QoS
on an internal network and a user signs in from a remote location,
you can only prioritize within
your internal, managed network.
Mark.
On 9/Jul/19 02:41, cyrus ramirez
On Mon, Jul 8, 2019, at 18:15, Joe Yabuki wrote:
> Hi all,
>
> How do you deal with QoS for Office365, since the IPs are subject to changes ?
For "Classic QoS" : you don't. At best you tell the customer it's done without
actually doing anything (it very often works). If it doesn't, see
On Tue, 9 Jul 2019 at 17:05, Tom Beecher wrote:
> Generally speaking, I agree that making QoS features work consistently on an
> external network you do not control is a fool's errand.
>
> But if that language was inserted into the contracts, and you can
> demonstrably prove it's not being
On 9/Jul/19 16:18, Ross Tajvar wrote:
> I think the difficulty lies in appropriately marking the traffic. Like
> Joe said, the IPs are always changing.
Does anyone know if they are reasonably static in an Express Route scenario?
Mark.
On Tue, 09 Jul 2019 17:16:52 +0300, Saku Ytti said:
> In previous life working with L3 MPLS VPN with deliveries far
> exceeding on-net size we bought access from partners and had QoS
> contracts in place, which were tested and enforced and they worked
> after some ironing during field trials.
On 9/Jul/19 16:37, Valdis Kl ē tnieks wrote:
> I'll bite.
>
> It's one thing to verify that no routers molested the QoS bits along the
> packet path.
>
> But how did you verify they "worked" as far as actually dropping packets off
> the correct flow (especially since if you have a high-priority
On Tue, 9 Jul 2019 at 17:37, Valdis Klētnieks wrote:
> But how did you verify they "worked" as far as actually dropping packets off
> the correct flow (especially since if you have a high-priority QoS, the flow
> that
> loses may be some other customer's flow)?
By congesting queues and
back on track to stir/shaken
would a service provider also need to implement this? or its for the big
carriers to do ?
On Mon, Jul 8, 2019 at 11:17 PM Michael Thomas wrote:
>
> On 7/8/19 7:11 PM, Christopher Morrow wrote:
> > when do we get back to stir/shaken?
>
> that would be nice. i have a
Hey Tom
> That's already been happening. OpenSSH pulled that stunt in 7.8.
OpenSSH always coloured interactive and non-interactive SSH. They just
used original TOS definition, which no one has used in the field, not
in the last 20 years at any rate. And which devices actually cannot
even match
I think the difficulty lies in appropriately marking the traffic. Like Joe
said, the IPs are always changing.
On Tue, Jul 9, 2019, 9:15 AM Mark Tinka wrote:
>
>
> On 9/Jul/19 16:08, Joe Yabuki wrote:
> > Hi all,
> >
> > Thanks for your replies,
> >
> > I'll rephrase just to clarify, our aim is
On 7/8/19 4:01 PM, adamv0...@netconsultings.com wrote:
And yet the SD-WAN promising MPLS experience over the internet and other BS
sells like crazy;)
To be fair, there are some folks who operate national or global big-I
Internet IP networks that do guarantee QoS as long as you stay on their
On 9/Jul/19 16:16, Saku Ytti wrote:
> In previous life working with L3 MPLS VPN with deliveries far
> exceeding on-net size we bought access from partners and had QoS
> contracts in place, which were tested and enforced and they worked
> after some ironing during field trials.
> Usually
On 9/Jul/19 16:23, Brandon Martin wrote:
>
> To be fair, there are some folks who operate national or global big-I
> Internet IP networks that do guarantee QoS as long as you stay on
> their network.
Yes, which is the point... as long as the traffic is on-net, you can
guarantee things.
Hi all,
Thanks for your replies,
I'll rephrase just to clarify, our aim is to do QoS within our extended LAN
(From remote sites to the Datacenter using the MPLS provider as transit) -
and we can't use DIA for a security reasons...
So arguably, we still need to mark/queue/police packets at the
Even if QoS on the Internet was possible it would be destroyed by everyone
marking all their traffic with the highest priority to get the best
performance. Tragedy of the commons.
-Original Message-
From: NANOG On Behalf Of Mark Tinka
Sent: Monday, July 8, 2019 10:40 AM
To:
On 9/Jul/19 16:46, Steve Mikulasik wrote:
> Even if QoS on the Internet was possible it would be destroyed by everyone
> marking all their traffic with the highest priority to get the best
> performance. Tragedy of the commons.
I kind of like the Internet the way it is. The best-effort
> On Jul 9, 2019, at 07:19, Mark Tinka wrote:
>
>
>
> On 9/Jul/19 16:18, Ross Tajvar wrote:
>> I think the difficulty lies in appropriately marking the traffic. Like
>> Joe said, the IPs are always changing.
>
> Does anyone know if they are reasonably static in an Express Route scenario?
That's already been happening. OpenSSH pulled that stunt in 7.8.
https://www.openssh.com/txt/release-7.8
ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed.
They will now use DSCP AF21 for interactive traffic and CS1 for
bulk. For a detailed rationale, please see the commit
On Tue, 9 Jul 2019, Mark Tinka wrote:
On 9/Jul/19 16:18, Ross Tajvar wrote:
I think the difficulty lies in appropriately marking the traffic. Like
Joe said, the IPs are always changing.
Does anyone know if they are reasonably static in an Express Route scenario?
At least sometimes M$ says
Hello,
I released the first major version of rVRRPd, an open source and
RFC3768-compliant VRRPv2 daemon. It actually only supports Linux but I
will soon be adding support for additional operating systems and platforms.
rVRRPd was born from my desire to develop skills in system development.
I
I respectfully just don't agree on that. In my view, software should
default to not setting those bits to anything by default, but should have
configuration options that allow them to be set if required. Every network
is different, and making assumptions based on RFC SHOULD's is an
unfortunate
On 09/07/2019 16:27, Jay Ford wrote:
On Tue, 9 Jul 2019, Mark Tinka wrote:
On 9/Jul/19 16:18, Ross Tajvar wrote:
I think the difficulty lies in appropriately marking the traffic. Like
Joe said, the IPs are always changing.
Does anyone know if they are reasonably static in an Express Route
On Tue, 9 Jul 2019 at 18:50, Tom Beecher wrote:
> I respectfully just don't agree on that. In my view, software should default
> to not setting those bits to anything by default, but should have
> configuration options that allow them to be set if required. Every network is
> different, and
Have you looked into Cisco’s SD-AVC? Also with the o365 connector?
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/avc/sd-avc/2-1-0/ug/sd-avc-2-1-0-ug.pdf
On Jul 2, 2019, at 17:18, Joe Yabuki wrote:
Hi all,
How do you deal with QoS for Office365, since the IPs are subject to changes ?
The agenda for the SHAKEN/STIR robocall summit was published today.
Date: Thursday, July 11, 2019
Time: 9:30 a.m. to 3:30 p.m.
Location: Commission Meeting Room at FCC Headquarters
It will also be live-streamed on the FCC web site.
On Tue, Jul 9, 2019 at 10:02 AM Tom Beecher wrote:
>>
>> At a previous employer (AOL, doing VoIP for customer service / call
>> centers, ~2004) we had a number of contractual agreements with
>> multiple providers to honor our QoS markings -- as far as I could tell
>> (marking test traffic under
On 9/Jul/19 17:06, Joel Jaeggli wrote:
> Express route peering with 12076 gives you more specific routes then you
> would otherwise see from 8075 (a /13 becomes a bunch of 17s etc) . it also
> gives you control over what region / application is exported to you.
As I had assumed.
But of
I looked back into work email from back then and I see where I made my
mistake. I had misread the 7.4 change where they added the option for allow
IPQoS=none , apparently my brain just skipped the word 'option', and it
stuck in my brain as the default behavior being 'none'. That's
embarrassing,
That’s why you do QoS between the customer’s packets not every packet.
> On 10 Jul 2019, at 12:46 am, Steve Mikulasik via NANOG
> wrote:
>
> Even if QoS on the Internet was possible it would be destroyed by everyone
> marking all their traffic with the highest priority to get the best
>
:How do you deal with QoS for Office365, since the IPs are subject to changes ?
How often is the data in:
https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service
out of date?
-Mike
--
> On Jul 9, 2019, at 9:19 AM, Mark Tinka wrote:
>
>
>
>> On 9/Jul/19 16:18, Ross Tajvar wrote:
>> I think the difficulty lies in appropriately marking the traffic. Like
>> Joe said, the IPs are always changing.
>
> Does anyone know if they are reasonably static in an Express Route scenario?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
Verisign is in the process of increasing the size and strength of
the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that
it operates. As part of this process, the ZSK for the .ARPA zone
will be increased in size from 1024 to 2048
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
Verisign is in the process of increasing the size and strength of
the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that
it operates. As part of this process, the ZSK for the .NET zone
will be increased in size from 1024 to 1280
39 matches
Mail list logo
