Re: 1GE L3 aggregation

[Mark Tinka]

On 22/Jun/16 22:04, David Charlebois wrote:

> Hello
> I'm curious about the overall recommendation when selecting a small class
> BGP router for IPv6 (with 1gig ports). We can see the current IPv4 routing
> table is around 615k routes and the IPv6 routing table is sitting around
> ~31k routes.
>
> In our case, we advertise a single /24 from our head office to 2 upstream
> providers. The routing is %100 for redundancy.
>
> Somebody mentioned that the Brocade CER-RT was once a best seller. Brocade
> are now offering the CER 4X-RT version at 256K IPv6 routes supported (1.5M
> IPv4 routes). We don't have immediate plans for IPv6, but I do foresee this
> in a few year. Question is - is 256k IPv6 routes suitable?

The CER/CES NetIron boxes from Brocade are reasonable.

That said, BGP-SD implementations apply both to IPv4 and IPv6. So in a
Metro-E Access deployment scenario, the number of IPv6 routes would not
matter, as we only download into FIB the minimum necessary to keep the
box alive.

Mark.

Re: IP and Optical domains?

[Phil Bedard]

We have a single IP and optical group, but that’s not common at most larger 
carriers.  We have a fairly complex national dark fiber backbone as well as 
complicated metro networks.  You see a lot of vendors tout IP/optical 
integration around optimization of resources, but the starting point is usually 
a carrier who provisions both L3 protection and L1 circuit protection at the 
same time.  It’s obvious to most that isn’t efficient, but there are carriers 
out there who do that because the groups are so disjoint.  I would say that 
does not represent the majority of carriers today however.  Optical vendors 
will tout optical restoration as a means to reduce excess L3 capacity and they 
are right, with modern CDC ROADMs and coherent optics you can plan a network 
around optical restoration and gain a lot of cost reduction by reducing L3 
capacity.  The tradeoff is in restoration times, as the photonic layer can’t 
restore very fast right now, so there is a middle ground for most networks of 
carrying either fully protected capacity at L3 or L1, and restoring other 
capacity dynamically.  Typically for a subset of traffic like high priority 
traffic.  

I read the bulk of this thread and IPoDWDM is interesting from a collapsing of 
boxes perspective if the network is simple enough it’s easy to operate and it 
makes financial sense.  All the major router vendors are being forced by 
content providers to integrate them into their boxes.   At OFC MS announced 
they had been working with InPhi to develop a shorter reach (80km) tunable 
QSFP28.  If it does not need to integrate into an optical control plane (like 
one doing optical restoration) then it’s a very valid solution and I think 
you’ll continue to see growth with it.   

I call SDN the get out of jail free card for optical vendors because they no 
longer have to even pretend they will interoperate via standard protocols like 
GMPLS.  They expose REST APIs and people are willing to take it because it’s 
fairly easy to deal with.  

Phil  

-Original Message-
From: NANOG  on behalf of Glen Kent 

Date: Saturday, June 18, 2016 at 17:27
To: "nanog@nanog.org" 
Subject: IP and Optical domains?

HI,

I was reading the following article:
http://www.lightreading.com/optical/sedona-boasts-multilayer-network-orchestrator/d/d-id/714616

It says that "The IP layer and optical layer are run like two separate
kingdoms," Wellingstein says. "Two separate kings manage the IP and optical
networks. There is barely any resource alignment between them. The result
of this is that the networks are heavily underutilized," or, from an
alternative perspective, "they are heavily over-provisioned."

Can somebody shed more light on what it means to say that the IP and
optical layers are run as independent kingdoms and why do ISPs need to
over-provision?

Thanks, Glen

Re: 1GE L3 aggregation

[David Charlebois]

Hello
I'm curious about the overall recommendation when selecting a small class
BGP router for IPv6 (with 1gig ports). We can see the current IPv4 routing
table is around 615k routes and the IPv6 routing table is sitting around
~31k routes.

In our case, we advertise a single /24 from our head office to 2 upstream
providers. The routing is %100 for redundancy.

Somebody mentioned that the Brocade CER-RT was once a best seller. Brocade
are now offering the CER 4X-RT version at 256K IPv6 routes supported (1.5M
IPv4 routes). We don't have immediate plans for IPv6, but I do foresee this
in a few year. Question is - is 256k IPv6 routes suitable?

Thanks
Dave

Cisco 2 factor authentication

[Ray Ludendorff]

Has anyone setup two factor VPN using a Cisco ASA VPN solution?
What sort of soft client based dual factor authentication options were used for 
the Cisco VPNs (e.g. Symantec VIP, Google authenticator, Azure authenticator, 
RSA, etc.)
I am trying to find what infrastructure is needed to come up with the solution.

Please contact me of list

Regards
Ray Ludendorff

Re: IP and Optical domains?

[Masataka Ohta]

Mark Tinka wrote:


I think you mean IPoDWDM something so much different from
usual ways to have IP over something.

Do you have any reference to it?


I said "visbility" due to what IPoDWDM can offer.

But I also said IP has no real "awareness" about the physical
infrastructure. It just knows it can't send/receive packets anymore.

With IPoDWDM, one could infer that the IP layer will quickly re-route
due to DWDM characteristics (related to fibre conditions).


Wrong. There is no room for such reroute with IP just over DWDM.

You are saying something IP over sublayer1 over sublayer2
over sublayer3 over sublayer4 over sublayer5 over DWDM IPoDWDM.

Of course, each sublayer has additional inefficiency and obscurity.

That you call it IPoDWDM means that you accept the obscurities
and though you think IPoDWDM 60% efficient, it is actually that
IP over sulayer1 is 60% efficient and if efficiencies between
other layers are 60%, actual efficiency of IPoDWDM is 4.7%,
which is "heavily underutilized".


However, in
actual fact, what IP really sees is the link going away, and thus,
triggering an IGP reconvergence.


And, with properly designed IGP, that's fine.


There is no difference if IP is running directly over fibre (in
Ethernet).


Ethernet is already too complex to be "directly over fiber".

Point to point Ethernet may barely be.

> The difference with IPoDWDM

Never call something a lot more complicated than Ethernet between
IP and DWDM IPoDWDM.

Masataka Ohta

Re: Google Geolocation issue

[Tom Okman]

I see your maxmind DB points to a right location as well as traceroute goes
to Austin.

Are you a member of their peering project? What you can see there?

Anyway, I still think that there are guys from google here that can be a
better help than me :)

Good luck.

Tom

2016-06-21 21:25 GMT+03:00 Chris Boyd :

> Dear list readers, please forgive the noise, but if there's anyone here
> from Google who can fix a geolocation issue I'd appreciate a reply.
>
> 208.81.245.226 is not in the UAE, it's in Austin, Texas.  Yes, I have
> filled out the form to request a fix, but the AI or whatever that's
> supposed to fix it has not, and we're well into 3 months after the first
> report.
>
> Thanks,
>
> --Chris
>
>


-- 
Tomas Okmanas

Re: IPv4 Legacy assignment frustration

[Kraig Beahn]

The following might add some clarity, depending upon how you look at it:

We, as "core" engineers know better than to use some of the sources listed
below, tho, my suspicion is that when an engineer or local IT person, on an
edge network starts to see various types of attacks, they play wack-a-mole,
based upon outdated or incomplete data, and never think twice about
revisiting such, as, from their perspective, everything is working just
fine.

In a networking psychology test, earlier this morning, I wrote to ten
well-known colleagues that I was fairly confident didn't regularly follow
the nanog lists. Such individuals comprised of IP and IT engineers for
which manage various network sizes and enterprises, ultimately posing the
question of "Where in the world is 150.201.15.7, as we were researching
some unique traffic patterns".

*Seven out of ten came back with overseas*. Two came back with more
questions "as the address space appeared to be assigned to APNIC", but was
routed domestically.

*One came back with the correct response.* (MORENET)

Two of the queried parties were representative of major networks, one for
an entire state governmental network with hundreds of thousands of actual
users and tens of thousands of routers, the other from another major
university. (Names left out, in the event they see this message later in
the day or week)

After probing the origin of their responses, I found the following methods
or data-sources were used:

-Search Engines - by far, the worst offender. Not necessarily "the engines"
at fault, but a result of indexed sites containing inaccurate or outdated
CIDR lists.
-User generated forums, such as  "Block non-North American Traffic for
Dummies Like Me
"
(Yes - that's the actual thread name on WebMasterWorld.com, from a Sr.
Member)
-Static (or aged) CIDR web-page based lists, usually placed for advertorial
generation purposes and rarely up to date or accurate. (usually via SE's or
forum referrals)
-APNIC themselves - A basic SE search resulted in an APNIC page

that,
on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the
current APNIC range.
-GitHub BGP Ranking tools: CIRCL / bgp-ranging example

(last
updated on May 16th, 2011, tho an RT lookup
 via the CIRCL tool
does shows the appropriate redirect/org)
-Several routing oriented books and Cisco examples

list
such range, for example, FR/ISBN 2-212-09238-5.
-And even established ISPs, that are publically announcing their "block list
", such as Albury's Local
ISP in Australia

The simple answer is to point IT directors, IP engineers or "the
receptionists that manages the network" to the appropriate registry
data-source, which should convince them that corrective action is
necessary, i.e. fix your routing table or firewall. The complexity begins
in trying to locate all of these people and directing them to the
appropriate data-source, which I think is an unrealistic task, even for the
largest of operators. Maybe a nanog-edge group is in order.

If the issue was beyond just a nuisance and If I were in your shoes, i'd
renumber or use an alternate range for the types of traffic affected by
such blocks, i.e. administrative web traffic trying to reach major
insurance portals. (Looks like AS2572 is announcing just over 700k IPv4
address, over about 43 ranges with only some potentially affected)

Realizing that renumbering is also extremely unrealistic, if you haven't
already reached the IPv6 bandwagon, that's an option or, if none of the
above seem reasonable, you could always put together a one-page PDF that
points these administrators to the appropriate resource to validate that
you, are in fact, part of the domestic United States.

I agree that a more accurate tool probably needs to be created for the
"general population to consume," but then again, even that solution, is
"just another tool" for the search-engines to index, and you're back at
square one.

As much as I think most of us would like to help fix this issue, I don't
know that a decent, non-invasive solution exists, at least based upon the
few hours we threw at this issue today...

On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch  wrote:

> Spurling, Shannon  wrote:
>
> > It’s a problem with the miss-use of the RIR delegation of a legacy
> > block.
> >
> > The assumption that because a block is assigned to a particular RIR, all
> > users in that block have to be in that RIR’s territory, without actually
> > running a query against that RIR’s Whois database.
>
> 

Re: IP and Optical domains?

[Jason Iannone]

The IP and Transport groups are customers of each other.  When I need
a wire, I ask the Transport group to deliver a wire.  This is pretty
simple division of labor stuff.  Transport has the intimate knowledge
of the layer 1 infrastructure and IP has intimate knowledge of
services.  Sure there is information share, but I don't need to assign
wavelengths or protection groups or channels.  I don't need to know if
I'm getting an OTU or some other lit service (except when I do need to
know).  We use clear jargon to order services from each other.
"Please deliver two diverse, unprotected circuits between cilli1 and
cilli2."  If I want LACP or spanning-tree, I want OTU or another means
of ensuring L2 tunneling, so I either predefine these requirements
before we start our relationship or I explicitly order it.

When I think of converging IP and Transport, I think of combining the
extraordinary depth of knowledge required by each group's individual
contributors.  You just turned your 100k employee into a 175k
employee.  On top of that, add that we're all becoming software
developers and you've got a three horned unicorn.  In the end I guess
this is the cycle of convergence to distribution and back writ HR.

On Sat, Jun 18, 2016 at 3:27 PM, Glen Kent  wrote:
> HI,
>
> I was reading the following article:
> http://www.lightreading.com/optical/sedona-boasts-multilayer-network-orchestrator/d/d-id/714616
>
> It says that "The IP layer and optical layer are run like two separate
> kingdoms," Wellingstein says. "Two separate kings manage the IP and optical
> networks. There is barely any resource alignment between them. The result
> of this is that the networks are heavily underutilized," or, from an
> alternative perspective, "they are heavily over-provisioned."
>
> Can somebody shed more light on what it means to say that the IP and
> optical layers are run as independent kingdoms and why do ISPs need to
> over-provision?
>
> Thanks, Glen

RE: IPv4 Legacy assignment frustration

[Tony Finch]

Spurling, Shannon  wrote:

> It’s a problem with the miss-use of the RIR delegation of a legacy
> block.
>
> The assumption that because a block is assigned to a particular RIR, all
> users in that block have to be in that RIR’s territory, without actually
> running a query against that RIR’s Whois database.

Actually, a simple whois query often isn't enough to solve this problem.
Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses that
are registered in other RIRs. ARIN, however, does.

(However, if the geoip people are using whois data, I can't believe they
aren't handling cases like this properly, because it's blatantly obvious
if you scan IPv4 address space for referrals.)


If you use FreeBSD-CURRENT's whois client, it tries to work mostly by
following referrals, rather than using a built-in database mapping query
strings to whois servers. If you query for 150.199.0.0 (for example) you
get the following (which I have brutally trimmed for length):

% IANA WHOIS server

refer:whois.apnic.net

inetnum:  150.0.0.0 - 150.255.255.255
organisation: Administered by APNIC
status:   LEGACY

% [whois.apnic.net]

inetnum:150.0.0.0 - 150.255.255.255
netname:ERX-NETBLOCK
descr:  Early registration addresses

remarks:Address ranges from this historical space have now
remarks:been transferred to the appropriate RIR database.remarks:
remarks:If your search has returned this record, it means the
remarks:address range is not administered by APNIC.
remarks:
remarks:Instead, please search one of the following databases:

(It then unhelpfully lists all the other RIRs.)

FreeBSD's whois client spots this failure then retries the query at ARIN.


There's a similar problem with RIPE, for instance if you query for
141.211.0.0:

% IANA WHOIS server

refer:whois.ripe.net

inetnum:  141.0.0.0 - 141.255.255.255
organisation: Administered by RIPE NCC
status:   LEGACY

% This is the RIPE Database query service.

inetnum:141.209.0.0 - 141.225.255.255
netname:NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK
descr:  IPv4 address block not managed by the RIPE NCC

remarks:You can find the whois server to query, or the
remarks:IANA registry to query on this web page:
remarks:http://www.iana.org/assignments/ipv4-address-space
remarks:
remarks:You can access databases of other RIRs at:

(It then unhelpfully lists all the other RIRs.)

Actually RIPE is even worse than APNIC because it implicitly has a
referral loop between IANA and RIPE.


BUT NOTE!

The APNIC and RIPE databases do in fact contain the referral information -
you can get it via RDAP but not whois. Repeating the examples,

$ curl -i https://rdap.apnic.net/ip/150.199.0.0
HTTP/1.1 301 Moved Permanently
Location: https://rdap.arin.net/registry/ip/150.199.0.0

$ curl -i https://rdap.db.ripe.net/ip/141.211.0.0
HTTP/1.1 301 Moved Permanently
Location: https://rdap.arin.net/registry/ip/141.211.0.0


Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog patches,
thundery showers. Moderate, occasionally very poor.

Questions asked of potential candidates for ARIN Board of Trustees / ARIN AC / NRO NC

[John Curran]

NANOGers -

   Each year, the ARIN community asks the potential nominees to the Board and
   ARIN Advisory Council to complete a questionnaire of biographic information 
as
   well as other questions that might help folks better understand their 
qualifications
   and perspective.  For example, the 2015 nominee questions included (among 
others)
   "How do you foresee ARIN's function, scale, or role changing in the wake of 
IPv4
   exhaustion?” and "What are your thoughts on the rights and responsibilities 
of legacy
   IP address holders?”

   The cutoff for submission of questions to the Nominations Committee for 
consideration
   for inclusion in the 2016 questionnaire is next Wednesday (29 June 2016) - 
please see
   the attached announcement for additional details and submission information.

Thanks!
/John

John Curran
President and CEO
ARIN

===

Begin forwarded message:

From: ARIN >
Subject: [arin-announce] Community Input Sought for 2016 Nominee Questionnaires
Date: June 15, 2016 at 11:30:51 AM EDT
To: >

Each fall, ARIN's membership elects individuals to the ARIN Board of
Trustees and Advisory Council (AC), including selecting one ARIN
representative to the Number Resource Organization Number Council (NRO
NC). To run, a nominee must submit an online questionnaire that is
designed to elicit details of their relevant experience. In preparation,
ARIN is opening the floor to the community for input in this year's
nominee questionnaires.

If you have questions that are relevant to policy issues or challenges
facing ARIN that you'd like candidates to answer, send them to
memb...@arin.net no later than 29 June 2016. Please 
mark whether your
question is directed to candidates for the Board of Trustees, AC, or the
NRO NC, or any combination of the three.

The Nomination Committee (NomCom) will review all submissions and then
determine the final list and phrasing of all candidate questions.

ARIN will publish candidate bios, including their questionnaire
responses, when the slate of candidates is announced on 15 September.
Questionnaire responses will also appear in the 2016 Voter Guide that
will be mailed to all member organizations this fall prior to elections.

To learn more about the Board of Trustees and AC election procedures and
to view the 2015 nominee questions, please visit:
https://www.arin.net/participate/elections/elec_procedures.html

To learn more about the NRO NC election/appointment procedures and to
view the 2015 nominee questions, please visit:
https://www.arin.net/participate/elections/nronumbercouncil.html

To learn more about ARIN Elections and upcoming key dates, please visit:
https://www.arin.net/participate/elections/index.html

As always, ARIN values community participation and input. We look
forward to receiving your questions!

Regards,

Wendy Leedy
Member Engagement Coordinator
American Registry for Internet Numbers (ARIN)

___
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (arin-annou...@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-announce
Please contact i...@arin.net if you experience any issues.

Re: IPv4 Legacy assignment frustration

[Alastair Johnson]

On 6/22/16 6:36 AM, Spurling, Shannon wrote:

It’s a problem with the miss-use of the RIR delegation of a legacy
block.

The assumption that because a block is assigned to a particular RIR,
all users in that block have to be in that RIR’s territory, without
actually running a query against that RIR’s Whois database.


I don't think it's an RIR / RIR-related problem, just - as you said - a 
short-sighted security practice.


Operators that connect to the Internet and then decide "OMG, Asia is 
evil" are fairly frustrating. This has caused me a number of problems 
for decades, as AU/NZ are fairly frequent trading partners of USA and I 
have frequently run into this attitude.

RE: IPv4 Legacy assignment frustration

[Spurling, Shannon]

It’s a problem with the miss-use of the RIR delegation of a legacy block.

The assumption that because a block is assigned to a particular RIR, all users 
in that block have to be in that RIR’s territory, without actually running a 
query against that RIR’s Whois database.



From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com] On 
Behalf Of Christopher Morrow
Sent: Tuesday, June 21, 2016 10:36 PM
To: Suresh Ramasubramanian 
Cc: Spurling, Shannon ; nanog@nanog.org
Subject: Re: IPv4 Legacy assignment frustration

how is this a problem with  the RIR ?

On Tue, Jun 21, 2016 at 11:01 PM, Suresh Ramasubramanian 
> wrote:
There is absolutely no budgeting for idiots.  Beyond a long hard process that 
is helped by internal escalations from affected people on a corporate network - 
ideally as senior as you can get - ot their IT staff.  “Missouri isn’t in 
China, you nitwit.  Fix it or I, the CFO, will go have a word with the CIO and 
..”

In other words, have affected people escalate up the chain to the ISP or more 
likely corporate IT team that’s doing this sort of stupid filteringg.

> On 21-Jun-2016, at 8:07 PM, Spurling, Shannon 
> > wrote:
>
> I am not sure how many on the list are Legacy resource holders from before 
> the RIR's were established, but there is an extremely short sighted security 
> practice that is being used across the internet.
>
> Apparently, the RIR that has been given "authority" for an IP prefix range 
> that was a legacy assignment is being used as a geographical locator for 
> those prefixes. For instance, we provide access for several /16's that are in 
> the 150/8 prefix that was set as APNIC. I am aware of quite a few 
> organizations in the US that have prefixes in that range. We have registered 
> our legacy resources with ARIN, but there are some people insist that somehow 
> the state of Missouri must be part of China because... "APNIC!". They set 
> firewalls and access rules based on that, and are hard pressed to not fix 
> them.
>
> Is there any way to raise awareness to this inconsistency so that security 
> people will stop doing this?

Re: IP and Optical domains?

[Mark Tinka]

On 22/Jun/16 13:17, Masataka Ohta wrote:

>  
> What? "the visibility is there"?
>
> I think you mean IPoDWDM something so much different from
> usual ways to have IP over something.
>
> Do you have any reference to it?

I said "visbility" due to what IPoDWDM can offer.

But I also said IP has no real "awareness" about the physical
infrastructure. It just knows it can't send/receive packets anymore.

With IPoDWDM, one could infer that the IP layer will quickly re-route
due to DWDM characteristics (related to fibre conditions). However, in
actual fact, what IP really sees is the link going away, and thus,
triggering an IGP reconvergence. It does not really know that the
degraded optical signal quality on the fibre was the cause, it just
knows that the link disappeared.

There is no difference if IP is running directly over fibre (in
Ethernet). The difference with IPoDWDM is that the re-routing is done
before the fibre actually loses link, because the line card is
monitoring the optical signal and deciding whether to keep the port up
or not. This is to minimize (or avoid) packet loss incurred by failing
only after link failure (which would be the case with generic IP running
directly over fibre (again, in Ethernet).

Whatever the case, IP is not aware about the state of the physical link.
It just sees the link going away.

But something tells me you know all this already, so...

>
> For my definition of IPoDWDM, see, for example:
>
> "Standardization of optical packet switching with
> many-wavelength packets"
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4542288
>
> or my newest paper in HPSR2016.

Interesting.

Do you know of any implementations?

Mark.

The following nameservers incorrectly return BADVERS

[Mark Andrews]

The following servers for Alexa top 1M names incorrectly return
BADVERS to a DNS query with a EDNS option.

BADVERS is supposed to be used for EDNS version negotiation not
because you see a EDNS option.  Please contact your nameserver
vendor for a fix.

This error will result in DNS validation failures if you are
serving signed zones.  This error will also result in slower
DNS resolution.

Mark

a.myradns.at b.myradns.at ns1.careerhub.com.au ns2.careerhub.com.au
ns3.careerhub.com.au lyra.caixa.gov.br mira.caixa.gov.br ns1.divio.ch
ns2.divio.ch ns4.divio.ch ns2.ec.com.cn sns.ec.com.cn ns1.sina.com.cn
mecca.dlnu.edu.cn ns2.brainydns.com ns1.commonmx.com ns2.commonmx.com
ns1.derbycon.com ns2.derbycon.com ns3.derbycon.com ns4.derbycon.com
ns1.dnsnuts.com ns2.dnsnuts.com ns1.dockyard.com ns3.dockyard.com
ns2.domainmx.com ns1.energeticsource.com ns2.energeticsource.com
dev2.hastydns.com ns1.hastydns.com ns2.hastydns.com ns.inboxinc.com
ns3.inboxinc.com ns1.kirklanddc.com ns2.kirklanddc.com ns1.nawebu.com
ns2.nawebu.com ns3.nawebu.com ns1.pebblecode.com ns2.pebblecode.com
ns3.pebblecode.com ns1.pro-websolutions.com ns4.pro-websolutions.com
ns1.redmonddc.com ns2.redmonddc.com ns1.rentondc.com ns2.rentondc.com
ns1.smtmdns.com ns2.smtmdns.com ns1.torresdns.com ns2.torresdns.com
ns1.usecanvas.com ns2.usecanvas.com ns4.weddingful.com ns1.worlize.com
ns2.worlize.com a.myradns.de b.myradns.de ns3.zenjoy.eu ns1.tsp.gov
ns2.tsp.gov ns1.360dns.net ns2.360dns.net uns1.bhn.net uns2.bhn.net
ns1.bindhost.net ns2.bindhost.net itchy.earthlink.net
scratchy.earthlink.net a.myradns.net b.myradns.net c.myradns.net
resolver1.qwest.net resolver2.qwest.net sauthns1.qwest.net
sauthns2.qwest.net ns1-asia.sprintlink.net ns1-auth.sprintlink.net
ns2-asia.sprintlink.net ns2-auth.sprintlink.net ns3-asia.sprintlink.net
dns4.websolvers.net ns2.panmedia.co.nz ns1.collegiateschool.org
ns4.collegiateschool.org ns.min-financas.pt dns.ntu.edu.tw ntust.edu.tw
dns.ntust.edu.tw ns2.grade.us

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

Re: IP and Optical domains?

[Masataka Ohta]

Mark Tinka wrote:


Typical awareness about the transport layer is not normally privy to IP.
Yes, IPoDWDM means the visbility is there, but really, all it's doing is
cutting off a link just before the thresholds are met, to avoid packet loss.


What? "the visibility is there"?

I think you mean IPoDWDM something so much different from
usual ways to have IP over something.

Do you have any reference to it?

For my definition of IPoDWDM, see, for example:

"Standardization of optical packet switching with
many-wavelength packets"
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4542288

or my newest paper in HPSR2016.

Masataka Ohta

Issues reaching major websites

[Matt Hoppes]

I know I had very sparse information. Apparently frontier was having some sort 
of transport issue in Pennsylvania. This from their NOC. 

Re: IP and Optical domains?

[Mark Tinka]

On 22/Jun/16 11:58, Masataka Ohta wrote:
 
>
> Today??? You asked "can be better designed", didn't you?

But IP does not manage transport characteristics. If packets can't get
through, they are dropped. Fairly simple.

Typical awareness about the transport layer is not normally privy to IP.
Yes, IPoDWDM means the visbility is there, but really, all it's doing is
cutting off a link just before the thresholds are met, to avoid packet loss.

Yes, BFD does provide IP some awareness, but this is not inherent in IP
itself.

>
> The problem, if any, is that doing much more than that
> results in "heavily underutilized" network.

Sorry, I'm just not getting your angle - could be something getting lost
in translation.

Not sure how frequent Hello messages exchanged by routing protocols
leads to a heavily under-utilized network.

Mark.

Re: IP and Optical domains?

[Masataka Ohta]

Mark Tinka wrote:


By not managing transport characteristics at all except
that links are on or off (or, if you want to guarantee QoS,
a little more than that).


But how do Layer 3 protocols manage transport characteristics today?


Today??? You asked "can be better designed", didn't you?

And, don't miss the following assumption:

> L3 HELO generated frequently enough.

> Again, this does not seem too removed from what happens already today.

The problem, if any, is that doing much more than that
results in "heavily underutilized" network.

> I don't disagree with what you imply by "heavily".

The implication is not mine.

Masataka Ohta

Re: Google Geolocation issue

[Jeroen Wunnink]

Email their NOC directly. I’ve had some success with that: g...@google.com / 
n...@google.com


Also, sign up at https://isp.google.com/, there’s an option there to provide a 
self-published geo-feed for your IP space: 
http://tools.ietf.org/id/draft-google-self-published-geofeeds-02.html

Which may or may not be taken into consideration for geo-locating your IP space 
;-)
I quote: "Google can process self-published IP geolocation data for your 
network. This information will be used as an additional signal to help improve 
the location accuracy Google products."



—
Jeroen Wunnink
IP Engineering Manager
Hibernia Networks - Amsterdam Office
Main numbers (Ext: 1011): USA +1.908.516.4200 | Canada +1.902.442.1780
Ireland +353.1.867.3600 | UK +44.1704.322.300 | Netherlands +31.208.200.622
24/7/365 IP NOC Phone: +31.20.82.00.623

jeroen.wunn...@hibernianetworks.com
www.hibernianetworks.com 









On 21/06/16 20:25, "NANOG on behalf of Chris Boyd"  wrote:

>Dear list readers, please forgive the noise, but if there's anyone here
>from Google who can fix a geolocation issue I'd appreciate a reply.
>
>208.81.245.226 is not in the UAE, it's in Austin, Texas.  Yes, I have
>filled out the form to request a fix, but the AI or whatever that's
>supposed to fix it has not, and we're well into 3 months after the first
>report.
>
>Thanks,
>
>--Chris
>
This e-mail and any attachments thereto is intended only for use by the 
addressee(s) named herein and may be proprietary and/or legally privileged. If 
you are not the intended recipient of this e-mail, you are hereby notified that 
any dissemination, distribution or copying of this email, and any attachments 
thereto, without the prior written permission of the sender is strictly 
prohibited. If you receive this e-mail in error, please immediately telephone 
or e-mail the sender and permanently delete the original copy and any copy of 
this e-mail, and any printout thereof. All documents, contracts or agreements 
referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an 
attachment to this e-mail may contain software viruses that could damage your 
own computer system. While Hibernia Networks has taken every reasonable 
precaution to minimize this risk, we cannot accept liability for any damage 
that you sustain as a result of software viruses. You should carry out your own 
virus checks before opening any attachment.

Re: IP and Optical domains?

[Mark Tinka]

On 22/Jun/16 10:20, Masataka Ohta wrote:
 
>
> By not managing transport characteristics at all except
> that links are on or off (or, if you want to guarantee QoS,
> a little more than that).

But how do Layer 3 protocols manage transport characteristics today?

Unless I misunderstand your statement.

>
> L3 protocols know links are off if L2 operators actively
> turn them off or if the protocols detect consecutive lack
> of L3 HELO generated frequently enough.
>
> L2 operators turns links off for maintenance and
> BER degradations need unscheduled maintenance.

Again, this does not seem too removed from what happens already today.

Unless I misunderstand what you are saying.

>  
>
> I'm afraid "heavily" implies a lot less utilization.

I don't disagree with what you imply by "heavily". What I am saying is
"a lot less" or "a lot more" is not a universal measure. It means
different things to different people, as business operations (which
largely drive this kind of thing) differ widely.

Mark.

Re: IP and Optical domains?

[Masataka Ohta]

Mark Tinka wrote:


I'd like to hear your proposals on how Layer 3 protocols can be better
designed to manage transport characteristics.


By not managing transport characteristics at all except
that links are on or off (or, if you want to guarantee QoS,
a little more than that).

L3 protocols know links are off if L2 operators actively
turn them off or if the protocols detect consecutive lack
of L3 HELO generated frequently enough.

L2 operators turns links off for maintenance and
BER degradations need unscheduled maintenance.


That's L1, which is also required to exist.


It's Layer 1 and Layer 2. Ethernet is running over those optics, albeit
with no "traditional" optical equipment in between.


So, no disagreement, here.


So, you deny the original point of "The result of this is that the
networks are heavily underutilized". OK.



We upgrade at 50% utilization. Others do it at 70% utilization. Others
do it at 100% utilization. Heck, I know some that do it at 40% utilization.


I'm afraid "heavily" implies a lot less utilization.

Masataka Ohta

Bad firewall/nameserver behaviour causing timeouts of DNS queries.

[Mark Andrews]

The following nameservers for Alexa top 1M names fail to respond
to EDNS queries with EDNS options specified or fail to respond to
consecutive EDNS queries.  These have been run through the checks
multiple times to reduce the probability of false positives as
timeout can be the due to multiple causes.

For many there are other errors that should also be addressed.

This misbehaviour can cause DNSSEC validation to FAIL when the
servers serve signed zones.

This misbehaviour does result in significantly slower DNS resolution
(multiple seconds).

You can test your servers at https://ednscomp.isc.org/

This is sent here because both SOA and whois contact details are
wrong too often to bother trying to send to these addresses even
if whois was easy to parse.

Please fix your firewalls / nameservers as they are causing operational
problems.

Mark

lb.pagofacil.com.ar lb.pagofacil.com.ar lb.pagofacil.com.ar
server.inet.edu.ar siet.inet.edu.ar ns2.pillar.com.au ns1.agric.wa.gov.au
ns2.agric.wa.gov.au ns3.agric.wa.gov.au ns1.win.be ns2.win.be
ns.ahlia.edu.bh lb3.ache.com.br ns2.bibliomed.com.br
ns3.caixaseguros.com.br sdccd01.light.com.br ns1.poupex.com.br
ns3.poupex.com.br ns1.semparar.com.br ns2.semparar.com.br
creaprw12.crea-pr.org.br dns5.allstate.ca ns1.bellnhs.ca ns3.bellnhs.ca
ns5.bellnhs.ca ns1.cpr.ca ns2.cpr.ca ns1.cnsc-ccsn.gc.ca
ns2.cnsc-ccsn.gc.ca ns1.knowledgeone.ca ns2.knowledgeone.ca ns3.mmms.ca
gemini.hrsb.ns.ca ns.city.windsor.on.ca ns2.city.windsor.on.ca
ns1.thomascookgroup.ca ns2.thomascookgroup.ca ns1.bger.ch ns2.bger.ch
dn2.1.cl ns.autopistacentral.cl peumo.bancoconsorcio.cl
roble.bancoconsorcio.cl dns.bci.cl dns2.bci.cl ns.subtel.cl
nsaut.tie.cl ns2.sina.com.cn name.srit.com.cn dns.hncj.edu.cn
dns2.hncj.edu.cn dns.hut.edu.cn dns2.hut.edu.cn dns.jju.edu.cn
dns.lit.edu.cn dns.by.gov.cn dns2.gxeea.cn ns1.coscologistics.sh.cn
ariadne.presidencia.gov.co bdpalacio.presidencia.gov.co ns3.360safe.com
ns4.360safe.com ns5.360safe.com ns2.51dns.com ns8.91989.com
ns9.91989.com ns1.advisorlynx.com ns2.advisorlynx.com ns1.aegis-k.com
ns2.aegis-k.com ns1.affinity-petcare.com ns01.airliquide.com
ns03.airliquide.com ns1.alidns.com ns1.alidns.com ns2.alidns.com
ns2.alidns.com ns2.alidns.com vip1.alidns.com vip1.alidns.com
vip1.alidns.com vip1.alidns.com vip1.alidns.com vip1.alidns.com
vip2.alidns.com vip2.alidns.com vip2.alidns.com vip2.alidns.com
vip2.alidns.com vip2.alidns.com vip2.alidns.com ns1.amaes.com
ns2.amaes.com ns1.amatteroffax.com ns3.amvescap.com ns5.amvescap.com
ns1.arcatapet.com office.arcatapet.com pridns.ascendas.com
ns01.avanade.com ns02.avanade.com ns2.avastkorea.com det.dns.bbdo.com
ns1.bcbsmn.com ns2.bcbsmn.com harris-ns.bcharrispub.com
harris-ns2.bcharrispub.com bor-cp01.borouge.com bvdns.broadviewnet.com
bvdns2.broadviewnet.com ns5.carbonlogic.com ns2.ccmnyc.com
ns1.cmsbiztech.com ns1.corsicaferries.com ns3.corsicaferries.com
ns4.corsicaferries.com ns1.credibanco.com ns2.credibanco.com
cscdnscph002d.csc.com cscdnshyd002d.csc.com cscdnsklm002d.csc.com
cscdnsmds002d.csc.com cscdnsnoi002d.csc.com cscdnssng002d.csc.com
palladium.csc.com wserver.cyberdental.com webmail.dbfsindia.com
ns1.deseretdigital.com ns2.deseretdigital.com huey.disney.com
huey11.disney.com a.dnspod.com a.dnspod.com c.dnspod.com c.dnspod.com
ns1.dnsv2.com ns1.dnsv2.com ns1.dnsv2.com ns1.dnsv2.com ns1.dnsv2.com
ns2.dnsv2.com ns2.dnsv2.com ns2.dnsv2.com ns2.dnsv2.com ns1.dnsv3.com
ns1.dnsv3.com ns1.dnsv3.com ns1.dnsv3.com ns1.dnsv3.com ns1.dnsv3.com
ns2.dnsv3.com ns2.dnsv3.com ns1.dnsv4.com ns1.dnsv4.com ns1.dnsv4.com
ns1.dnsv4.com ns1.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com
ns2.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com ns1.dnsv5.com
ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com
ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com
ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com
ns2.dnsv5.com ns2.dnsv5.com ns03.dominos.com ns04.dominos.com
ns05.dominos.com ns1.dynalifedx.com ns1.dynamex.com ns2.dynamex.com
name1.eidebailly.com name2.eidebailly.com ns1.evaair.com ns2.evaair.com
ns3.evaair.com ns4.evaair.com ns.excodaegu.com ns.fanforum.com
ns1.fanforum.com leo.generator.com ns1.gesnetwork.com
ns01.globalexchangetechnology.com ns02.globalexchangetechnology.com
gtmgrin.gmrc.com gtmnew.gmrc.com ns3.gmrc.com ns4.gmrc.com
ns2.greensburgdailynews.com dns.heffel.com dns1.hichina.com
dns1.hichina.com dns1.hichina.com dns10.hichina.com dns10.hichina.com
dns10.hichina.com dns11.hichina.com dns11.hichina.com dns11.hichina.com
dns13.hichina.com dns13.hichina.com dns13.hichina.com dns14.hichina.com
dns14.hichina.com dns14.hichina.com dns17.hichina.com dns17.hichina.com
dns18.hichina.com dns18.hichina.com dns2.hichina.com dns2.hichina.com
dns21.hichina.com dns21.hichina.com dns21.hichina.com dns22.hichina.com
dns22.hichina.com dns22.hichina.com dns25.hichina.com dns25.hichina.com
dns25.hichina.com dns26.hichina.com dns26.hichina.com dns26.hichina.com