Google Fiber

[Robert DeVita]

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
[https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/linkedin.png]
[https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/twitter.png]
[https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/phone2.png]  
214-305-2444
[https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/mobile.png]  
469-441-8864
[https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/email1.png]  
radev...@mejeticks.com
[https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/website.png]  
www.mejeticks.com
[https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/address1.png] 
 1919 McKinney Ave, Dallas, TX 75201

Re: Google Fiber

[Tom Beecher]

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
>
>
>
> [image: photo]
>
> [image:
> https://s3.amazonaws.com/images.wisestamp.com/symbols/frames/frame_bubble_left_top_part.png]
>
> Robert DeVita
> Managing Director, Mejeticks
>
> [image:
> https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/linkedin.png]
> 
>
> [image: https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/twitter.png]
> 
>
> [image:
> https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/phone2.png]
>   214-305-2444 <214-305-2444>
>
> [image:
> https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/mobile.png]
>   469-441-8864 <469-441-8864>
>
> [image:
> https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/email1.png]
>   radev...@mejeticks.com 
>
> [image:
> https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/website.png]
>   www.mejeticks.com 
>
> [image:
> https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/address1.png]
>   1919 McKinney Ave, Dallas, TX 75201
>
>
>
>
>

Re: QoS for Office365

[Tom Beecher]

>
> 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 at all with the marking, and that wasn't enough to make
> any difference... I briefly toyed with the idea of asking for some
> money back / trying to enforce the terms of the agreements, but
> figured that there wasn't much point - expecting QoS to work in
> someone else's network based upon your markings seems like a fool's
> errand.
>

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 done, enforcing contract terms should
always be done. Depending on the strength of the remedy, could have been a
lot of free service, enough financial incentive for them to MAKE it work
correctly, or leverage to open renegotiations for more favorable terms for
you.

You know that in reverse they would have done the same to you. :)

On Mon, Jul 8, 2019 at 6:38 PM Warren Kumari  wrote:

> On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka  wrote:
> >
> >
> >
> > On 8/Jul/19 21:03, Robert Webb wrote:
> > > I took the OP's request as for doing QoS at the edge of their network
> > > and not necessarily the entire path.
> >
> > Indeed, but even then, you could be handing off the traffic to a
> > downstream customer, and can't guarantee what they do to those ToS
> fields.
>
> I disagree -- you *can* guarantee what someone else will do with your
> ToS fields... they will A: ignore them and / or B: scribble all
> over them.
>
> 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 at all with the marking, and that wasn't enough to make
> any difference... I briefly toyed with the idea of asking for some
> money back / trying to enforce the terms of the agreements, but
> figured that there wasn't much point - expecting QoS to work in
> someone else's network based upon your markings seems like a fool's
> errand.
>
> W
>
> >
> >
> > >
> > > As another person stated, the real answer is to add more bandwidth if
> > > you are having to QoS to Office365 because it is affecting other
> > > internet based services.
> >
> > Yes and no.
> >
> > More bandwidth never hurt anyone, but packet loss in the remote network
> > toward the cloud will hurt you.
> >
> > Mark.
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>

Re: QoS for Office365

[Mark Tinka]

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 financial incentive for them
> to MAKE it work correctly, or leverage to open renegotiations for more
> favorable terms for you.

Perhaps plenty of service credits. Anything else would just burn too
much time on either end for no practical outcome.

Mark.

Re: QoS for Office365

[Mark Tinka]

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 arguably, we still need to mark/queue/police packets at the Edge of
> the Internet and on the remote site. For INTERNET we will throw
> bandwidth so it will not be a point of congestion (hopefully once we
> are in the Backbone's ISP we will go to Microsoft directly)

In that case, co-ordinate the QoS profile with your MPLS provider and
test both ends to make sure you receive what you send for on-net traffic.

Verifying that your MPLS provider is forwarding your traffic according
to the agreed-upon QoS profile is another thing.

As for the off-net traffic entering your network, well, you know about
that already...

Mark.

Re: QoS for Office365

[Saku Ytti]

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 done, enforcing contract terms should 
> always be done. Depending on the strength of the remedy, could have been a 
> lot of free service, enough financial incentive for them to MAKE it work 
> correctly, or leverage to open renegotiations for more favorable terms for 
> you.
>
> You know that in reverse they would have done the same to you. :)

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 contract was bidirectional, with partner also using our
network for extending reach of their network, so both had incentive to
offer working QoS with network-edge translation of marking.

-- 
  ++ytti

Re: QoS for Office365

[Ross Tajvar]

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 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 Edge of
> > the Internet and on the remote site. For INTERNET we will throw
> > bandwidth so it will not be a point of congestion (hopefully once we
> > are in the Backbone's ISP we will go to Microsoft directly)
>
> In that case, co-ordinate the QoS profile with your MPLS provider and
> test both ends to make sure you receive what you send for on-net traffic.
>
> Verifying that your MPLS provider is forwarding your traffic according
> to the agreed-upon QoS profile is another thing.
>
> As for the off-net traffic entering your network, well, you know about
> that already...
>
> Mark.
>

Re: QoS for Office365

[Mark Tinka]

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.

Re: QoS for Office365

[Brandon Martin]

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 
network.  Most of them operate an MPLS, too, no surprise.  Sprintlink is 
one that I know of.


They tend to be on the expensive side when it comes to IP service.
--
Brandon Martin

Re: QoS for Office365

[Mark Tinka]

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 contract was bidirectional, with partner also using our
> network for extending reach of their network, so both had incentive to
> offer working QoS with network-edge translation of marking.

I think when the partner participates in a private service, end-to-end,
there's a higher chance things will work (which I believe is one of the
components for Inter-AS l3vpn's and QoS).

However, when part of the partner's offering is off-net (especially
where off-net = public Internet), much less likely.

Mark.

Re: QoS for Office365

[Mark Tinka]

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.

Large, global, transit-free backbones fair well in such scenarios as the
majority of the traffic lives on-net as a matter of course.

Mark.

Re: QoS for Office365

[Valdis Klētnieks]

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.

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 QoS, the flow 
that
loses may be some other customer's flow)?


pgpSXld_60SMw.pgp
Description: PGP signature

Re: QoS for Office365

[Joe Yabuki]

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 Edge of the
Internet and on the remote site. For INTERNET we will throw bandwidth so it
will not be a point of congestion (hopefully once we are in the Backbone's
ISP we will go to Microsoft directly)

Joe

On Tue, Jul 9, 2019 at 4:06 PM Mark Tinka  wrote:

>
>
> 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 financial incentive for them
> > to MAKE it work correctly, or leverage to open renegotiations for more
> > favorable terms for you.
>
> Perhaps plenty of service credits. Anything else would just burn too
> much time on either end for no practical outcome.
>
> Mark.
>

RE: QoS for Office365

[Steve Mikulasik via NANOG]

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: nanog@nanog.org
Subject: Re: QoS for Office365



On 2/Jul/19 23:18, Joe Yabuki wrote:

> Hi all,
>
> How do you deal with QoS for Office365, since the IPs are subject to 
> changes ?
>
> How can we mark the trafic while keeping the security (I fear the 
> marking based on TCP/UDP Ports since they are not without an 
> additional risk coming from worms/virus using those ports for example, 
> and doing that directly on the PCs doesn't seem to be the best solution) ?

Funny, I was just answering an internal question about this, last week.

As with all things Internet, my stance is if you don't have end-to-end control, 
trying to do QoS is pointless.

That said, I believe it should be possible to apply some kind of meaningful, 
end-to-end QoS together with Microsoft if you took up one of their Express 
Route services, given that is considered a private, premium service.

Mark.

Re: QoS for Office365

[Mark Tinka]

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 QoS, the flow 
> that
> loses may be some other customer's flow)?

With some things, you need to have faith until you are given a reason
not to.

Just like when you are back in 26K and the Captain and his First Officer
are up front :-).

Mark.



signature.asc
Description: OpenPGP digital signature

Re: QoS for Office365

[Mark Tinka]

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 nature is
what allows us to build it in a way that makes it a viable option for
global data transport.

If all paths on the Internet had to be high-priority, I doubt it'd be a
viable project outside of a monopoly or duopoly.

Mark.

Re: QoS for Office365

[Joel Jaeggli]

> 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?

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.

My early experience as a customer with it was that there was on RPF check that 
I found to be a problem as a multihomed network.

> 
> Mark.
> 

Re: QoS for Office365

[Saku Ytti]

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 verifying expectations to results.

-- 
  ++ytti

Re: QoS for Office365

[Tom Beecher]

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 message:
   https://cvsweb.openbsd.org/src/usr.bin/ssh/readconf.c#rev1.284




On Tue, Jul 9, 2019 at 10:50 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
> performance. Tragedy of the commons.
>
>
>
> -Original Message-
> From: NANOG  On Behalf Of Mark Tinka
> Sent: Monday, July 8, 2019 10:40 AM
> To: nanog@nanog.org
> Subject: Re: QoS for Office365
>
>
>
> On 2/Jul/19 23:18, Joe Yabuki wrote:
>
> > Hi all,
> >
> > How do you deal with QoS for Office365, since the IPs are subject to
> > changes ?
> >
> > How can we mark the trafic while keeping the security (I fear the
> > marking based on TCP/UDP Ports since they are not without an
> > additional risk coming from worms/virus using those ports for example,
> > and doing that directly on the PCs doesn't seem to be the best solution)
> ?
>
> Funny, I was just answering an internal question about this, last week.
>
> As with all things Internet, my stance is if you don't have end-to-end
> control, trying to do QoS is pointless.
>
> That said, I believe it should be possible to apply some kind of
> meaningful, end-to-end QoS together with Microsoft if you took up one of
> their Express Route services, given that is considered a private, premium
> service.
>
> Mark.
>
>

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Izzy Goldstein - TeleGo]

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 lot of questions about stir/shaken.
> attacking a problem statement rfc seems rather bizarre and unhinged to
> me. it outlines a lot of the objections i had to p-asserted-identity i
> had way back when.
>
> Mike
>
>

-- 

Izzy Goldstein

Chief Technology Officer

Main: (212) 477-1000 x 2085 <(212)%20477-1000>

Direct: (929) 477-2085

Website: www.telego.com 





Confidentiality Notice: This e-mail may contain confidential and/or
privileged information. If you are not the intended recipient or have
received this e-mail in error please notify us immediately by email reply
and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden. Any
views or opinions presented in this email are solely those of the author
and do not necessarily represent those of TeleGo (T). Employees of TeleGo
are expressly required not to make defamatory statements and not to
infringe or authorize any infringement of copyright or any other legal
right by email communications. Any such communication is contrary to TeleGo
policy and outside the scope of the employment of the individual concerned.
TeleGo will not accept any liability in respect of such communication, and
the employee responsible will be personally liable for any damages or other
liability arising.


TeleGo Hosted PBX 

Re: QoS for Office365

[Saku Ytti]

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 for (They can match PREC, DSCP definition of TOS, not
original). But it took some time of convincing OpenSSH people that
reading original RFC isn't going to give sufficient understanding of
how TOS is used in real network.

I applaud this change. In home use your WIFI actually does honour QoS
and many enterprise networks do. And they mostly will align with this
default. So it's good default.

Home user internet experience would be vastly superior if WAN would
also do some rudimentary QoS, one silver bullet is to prioritise small
packets during congestion. Makes so much better experience on people
who regularly have their WAN uplink congested. Sadly not widely done
and impossible in most cases to do for NET=>Customer direction. Would
be terrific if CPE could tell far-end what QoS policy to use, so
residential users could decide on their end the far end QoS config.

-- 
  ++ytti

Re: QoS for Office365

[Jay Ford]

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 that Express Route is just for Azure, not for 
Orifice 365.  It's even possible that using Express Route for O365 could be 
worse due to undermining/bypassing some of the O365 availability mechanisms.


__
Jay Ford , Network Engineering, University of Iowa

rVRRPd - A new open source VRRPv2 daemon

[Nicolas Chabbey]

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 also wanted to provide another open and secure implementation of a
FHRP to the network community.

Here's a summary of what rVRRPd (v0.1.0) is:
 - Implemented almost entirely in Rust
 - Interoperable with RFC3768 compliant devices
 - Support for RFC2338 simple password authentication
 - Support for additional proprietary authentication methods
 - Easily configurable using TOML
 - Multithreaded operations
 - Fast, secure and scalable

This implementation is aimed to be fast and secure, however please keep
in mind, it is still in its infancy. It is not yet ready for production
use but should be fairly stable.

I'm the only developer at this time, and my resources are limited.
However, I took the time to fuzz the latest version, and to do some
interoperability testing. So far, the results have been great.

Of course, I'm open to any suggestions and feedback. Anything that can
improve the project constructively is more than welcome. I am also open
to contributors.

You can find the latest development version of rVRRPd at
https://github.com/e3prom/rVRRPd

Regards



signature.asc
Description: OpenPGP digital signature

Re: QoS for Office365

[Tom Beecher]

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 choice.

On Tue, Jul 9, 2019 at 11:22 AM Saku Ytti  wrote:

> 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 for (They can match PREC, DSCP definition of TOS, not
> original). But it took some time of convincing OpenSSH people that
> reading original RFC isn't going to give sufficient understanding of
> how TOS is used in real network.
>
> I applaud this change. In home use your WIFI actually does honour QoS
> and many enterprise networks do. And they mostly will align with this
> default. So it's good default.
>
> Home user internet experience would be vastly superior if WAN would
> also do some rudimentary QoS, one silver bullet is to prioritise small
> packets during congestion. Makes so much better experience on people
> who regularly have their WAN uplink congested. Sadly not widely done
> and impossible in most cases to do for NET=>Customer direction. Would
> be terrific if CPE could tell far-end what QoS policy to use, so
> residential users could decide on their end the far end QoS config.
>
> --
>   ++ytti
>

Re: QoS for Office365

[Paul Thornton]

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
scenario?


At least sometimes M$ says that Express Route is just for Azure, not for
Orifice 365.  It's even possible that using Express Route for O365 could
be worse due to undermining/bypassing some of the O365 availability
mechanisms.


I've just been involved in turning up a new customer who ordered Express 
Route specifically for O365 use - they have no Azure presence.


After much discussions between us, the customer and MS it transpired 
that they (MS) really didn't want to support using Express Routes and 
O365 - there had been many instances of routing problems and people not 
really understanding what the end result was going to look like. 
Apologies for being vague here, but I wasn't directly in the loop - 
except to say that MS dissuaded the customer from this and told them to 
just use their Internet connection instead.


The MS techs told us that this was their preferred option now.  A year 
or two back, they wanted everyone to access O365 via Express Route...


Paul.

Re: QoS for Office365

[Saku Ytti]

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 making assumptions based on RFC SHOULD's is an unfortunate 
> choice.

You are entitled to that opinion, I just wanted to correct you that
this is not a change in OpenSSH behaviour from your point of view,
just different bits. For you it's business as usual.

I don't anticipate Internet users in general to be capable of
configuring QoS and I think they deserve reasonable defaults, and
those who understand what they want, can change those defaults. The
WLAN AP you shop from typical provider has QoS built-in, and it works
reasonably, with reasonable definition.
I wish we'd take it further, and give reasonable last mile QoS to
consumer, the 'small packets first in congestion' would on average
increase user experience significantly.

-- 
  ++ytti

Re: QoS for Office365

[Mark Tinka]

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 course, you'd pay for that private service :-).

Mark.

Re: QoS for Office365

[Tom Beecher]

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, thank you for correcting me.

On Tue, Jul 9, 2019 at 12:19 PM Saku Ytti  wrote:

> 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 making assumptions based on RFC SHOULD's is an
> unfortunate choice.
>
> You are entitled to that opinion, I just wanted to correct you that
> this is not a change in OpenSSH behaviour from your point of view,
> just different bits. For you it's business as usual.
>
> I don't anticipate Internet users in general to be capable of
> configuring QoS and I think they deserve reasonable defaults, and
> those who understand what they want, can change those defaults. The
> WLAN AP you shop from typical provider has QoS built-in, and it works
> reasonably, with reasonable definition.
> I wish we'd take it further, and give reasonable last mile QoS to
> consumer, the 'small packets first in congestion' would on average
> increase user experience significantly.
>
> --
>   ++ytti
>

Re: QoS for Office365

[Edward Salonia]

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 ?

How can we mark the trafic while keeping the security (I fear the marking based 
on TCP/UDP Ports since they are not without an additional risk coming from 
worms/virus using those ports for example, and doing that directly on the PCs 
doesn't seem to be the best solution) ?

Many thanks,
Joe

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Sean Donelan]

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.

https://www.fcc.gov/document/chairman-pai-announces-agenda-shakenstir-robocall-summit



The agenda looks like lots of happy, happy talk from industry 
representatives.


Unfortunately, like other third-party problems, its not about the 
technology.  Its really about changing the incentives for all the actors 
involved. But the first and second-party players don't want the incentives 
to be changed for them.

Re: QoS for Office365

[Warren Kumari]

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 congestion events) only one of about seven
>> did anything at all with the marking, and that wasn't enough to make
>> any difference... I briefly toyed with the idea of asking for some
>> money back / trying to enforce the terms of the agreements, but
>> figured that there wasn't much point - expecting QoS to work in
>> someone else's network based upon your markings seems like a fool's
>> errand.
>
>
> 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 done, enforcing contract terms should 
> always be done. Depending on the strength of the remedy, could have been a 
> lot of free service, enough financial incentive for them to MAKE it work 
> correctly, or leverage to open renegotiations for more favorable terms for 
> you.
>
> You know that in reverse they would have done the same to you. :)
>

Yeah, at that point in AOL's trajectory there were (at least from my
point of view!) much much bigger issues -- like, "Who's getting laid
off this week? and how do I remove their access? and who's going to do
whatever they were doing (if anything)?!" and trying to make enhanced
cRTP work over GRE over yet more GRE over IPSEC (because, well,
reasons).
Yes, in an ideal world we would have received some sort of credits --
but then again, in an ideal world, I wouldn't have been trying to run
VOIP over cRTP over GRE over GRE over IPSEC over DS3 to E3 converters
to India...

W


> On Mon, Jul 8, 2019 at 6:38 PM Warren Kumari  wrote:
>>
>> On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka  wrote:
>> >
>> >
>> >
>> > On 8/Jul/19 21:03, Robert Webb wrote:
>> > > I took the OP's request as for doing QoS at the edge of their network
>> > > and not necessarily the entire path.
>> >
>> > Indeed, but even then, you could be handing off the traffic to a
>> > downstream customer, and can't guarantee what they do to those ToS fields.
>>
>> I disagree -- you *can* guarantee what someone else will do with your
>> ToS fields... they will A: ignore them and / or B: scribble all
>> over them.
>>
>> 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 at all with the marking, and that wasn't enough to make
>> any difference... I briefly toyed with the idea of asking for some
>> money back / trying to enforce the terms of the agreements, but
>> figured that there wasn't much point - expecting QoS to work in
>> someone else's network based upon your markings seems like a fool's
>> errand.
>>
>> W
>>
>> >
>> >
>> > >
>> > > As another person stated, the real answer is to add more bandwidth if
>> > > you are having to QoS to Office365 because it is affecting other
>> > > internet based services.
>> >
>> > Yes and no.
>> >
>> > More bandwidth never hurt anyone, but packet loss in the remote network
>> > toward the cloud will hurt you.
>> >
>> > Mark.
>>
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

Re: QoS for Office365

[Brian Knight]

> 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?
> 
> Mark.

Yes, the IPs used on the ExpressRoute connection are whatever is chosen for the 
internal IP scheme of the VPC. ExpressRoute is a VPN connection into that 
internal side of a VPC.  On our carrier (MegaPort), ExpressRoute looks similar 
to an Option A NNI connection. BGP is used for routing.

The source IPs on packets crossing out of the VPC onto the Azure-provided 
Internet may or may not be static, but internally they are usually static RFC 
1918 addresses.

We’ve been using ExpressRoute for our own office systems and a small handful of 
customers for about two years now. However, we don’t use diffserv on 
ExpressRoute, so can’t comment on that.

-Brian

.NET Zone DNSSEC Operational Update -- ZSK length change

[Wessels, Duane via NANOG]

-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 bits.

On July 10, 2019 the 1280 bit ZSK will be pre-published in the .NET
zone.  On July 15, the .NET zone will be signed with the 1280 bit
ZSK.  On July 20, the 1024 bit ZSK will be removed from the zone.

We do not anticipate any problems from this upgrade.  In accordance
with our normal operating procedures we have a rollback process
should it become necessary to revert to the 1024 bit ZSK.

DW

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJdJQifAAoJEGyZpGmowJiNVEsH/2T8Qm/ZZiM7K1G+6XN4wMSR
oqyuzY/0AiqXpw0C2aL3sE3VhYPZWTY+H5wwbvU+ZoAbiMfcOygBv/JTLizpjLLK
NJD+Gh51Z6cQn5yk9cPjRtoxdQrV83T0gRQIlPeFW3sm9GrXgropfQ/Dw7O0lHkZ
x2oiGwC0HF5npi6OWEHpETemtSMWl5HpFfmYZhzXoBSzEbzHgXQwr0Fie9wtNkDm
qPjwaeq3drENOoum4egpAFxQZM7FclLtyqqT24h0m5GeunHIcXRRcfoOAEnEmjRJ
b5ePCKxHqNY2Iz6MpiedTCpD2RIbI51wVhNGfmCiwyyl3500oqjvcmtYh00gCIU=
=XP9d
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME cryptographic signature

.ARPA Zone DNSSEC Operational Update -- ZSK length change

[Wessels, Duane via NANOG]

-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 bits.

On July 11, 2019 the 2048 bit ZSK will be pre-published in the .ARPA
zone.  On July 21, the .ARPA zone will be signed with the 2048 bit
ZSK.  On August 10, the 1024 bit ZSK will be removed from the zone.

We do not anticipate any problems from this upgrade.  In accordance
with our normal operating procedures we have a rollback process
should it become necessary to revert to the 1024 bit ZSK.

DW

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJdJQifAAoJEGyZpGmowJiNxjcH/3a+ox9KyGAT5vnrcxfEYYIQ
X2iQ0dSEBCv9JPNwTnKkV2U2xzG3uZb6LHjq9tihtA4M04IaMvlLnZMUFUyGgzrl
ACvn6j9qCE0q7sgDGo/RNWXBsAd58mKgBVMMRCBR6AklDHVA+grEH2CwDwP0eGYZ
8dy6Cf94jqXqiVDQIxoK31YhYFqNVRhZE4f72V+6lh1fg4GrsfXKeErYwQooxdYT
91H9TmffWmEpG+eYdgWMOPPS+nsrDr/MAuSVD0t5hT8H/HrCo45MNxxskmwLg0Ni
QAHgy5Ao2jgJj6MkzZdwjldM8mn5YzMegiHUF9R5W5TRlnNm7uGTU32Irzu7b/8=
=lJK6
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME cryptographic signature

Re: QoS for Office365

[Mike O'Connor]

: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

-- 
 Michael J. O'Connor  m...@dojo.mi.org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Nothing unreal exists." -Kiri-Kin-Tha's First Law Of Metaphysics


signature.asc
Description: PGP signature

Re: QoS for Office365

[Mark Andrews]

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 
> performance. Tragedy of the commons. 
> 
> 
> 
> -Original Message-
> From: NANOG  On Behalf Of Mark Tinka
> Sent: Monday, July 8, 2019 10:40 AM
> To: nanog@nanog.org
> Subject: Re: QoS for Office365
> 
> 
> 
> On 2/Jul/19 23:18, Joe Yabuki wrote:
> 
>> Hi all,
>> 
>> How do you deal with QoS for Office365, since the IPs are subject to 
>> changes ?
>> 
>> How can we mark the trafic while keeping the security (I fear the 
>> marking based on TCP/UDP Ports since they are not without an 
>> additional risk coming from worms/virus using those ports for example, 
>> and doing that directly on the PCs doesn't seem to be the best solution) ?
> 
> Funny, I was just answering an internal question about this, last week.
> 
> As with all things Internet, my stance is if you don't have end-to-end 
> control, trying to do QoS is pointless.
> 
> That said, I believe it should be possible to apply some kind of meaningful, 
> end-to-end QoS together with Microsoft if you took up one of their Express 
> Route services, given that is considered a private, premium service.
> 
> Mark.
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org