On 11/12/21 23:47, Jeff Tantsura wrote:
LAG - Micro BFD (RFC7130) provides per constituent livability.
Not sure if this has changed, but the last time I looked into it, Micro
BFD's for LAG's was only supported and functional on point-to-point
Ethernet links.
In cases where you are
Randy will be presenting draft-ymbk-sidrops-rov-no-rr during RIPE-83, at
around 1530hrs UTC:
https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-rov-no-rr-02
Most grateful if you can join, and provide some initial feedback. Thanks.
Mark.
During the nation-wide lockdown of 2020, around the world, I took up
live-streaming my DJ sets online, since I couldn't play live. For those
that haven't seen them, you're welcome to my Youtube channel to catch them:
https://yt.djmt.africa/watch
Anyway, what I wanted to say is that I was
On 11/18/21 01:29, Jay R. Ashworth wrote:
This seems like a really bad idea to me; am I really the only one who noticed?
https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
That's over a week old and I don't see 3000 comments on it, so maybe it's just
me. So many things are
year we turn
away submissions, due to filling up all available programme slots
before the deadline. Presenters should endeavour to get material to
the PC sooner rather than later.
For any questions or concerns, please email the PC Chairs.
We look forward to receiving your presentation prop
On 10/27/21 01:58, Randy Bush wrote:
i run a FORT RPKI relying party instance. i am looking for some
visibility into its operation.
is it up: both ways, fetching and serving routers?
from what CAs has it pulled, how recently and frequently with
what success?
what routers is it
On 10/25/21 18:12, Masataka Ohta wrote:
So are IP entities behind NAT. So?
I still don't understand your point.
Are you asserting that NAT'ed devices do not have an IP address?
Mark.
On 10/25/21 08:29, Lady Benjamin Cannon of Glencoe, ASCE wrote:
I’m typing this on an LTE UE on our network with a NAT’d IPv4 IP address.
Feels relevant.
We may be missing each other here...
From the point of view of TCP/IP, a node behind a CGN has a unique IP
address.
So what I'm
On 10/25/21 01:35, Masataka Ohta wrote:
So are IP entities behind NAT. So?
Your point being...?
Mark.
On 10/24/21 19:19, Ca By wrote:
Nodes in an ip network require ip addresses. 4G and 5G are ip networks
for both voice and data.
I do not believe it is either technically nor economically feasible to
run a 4g or 5g network without an ip address on the ue.
*shaking_my_head*
For the
On 10/24/21 18:25, Masataka Ohta wrote:
Are you saying mobile terminals must be identified by IP addresses?
Ummh, how else do you expect a player on the Internet to, ummh, play?
Mark.
On 10/22/21 18:08, t...@pelican.org wrote:
I don't think it'll ever make money, but I think it will reduce costs. CGNAT
boxes cost money, operating them costs money, dealing with the support fallout
from them costs money. Especially in the residential space, where essentially
if the
On 10/22/21 17:45, Bryan Fields wrote:
Until IPv6 becomes provides a way to make money for the ISP, I don't see it
being offered outside of the datacenter.
It is being offered, it's just not being adopted.
We deliver an IPv6 /126 p2p and /56 or /48 onward assignment to all our
DIA
On 10/22/21 15:19, Jason Iannone wrote:
Thanks for sharing. Maybe I have blinders on, but LDPv6 and the v6 SR
flavors don't have much use if v4 CE sites aren't supported.
Indeed. If your goal is an IPv6-only network with IPv6-only services,
then Nokia may have an answer for you.
But if
On 10/22/21 14:03, Jens Link wrote:
I don't think it was overlooked or forgotten. More along
"We have always done it this way", "We had problems enabling IPv6 (ages
ago)" or something else you can find on https://ipv6excuses.com/.
I think it's a combination of both... they tried back in
For those who run FreeBSD, the Fort RPKI validator is now available in
the ports tree:
https://www.freshports.org/net/fort/
Many thanks to Toni Kalombo for submitting and maintaining the port, and
to Philip Paeps to committing it.
I've also sent a note to the Fort developers to update the
On 10/21/21 22:50, Lady Benjamin Cannon of Glencoe, ASCE wrote:
Outside the datacenter is where DC power really shines in my opinion. Inside
the DC, everything is AC now and probably for the best.
We never came up with a modular standard for -48VDC. Perhaps that could have
changed
On 10/21/21 21:18, Jason Iannone wrote:
Hi all,
Have there been any gap closures on RFC7439? I am particularly
interested in 4PE, 4VPE, and other MPLS enabled services like L3VPN,
NG-MVPN, E-Line, E-LAN, and EVPN. Does Juniper have an
"ipv4-tunneling" mpls keyword?
I posted this here
On 10/21/21 20:28, Fred Baker wrote:
I’m not sure I disagree, but let throw in a point of consideration.
Historically, as you note, the caller pays the toll. However, the
caller also CHOSE to call, even though the called party might find the
call irritating. With a CDN, the network is out
On 10/21/21 14:54, Brian Johnson wrote:
There is still zoning on some platforms, but there are now redundancies for the
zones.
Sounds complex. But to each their own.
Mark.
On 10/21/21 03:19, Brian Johnson wrote:
+1 on -48VDC.
Wasn't much fun when half the router would shutdown because power
supplies failed, due to what was known as "power zoning" those days.
I haven't deployed a larger router on DC in over 13 years. I'm not sure
if this is still a thing,
On 10/20/21 20:37, Lady Benjamin Cannon of Glencoe, ASCE wrote:
-48VDC power is still the best.
I really envy folk that love DC for networking gear :-).
Work in 2007 was an all-DC network. I rebuilt it into AC, considering
the ISP also owned the data centre (most of whose customers
On 10/20/21 19:32, Mel Beckman wrote:
such tinkaing...
Cute...
is rare. It certainly doesn’t rise to the level of “never works out of the
box.”
Luck you.
Mark.
On 10/20/21 18:38, Mel Beckman wrote:
I’ve used many commercial NMS platforms. I’ve yet to find one that doesn’t work
“out of the box”. Unless by “out of the box” you mean “clairvoyantly
configured”.
Please identify the ones you think fail your test.
Have you always used an NMS that
On 10/20/21 18:08, Mel Beckman wrote:
Mark,
Before 1983, the ARPANET wasn’t an internet, let alone The Internet.
Each ARPANET connection required a host-specific interface (the “IMP”)
and simplex Network Control Protocol (NCP). NCP used users'
email addresses, and routing had to be
On 10/20/21 17:26, Mel Beckman wrote:
Mark,
As long as we’re being pedantic, January 1, 1983 is considered the
official birthday of the Internet, when TCP/IP first let different
kinds of computers on different networks talk to each other.
It’s 2021, hence the Internet is /less/ than, not
On 10/20/21 11:55, Nat Fogarty wrote:
Hi there,
I'm interested in what you good folks do in terms of network visibility.
My interests are around Service Provider space - visibility for IPoE,
PPPoE, TCP(User Experience).
I use a product called "VoIPmonitor" for all things VoIP - and it
On 10/18/21 14:16, Masataka Ohta wrote:
As copper and optical fiber for access politically belongs to ITU,
DSL and optical fiber standards of ITU are followed by the IETF
world.
Yes, but nobody cares about Layer 1 or Layer 2.
Once the road is built, all anyone remembers is the car I drove
On 10/18/21 10:11, Masataka Ohta wrote:
As you are seemingly requesting international legal formality,
let me point out there are "International Telecommunication
Regulations", based on which network neutrality is discussed
by ITU.
And since when does the IETF world follow the ITU
On 10/16/21 15:44, Masataka Ohta wrote:
What?
I will use my network for what I want my network to do for me. There are
no international rules about why a network must be built. Provided that
I am clear to those whom I want to connect to my network, I can do what
I want with it and not
FYI.
Step by step, the tyrants shall be stripped.
Mark.
Forwarded Message
Subject:[members-discuss] Update on legal case - Freeze of Bank accounts
Date: Fri, 15 Oct 2021 14:53:03 +0400
From: Eddy Kayihura
To: AfriNIC Discuss
Dear Colleagues,
We are happy
On 10/13/21 19:59, Fletcher Kittredge wrote:
Hey! From the description it must be one of our clients!
Just beware if you go this route, a network that is probably already
unstable and unreliable will become at least an order of magnitude
worse. You can't fix ten lbs of stuff into a 4 lb
On 10/13/21 17:24, Masataka Ohta wrote:
The problem is that, unlike neutral transit providers, "the bits"
is biased by the CDN provider.
Then, access/retail ISPs who also want to supply their own contents,
even though they must be neutral to contents provided by neutral
transit providers,
Hi all.
I thought I'd share our recent experiences, per subject, just in case
others run into the same problems.
So... we finally decided to try 17.3(4a)MD for the CSR1000v, after years
of happy operation. Good Lord, what a drama!
At first, we couldn't figure out why iBGP sessions to all
On 10/12/21 18:33, Sabri Berisha wrote:
Yes, let's go back to 2003. The ISP I worked for at that time was one of
the first in the country (if not the first) to host Akamai's caching servers.
Ten years later I worked on a project where Akamai caching was embedded in
subscriber management
On 10/12/21 17:39, Jared Brown wrote:
Since we aren't talking about random pirated content, but p2p streaming from a
major content provider it would obviously be point & click.
Yes, in which case Jane + Thatho don't need to worry about device
compatibility, especially if the device is
On 10/12/21 17:13, Jared Brown wrote:
That's not how it works. Several streaming BitTorrent clients
specifically request blocks in order so that you can start watching
immediately.
Not that you need a special client, it works pretty well with the standard
client as well on a well
On 10/11/21 22:57, Matthew Walster wrote:
Ignoring for the moment that P2P is inherently difficult to stream
with (you're usually downloading chunks in parallel, and with devices
like Smart TVs etc you don't really have the storage to do so anyway)
there's also the problem that things like
On 10/12/21 14:20, Jason Iannone wrote:
Isn't this a problem with legacy peering agreements in today's
internet? The same thing happened between Netflix, Level3, and Verizon
a few years ago. The legacy concept of settlement-free peering is
based on traffic forwarding parity. If what I
On 10/11/21 22:05, Matthew Petach wrote:
Let's check back in 2026, and see if someone's become fantastically
successful doing this or not. ;)
I have to say, your idea is quite fantastical. I'm not sure I have
enough brain cells to consider how it will work, remembering that vCPE's
were
On 10/11/21 17:26, Niels Bakker wrote:
I don't think that's being entirely fair. Netflix in plenty places
differentiates its subscriptions based partly on video resolution:
https://help.netflix.com/en/node/24926/us
Some people will definitely care enough to sign up for a more
On 10/11/21 09:49, Matthew Petach wrote:
Going back to the fact that it's not the content providers "using"
a lot of bandwidth, it's the eyeball customer *requesting* a lot
of bandwidth, I think the best approach is for the content providers
to help manage traffic levels by lowering bit rates
On 10/11/21 00:10, Niels Bakker wrote:
Sounds like you think SK should be paying Netflix for bringing their
content all the way from the US to the Korean peninsula. That's some
expensive wet cable being used there.
Do we know whether Netflix don't already have OCA's and/or local peering
On 10/10/21 23:57, Sabri Berisha wrote:
I have worked for ISPs. And I remember the late 90s. Bandwidth was $35/mbit
on average, at least for the outfit where I was. Consumers paid roughly $40
for their DSL connections, which at the time went up to 2Mbit depending
on the age of the copper and
On 10/11/21 02:58, Owen DeLong wrote:
That’s irrelevant to what he is saying.
What he’s saying (and he’s 100% correct) is that any tax a corporation pays is
collected from their customers one way or another.
A corporation has no other source of income with which to pay its taxes beyond
On 10/11/21 03:05, Owen DeLong wrote:
Which is the kind of ignorant view of the situation that creates this problem
in the first place.
It’s not for “no $$”, it’s for all the $$ they got from all those 100Mbps links
that they are delivering those Tbps of traffic to.
If the aggregate $$
On 10/10/21 23:42, Doug Barton wrote:
I didn't say income tax. Corporate taxes are considered an expense by
the corporation paying them. Like all other expenses, they are
factored into the cost of goods/services sold.
Ah, yes, agreed. I thought you meant something else...
First, I'm
On 10/11/21 01:43, Keith Medcalf wrote:
This is blatantly incorrect. The bits were payed for by the requestor.
You totally missed my dig...
I was being sarcastic.
Mark.
On 10/11/21 00:31, Geoff Huston wrote:
In many environments, the words we use to describe this form of price setting
are generally prefixed by the adjective “illegal” :-)
Indeed - colluding is generally frowned upon, in which case we are
doomed to the current model, and may the best man
On 10/10/21 22:13, Michael Thomas wrote:
Isn't that what Erlang numbers are all about? My suspicion is that
after about 100Mbs most people wouldn't notice the difference in most
cases. My ISP is about 25Mbs on a good day (DSL) and it serves our
needs fine and have never run into bandwidth
On 10/10/21 22:10, Geoff Huston wrote:
I have to agree with Doug Barton's earlier observation is that the base problem
is that the ISPs are using a flawed business model and they don't want to
charge their customers what it really costs to provide them with high speed
access, nor do they
On 10/10/21 21:33, Matthew Petach wrote:
If you sell a service for less than it costs to provide, simply
based on the hopes that people won't actually *use* it, that's
called "gambling", and I have very little sympathy for businesses
that gamble and lose.
You arrived at the crux of the
On 10/10/21 21:08, Doug Barton wrote:
Except that Facebook, Microsoft, and Amazon all caved to SK's demands:
"The popularity of the hit series "Squid Game" and other offerings
have underscored Netflix's status as the country's second-largest data
traffic generator after Google's YouTube,
On 10/8/21 18:22, Sabri Berisha wrote:
Who says they were ... ahem ... watching? :)
I considered that... and decided that scrolling the Netflix library
doesn't create that much data :-).
Of course, who pays 100% attention anymore these days. You've watched an
episode if it was playing.
On 10/8/21 17:26, Tom Beecher wrote:
There is already lots of published research on social media addiction
that does call it out just that strongly.
Oh no, I didn't mean that the research to link social media addiction to
long-term mental harm does not exist. It's just that such research
On 10/8/21 17:12, Tom Beecher wrote:
Yeah.. I mean people couldn't get stuck in the DoomScroll, so they
chose to do something else. I'm sure plenty of people did something
besides Netflix.
For sure.
We just happened to measure Netflix on our side. I'm certain other
operators measuring
On 10/8/21 17:07, cosmo wrote:
A psychologist would probably describe this as "self soothing behavior"
An addiction specialist would identify it as illicit drug substitution
: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7370931/
Which they probably will, but it won't be labeled as
On 10/8/21 16:34, Steven Bakker via NANOG wrote:
My inner cynic is interpreting this data a bit differently. Instead of
going out for a walk or just engage in the gentle art of doing
nothing, the social media users need something to keep their minds
distracted from the here and now.
So we are reviewing our flow data, and it's very clear, on our network,
that during the period Facebook were experiencing their global outage,
Netflix traffic went up 3X for us.
The psychological assessment of this, for me, is most interesting;
especially because like carbohydrates, social
On 10/8/21 07:25, Sabri Berisha wrote:
Whenever there is an aviation incident, the keyboard warriors at pprune.org
are always the first to start speculating about root causes, and complain how
the air crew made mistakes. They, the keyboard warriors, of course know how
best to fly an aircraft
On 10/7/21 20:46, Max Tulyev wrote:
We have 2 ports from Telia, one in Kiev (Ukraine) and one in New York
(USA). I have seen both ports simultaneously dropped traffic volume
for about one hour today.
Our traffic across Telia dipped at 1600hrs UTC yesterday, and recovered
2hrs later.
No
On 10/7/21 18:21, William Herrin wrote:
It wasn't forgotten. Folks gained a lot of experience with anycast DNS
between 2002 and 2006. Not withdrawing the routes when the servers are
deemed malfunctioning turned out not to be an operationally sound
practice. The theory offered in 3258 was
On 10/7/21 16:33, Nick Hilliard wrote:
there was more to it than that. The grammar was too complicated to
easily describe common policies and too limited to describe complex
policies. The structure was difficult to extend when the routing
became more complicated (e.g. mpls, route
On 10/7/21 13:18, Jean St-Laurent wrote:
Something public that we know now, is that it's possible to totally shut down
facebook and restart it.
Can we shutdown the full internet one day and see if it will restart properly
without too much hack here and there?
I think one thing that I
On 10/7/21 08:26, Hank Nussbacher wrote:
Better question is why do we not see any FB netadmins on NANOG? I'm
not talking about October 2021 but rather over the past 3-5 years how
many FB techies have posted here like we see people from Google,
Cloudflare, Akamai, etc.?
They are likely
https://www.kentik.com/blog/facebooks-historic-outage-explained/?mkt_tok=ODY5LVBBRC04ODcAAAF_9diyPhC6WFsJNFpS4z2ggF-DWEc6FksyD3aW8B3am5tUvtTOJDYl2MIgMdsmmqOLTL-BpUugbQHAIXCT677LE0OxHM8Dy-mqRorJQXnAjg4
Mark.
On 10/7/21 00:22, Michael Thomas wrote:
But it wasn't just their DNS subnets that were pulled, I thought. I'm
obviously really confused. Anycast to a DNS server makes sense that
they'd pull out if they couldn't contact the backend. But I thought
that almost all of their routes to the
On 10/7/21 00:37, Michael Thomas wrote:
Maybe the problem here is that two things happened and the article
conflated the two: the DNS infrastructure pulled its routes from the
anycast address and something else pulled all of the other routes but
wasn't mentioned in the article.
The
On 10/6/21 06:51, Hank Nussbacher wrote:
- "During one of these routine maintenance jobs, a command was issued
with the intention to assess the availability of global backbone
capacity, which unintentionally took down all the connections in our
backbone network"
Can anyone guess as to
On 10/5/21 16:59, Matthew Kaufman wrote:
Disagree for two reasons:
1. If you have some DNS working, you can point it at a static “we are
down and we know it” page much sooner.
Isn't that what Twirra is for, nowadays :-)...
2. If you have convinced the entire world to install tracking
On 10/5/21 16:49, Joe Greco wrote:
Unrealistic user expectations are not the point. Users can demand
whatever unrealistic claptrap they wish to.
The user's expectations, today, are always going to be unrealistic,
especially when they are able to enjoy a half-decent service
On 10/5/21 15:40, Mark Tinka wrote:
I don't disagree with you one bit. It's for that exact reason that we
built:
https://as37100.net/
... not for us, but specifically for other random network operators
around the world whom we may never get to drink a crate of wine with.
I have
On 10/5/21 15:04, Joe Greco wrote:
You don't think at least 10,000 helpdesk requests about Facebook being
down were sent yesterday?
That and Jane + Thando likely re-installing all their apps and
iOS/Android on their phones, and rebooting them 300 times in the hopes
that Facebook and
On 10/5/21 14:58, Jean St-Laurent wrote:
If your NS are in 2 separate entities, you could still resolve your
MX/A//NS.
Look how Amazon is doing it.
dig +short amazon.com NS
ns4.p31.dynect.net.
ns3.p31.dynect.net.
ns1.p31.dynect.net.
ns2.p31.dynect.net.
pdns6.ultradns.co.uk.
On 10/5/21 14:52, Joe Greco wrote:
That's not quite true. It still gives much better clue as to what is
going on; if a host resolves to an IP but isn't pingable/traceroutable,
that is something that many more techy people will understand than if
the domain is simply unresolvable. Not
On 10/5/21 08:55, a...@nethead.de wrote:
Rumour is that when the FB route prefixes had been withdrawn their
door authentication system stopped working and they could not get back
into the building or server room :)
Assuming there is any truth to that, guess we can't cancel the hard
On 10/5/21 14:08, Jean St-Laurent via NANOG wrote:
Maybe withdrawing those routes to their NS could have been mitigated by having
NS in separate entities.
Well, doesn't really matter if you can resolve the A//MX records,
but you can't connect to the network that is hosting the
On 10/5/21 09:29, Łukasz Bromirski wrote:
…like a, say, „single pane of glass”? ;)
Oh dear Lord :-)...
Mark.
On 10/4/21 20:48, Luke Guillory wrote:
I believe the original change was 'automatic' (as in configuration
done via a web interface). However, now that connection to the outside
world is down, remote access to those tools don't exist anymore, so
the emergency procedure is to gain physical
On 10/4/21 22:33, Eric Kuhnke wrote:
I am starting to see reports that in ISPs with very large numbers of
residential users, customers are starting to press the factory-reset
buttons on their home routers/modems/whatever, in an attempt to make
Facebook work. This is resulting in much
On 10/4/21 22:27, Łukasz Bromirski wrote:
I bet FB tested the change on smaller scale and everything was fine,
and only then started to roll this over wider network and at that
point „something” broke. Or some bug needed a moment to start
cascading issues around the infra.
This is the
On 10/4/21 22:23, Baldur Norddahl wrote:
Not in such a primitive fashion no. But they could definitely have a
secondary network that will continue to work even if something goes
wrong with the primary.
On IPv6, no less :-).
On a serious note, I can't even imagine what it takes to run a
On 10/4/21 21:55, Nick Hilliard wrote:
Nearly 30 years on, this is still the state of the art.
Not an unlike an NMS... still can't walk into a shop and just buy one
that works out of the box :-).
Mark.
On 10/4/21 18:22, Eric Kuhnke wrote:
Considering the massive impact of this it would be interesting to see
some traffic graphs from ISPs that have PNIs with Facebook, or high
volume peering sessions across an IX, showing traffic to FB falling
off a cliff.
Our PNI's and FNA's in Africa
On 10/2/21 08:14, Bill Woodcock wrote:
We did not use an NTA, but we did flush our cache immediately once
Slack had fixed their problem. I think that’s the right balance of
carrot and stick.
Tend to agree with this approach.
But I can see how an issue like this could be potentially
So, that wasn't fun, yesterday:
https://lists.dns-oarc.net/pipermail/dns-operations/2021-September/021340.html
We were also hit, given we run DNSSEC on our resolvers.
Interesting some large open resolver operators use Negative TA's for
this sort of thing. Not sure how this helps with the
On 10/1/21 19:28, Randy Bush wrote:
in fact, this seems to be the modern conservative style for some years.
i sometimes wonder if it is worth the config pain.
If having routers dedicated to peering, transit or edge functions is
worth the extra pain, in lieu of doing it all on one box?
On 10/1/21 20:17, Adam Thompson wrote:
Do people in other parts of the world have access (both physical and
logical) to enough bilateral peering (and budgets...) that it makes
sense to deploy a router per peer?
Certainly not a router per peer, but a peering router per city, where it
may
On 10/1/21 18:31, Tom Hill wrote:
Many (most?) route servers provide little control over who your routes
are advertised toward. This can be fun where DDoS is concerned.
I've used some that did have deny-list controls for ASNs, fail to
consistently apply those rules. Again, that was a 'fun'
On 10/1/21 18:05, Laura Smith wrote:
Speaking as one of those smaller ISPs willing to do whatever it takes, perhaps
you could answer me this riddle.
- PoP in one of your "half-decent data centres" ... tick.
- Connnection to one of your "exchange point" ... tick.
- $certain_large_cdn
On 10/1/21 16:19, Blake Hudson wrote:
I'll never understand over how ISPs see content providers as the enemy
(or a rival). The content is why ISPs have customers. Don't get upset
when your customer uses the service that you sold them (in a way that
is precisely in accordance with the
So, I have it on good authority that from release 21.7.R1, Nokia not
only introduces LDPv6 to their IXR platform, but also provides native
support for l2vpnv6 and l3vpnv6 signaling.
AFAIK, Cisco and Juniper only support mpls2ip forwarding for LDPv6, and
all other VPN services can only be
On 10/1/21 01:51, Valdis Klētnieks wrote:
Am I insufficently caffienated, or is uRPF the least of your problems
if you don't have a full table *and* don't have a default route?
A partial table with no default is perfectly fine for a peering router.
As long as your peering router knows how
On 9/30/21 17:56, Hunter Fuller wrote:
On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka wrote:
If you don't plan to run a full BGP table on a device, don't enable uRPF, even
loose-mode.
At least in Ciscoland, loose URPF checks will pass if you have a
default route. So I do not think it could
On 9/29/21 20:14, Phil Bedard wrote:
Disclosure I work for Cisco and try to look after some of their
peering guidelines.
Agree with Adam’s statement, use uRPF on edge DIA customers. Using it
elsewhere on the network eventually is going to cause some issue and
its usefulness today is
On 9/29/21 19:07, Adam Thompson wrote:
We just ran into a typical case where uRPF caused a partial outage for
one of my customers: the customer is multi-homed, with another
provider that I'm *also* connected to. Customer advertised a
longer-prefix to the other guy, so I started sending
On 9/29/21 23:36, Anoop Ghanwani wrote:
This is not true for all ASICs. Some ASICs choose to incur the
penalty in a different way, e.g., by halving the prefix tables. The
prefix table is then duplicated so that uRPF SA and forwarding DA
lookups can happen in parallel. What kind of
On 9/29/21 16:21, Blake Hudson wrote:
I do not use uRPF on upstream/transit/IX links or with multi-homed
customers - or anywhere else where traffic could be asymmetrical; I
prefer to use stateless ACLs at these locations.
On peering and transit routers, on ports facing the remote side, we
On 9/29/21 15:14, Dave Cohen wrote:
As Mark says YMMV as different providers will have markedly different
conventions, however one additional challenge that will be widespread
is that most carriers are not placing their L2/3 hardware in the cable
landing stations, preferring instead to
On 9/29/21 04:23, PAUL R BARFORD wrote:
Hello,
I am a researcher at the University of Wisconsin. My colleagues at
Northwestern University and I are studying submarine cable infrastructure.
Our interest is in identifying submarine links in traceroute
measurements. Specifically, for a
401 - 500 of 2576 matches
Mail list logo
