Re: Whois vs GDPR, latest news

[Hank Nussbacher]

On 23/05/2018 04:50, John Levine wrote:
>> What about the likely truth that if anyone from Europe mails the list, then
>> every mail server operator with subscribers to the list must follow the
>> GDPR Article 14 notification requirements, as the few exceptions appear to
>> not apply (unless you’re just running an archive).
> Some of us whose businesses and equipment are entirely in North
> America will take our chances. This is NANOG, not EUNOG, you know.
> Also, one thing that has become painfully clear is that the number of
> people who imagine that they understand the GDPR exceeds the number
> who actually understand it by several orders of magnitude. The "you
> have to delete all my messages from the archive if I unsubscribe"
> nonsense is a good indicator. R's, John
Every generation needs its religious wars.  Unix vs Windows.  OSI vs
TCPIP.  Now there is GDPR vs Theworld.

-Hank

Re: DirecTV Now contact

[Darin Steffl]

In my testing, I see Directv now coming from akamai. We peer with them
directly and we're only 4ms away and I sometimes still see buffering.

So I'd say there's something more going on. I have no trouble with Netflix,
YouTube, real choice demo.

On Tue, May 22, 2018, 2:07 PM Mike Hammett  wrote:

> I don't have DirecTV Now. What CDN are they using? Fire up a stream and
> use Torch to see what IP it's coming from.
>
> Torch is a tool in Mikrotik RouterOS. I recognize those three as likely
> being familiar with RouterOS, so I sent them that way.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Joshua Stump" 
> To: "mike lyon" , "Michael Crapse" <
> mich...@wi-fiber.io>
> Cc: "NANOG list" 
> Sent: Tuesday, May 22, 2018 1:59:27 PM
> Subject: RE: DirecTV Now contact
>
> Similar experience for us as well.
>
> Joshua Stump
> Network Admin
> Fourway.NET
> 800-733-0062
>
> -Original Message-
> From: NANOG  On Behalf Of mike.l...@gmail.com
> Sent: Tuesday, May 22, 2018 2:29 PM
> To: Michael Crapse 
> Cc: NANOG list 
> Subject: Re: DirecTV Now contact
>
> Yeah, our eyeball network has problems with DirecTV too.
>
> Would be nice if they were at the various peering exchanges...
>
> -Mike
>
> > On May 22, 2018, at 11:08, Michael Crapse  wrote:
> >
> > Our eyeball network is consistently having some streaming
> > issues(buffering) with DirecTV now. Our main recourse is to sell them
> > on youtube TV and netflix. fixes the issue, no more complaints from
> > our customers. Issues mainly occur during peak times and even on
> > 300+mbps low latency/jitter customers.
> > However, if someone from DirecTV could contact me off list and we can
> > debug this issue so that we don't have to keep pulling people to other
> > services that would be great.
> > Alternatively, if anyone could suggest with whom to peer to reduce the
> > impact of this issue, that would be great.
> > A solution that would be even better is if someone from Youtube TV
> > would contact us off list and we can set up something commissioned
> > based for all the good things we say about your service, and of course
> > give our tech support people a reason to not be frustrated with the
> > calls we receive for this issue.
>
>
>

Re: Geolocation issue with a twist

[Jason Hellenthal]

You will probably need to host that attachment elsewhere and post a link to it. 
Attachments don’t really fly to mailing lists.

> On May 22, 2018, at 15:50, Clay Stewart  wrote:
> 
> Can someone point me for help with the following issue?
> 
> I purchased a /24 late last year on auction which was originally owned by
> Cox communications in Europe. It had Geolocation in a lot of bad places,
> and Cox got it 'cleared' up for me.
> 
> But there is still one issue, an ISP in Spain has it in a Geo database
> which is pointed to my correct location, but because it is a Spain ISP, the
> block has lots of issues in block apps and redirects to spam sites.
> 
> Attach is a snapshot with the incorrect ISP highlight and Geo database. I
> cannot get any info from the Geo database.
> 
> I am new to this list, so I hope this is an appropriate question.


-- 

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Whois vs GDPR, latest news

[Mark Andrews]

Domain whois is absolutely useful.  Try contacting a site to report
that their nameservers are hosed without it.  People forget that the
primary purpose of whois is to report faults.  You don’t need to do
it very often but when you do it is crucial.  Remember that about
50% of zones have not RFC compliant name servers (the software is
broken) and that newer resolver depend on default behaviour working
correctly.

> On 23 May 2018, at 12:37 pm, Matt Harris  wrote:
> 
> Maybe I'm going out on a limb here, but was domain whois ever really that
> useful?  I can't remember ever using it for any legitimate sort of
> activity, and I know it gets scraped quite a bit by spammers.  Most of the
> data is bogus these days on a lot of TLDs which allow "anonymous
> registrations" and which registrars often charge an extra dollar or two
> for.  Showing the authoritative nameservers is neat, but a simple NS record
> query against the next level up would suffice to provide that information
> as well.  The date of expiration may be useful if you're trying to grab a
> domain when it expires, but registrar policies often drag that out anyways
> and half the time the registrar squats on any decent domain when it expires
> anyhow.  Date of original registration may be interesting for one reason or
> another... but none of this data is personally identifiable information
> anyhow.
> 
> Now on the other hand, RIR whois is actually very useful for determining
> the rightful owner and abuse contacts for IP address space... Since RIRs
> are designated by region and, afaik, only RIPE NCC data would be impacted
> by GDPR... well, I'm surprised this isn't being talked about more than the
> domain name side of things.
> 
> Take care,
> Matt

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

Re: Segment Routing

[steve ulrich]

On Tue, May 22, 2018 at 9:59 AM Saku Ytti  wrote:

> On 22 May 2018 at 17:43, steve ulrich  wrote:
>
> Hey,
>
> > sorry, yes. i was referring to SRTE wrt the pop operation.
>
> Yup RSVP=>SR is more ambiguous and debatable than LDP=>SR which is
> unambiguous win.
>
> > not labels but they are encoded as labels.  i hope operators have the
> option
> > to configure common/consistent label ranges, but i don't necessarily
> assume
> > it.  tooling to resolve this will be required just as in the LDP world.
>
> I've not had this tooling in LDP world, and not anticipating to need
> it in SR world. But maybe I'm missing something, what kind of
> information do you need in LDP world which you need to develop tooling
> for, and how does the problem+solution translate to SR world?
>

in the day's of yore, i know a few folks who built tooling to validate
and/or detect failure to sync between the IGP and LDP or detect data plane
black holing behaviors caused by resolution in the RIB w/no complementary
label allocation (or LDP convergence lagging significantly).
implementations have come a long way since then.  but yeah, IGP-LDP sync
lag has been a thing for some folks.

in a world of anycast/prefix-SIDs some of this doesn't necessarily go away,
it just looks kind of different.  though to be fair, this alignment
improves (the IGP/LDP convergence sync case goes away) for all the reasons
you've cited previously in this thread.





-- 
steve ulrich (sulrich@botwerks.*)

Geolocation issue with a twist

[Clay Stewart]

Can someone point me for help with the following issue?

I purchased a /24 late last year on auction which was originally owned by
Cox communications in Europe. It had Geolocation in a lot of bad places,
and Cox got it 'cleared' up for me.

But there is still one issue, an ISP in Spain has it in a Geo database
which is pointed to my correct location, but because it is a Spain ISP, the
block has lots of issues in block apps and redirects to spam sites.

Attach is a snapshot with the incorrect ISP highlight and Geo database. I
cannot get any info from the Geo database.

I am new to this list, so I hope this is an appropriate question.

Re: Whois vs GDPR, latest news

[Matt Harris]

 Maybe I'm going out on a limb here, but was domain whois ever really that
useful?  I can't remember ever using it for any legitimate sort of
activity, and I know it gets scraped quite a bit by spammers.  Most of the
data is bogus these days on a lot of TLDs which allow "anonymous
registrations" and which registrars often charge an extra dollar or two
for.  Showing the authoritative nameservers is neat, but a simple NS record
query against the next level up would suffice to provide that information
as well.  The date of expiration may be useful if you're trying to grab a
domain when it expires, but registrar policies often drag that out anyways
and half the time the registrar squats on any decent domain when it expires
anyhow.  Date of original registration may be interesting for one reason or
another... but none of this data is personally identifiable information
anyhow.

Now on the other hand, RIR whois is actually very useful for determining
the rightful owner and abuse contacts for IP address space... Since RIRs
are designated by region and, afaik, only RIPE NCC data would be impacted
by GDPR... well, I'm surprised this isn't being talked about more than the
domain name side of things.

Take care,
Matt

Re: Whois vs GDPR, latest news

[Don Gould]

What is GDPR?

My current guess is "Just another thing to learn since whois is now broken 
because to many of us just abused a once useful tool"



On 23 May 2018 1:50:17 PM NZST, John Levine  wrote:
>>What about the likely truth that if anyone from Europe mails the list,
>then
>>every mail server operator with subscribers to the list must follow
>the
>>GDPR Article 14 notification requirements, as the few exceptions
>appear to
>>not apply (unless you’re just running an archive).
>
>Some of us whose businesses and equipment are entirely in North
>America will take our chances.  This is NANOG, not EUNOG, you know.
>
>Also, one thing that has become painfully clear is that the number of
>people who imagine that they understand the GDPR exceeds the number
>who actually understand it by several orders of magnitude.
>
>The "you have to delete all my messages from the archive if I
>unsubscribe" nonsense is a good indicator.
>
>R's,
>John

--
Don Gould
5 Cargill Place
Richmond
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699
Ph: +61 3 9111 1821 (Melb)
www.bowenvale.co.nz
skype: don.gould.nz

Re: Whois vs GDPR, latest news

[Jimmy Hess]

Perhaps it's time that some would consider  new RBLs  and  Blackhole
feeds  based on :
Domains with deliberately unavailable WHOIS data.

Including  domains whose  registrant has failed to cause their domain
registrar and/or registry to
list personally identifiable details for registrant and contacts   on
servers available to
the public using the TCP port 43 WHOIS service.

For any reason,  whether use of a privacy service,  or by a  Default
"Opt-to-Privacy Rule" enforced
by a  local / country-specific regulation such as GPDR.

Stance

* Ultimate burden goes to the REGISTRANT of any Internet Domain to take the
  steps to ensure their domain or IP address registry makes public
contacts appear
  in WHOIS at all times for  their Domain and/or IP address(es) --- including
  a traceable registrant name AND direct Telephone and E-mail contacts
 to a responsible
  party specific to the domain from which a timely response is available and
  are not through a re-mailer or proxy service.

People may have in their country a legal right to secure control of
a domain on a registry
And anonymize  their registration:"Choose not to have personal
information listed in WHOIS".

HOWEVER, Making this choice might then result in adverse consequences
towards connectivity AND accessibility to your resources from others
during such times
as you exercise your option to have no identifiable WHOIS data.

The registration of a domain with hidden or anonymous data only ensures
exclusivity of control.  Registration of a domain  with
questionable or unverifiable personal
registrant or contact information does not guarantee that  ISPs  or
other sites connected to the
internet will choose to allow their own users and DNS infrastructure
access to   un-WHOISable domains.

Then have:
---

* Right-hand sided BLs for Internet domains with no direct
WHOIS-listed registrant address and  real-person contacts
including  name, address, direct e-mail and phone number valid for
contact during the domain's operational hours.

* Addons/Extensions for Common Web Browsers  to check the BLs  before
allowing access to a HTTP or HTTPS  URL.  Then display a prominent
"Anonymized Domain:
Probable  Scam/Phishing Site"   within the Web Browser MUA;

And limit or disable high-risk functions for anonymous sites:  such as
 Web Form Submissions,
Scripting,  Cookies,  Etc   to  Non-WHOIS'd domains.

if   the domain's  WHOIS  listingis  missing  or showed a privacy
service, or had appeared  t
runcated or anonymized.

* IP Address DNSBL for IP Address allocations  with no direct
WHOIS-listed  holder address real-person contacts.
including name, address, direct e-mail and phone number valid for
contact during the hours when that IP address
is connected to the internet.

* DNS response policy zones (for resolver blacklists)  for internet
domains with no WHOIS-listed registrant &
real-person contacts  including name, address, direct e-mail and phone
number valid for contact.


The EU  GDPR   _might_  require  your  registrar to offer you the
ability Opt by default to mask your
personal information and e-mail from domain or IP  WHOIS data,

But  should you  choose  to Not opt to have identifiable contacts and
ownership published:

There may be networks and resources that will refuse access,  Or whose
users  will not be allowed
to resolve your DNS names,  due to your refusal to identify
yourself/provide contacts   for   vetting,
identifying and reporting technical issues, abuse, etc.

Real-Life equivalent  would beDirectories/Listings of
Recommended businesses that
refuse to accept listings from businesses whose  Owner  wants to stay Anonymous.

Or  people who don't want to buy their groceries from random shady
buildings  that don't even
have a proper sign out.

--
-JH

On Wed, May 16, 2018 at 4:10 PM, Constantine A. Murenin
 wrote:
> I think this is the worst of both worlds.  The data is basically still
> public, but you cannot access it unless someone marks you as a
> "friend".
>
> This policy is basically what Facebook is.  And how well it played out
> once folks realised that their shared data wasn't actually private?
>
> C.
>
> On 16 May 2018 at 16:02, Brian Kantor  wrote:
>> A draft of the new ICANN Whois policy was published a few days ago.
>>
>> https://www.icann.org/en/system/files/files/proposed-gtld-registration-data-temp-specs-14may18-en.pdf
>>
>> From that document:
>>
>> "This Temporary Specification for gTLD Registration Data (Temporary
>> Specification) establishes temporary requirements to allow ICANN
>> and gTLD registry operators and registrars to continue to comply
>> with existing ICANN contractual requirements and community-developed
>> policies in light of the GDPR. Consistent with ICANN’s stated
>> objective to comply with the GDPR, while maintaining the existing
>> WHOIS system to the greatest extent possible, the Temporary
>> Specification maintains robust 

Re: Whois vs GDPR, latest news

[John Levine]

>What about the likely truth that if anyone from Europe mails the list, then
>every mail server operator with subscribers to the list must follow the
>GDPR Article 14 notification requirements, as the few exceptions appear to
>not apply (unless you’re just running an archive).

Some of us whose businesses and equipment are entirely in North
America will take our chances.  This is NANOG, not EUNOG, you know.

Also, one thing that has become painfully clear is that the number of
people who imagine that they understand the GDPR exceeds the number
who actually understand it by several orders of magnitude.

The "you have to delete all my messages from the archive if I
unsubscribe" nonsense is a good indicator.

R's,
John

NANOG 73 Agenda is Published

[Ryan Woolley]

NANOG Community,

The NANOG 73 Agenda is published at http://www.cvent.com/d/ttqv1z/16K
and available as an iCal feed at
https://pc.nanog.org/static/published/meetings/NANOG73/agenda.ics

The Program Committee has worked closely with our speakers to develop
a first-rate program, and we encourage all attendees to enjoy the
whole conference.  As we review submitted content, minor changes to
the agenda are possible and will be reflected in the online feed.

Thank you to the many members of our community who submitted
interesting content for NANOG 73!  Close to 500 attendees have
registered and the NANOG family looks forward to welcoming all of you
to Denver.

Useful Information:
- NANOG 73 General Information and Registration: http://www.cvent.com/d/ttqv1z
- Hotel Room Block(s) Information: http://www.cvent.com/d/ttqv1z/8K
- There are a few remaining spots to register for the NANOG 73
Hackathon: http://www.cvent.com/d/ttqv1z/4K
- A welcome message that will be sent to registered NANOG 73 attendees
shortly will provide more information on scheduled events and
applications to help you to make the most of your time in Denver
- Register to attend NANOG On The Road Washington, DC, taking place in
September at http://www.cvent.com/d/ygqk8s/4W

Safe travels and see you in Denver.


Sincerely,

Ryan Woolley,
on behalf of the NANOG Program Committee

[NANOG-announce] NANOG 73 Agenda is Published

[Ryan Woolley via NANOG-announce]

This message has been wrapped due to the DMARC policy setting to
prevent NANOG subscribers from being unsubscribed due to bounces.
--- Begin Message ---
NANOG Community,

The NANOG 73 Agenda is published at http://www.cvent.com/d/ttqv1z/16K
and available as an iCal feed at
https://pc.nanog.org/static/published/meetings/NANOG73/agenda.ics

The Program Committee has worked closely with our speakers to develop
a first-rate program, and we encourage all attendees to enjoy the
whole conference.  As we review submitted content, minor changes to
the agenda are possible and will be reflected in the online feed.

Thank you to the many members of our community who submitted
interesting content for NANOG 73!  Close to 500 attendees have
registered and the NANOG family looks forward to welcoming all of you
to Denver.

Useful Information:
- NANOG 73 General Information and Registration: http://www.cvent.com/d/ttqv1z
- Hotel Room Block(s) Information: http://www.cvent.com/d/ttqv1z/8K
- There are a few remaining spots to register for the NANOG 73
Hackathon: http://www.cvent.com/d/ttqv1z/4K
- A welcome message that will be sent to registered NANOG 73 attendees
shortly will provide more information on scheduled events and
applications to help you to make the most of your time in Denver
- Register to attend NANOG On The Road Washington, DC, taking place in
September at http://www.cvent.com/d/ygqk8s/4W

Safe travels and see you in Denver.


Sincerely,

Ryan Woolley,
on behalf of the NANOG Program Committee
--- End Message ---
___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

[NANOG-announce] NANOG 73 Agenda is Published

[Ryan Woolley via NANOG-announce]

This message has been wrapped due to the DMARC policy setting to
prevent NANOG subscribers from being unsubscribed due to bounces.
--- Begin Message ---
NANOG Community,

The NANOG 73 Agenda is published at http://www.cvent.com/d/ttqv1z/16K
and available as an iCal feed at
https://pc.nanog.org/static/published/meetings/NANOG73/agenda.ics

The Program Committee has worked closely with our speakers to develop
a first-rate program, and we encourage all attendees to enjoy the
whole conference.  As we review submitted content, minor changes to
the agenda are possible and will be reflected in the online feed.

Thank you to the many members of our community who submitted
interesting content for NANOG 73!  Close to 500 attendees have
registered and the NANOG family looks forward to welcoming all of you
to Denver.

Useful Information:
- NANOG 73 General Information and Registration: http://www.cvent.com/d/ttqv1z
- Hotel Room Block(s) Information: http://www.cvent.com/d/ttqv1z/8K
- There are a few remaining spots to register for the NANOG 73
Hackathon: http://www.cvent.com/d/ttqv1z/4K
- A welcome message that will be sent to registered NANOG 73 attendees
shortly will provide more information on scheduled events and
applications to help you to make the most of your time in Denver
- Register to attend NANOG On The Road Washington, DC, taking place in
September at http://www.cvent.com/d/ygqk8s/4W

Safe travels and see you in Denver.


Sincerely,

Ryan Woolley,
on behalf of the NANOG Program Committee
--- End Message ---
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Segment Routing

[Saku Ytti]

> in the day's of yore, i know a few folks who built tooling to validate
> and/or detect failure to sync between the IGP and LDP or detect data plane
> black holing behaviors caused by resolution in the RIB w/no complementary
> label allocation (or LDP convergence lagging significantly). implementations
> have come a long way since then.  but yeah, IGP-LDP sync lag has been a
> thing for some folks.

No matter what the protocol, there will be occasional bugs, and we
will continue to develop ad-hoc scripts to detect and workaround those
when possible until such time that software upgrade is practical. None
of these are practical to write ahead of time, as we won't know what
the bug is we're trying to detect.
This is not protocol discussion in itself, but we can make an argument
that if there is bug probability per SLOC, less SLOC is less bugs, and
label signalling in IGP is far simpler than LDP.

-- 
  ++ytti

Re: Telecommunications Outage Report: Northern California Firestorm 2017

[Scott Weeks]

--- s...@donelan.com wrote:
From: Sean Donelan 

:: During the 2017 wildfires, there were no forms of 
:: communications or technologies that worked better 
:: than the rest.

I don't have time to read all 80+ pages and don't see 
it in the contents.  Do you know what services restored 
first?

scott

RE: earthlink email problems

[Keith Medcalf]

>host 23.227.197.10
10.197.227.23.in-addr.arpa domain name pointer horsezipsworld.com.

>host horsezipsworld.com
horsezipsworld.com has address 23.227.197.11
horsezipsworld.com mail is handled by 10 mail.horsezipsworld.com.

>host mail.horsezipsworld.com
mail.horsezipsworld.com has address 23.227.197.11

>host 23.227.197.11
11.197.227.23.in-addr.arpa domain name pointer horsezipsworld.com.


The above are inconsistent.  IPAddress -> Name =/= the found name -> IPAddress


>host 209.86.93.228
228.93.86.209.in-addr.arpa domain name pointer mx3.earthlink.net.

>host mx3.earthlink.net
mx3.earthlink.net has address 209.86.93.228

Thee appear to be consistent ...


---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of jimmy
>keffer
>Sent: Tuesday, 22 May, 2018 13:01
>To: nanog@nanog.org
>Subject: earthlink email problems
>
>my has problems sending mail to earthlink.net the sever has a ptr abd
>reverse dns set but i get this To: ji...@horsezipsworld.com
>Subject: Message undeliverable: MegaBBS Forum horsezip's world : New
>user alert
>From: mailer-dae...@horsezipsworld.com
>Date: Sun, 20 May 2018 23:40:41 -0400
>
>Your message did not reach some or all of the intended recipients.
>
>   Sent: Sun, 20 May 2018 23:40:40 -0400
>   Subject: MegaBBS Forum horsezip's world : New user alert
>
>The following recipient(s) could not be reached:
>
>horse...@earthlink.net
>   Error Type: SMTP
>   Remote server (209.86.93.228) issued an error.
>   hMailServer sent: MAIL FROM:
>   Remote server replied: 550 ERROR: No or mismatched reverse DNS
>(PTR)
>entries for 23.227.197.10
>
>
>
>hMailServer
>
>any one here who can help my server sends mail to servers fine gmail
>etc
>jimmy

Re: Segment Routing

[Scott Whyte]

On 5/22/18 7:04 AM, steve ulrich wrote:

fwiw - there's a potentially significant loss of visibility w/SR from a
traffic management perspective depending on how it's deployed.  though, i
doubt the OP is really driving at this point.

the data plane behavior on LDP is swap oriented, while the data plane on SR
is pop oriented.  depending on the hardware capabilities in use this may
have (subtle) traffic engineering or diagnostic implications at a minimum.
folks will likely have to build tooling to address this.

we're pushing the bubble of complexity around.


Moving the complexity to where it scales better is a win all by itself.



On Tue, May 22, 2018 at 8:47 AM Saku Ytti  wrote:


On 22 May 2018 at 11:19, Matt Geary  wrote:


really seeing the value of SR to replace LDP on my backbone. With some
scripting and lots of software tools I can make it just like LDP, but

why?

So break the ease of LDP just to get label switching on my hub core not
really seeing it, unless someone has done it and they are seeing the

value.

Can you elaborate what scripting and software tools are needed? If you'd
talk
about RSVP particularly AutoBW and SR, then yeah, but SR on itself should
be less of a chore than LDP.

SR is what MPLS was intended to be day1, it just wasn't very marketable
idea
to sell MPLS and sell need for changing all the IGPs as well.
LDP is added state, added signalling, added complexity with reduced
visibility.
SR is like full-mesh LDP (everyone has everyone's label POV), while also
removing one protocol entirely.

--
   ++ytti

Re: earthlink email problems

[Matt Harris]

On Tue, May 22, 2018 at 2:00 PM, jimmy keffer 
wrote:

> my has problems sending mail to earthlink.net the sever has a ptr abd
> reverse dns set but i get this To: ji...@horsezipsworld.com
>
>Remote server replied: 550 ERROR: No or mismatched reverse DNS (PTR)
> entries for 23.227.197.10
>
> any one here who can help my server sends mail to servers fine gmail etc
> jimmy
>

Your A record does not match that IPv4 addr:

(mdh@kirin) [~/]# host 23.227.197.10
10.197.227.23.in-addr.arpa domain name pointer horsezipsworld.com.
(mdh@kirin) [~/]# host horsezipsworld.com
horsezipsworld.com has address 23.227.197.11

You may want to set something up like mail. which points to
23.227.197.10
and then set the PTR for  23.227.197.10 to mail. so that you have a
matching set.  PTR's that don't match are unreliable - I can set a PTR for
my IP addresses to matt.google.com, but that doesn't mean I have any
authority regarding google.com.

Take care,
Matt

Re: DirecTV Now contact

[Mike Hammett]

I don't have DirecTV Now. What CDN are they using? Fire up a stream and use 
Torch to see what IP it's coming from. 

Torch is a tool in Mikrotik RouterOS. I recognize those three as likely being 
familiar with RouterOS, so I sent them that way. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Joshua Stump"  
To: "mike lyon" , "Michael Crapse"  
Cc: "NANOG list"  
Sent: Tuesday, May 22, 2018 1:59:27 PM 
Subject: RE: DirecTV Now contact 

Similar experience for us as well. 

Joshua Stump 
Network Admin 
Fourway.NET 
800-733-0062 

-Original Message- 
From: NANOG  On Behalf Of mike.l...@gmail.com 
Sent: Tuesday, May 22, 2018 2:29 PM 
To: Michael Crapse  
Cc: NANOG list  
Subject: Re: DirecTV Now contact 

Yeah, our eyeball network has problems with DirecTV too. 

Would be nice if they were at the various peering exchanges... 

-Mike 

> On May 22, 2018, at 11:08, Michael Crapse  wrote: 
> 
> Our eyeball network is consistently having some streaming 
> issues(buffering) with DirecTV now. Our main recourse is to sell them 
> on youtube TV and netflix. fixes the issue, no more complaints from 
> our customers. Issues mainly occur during peak times and even on 
> 300+mbps low latency/jitter customers. 
> However, if someone from DirecTV could contact me off list and we can 
> debug this issue so that we don't have to keep pulling people to other 
> services that would be great. 
> Alternatively, if anyone could suggest with whom to peer to reduce the 
> impact of this issue, that would be great. 
> A solution that would be even better is if someone from Youtube TV 
> would contact us off list and we can set up something commissioned 
> based for all the good things we say about your service, and of course 
> give our tech support people a reason to not be frustrated with the 
> calls we receive for this issue. 

earthlink email problems

[jimmy keffer]

my has problems sending mail to earthlink.net the sever has a ptr abd
reverse dns set but i get this To: ji...@horsezipsworld.com
Subject: Message undeliverable: MegaBBS Forum horsezip's world : New
user alert
From: mailer-dae...@horsezipsworld.com
Date: Sun, 20 May 2018 23:40:41 -0400

Your message did not reach some or all of the intended recipients.

   Sent: Sun, 20 May 2018 23:40:40 -0400
   Subject: MegaBBS Forum horsezip's world : New user alert

The following recipient(s) could not be reached:

horse...@earthlink.net
   Error Type: SMTP
   Remote server (209.86.93.228) issued an error.
   hMailServer sent: MAIL FROM:
   Remote server replied: 550 ERROR: No or mismatched reverse DNS (PTR)
entries for 23.227.197.10



hMailServer

any one here who can help my server sends mail to servers fine gmail etc
jimmy

RE: DirecTV Now contact

[Joshua Stump]

Similar experience for us as well.

Joshua Stump
Network Admin
Fourway.NET
800-733-0062

-Original Message-
From: NANOG  On Behalf Of mike.l...@gmail.com
Sent: Tuesday, May 22, 2018 2:29 PM
To: Michael Crapse 
Cc: NANOG list 
Subject: Re: DirecTV Now contact

Yeah, our eyeball network has problems with DirecTV too.

Would be nice if they were at the various peering exchanges...

-Mike

> On May 22, 2018, at 11:08, Michael Crapse  wrote:
> 
> Our eyeball network is consistently having some streaming 
> issues(buffering) with DirecTV now. Our main recourse is to sell them 
> on youtube TV and netflix. fixes the issue, no more complaints from 
> our customers. Issues mainly occur during peak times and even on 
> 300+mbps low latency/jitter customers.
> However, if someone from DirecTV could contact me off list and we can 
> debug this issue so that we don't have to keep pulling people to other 
> services that would be great.
> Alternatively, if anyone could suggest with whom to peer to reduce the 
> impact of this issue, that would be great.
> A solution that would be even better is if someone from Youtube TV 
> would contact us off list and we can set up something commissioned 
> based for all the good things we say about your service, and of course 
> give our tech support people a reason to not be frustrated with the 
> calls we receive for this issue.

Re: DirecTV Now contact

[mike . lyon]

Yeah, our eyeball network has problems with DirecTV too.

Would be nice if they were at the various peering exchanges...

-Mike

> On May 22, 2018, at 11:08, Michael Crapse  wrote:
> 
> Our eyeball network is consistently having some streaming issues(buffering)
> with DirecTV now. Our main recourse is to sell them on youtube TV and
> netflix. fixes the issue, no more complaints from our customers. Issues
> mainly occur during peak times and even on 300+mbps low latency/jitter
> customers.
> However, if someone from DirecTV could contact me off list and we can debug
> this issue so that we don't have to keep pulling people to other services
> that would be great.
> Alternatively, if anyone could suggest with whom to peer to reduce the
> impact of this issue, that would be great.
> A solution that would be even better is if someone from Youtube TV would
> contact us off list and we can set up something commissioned based for all
> the good things we say about your service, and of course give our tech
> support people a reason to not be frustrated with the calls we receive for
> this issue.

Re: Segment Routing

[steve ulrich]

sorry, yes. i was referring to SRTE wrt the pop operation.

in most of the implementations i've poked at, there is the ability to
specify a consistent label range, but it's not always the case.  SIDs are
not labels but they are encoded as labels.  i hope operators have the
option to configure common/consistent label ranges, but i don't necessarily
assume it.  tooling to resolve this will be required just as in the LDP
world.


On Tue, May 22, 2018 at 9:19 AM Saku Ytti  wrote:

> Hey Steve,
>
> > the data plane behavior on LDP is swap oriented, while the data plane on
> SR
> > is pop oriented.  depending on the hardware capabilities in use this may
> > have (subtle) traffic engineering or diagnostic implications at a
> minimum.
> > folks will likely have to build tooling to address this.
>
> I think you're thinking of SR-TE, SR in normal LDP-like use case would be
> single
> egress label with swap on LSRs.
>
> Ingress PE would figure out label by using egress PE index as an
> offset to next-hop
> P's label range.
> Nexthop P would swap the label determining out label using same mechanism.
>
> I practice operators would configure same label range in every box, so
> swap would be
> from same label to same label. But that is purely due to operator
> configuration, and
> it's still swap.
>
> --
>   ++ytti
>


-- 
steve ulrich (sulrich@botwerks.*)

Re: Segment Routing

[steve ulrich]

fwiw - there's a potentially significant loss of visibility w/SR from a
traffic management perspective depending on how it's deployed.  though, i
doubt the OP is really driving at this point.

the data plane behavior on LDP is swap oriented, while the data plane on SR
is pop oriented.  depending on the hardware capabilities in use this may
have (subtle) traffic engineering or diagnostic implications at a minimum.
folks will likely have to build tooling to address this.

we're pushing the bubble of complexity around.

On Tue, May 22, 2018 at 8:47 AM Saku Ytti  wrote:

> On 22 May 2018 at 11:19, Matt Geary  wrote:
>
> > really seeing the value of SR to replace LDP on my backbone. With some
> > scripting and lots of software tools I can make it just like LDP, but
> why?
> > So break the ease of LDP just to get label switching on my hub core not
> > really seeing it, unless someone has done it and they are seeing the
> value.
>
> Can you elaborate what scripting and software tools are needed? If you'd
> talk
> about RSVP particularly AutoBW and SR, then yeah, but SR on itself should
> be less of a chore than LDP.
>
> SR is what MPLS was intended to be day1, it just wasn't very marketable
> idea
> to sell MPLS and sell need for changing all the IGPs as well.
> LDP is added state, added signalling, added complexity with reduced
> visibility.
> SR is like full-mesh LDP (everyone has everyone's label POV), while also
> removing one protocol entirely.
>
> --
>   ++ytti
>


-- 
steve ulrich (sulrich@botwerks.*)

DirecTV Now contact

[Michael Crapse]

Our eyeball network is consistently having some streaming issues(buffering)
with DirecTV now. Our main recourse is to sell them on youtube TV and
netflix. fixes the issue, no more complaints from our customers. Issues
mainly occur during peak times and even on 300+mbps low latency/jitter
customers.
However, if someone from DirecTV could contact me off list and we can debug
this issue so that we don't have to keep pulling people to other services
that would be great.
Alternatively, if anyone could suggest with whom to peer to reduce the
impact of this issue, that would be great.
A solution that would be even better is if someone from Youtube TV would
contact us off list and we can set up something commissioned based for all
the good things we say about your service, and of course give our tech
support people a reason to not be frustrated with the calls we receive for
this issue.

RE: Segment Routing

[Jakob Heitz (jheitz)]

Nexus supports LDP.

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/mpls/configuration/guide/mpls_cg/mp_ldp_overview.html


Regards,
Jakob

Re: Subsea availability

[Paul Rolland (ポール・ロラン)]

Hello,

On Tue, 22 May 2018 06:35:12 +0100
Martin Hepworth  wrote:

> I'll put this as a starter
> 
> http://submarine-cable-map-2018.telegeography.com/

This one is rather cool too:
http://he.net/3d-map/

Paul
 
-- 

Paul RollandE-Mail : rol(at)witbe.net
CTO - Witbe.net SA  Tel. +33 (0)1 47 67 77 77
Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99
F-92057 Paris La DefenseRIPE : PR12-RIPE

LinkedIn : http://www.linkedin.com/in/paulrolland
Skype: rollandpaul

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 




pgpHiUfDf_9bz.pgp
Description: OpenPGP digital signature

Re: Segment Routing

[Matt Geary]

Hi Saku gotcha and I see most config examples are RSVP/SR-TE like, where in
most of the networks I have come across basic LDP is more than acceptable.

On Tue, May 22, 2018, 17:48 Saku Ytti  wrote:

> Hey Matt,
>
> > I guess my point is why go through the extra config to program labels for
> > each box when LDP does it for you? Why loose potential visibility to
> network
> > traffic? Cisco sales and marketing is digging huge into the SR game for
> > enterprise and SDWAN like backbone networking. They are touting about the
> > whole industry changing, but I'm not seeing it anywhere in the large
> network
> > or provider space. Hench my original question why SR over LDP? Seems SR
> is a
> > lot of extra config to give you all the program options for white box
> like
> > networking, when basic LDP in a Cisco variant works just fine.
>
> There isn't inherently anything you need to configure in SR, it's all
> implementation detail.
> Juniper requires you configure your 'index', but just as well 'index'
> could be inferred from your loopback0 or router-id.
>
> And indeed in your configuration generation where you generate your
> router-id, you can use static method to turn router-id into unique
> index and configure it once.
> Or you could ask vendor to implement feature to auto-assign index.
>
> Much like some devices can auto-assign unique RD to VRF, some require
> operator to assign them. Entirely implementation detail, not a valid
> argument between protocols.
>
>
> The upside of SR to LDP
>   - removal of entire protocol
>   - full-mesh visibility
>   - guaranteed IGP+Label sync
>
> The amount of configuration needed to do SR like LDP should be less
> than LDP. Confusion may arise by looking at SR examples, as SR can
> also be used like RSVP, which indeed is far more complex use-case.
>
> --
>   ++ytti
>

Re: Segment Routing

[Saku Ytti]

Hey Matt,

> I guess my point is why go through the extra config to program labels for
> each box when LDP does it for you? Why loose potential visibility to network
> traffic? Cisco sales and marketing is digging huge into the SR game for
> enterprise and SDWAN like backbone networking. They are touting about the
> whole industry changing, but I'm not seeing it anywhere in the large network
> or provider space. Hench my original question why SR over LDP? Seems SR is a
> lot of extra config to give you all the program options for white box like
> networking, when basic LDP in a Cisco variant works just fine.

There isn't inherently anything you need to configure in SR, it's all
implementation detail.
Juniper requires you configure your 'index', but just as well 'index'
could be inferred from your loopback0 or router-id.

And indeed in your configuration generation where you generate your
router-id, you can use static method to turn router-id into unique
index and configure it once.
Or you could ask vendor to implement feature to auto-assign index.

Much like some devices can auto-assign unique RD to VRF, some require
operator to assign them. Entirely implementation detail, not a valid
argument between protocols.


The upside of SR to LDP
  - removal of entire protocol
  - full-mesh visibility
  - guaranteed IGP+Label sync

The amount of configuration needed to do SR like LDP should be less
than LDP. Confusion may arise by looking at SR examples, as SR can
also be used like RSVP, which indeed is far more complex use-case.

-- 
  ++ytti

Re: Segment Routing

[Matt Geary]

I guess my point is why go through the extra config to program labels for
each box when LDP does it for you? Why loose potential visibility to
network traffic? Cisco sales and marketing is digging huge into the SR game
for enterprise and SDWAN like backbone networking. They are touting about
the whole industry changing, but I'm not seeing it anywhere in the large
network or provider space. Hench my original question why SR over LDP?
Seems SR is a lot of extra config to give you all the program options for
white box like networking, when basic LDP in a Cisco variant works just
fine.

On Tue, May 22, 2018, 16:19 Saku Ytti  wrote:

> Hey Steve,
>
> > the data plane behavior on LDP is swap oriented, while the data plane on
> SR
> > is pop oriented.  depending on the hardware capabilities in use this may
> > have (subtle) traffic engineering or diagnostic implications at a
> minimum.
> > folks will likely have to build tooling to address this.
>
> I think you're thinking of SR-TE, SR in normal LDP-like use case would be
> single
> egress label with swap on LSRs.
>
> Ingress PE would figure out label by using egress PE index as an
> offset to next-hop
> P's label range.
> Nexthop P would swap the label determining out label using same mechanism.
>
> I practice operators would configure same label range in every box, so
> swap would be
> from same label to same label. But that is purely due to operator
> configuration, and
> it's still swap.
>
> --
>   ++ytti
>

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 17:43, steve ulrich  wrote:

Hey,

> sorry, yes. i was referring to SRTE wrt the pop operation.

Yup RSVP=>SR is more ambiguous and debatable than LDP=>SR which is
unambiguous win.

> not labels but they are encoded as labels.  i hope operators have the option
> to configure common/consistent label ranges, but i don't necessarily assume
> it.  tooling to resolve this will be required just as in the LDP world.

I've not had this tooling in LDP world, and not anticipating to need
it in SR world. But maybe I'm missing something, what kind of
information do you need in LDP world which you need to develop tooling
for, and how does the problem+solution translate to SR world?

-- 
  ++ytti

Re: Segment Routing

[Mark Tinka]

On 22/May/18 16:35, Saku Ytti wrote:

> My first google hit shows IPv6 support:
>
> https://www.juniper.net/documentation/en_US/junos/topics/example/example-configuring-spring-srgb.html

I meant as a field deployment in an operator network, and not what
documentation says code can do.


> I think there may be some confusing with MPLS and IPv6 dataplane
> carrying IPv4/IPv6. MPLS dataplane seems to support in JunOS both IPv4
> and IPV6 labeled prefixes. IPv6 dataplane I could not be less
> interested in, I think it's trash.

Well, I want to forward IPv6 traffic in an MPLS data plane, the same way
I am currently forwarding IPv4 and Ethernet traffic in an MPLS data
plane. And I want to do this as ships-in-the-night to avoid shared risk
by combining 2 protocols into one (the way 6PE depends on IPv4, for
example).

If IPv6 traffic is being forwarded in the core purely on labels
(generated purely either by LDPv6 or SRv6, and not by
6PE-and-friends-type sorcery), then I can disable BGPv6 in the core.

Mark.

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 17:29, Mark Tinka  wrote:

> This is what I'm struggling to find, as for me, this would be the ideal
> use-case for SR.

My first google hit shows IPv6 support:

https://www.juniper.net/documentation/en_US/junos/topics/example/example-configuring-spring-srgb.html

I think there may be some confusing with MPLS and IPv6 dataplane
carrying IPv4/IPv6. MPLS dataplane seems to support in JunOS both IPv4
and IPV6 labeled prefixes. IPv6 dataplane I could not be less
interested in, I think it's trash.
-- 
  ++ytti

Re: Segment Routing

[Mark Tinka]

On 22/May/18 16:21, Saku Ytti wrote:

> I have not, but I'm not good source as I don't track this.

This is what I'm struggling to find, as for me, this would be the ideal
use-case for SR.


>  I'm just
> pointing out that LDP
> was/is IPv4 protocol, where as SR IGP extensions are from day1 IPv4+IPv6 with 
> no
> particular bias.

RFC7552 has been shipping since 2015, and this I know works well. If it
wasn't for Cisco's spotty support in the various platforms in their
portfolio, I'd have taken BGPv6 out of my core ages ago, as Juniper (our
other vendor) has had LDPv6 support for quite a while now.

Mark.

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 17:17, Mark Tinka  wrote:

> Have you seen an actual deployment in the field, forwarding IPv6 traffic
> inside MPLS? My use-case would be to remove BGPv6 in the core, the same way
> I removed BGPv4 from the core back in 2008.

I have not, but I'm not good source as I don't track this. I'm just
pointing out that LDP
was/is IPv4 protocol, where as SR IGP extensions are from day1 IPv4+IPv6 with no
particular bias.

-- 
  ++ytti

Re: Segment Routing

[Saku Ytti]

Hey Steve,

> the data plane behavior on LDP is swap oriented, while the data plane on SR
> is pop oriented.  depending on the hardware capabilities in use this may
> have (subtle) traffic engineering or diagnostic implications at a minimum.
> folks will likely have to build tooling to address this.

I think you're thinking of SR-TE, SR in normal LDP-like use case would be single
egress label with swap on LSRs.

Ingress PE would figure out label by using egress PE index as an
offset to next-hop
P's label range.
Nexthop P would swap the label determining out label using same mechanism.

I practice operators would configure same label range in every box, so
swap would be
from same label to same label. But that is purely due to operator
configuration, and
it's still swap.

-- 
  ++ytti

Re: Segment Routing

[Mark Tinka]

On 22/May/18 16:14, Saku Ytti wrote:

> Yes. In ISIS you'd use Prefix-SID sTLV and attach it to TLV-236 (IPv6)
> or TLV-237 (Multitopo IPv6).
>
> The standard itself has not had any IPv4 bias, IPv6 has had first
> class support since first draft.

Have you seen an actual deployment in the field, forwarding IPv6 traffic
inside MPLS? My use-case would be to remove BGPv6 in the core, the same
way I removed BGPv4 from the core back in 2008.

I know LDPv6 can do this, but support across multiple platforms is not
where it needs to be yet, making network-wide deployment impractical.

Mark.

Re: Segment Routing

[Saku Ytti]

Hey Mark,

> Can I use that to create MPLS LSP's to carry IPv6 traffic over an IPv6
> next-hop, like LDPv6 has been designed to, i.e., not need for IPv4 in any
> way to forward MPLS frames carrying an IPv6 payload?

Yes. In ISIS you'd use Prefix-SID sTLV and attach it to TLV-236 (IPv6)
or TLV-237 (Multitopo IPv6).

The standard itself has not had any IPv4 bias, IPv6 has had first
class support since first draft.

-- 
  ++ytti

Re: Segment Routing

[Mark Tinka]

On 22/May/18 15:38, Saku Ytti wrote:

> Why 'alas'? In ISIS you're free to signal Prefix-SID on IPv4 or IPv6,
> there isn't anything inherently IPv4 in the standard.

Can I use that to create MPLS LSP's to carry IPv6 traffic over an IPv6
next-hop, like LDPv6 has been designed to, i.e., not need for IPv4 in
any way to forward MPLS frames carrying an IPv6 payload?

Don't remember that being the case the last time I checked, but things
could have moved on since then.

Mark.

Re: Subsea availability

[Max Tulyev]

May be there is something similar, but with the sales contact for each
cable system? ;)

22.05.18 08:54, Reid Fishler пише:
> Not to mention:
> https://www.cablemap.info/
> 
> Reid
> 
> 
> On Tue, May 22, 2018 at 1:46 AM james jones  wrote:
> 
>> Not interactive but cool animation:
>>
>> https://www.youtube.com/watch?v=IlAJJI-qG2k
>>
>> On Tue, May 22, 2018 at 1:37 AM, Mehmet Akcin  wrote:
>>
>>> yeah, I know and already reached out to my friends at Telegeography on
>> how
>>> to make www.submarinecablemap.com interactive
>>>
>>> On Mon, May 21, 2018 at 10:35 PM, Martin Hepworth 
>>> wrote:
>>>
 I'll put this as a starter

 http://submarine-cable-map-2018.telegeography.com/

 There's probably better by now

 Martin

 On Tue, 22 May 2018 at 06:13, Mehmet Akcin  wrote:

> Hello there,
>
> I am working on a masters project idea to create an interactive map of
>>> the
> world’s subsea cables (cls to cla without local loops from cls to dc)
>
> I would like to know if anyone have worked with something like this in
>>> the
> past, and whether you think it would be cool to have a map where you
>> can
> see subsea cable availability.
>
> I am also going to be at nanog denver to talk about this project with
> people. Let me know if you are available and interested in talking on
>>> ways
> to collaborate.
>
> I have few ideas on how to make this work with using ripe atlas probe
>>> like
> devices installed in strategic locations.
>
> Mehmet
>
 --
 --
 Martin Hepworth, CISSP
 Oxford, UK

>>>
> 

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 11:19, Matt Geary  wrote:

> really seeing the value of SR to replace LDP on my backbone. With some
> scripting and lots of software tools I can make it just like LDP, but why?
> So break the ease of LDP just to get label switching on my hub core not
> really seeing it, unless someone has done it and they are seeing the value.

Can you elaborate what scripting and software tools are needed? If you'd talk
about RSVP particularly AutoBW and SR, then yeah, but SR on itself should
be less of a chore than LDP.

SR is what MPLS was intended to be day1, it just wasn't very marketable idea
to sell MPLS and sell need for changing all the IGPs as well.
LDP is added state, added signalling, added complexity with reduced visibility.
SR is like full-mesh LDP (everyone has everyone's label POV), while also
removing one protocol entirely.

-- 
  ++ytti

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 12:36, Mark Tinka  wrote:

> I was excited about SR because I thought it would finally enable native
> MPLSv6 forwarding. But alas...

Why 'alas'? In ISIS you're free to signal Prefix-SID on IPv4 or IPv6,
there isn't anything inherently IPv4 in the standard.

-- 
  ++ytti

Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in general)

[Sebastian Wiesinger]

* David Hubbard  [2018-05-16 19:01]:
> I’m curious if anyone who’s used 3356 for transit has found
> shortcomings in how their peering and redundancy is configured, or

>From a recent experience I can tell you that a change request to
change a peering from "full table" to "default route only" has
resulted in now 3+ weeks of conversation and an outage when they
misconfigured their session without them realising it.

Colleague of mine is now trying to send them the exact required set
commands for the Juniper gear they're using.

This is not what I would expect from a carrier like 3356.

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant

Re: Subsea availability

[Reid Fishler]

Not to mention:
https://www.cablemap.info/

Reid


On Tue, May 22, 2018 at 1:46 AM james jones  wrote:

> Not interactive but cool animation:
>
> https://www.youtube.com/watch?v=IlAJJI-qG2k
>
> On Tue, May 22, 2018 at 1:37 AM, Mehmet Akcin  wrote:
>
> > yeah, I know and already reached out to my friends at Telegeography on
> how
> > to make www.submarinecablemap.com interactive
> >
> > On Mon, May 21, 2018 at 10:35 PM, Martin Hepworth 
> > wrote:
> >
> > > I'll put this as a starter
> > >
> > > http://submarine-cable-map-2018.telegeography.com/
> > >
> > > There's probably better by now
> > >
> > > Martin
> > >
> > > On Tue, 22 May 2018 at 06:13, Mehmet Akcin  wrote:
> > >
> > >> Hello there,
> > >>
> > >> I am working on a masters project idea to create an interactive map of
> > the
> > >> world’s subsea cables (cls to cla without local loops from cls to dc)
> > >>
> > >> I would like to know if anyone have worked with something like this in
> > the
> > >> past, and whether you think it would be cool to have a map where you
> can
> > >> see subsea cable availability.
> > >>
> > >> I am also going to be at nanog denver to talk about this project with
> > >> people. Let me know if you are available and interested in talking on
> > ways
> > >> to collaborate.
> > >>
> > >> I have few ideas on how to make this work with using ripe atlas probe
> > like
> > >> devices installed in strategic locations.
> > >>
> > >> Mehmet
> > >>
> > > --
> > > --
> > > Martin Hepworth, CISSP
> > > Oxford, UK
> > >
> >

Re: Segment Routing

[Matt Geary]

SR as a replacement for LDP, but SR-LDP imterop is imteresting too. Do.you
have any experience with that?

On May 22, 2018 02:59, "dip"  wrote:

Matt,

Just to clarify, Are you asking for SR and LDP interop or SR over LDP? Two
different things.

Thanks
Dip

On Fri, May 18, 2018 at 3:11 AM, Matt Geary  wrote:

> Hello maillist anyone had any experience with segment routing and its
> performance over LDP? We are evaluating the option to move to SR over LDP
> so we can label switch across our Nexus L3 switching environment.
>
> Thanks
> Packet Plumber
>

-- 
Sent from iPhone

Re: Segment Routing

[Matt Geary]

Yeah Cisco rep commented that adding LDP to nexus would make ASR obsolete.
48x10g with LDP for $5-7k Yeah no brainer. Although on other point I am not
really seeing the value of SR to replace LDP on my backbone. With some
scripting and lots of software tools I can make it just like LDP, but why?
So break the ease of LDP just to get label switching on my hub core not
really seeing it, unless someone has done it and they are seeing the value.

On Tue, May 22, 2018, 10:14 Mark Tinka  wrote:

>
>
> On 22/May/18 10:06, Matt Geary wrote:
>
> Yes we are considering changing to SR on our backbone because LDP is not
> supported on the nexus switches. Although, we have no experience with SR
> and looks plainly simple but we loose some of the LSP path selection.
>
>
> Got you.
>
> I'm more curious about use-cases for folk considering SR, than SR itself.
>
> 4 years on, and I still can't find a reason to replace my LDP network with
> SR.
>
> Your use-case makes sense, as it sounds like Cisco deliberately left LDP
> out of your box, considering SR is in. But that's a whole other discussion
> :-)...
>
> Mark.
>

Re: Segment Routing

[Matt Geary]

Yes we are considering changing to SR on our backbone because LDP is not
supported on the nexus switches. Although, we have no experience with SR
and looks plainly simple but we loose some of the LSP path selection.

On Tue, May 22, 2018, 10:05 Mark Tinka  wrote:

>
>
> On 18/May/18 12:11, Matt Geary wrote:
>
> Hello maillist anyone had any experience with segment routing and its
> performance over LDP? We are evaluating the option to move to SR over LDP
> so we can label switch across our Nexus L3 switching environment.
>
>
> Is your use-case because you need label switching and the Nexus does not
> support LDP?
>
> Mark.
>

Re: Segment Routing

[Mark Tinka]

On 22/May/18 14:10, Ca By wrote:

>
>
>
> Well look at how many authors are on this rfc, that means it is super
> good right? More authors, more brains
>
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07
>
>
> Actually it is just an embarasssing marketing technique. Sad!

Let's hope it doesn't suffer the same fate as LDPv6 did, whose
implementation across all platforms within one specific vendor is very
poor, meaning you can't really use it in real life, never mind a
multi-vendor network.

Mark.

Re: Segment Routing

[Ca By]

On Tue, May 22, 2018 at 2:39 AM Mark Tinka  wrote:

>
>
> On 22/May/18 10:51, James Bensley wrote:
>
> > I'm also interested in the uses cases.
> >
> > As a "typical" service provider (whatever that means) who doesn't have
> > any SR specific requirements such as service chaining, the only
> > reason/feature SR has which currently makes me want to deploy it is
> > TI-FLA (to improve our (r)LFA coverage) - but this is only for failure
> > scenarios so under normal working conditions as far as I know, there
> > is no benefit available to us right now.
>
> +1.
>
> I was excited about SR because I thought it would finally enable native
> MPLSv6 forwarding. But alas...
>
> I've heard of "quiet" tests going on within some operator networks, but
> if you look around, SR is being pushed by the vendors, and none of them
> can give me a concrete example of a deployment in the wild worth talking
> about.
>
> Of course, always open to correction...


Well look at how many authors are on this rfc, that means it is super good
right? More authors, more brains

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07


Actually it is just an embarasssing marketing technique. Sad!


>
> Mark.
>

Re: Segment Routing

[Mark Tinka]

On 22/May/18 10:51, James Bensley wrote:

> I'm also interested in the uses cases.
>
> As a "typical" service provider (whatever that means) who doesn't have
> any SR specific requirements such as service chaining, the only
> reason/feature SR has which currently makes me want to deploy it is
> TI-FLA (to improve our (r)LFA coverage) - but this is only for failure
> scenarios so under normal working conditions as far as I know, there
> is no benefit available to us right now.

+1.

I was excited about SR because I thought it would finally enable native
MPLSv6 forwarding. But alas...

I've heard of "quiet" tests going on within some operator networks, but
if you look around, SR is being pushed by the vendors, and none of them
can give me a concrete example of a deployment in the wild worth talking
about.

Of course, always open to correction...

Mark.

Re: Segment Routing

[Mark Tinka]

On 22/May/18 10:19, Matt Geary wrote:

> Yeah Cisco rep commented that adding LDP to nexus would make ASR
> obsolete. 48x10g with LDP for $5-7k Yeah no brainer.

Gee, someone at Cisco had their thinking cap on. Let's hope Gert isn't
reading this, lest he vent-off about the 6500/7600 debacle (and rightly
so) :-).

Seriously though, crippling one box to help ship another has never sat
well with me. In the first instance, what business does a switch have
being a label switching router? Maybe I'm too purist, but when functions
begin to overlap like this, it's headache for operators and multiple
sources of revenue for equipment vendors, despite what their "portfolio
positioning" suggests. They are very aware about the confusion they are
causing, at our expense.

At least there are some new entrants into the space that haven't yet
been totally corrupted by the silo-based approach that leads to the same
company appearing like 1,200 different ones.


> Although on other point I am not really seeing the value of SR to
> replace LDP on my backbone. With some scripting and lots of software
> tools I can make it just like LDP, but why? So break the ease of LDP
> just to get label switching on my hub core not really seeing it,
> unless someone has done it and they are seeing the value.

Yep, my point exactly.

Mark.

Re: Segment Routing

[James Bensley]

On 22 May 2018 at 09:14, Mark Tinka  wrote:
> I'm more curious about use-cases for folk considering SR, than SR itself.
>
> 4 years on, and I still can't find a reason to replace my LDP network
> with SR.
>
> Your use-case makes sense, as it sounds like Cisco deliberately left LDP
> out of your box, considering SR is in. But that's a whole other
> discussion :-)...

I'm also interested in the uses cases.

As a "typical" service provider (whatever that means) who doesn't have
any SR specific requirements such as service chaining, the only
reason/feature SR has which currently makes me want to deploy it is
TI-FLA (to improve our (r)LFA coverage) - but this is only for failure
scenarios so under normal working conditions as far as I know, there
is no benefit available to us right now.

Cheers,
James.

Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in general)

[Ben Cannon]

Yep?



-Ben

> On May 21, 2018, at 6:37 PM, Aaron Gould  wrote:
> 
> 9010 and 7609 Small? 
> 
> Aaron
> 
>> On May 19, 2018, at 3:51 PM, Ben Cannon  wrote:
>> 
>> Isn’t that the ASR9010?  (And before that 7609?)
>> 
>> -Ben
>> 
 On May 18, 2018, at 4:20 AM, Tom Hill  wrote:
 
 On 17/05/18 14:24, Mike Hammett wrote:
 There's some industry hard-on with having a few ginormous routers instead 
 of many smaller ones.
>>> 
>>> "Industry hard-on", ITYM "Greedy vendors".
>>> 
>>> Try finding a 'small' router with a lot of ports (1 & 10GE) for your
>>> customers, and the right features/TCAM/CP performance, for a price that
>>> permits you to buy a lot of them.
>>> 
>>> -- 
>>> Tom
> 

Re: Segment Routing

[Mark Tinka]

On 22/May/18 10:06, Matt Geary wrote:

> Yes we are considering changing to SR on our backbone because LDP is
> not supported on the nexus switches. Although, we have no experience
> with SR and looks plainly simple but we loose some of the LSP path
> selection.

Got you.

I'm more curious about use-cases for folk considering SR, than SR itself.

4 years on, and I still can't find a reason to replace my LDP network
with SR.

Your use-case makes sense, as it sounds like Cisco deliberately left LDP
out of your box, considering SR is in. But that's a whole other
discussion :-)...

Mark.

Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in general)

[Mark Tinka]

On 19/May/18 22:51, Ben Cannon wrote:

> Isn’t that the ASR9010?  (And before that 7609?)

The ASR9901 comes reasonably close - as close as the MX204 could get
(although 1Gbps ports might be an issue).

Mark.

Re: Segment Routing

[Mark Tinka]

On 18/May/18 12:11, Matt Geary wrote:

> Hello maillist anyone had any experience with segment routing and its
> performance over LDP? We are evaluating the option to move to SR over LDP
> so we can label switch across our Nexus L3 switching environment.

Is your use-case because you need label switching and the Nexus does not
support LDP?

Mark.

Re: is odd number of links in lag group ok

[Mark Tinka]

On 17/May/18 01:32, Ben Cannon wrote:

> While it goes without saying that you need the same (can be 5!) number of 
> links to each router in a multichassis LAG, what isn’t so obvious are things 
> like port groups etc.

I'm not sure the OP was talking about MC-LAG. Just a regular LAG.

Mark.

Re: Juniper BGP Convergence Time

[Mark Tinka]

On 16/May/18 18:59, Phil Lavin wrote:

> Ask if they will configure BFD for you. I’ve not found many transit providers 
> that will, but it’s worth a shot and it will lower failure detection to circa 
> 1 second.
We've tended to shy away from it, but we have 2 customers we've done it for.

Mark.