Re: Routed optical networks

[Mark Tinka]

On 5/3/23 11:10, Vasilenko Eduard wrote:


You are right. My message was pretty much geared toward incumbents.

But the majority of the access/aggregation is in their possessions, 
isn’t it?




Generally, I'd say yes.

But to the OP's survey, the incumbents also have the majority 
installations of copper, and are least likely to use MPLS all the way 
into the Access. They would more typically use 802.1Q or Q-in-Q.


Smaller operators green-fielding Access networks will rely mostly on 
fibre (particularly GPON) and MPLS all the way into the Access.


It's just that FTTx services are growing at a much faster rate than 
copper-based services are. Depending on the market, it may not always be 
the incumbent witnessing this growth, although when they do finally get 
their act together, they can make up for lost time rather quickly.



They typically have ducts that were huge for copper that is already 
extracted.


One more fiber cable would be easy.



Agreed.



Agree that for competitive carriers DWDM would be more often needed.

Even for competitive carriers, it makes sense to evaluate the cost to 
put fiber into the duct of incumbents.


Especially because in some countries the price would be regulated.

It would solve the problem forever – no need for the DWDM speed upgrade.



Well, the only issue with that is that some markets make it more 
difficult to re-open up the roads for several years. Some worse than 
others. In such a case, DWDM is your best option.



I am calling to just not forget to evaluate this option too. Reminder: 
dark fiber is the best technical solution, for sure.




In general, most operators, regardless of size, will prefer dark fibre 
as a first option, especially for short spans like in the metro. But of 
course, real life is vastly different.


Mark.

Re: Routed optical networks

[Mark Tinka]

On 5/3/23 08:20, Vasilenko Eduard wrote:


I would risk to say a little more on this.

Indeed, maybe the situation (in many countries) when the Carrier sells 
a lot of TDM services.


But in general, packet services are enough these days for many 
carriers/regions.




There aren't enough TDM services to warrant DWDM, nowadays.

The reason for DWDM is mainly being driven by Ethernet, and IP.

At any reasonable scale, it's actually pretty hard to buy a TDM service, 
in most markets.



Additionally, I am sure that in many countries/Metro it is cheaper to 
lay down a new fiber than to provision DWDM, even if it is a pizza box.




I disagree. Existing fibre may be cheap because it was laid down a 
decade or more ago, en masse, by several operators. So the market would 
be experiencing a glut, not because it is cheap to open up the roads and 
plant more fibre, but because there is so much of it to begin with.


At worst, there is still enough duct space that the operator can blow 
more fibre. But when that duct gets full, and there are no more free 
ducts available, or another route needs to get built for whatever 
reason, it is a rather costly affair to open up the roads and trunk some 
fibre, in any market.


So no, DWDM is not more expensive, if you are delivering services at 
scale. It is actually cheaper. It is only more expensive if you are 
small scale, because in some markets, the fibre glut means you can buy 
dark fibre for cheaper than you can light it with DWDM. But this is a 
situation unique to small operators, not large ones.




The colored interface is still very expensive.



This only matters for the line side.

For client-facing, it's not a drama. And you typically buy more optics 
for the client side than you do the line side.



Of course, there are some Cities (not “towns”) where it is very 
expensive or maybe even impossible to lay down a new fiber.


Yes, in the majority of cases, it is cheaper to lay down fiber.



I think what you mean to say is that in the majority of cases where 
there is fibre glut, and dark fibre is a market option, buying fibre is 
cheaper than lighting it with DWDM. This is true. But I think that on a 
global scale, this is the exception, not the rule.


In general, you are not likely to be able to buy dark fibre, cheaply or 
otherwise, if you look at all markets in the world.



Hence, the importance of DWDM for the Metro is overestimated.



Again, only if you are small scale.

If you are a large scale operator with as many IP/Ethernet customers as 
you have Transport, DWDM is essential.



Use only routers. Provision enough fiber. Have always 1 router hop to 
the aggregation (hub-spoke topology), no routers chaining in the ring.


If fiber is not enough – then use normal DWDM with an external 
transponder. Routers would be still in hub-spoke topology.




Yeah, you sound like an equipment vendor whose main customers are 
incumbent telco's in a few rich markets :-).


The life of the average operator, around the world, is far less glamorous.

Mark.

Re: 100G-LR1 (DR/FR)

[Mark Tinka]

Coming back to this thread a little - what are folk seeing where 3rd 
party networks are involved?


Are you able to convince providers to run FR optics, where LR4 are still 
commonplace?


Mark.

Re: Routed optical networks

[Mark Tinka]

On 5/2/23 22:28, Eve Griliches wrote:

So right Jaredmagic has been in the NPU capacity increase that's 
driven the cost per 100G down on 1RU routers;


But that has only mainly solved for speed. Features have taken a hit, 
especially if the operator is motivated by the costs of merchant silicon.


There has been a marked improvement of features from merchant silicon, 
both from their vendors as well as the router OEM's that implement them 
in clever ways to work around their restrictions, but there are still 
some things only in-house silicon can do, at a price point most 
operators are not comfortable to pay anymore.


I think that as more of the Internet collapses into the hands of a few 
public cloud and content providers, operators are likely to place less 
and less importance on features, and just focus on speed, since the 
public Internet offers very little guarantees, if not none at all. I'm 
keen to see how this pans out.



and the integration of DSPs and more into QSFP-DD form factors at 
much lower power than expected.


Coherent has certainly changed the game, no doubt. If you grow steadily, 
you can wait for the evolution to make it into the IP/MPLS. If you need 
to move faster, you can't ignore the importance of Transport options in 
your network.


Mark.

Re: Routed optical networks

[Mark Tinka]

On 5/2/23 16:01, Eve Griliches wrote:


Hi Etienne,
Below is our (Cisco) definition of the Routed Optical Network. The 
goal, metro or long haul or subsea, is to reduce the number of control 
planes. By migration TDM traffic using CEM or PLE to the IP layer, you 
eliminate the OTN control plane and management. Eventually, when 
standards are settled the ultimate goal is to have a single 
control plane for the network. I'm not trying to be a commercial here, 
but you can read more in the resources section on this page: 
https://www.cisco.com/c/en/us/solutions/service-provider/routed-optical-networking/index.html

HTH,
Eve

Routed optical networking, is an architecture that delivers improved 
operational efficiencies and simplicity. The solution works by merging 
IP and private line services onto a single layer where all the 
switching is done at Layer 3. Routers are connected with standardized 
400G ZR/ZR+ coherent pluggable optics.


With a single service layer based upon IP, flexible management tools 
can leverage telemetry and model-driven programmability to streamline 
lifecycle operations. This simplified architecture integrates open 
data models and standard APIs, enabling a provider to focus on 
automation initiatives for a simpler topology.





To be honest, I've been hearing about this since as long as I can 
remember. IPoDWDM was another attempt at trying to make the above a reality.


But for some reason, operators prefer to keep these networks separate, 
and many customers, especially very large ones, prefer to bypass routers 
for their Transport services.


I think the effort will be appreciated, but if history is anything to go 
by, vendors are going to struggle to strip operators and customers away 
from some degree of separation.


Mark.

Re: Routed optical networks

[Mark Tinka]

On 5/2/23 21:32, Jared Mauch wrote:


I’ve seen proposals for an LSR MPLS/ROADAM type solution, where imagine you are 
at a hop where in a long distance system solution, you would end up with OEO, 
but instead you get directionality capability with an IP/MPLS capable device.


My memory is rather fuzzy, but didn't Juniper attempt something like 
this in their PTX's after they picked up BTI? I think the plan was to 
co-locate the ROADM at the bottom of the PTX chassis, or something along 
those lines.


I know Cisco (and Juniper) tried by integrating GMPLS into their code as 
a starting point, but that didn't go very far with customers. It just 
seemed impossible for the Transport teams to allow the IP/MPLS teams 
that level of access into their line system :-).




   As mentioned previously, the 400-ZR/ZR+/ZR-Bright/+0 optics are the latest 
example of that.


A rather high barrier to entry for most operators, but we have to start 
from somewhere.



I know of a few companies that have looked at solutions like this, and can 
expect there to be some interesting solutions that would appear as a result.  
Optical line systems tend to have pretty low power requirements compared to a 
router, but some of the routers are getting pretty low power as well when it 
comes to the power OPEX/bit, and if you have the ability to deliver services as 
an integrated packet optical you could see reduced costs and simplified 
components/sparing.


The main problem is distance.

If you need to move that kind of capacity more than 50km, it's hard to 
avoid DWDM.




I’ll also say that I’ve not yet seen the price compression that I had expected 
in the space yet, but I figure that’s coming.  We are seeing the bits/watt 
ratio improve though, so for the same or less power consumption you get more 
bits.  Some of this technology stuff is truly magical.


I think for long spans, DWDM will not only be cheaper, but the only 
feasible solution.


For the metro, it will come down to what motivates the business... 
plenty of features, or plenty of speed.


Also, DWDM vendors are adding speed and distance faster and cheaper than 
the IP/MPLS vendors can. So they will always be one step ahead in that 
respect; and we have the submarine cable systems to thank for that.


Mark.

Re: Routed optical networks

[Mark Tinka]

On 5/2/23 16:25, Izaac wrote:


This is a very convoluted way of backing into the ole packet-switched
vs. circuit switched decision.


A fight that will never go away.

There has been some compromise in recent years, with Transport-heavy 
customers accepting standard Ethernet services, but only if they are 
carried by a Transport device.


Mark.

Re: Routed optical networks

[Mark Tinka]

On 5/2/23 07:28, Vasilenko Eduard via NANOG wrote:

The incumbent carrier typically has enough fiber strands to avoid any 
colored interfaces (that are 3x expensive compare to gray) in the Metro.


Metro ring typically has 8-10 nodes (or similar). 16-20 strands of 
fiber were not possible to construct anyway – any cable is bigger.


It is the same cost to lay down fiber on 16 strands or 32.

Hence, PTT just does not need DWDM in Metro, not at all. Hence, the 
DWDM optimization that you are talking about below is not needed too.




This may or may not always be the case. Especially for large carriers, 
where there could be a requirement to sell some of those dark fibre 
pairs to large customers (think the content folk coming into town, 
e.t.c.), they may no longer have the priviledge of having plenty of free 
fibre in the metro. Or if they did, the rate of traffic expansion means 
they burn through those fibre pairs pretty quick.


10Gbps isn't a lot nowadays, and 100Gbps may start to push the limits 
depending on the size of the operator, the scope of the Metro-E ring and 
the level of service that needs to be maintained during a re-route (two 
available paths in the ring could balance 100Gbps of traffic, but if one 
half of that ring breaks, the remaining path may need to carry a lot 
more than 100Gbps, and then packets start to fall flat on the floor).


At that scale, DWDM in the metro will make sense, at least more sense 
than 400G-ZR, at the moment.



If you rent a single pair of fiber then you need colored interfaces to 
multiplex 8-10 nodes into 1 pair on the ring.


Then the movement of transponders from DWDM into the router would 
eliminate 2 gray interfaces on every node (4 per link): one on the 
router side, and another on the DWDM side.


Overall, it is about a 25% cost cut of the whole “router+DWDM”.



Some operators would also be selling Transport services in or along the 
metro, and customers paying for that may require that they do not cross 
a router device.



It is still 2x more expensive compare to using additional fiber 
strands on YOUR fiber.




There are plenty of DWDM pizza boxes that cost next to nothing. At 
scale, the price of these is not a stumbling block. And certainly, the 
price of these would be far lower than a router line card.




By the way, about “well-defined stack of technologies”:

NMS (polished by SDN our days) should be cross-layer: it should manage 
at the same time: ROADM/OADM in DWDM and colored laser in Router.


It is a vendor lock up to now (no multi-vendor). Hence, 25% cost 
savings would go to the vendor that has such NMS, not to the carrier.


Technology still does not make sense because no multivendor support 
between the NMS of one vendor and the router or DWDM of another.


Looking at the NMS history, it would probably never be multi-vendor. 
For that reason, I am pessimistic about the future of the colored 
interfaces in routers (and alien lambdas in DWDM). Despite a potential 
25% cost advantage in eliminating gray interfaces.




OpenROADM is a good initiative. But it seems it's to be to Transport 
equipment vendors what IPv6 and DNSSEC is to the IP world :-).


Mark.

Re: Best Linux (or BSD) hosted BGP?

[Mark Tinka]

On 5/1/23 20:04, Tomas Jonsson wrote:


VyOS uses FRR, but they used to run quagga.

And most bsd(?)/linux package managers has frr in their repository so 
maybe that could be something to look at?


pfSense running FRR is a pretty solid BGP router.

Mark.

Re: IPv4 Subnet 23.151.232.0/24 blackholed?

[Mark Tinka]

You're welcome to use our looking glasses which over Europe and Africa:

https://as37100.net/

But so far, we are seeing this in AMS:

BGP routing table entry for 23.151.232.0/24, version 2411923092
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  37100 3257 23470 23470 23470 23470
    105.26.64.17 from 105.26.64.17 (105.16.0.131)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 37100:1 37100:13
  path 211B5070 RPKI State not found
  rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  37100 3257 23470 23470 23470 23470
    105.26.64.1 from 105.26.64.1 (105.16.0.131)
  Origin IGP, metric 0, localpref 100, valid, external, best
  Community: 37100:1 37100:13
  path 211B6A5C RPKI State not found
  rx pathid: 0, tx pathid: 0x0

And in JNB:

BGP routing table entry for 23.151.232.0/24, version 1526622268
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  37100 3257 23470 23470 23470 23470
    105.22.32.1 from 105.22.32.1 (105.16.0.163)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 37100:1 37100:13
  path 44E5427C RPKI State not found
  rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  37100 3257 23470 23470 23470 23470
    105.22.40.1 from 105.22.40.1 (105.16.0.162)
  Origin IGP, metric 0, localpref 100, valid, external, best
  Community: 37100:1 37100:13
  path 44E60E94 RPKI State not found
  rx pathid: 0, tx pathid: 0x0

Mark.

On 4/26/23 13:33, Travis Garrison wrote:


We are able to see your range from Cogent and Hurricane Electric now. 
Just took time


Routes For: 23.151.232.0/24

Timestamp: 2023-04-26 11:27:07 UTC

  - Prefix: 23.151.232.0/24

    - RPKI State: Not Verified

    - AS Path: 6939 → 23470 → 23470 → 23470 → 23470

    - Next Hop: 184.105.58.113

    - Weight: 170

    - Local Preference: 100

    - MED: 0

    - Communities:

- Originator:

- Peer: 216.218.253.50

    - Age: 6 hours (Wed, 26 Apr 2023 05:01:41 UTC)

  - Prefix: 23.151.232.0/24

    - RPKI State: Not Verified

    - AS Path: 6939 → 23470 → 23470 → 23470 → 23470

    - Next Hop: 184.105.92.241

    - Weight: 170

    - Local Preference: 100

    - MED: 0

    - Communities:

- Originator:

- Peer: 100.78.0.6

    - Age: 6 hours (Wed, 26 Apr 2023 05:01:39 UTC)

  - Prefix: 23.151.232.0/24

    - RPKI State: Not Verified

    - AS Path: 174 → 3257 → 23470 → 23470 → 23470 → 23470

    - Next Hop: 38.140.137.161

    - Weight: 170

    - Local Preference: 100

    - MED: 10020

    - Communities:

  - 174:21000

  - 174:22013

    - Originator:

- Peer: 66.28.1.16

    - Age: 3 hours (Wed, 26 Apr 2023 08:57:05 UTC)

Thanks

Travis

*From:* NANOG  *On 
Behalf Of *August Yang via NANOG

*Sent:* Tuesday, April 25, 2023 9:54 PM
*To:* Ryan Hamel ; Neel Chauhan ; 
nanog@nanog.org

*Subject:* Re: IPv4 Subnet 23.151.232.0/24 blackholed?

The range has only been announced for 2 hours. Just wait longer for 
filters to refresh as Ryan advised.


On 2023-04-25 10:49 p.m., Ryan Hamel wrote:

Neel,

Carriers rebuild their prefixes lists once or twice in a 24 hour
period. Considering that you just got the block today and is in
ReliableSite's AS-SET, you just got to be patient.

Having announcements propagated immediately either sounds like it
happened a day after you gave them the LOA, or they have
unfiltered transit circuits, which is worrisome.

Ryan

-- Original Message --
From "Neel Chauhan"  
To nanog@nanog.org
Date 4/25/2023 7:35:40 PM
Subject IPv4 Subnet 23.151.232.0/24 blackholed?


Hi,

I recently got the IPv4 allocation 23.151.232.0/24 from ARIN.
I also had my hosting company ReliableSite announce it to the
internet.

Right now, I can only access networks that peer with
ReliableSite via internet exchanges, such as Google,
CloudFlare, OVH, Hurricane Electric, et al.

It seems the Tier 1 ISPs (e.g. Lumen, Cogent, AT, et al.)
are blackholing the IPv4 subnet 23.151.232.0/24. Could someone
who works at a Tier 1 NOC please check and remove the
blackhole if any exists?

Normally when ReliableSite announced my prior (then-leased)
IPv4 space it gets propagated via BGP almost immediately. This
time it's not going through at all.

Best,

Neel Chauhan

--
Best regards
August Yang

Re: Reverse DNS for eyeballs?

[Mark Tinka]

On 4/21/23 14:37, Chris Adams wrote:


I don't see any benefit to programmatically-generated reverse DNS.  I
stopped setting it up a long time ago now.  Really, reverse DNS these
days is mostly only useful for:

- mail servers (where it shows a modicum of control and clue)
- infrastructure/router IPs (so mtr/traceroute can show useful info)


Agreed.

Mark.

Re: Reverse DNS for eyeballs?

[Mark Tinka]

On 4/21/23 15:02, Frank Habicht wrote:



I would say the absence of reverse DNS tells useful info to receiving 
MTAs - to preferably not accept.


As does a randomly-generated one...

Mark.

Re: Backup DC power standardization with Photovoltiac battery systems?

[Mark Tinka]

On 4/18/23 08:41, Sean Donelan wrote:



I'd prefer broadband CPE (UL listed) with a standardized backup power 
connector (doesn't exist, but I can dream).


Out here, most people use this to keep CPE going when the power is out:

https://www.takealot.com/gizzu-8800mah-mini-ups-dual-dc/PLID71930088?gclid=CjwKCAjwov6hBhBsEiwAvrvN6Bwdu_8uBXMXa8pC475Hd6H4Aa_fUyYeDkYg13Q-j6tkjWCGHqAFYBoC26UQAvD_BwE=aw.ds

Nice, compact, neat package that is portable and will give reasonable 
backup time when needed.


For CO or data centre applications, most gear should be good for 48V. If 
it's lower than that and you have a ton of them, you are probably better 
off with a protected AC source.


Mark.

Re: Backup DC power standardization with Photovoltiac battery systems?

[Mark Tinka]

On 4/15/23 03:06, Sean Donelan wrote:

If both PV battery walls and broadband CPE supported 
Power-Over-Ethernet as a backup power source, that would work too.  
POE supports greater distances than USB-C.


Well, you generally want to only power your devices off the battery if 
you are unable to generate power from PV, or if you have a grid outage.


The other issue is if you also want to use the grid as a charge source 
for the battery, you are going to need an inverter, in which case 
attaching DC loads to a DC bus that contains both the battery and a 
standard, el-cheapo hybrid inverter makes things tricky.


If you don't want to use the grid for anything, then your main source of 
charge current would be PV. If it's a 48V battery, you will need 
something else to step that voltage down for devices on the DC bus that 
require less than 48VDC.


Mark.

Re: 100G-LR1 (DR/FR)

[Mark Tinka]

On 4/3/23 22:54, Tony Wicks wrote:


I have been using the  QSFP-100G-CWDM4 2k optics for within rack/DC for a 
couple of years now. They are about the same price as SR optics but allow the 
use of simple duplex single mode patches without blasting 10K optics at each 
other over a 2M patch. Never had one fail or any compatibility issues.


Our use of multi-mode fibre is historical, from the days when vendors 
sold line cards that were mode-fixed and not pluggable. The installed 
base is so large that it's just easier to carry on with multi-mode for 
in-rack cabling, where it's needed.


Mark.

Re: 100G-LR1 (DR/FR)

[Mark Tinka]

On 4/3/23 02:14, David Siegel wrote:

At this point, I'd be happy to see others happily deploy a 
single-lambda optic of almost any variety!  Since deploying 400G in a 
clients network (but 100G still being the preferred connection 
choice), any inquiry with respect to LR1, FR1 or DR+ is met with "no 
thanks, LR4 please."


If asked, I'd recommend FR1.  They're available at a great 
price-point, and 2km reach is adequate for most applications.


Agreed.

Pricing between LR4, FR and DR is not too far apart.

The only optic that is substantially cheaper than all of them is the SR4.

So in my mind, FR is the most ideal, although I'd still use SR4 for 
in-rack, multi-mode cabling.


Mark.

Re: 100G-LR1 (DR/FR)

[Mark Tinka]

On 3/31/23 15:51, Ca By wrote:


We use a lot of 100g-FR

For dense deployment and limited faceplate space, 100g-fr / dr are the 
only way.


LR4 is dead to me.


We run the SR4 optics for in-rack cabling, because they are about 4X 
cheaper than all the single-mode options.


We have been heavy on the LR4 optics, but are now starting to test (and 
if happy, switch to) the FR units, as they are even cheaper than the LR4 
option.


The DR options don't make much sense for us, because we prefer the SR4 
for in-rack cabling, and given how large data centres are nowadays, 500m 
might not enough to interconnect with customers.


But for un-amplified Metro-E deployments, we are looking forward to 
testing Adva's 100G-ZR, which is also a single lane optic.


Mark.

Re: Is malicious asymmetrical routing still a thing?

[Mark Tinka]

On 3/9/23 22:27, Aaron1 wrote:


Sounds like something uRPF would prevent

Does anyone do uRPF ?  lol


On routers where we carry a full table, we do.

Mark.

Re: A blatant podcast plug

[Mark Tinka]

On 3/5/23 22:34, Dave Taht wrote:


I rather enjoyed doing this podcast a few weeks ago, (and enjoy this
podcast a lot, generally), and it talks to what I've been up to for
the past year or so on fixing bufferbloat for ISPs.

https://packetpushers.net/podcast/heavy-networking-666-improving-quality-of-experience-with-libreqos/

I am kind of curious as to how much XDP and EBPF now exist in the
nanog universe and other applications y'all are finding for it?


Timely! Giving it a listen now.

You may also be interested in Geoff's BBR talk, especially over satellite:

https://2023.apricot.net/assets/files/APPS314/2023-03-01-leos-and-_1677635168.pdf

He gave it in Manila, last week.

Mark.

Re: Coherent 100G in QSFP28

[Mark Tinka]

On 2/28/23 12:23, Pascal Masha wrote:


How much will these cost?


Unclear at this time.

Mark.

Re: Coherent 100G in QSFP28

[Mark Tinka]

On 2/13/23 16:47, Tarko Tikan wrote:


To the best of my knowledge the actual products are like ~1y away.


Yes - if you are keen, reach out to your Adva (Adtran now, really) AM to 
get some beta units for testing; but FCS is Q2'24.


Getting our hands on some to see how they perform. Won't replace 
longhaul DWDM applications, but can be very handy in the 1km - 120km 
metro range.


Mark.

Re: Coherent 100G in QSFP28

[Mark Tinka]

On 2/13/23 15:54, Jared Brown wrote:


Looks like coherent 100G in the QSFP28 form factor is finally on the horizon.

 From the datasheet:
* 100G coherent DWDM in QSFP28 form factor
* tunable, flexible grid
* 300 km with amplification, 120 km without
* industrial or commercial temperature
* 5 watts

https://www.adva.com/en/products/open-optical-transport/pluggables-and-subsystems/coherent-100zr


They have been working on this for quite some time, and it's good to see 
it's baked.


Emphasis on ZR...

Mark.

Re: MX204 and MPC7E-MRATE EoL - REVOKED

[Mark Tinka]

On 1/28/23 09:29, Saku Ytti wrote:


If I'd have to stab in the dark based on nothing, I'd imagine they
forgot HMC is no longer shipping, and then panicked and EOLd all HMC
boxes, until someone did more work, and gathered they probably can
support a few HMC platforms with existing HMC parts they have.
I would be very uneasy committing to HMC gear, unless I'd have a
better understanding of what the problem was, and why it is no longer
a problem. My concern would be, if they were wrong once to EOL all,
then wrong again to revoke some EOL, can I trust them now to have HMC
parts for any RMAs I have down the life expectancy. Not at all
uncommon to run a box for a decade in SP network, and Juniper released
all-new HMC gear, after Micron announced HMC EOL.


What I've been able to gather is that Micron indicated that they could 
support another "couple" of years of the MX204 and MPC7E. After that, 
it's all up in the air again.


Considering how popular the MX204 is, and just how much the MX304 does 
not offer the same value, makes sense for Juniper to milk it while they can.


Personally, I'm okay with it. If they EoL the MX204 in some years from 
now, I have no problem running it until it's on its last legs. With the 
way things are going, we don't really have the same luxuries we used to 
when it comes to refresh cycles.


Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/6/23 07:42, Sabri Berisha wrote:


There were few raindrops, so we have an outage. Again.

I timed it. It took me less than 4 minutes to get it up and running.

Oh, and you were right about the UPS batteries. The UPS on top of my
garage door opener died halfway through opening the door.


You could try the 12V 7Ah Li-Ion batteries for your UPS, if you don't 
want to have to think about it.


https://www.amazon.com/Battery-HWE-Lithium-LiFePO4-Outdoor/dp/B095K38M6C

It comes with a BMS, so you don't have to worry about under- or 
over-voltage.




Silicon Valley, the most technological place on earth, and I can't
even have stable power.


I think power companies don't evolve at the same rate as computers :-).

Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/5/23 11:12, William Herrin wrote:


Hi Roy,

My guess is that your 20kw Onan isn't up to stably producing 20kw any
more. Or perhaps the older transfer switch with its mechanical timer
relays has gotten dodgy. The modern consumer gear is very reliable but
the pre-2010s commercial/industrial gear (such as Onan) takes a lot of
TLC to keep it working right.

Another thing that can happen is uneven load. The utility won't care
that 80% of your draw is on one side of the circuit but that'll stop a
generator in its tracks.

If you want to know for sure, get yourself an inductive clamp meter
and start checking the amperages at the breakers. You can get a cheap
one under 50 bucks. You just set it for AC amps, take the cover off
your breaker panel and clamp the jaws around the "hot" wires coming
from each breaker, one at a time.

As John mentioned, unless you have a really large house or a tankless
electric water heater, it's really odd to overwhelm a 20kw generator.
Even with the auxiliary resistive heat.


Agree with this assessment.

20kW rated is plenty of energy for even a demanding home.

Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/5/23 08:56, Roy wrote:



I don't know how much the pumps require.  The water well is about 100 
feet from the house and the pressure tank.


The septic pump has to pump uphill to the drainage field. Distance is 
about 250 feet and elevation gain of 100 feet or so.


The heat pump doesn't seem to be a problem but the aux heat is on two 
20amp 220v circuits.   There is a switch on the fan enclosure to 
disable the aux heat.


Another biggie is the electric hot water heater.

On 1/30 it never broke 32 degrees and the house used 145KWHR (average 
was 6KWH).  Thank goodness I am not far from the Columbia River and 
the BPA has a major substation about 5 miles away so I pay less than 
10 cents per KWH


Over 2022, I lost power about 8 times.  The longest outage was 15 hours.


I would suggest having your generator checked by a professional, because 
it sounds like even if it's rated at 20kW, it is under-performing.


It sounds like it may have lost some of its spark, over the years.

Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/5/23 09:32, John van Oppen wrote:

20 KW should easily cover the 9KW you could max draw with your strip heat.   It 
is super uncommon to have even peak loads over 20 KW in a house.   Even your 
peak day was only an average of 6 KW.

You might need some load shedding just to keep the big stuff from coming on all 
at once but that is pretty easy.   If you have instant hot water that also 
could be a problem those are huge, typically 15-20 KW by themselves.


I agree - sounds like Roy would benefit from either doing some load 
shedding and/or switching out gear that is more power-efficient.


Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/5/23 07:47, Chris Adams wrote:


My house isn't very big, and I live alone (so less demand for hot water
for example), and I hit a peak demand of 15kW a couple of months ago
during a cold snap (I've seen it higher, maybe 16kW IIRC, just didn't
dig any deeper).  I probably took a hot shower while the heat was
running, but I didn't cook anything that day, which could easily pulled
another 1-2kW (oven, microwave, etc.).  And that's without any
water/septic pumps.

Electric heat pumps are great for power efficiency until the temperature
drops and they switch over to pure electric heat.


Okay - if you live in a pretty cold climate, that may be it.

Sounds like you need to do some demand-side management :-).

Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/5/23 07:02, Roy wrote:



My all electric house is in a rural area.  The generator that came 
with the place is a 20KW Onan,  The bad news is in can't handle the 
house.  I think it is the Aux Heat on the heat pump that is the 
problem.  I have to also power the well pump and the septic pump.


Is your house single or 3-phase?

I'd be curious how much horsepower your well and septic pumps require. 
The most I've seen is 15hp @ 11kW, but that is pretty massive for an 
average home, even an off-grid one. Typical requirements would be in 
0.75kW - 5kW range, which is a wide range.


Do you know how much power the heat pump requires?

I'd struggle to see how a 20kW generator struggles to to run a home, 
unless you've also got heated floors, saunas, steam baths, water and 
space heaters, electric stoves and ovens all running at the same time :-).


Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/4/23 23:58, Sabri Berisha wrote:


I'd say I have something in between. I have a WEN GN875i: 
https://www.amazon.com/WEN-GN875i-Transfer-Switch-Ready-8750-Watt-Generator/dp/B08STWSWLH/

That's 7kw rated and 8.75kw peak. More than enough to support my home.


Yeah, plenty of juice.



I previously had one of those smaller 2200 watt generators. The problem
with those is that you're now limited to 1600 watt running, which barely
powers the fridge, lights, internet, and maybe some tv. Our power usually
goes out when it's very warm, so I like some AC.


Makes sense.



Mine is electrical (but not automatic) start, I have to flip the main and
a circuit breaker, which is protected by an interlock switch. Similar to
https://www.amazon.com/Generator-Interlock-Compatible-panels-Professional-Interlocking/dp/B0BN9T9DXT/

The interlock switch ensures that I'm not backfeeding to the grid, and
was necessary to pass inspection.

Usually I have it up and running within 10 minutes. That's how long it
takes for my UPS script to kick in and start shutting down servers.


Awesome!

Thanks for sharing.

Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/4/23 23:36, Sabri Berisha wrote:


Those must be different from ours, because we don't have that...


Even before we had power issues in South Africa, garage and gate motors 
had batteries in them. So it appears to be historical, for some reason 
or other.




Pretty impressive. How do they do that in SA?


Providing backup power is not an issue in major data centres.

GPON providers also do rather well in keeping the lights on during an 
outage. When outages were still relatively limited 5 or so years ago, 
you couldn't keep your home link up for more than an hour during an 
outage. Now with outages being more sustained, neither I nor a 
reasonable sample of folk I know have had their GPON fibre out during an 
outage, even when they occur multiple times in the day. I suspect decent 
use of batteries and generators.


Wireless ISP's seem to be doing just fine too, as they, obviously, have 
limited scale. Again, batteries and generators.


The mobile carriers suffer the most, as do operators who deploy Metro 
PoP's in commercial buildings that aren't consistent with backup power 
promises. The mobile operators are having to deal with battery theft and 
incomplete battery recharges between multiple outages in a single day.


Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/4/23 08:11, William Herrin wrote:


Not for more than a decade now, at least not in the U.S. When you're
up to whole-house generator prices everyone expects electric start.
Half the portables have electric start. Most lawnmowers have electric
start. Once you have that, the cost to make the switch automatic
instead of manual is trivial. And the mass-produced consumer-grade
switches are quite reliable.


Fair point, but it is not uncommon (YMMV) for backup solutions to not be 
whole-home, and this includes generators. I have not lived in the U.S. 
on any meaningfully extended basis, so I can't speak to the degree to 
which folk that install backup power choose their cost/value matrix. But 
in many other places I've lived, especially where the power is 
frequently out, splitting the house loads into different panels a 
generator or small solar/battery system can support is commonplace; 
mainly for convenience but also to reduce the chances of a fire or 
electrical shock from having to run wires ad hoc.


The same would also apply to renewables, especially where budget is 
limited and folk can't afford to backup the entire home.


This is often cheaper than investing in large backup solutions, while 
still providing some degree of convenience to power what one would 
consider critical items, whatever that means to them.


I've been helping quite a number of folk wire small inverters with 
limited power and backup battery time into DB boards that feed only 
lights and plugs to specifically drive wi-fi, TV, an IP phone and a 
fridge. The inverters and accompanying battery aren't terribly expensive 
here (US$500 - US$800 for a Lead Acid system, and up to US$1,400 for a 
Li-Ion one), and labour in Africa is dirt cheap (less than US$100 for an 
installation), so it's budget-friendly, and keeps basics going. One 
could even charge a laptop.


In general, the main things folk will not backup are electric stoves, 
electric ovens, electric water heaters, electric space heaters and air 
conditioners. Obviously, in places with winter periods, serious plans 
have to be made to avoid death from cold.


Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/4/23 07:48, William Herrin wrote:


Pre-wired makes it a standby generator, which 9 times out of 10 is
automatic start with an automatic transfer switch. It's running within
seconds whether you're home or not. Electricians cost too much and
20kva natural gas / propane generators with an ATS don't cost enough
more than the portables.

Compare:

https://www.costco.com/honeywell-18kw-home-standby-generator-with-transfer-switch.product.4000106705.html

and:

https://www.amazon.com/Honda-2200-Watt-120-Volt-Portable-Generator/dp/B079YF1HF6

understanding that an electrician will cost you $2000-$3000 for the
labor with any genset modification to the house wiring.


Aware of all this - I operate one or two submarine cable landing stations...

What I mean by "pre-wired" is that, perhaps, the generator is pre-setup 
and wired into the house, but is not in standby mode to manage costs, 
and perhaps, to be reliable since ATS's are often dodgy.


Maybe a manual start is required. Maybe a changeover switch has to be 
flipped. That sort of thing.


Of course, we are speculating, and Sabri can answer best.

Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/4/23 07:29, William Herrin wrote:


If it's just a little gasoline generator, 30 minutes is about right.
It takes 10 minutes to decide the power isn't coming back soon and
another 10 to drag the generator out of the shed, hook up the wires
and get it going even though it's cold, wet, and hasn't been run for
several months. That leaves 10 minutes to spare figuring out how to
convince the UPS that the generator power is good enough to retransfer
and stay.


Indeed - I was guessing given how reliable PG have been for Sabri, a 
lot is probably pre-wired. I may be wrong.


Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/3/23 21:11, Sabri Berisha wrote:


Living in an area served by PG, I've had my share of power cuts. At home
I have a 600va UPS that protects my cable modem, RPI router, and POE switch
which serves 2 APs. That lasts about 30 minutes, which gives me enough time
to fire up my generator.


I'd assume it doesn't take you that long to fire up the genie, if you 
are home when the power goes out :-).


Out of interest, depending on how long you've had the UPS, how many 
times have you changed the battery?




Tip of the day: I also have a 1000va UPS that protects my garage door opener.
This makes it a lot easier to a. get a car out if needed, and b. get my
generator out of the garage.


In South Africa, garage door motors historically come standard with a 
12V 7Ah Lead Acid battery. What most people don't realize is that within 
1.5 to 2 years, those batteries are dead, and since there was power most 
of the time, they never noticed, until the power went out and the 
battery did not have sufficient energy to drive the motor.


It is not uncommon to see folk here moving to Li-Ion batteries with the 
same capacity to drive garage and gate motors. Personally, I try to only 
use Li-Ion packs in well ventilated, not-too-tight spaces, that come 
with a BMS and a charger that is predictable :-). So I avoid these 
little ones, and feel safer with Lead Acid batteries for garage and gate 
motors.




Lastly, in the spirit of happy wife, happy life, I have another 600va UPS
that covers my tankless water heater. It heats using natural gas, but the
control panel still needs power. That thing lasts pretty long.


There are tankless water heaters that can take standard AA batteries to 
spark the igniter as well, but yes, if yours is electric, makes sense to 
put a UPS on it. At my place, I use both a PV-based controller to heat 
traditional water tanks, and also have just as many tankless water 
heaters. The former is for end-of-day showers and dish washing once the 
sun has done its thing, the latter is for the morning jobs for the same 
things, or if it's cloudy/rainy outside.


Even though I have whole-home backup, I did place a UPS on the PV-based 
controller, because even if it is connected to solar panels, it is 
still, in essence, an inverter, meaning it requires a grid before it can 
generate solar power. That is what the UPS does for it. It was my first 
deployment of renewable energy, so I needed the UPS before I backed up 
the entire home.




YMMV, of course, but I went through numerous outages recently. And by
numerous, I mean enough for our City leadership to get pissed off at PG
and demand explanations.


Judging by our situation, I'd take the city leadership demanding 
explanations any day :-). We are way past that, down here. It's so bad, 
folk are deploying self-generation and self-storage by the truck loads. 
It's the gold rush for solar and battery installers right now. People 
have all but given up on the power company (Eskom) ever going back to 
its glory days.




So far, my current ISP (Spectrum cable) has had 0 outages as a result of
power loss. Which is pretty impressive, given the instability of the grid
in this area.


Not bad.

Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/3/23 19:53, Saku Ytti wrote:


In practice I would default to expecting 0 min availability during
power outage, regardless of how resilient my CPE is. We can scarcely
make the Internet work at the best of times.


Agreed, this is a good place to start. It's a bit doom & gloom, but most 
people underestimate just how much work it takes power companies to 
generate and distribute energy. Consequently, they never have to think 
about generation and/or load management, if they had to do it on their 
own, meaning they will usually consider the cheapest solution possible, 
which for electricity, usually ends in tears.


Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/3/23 19:25, Brian Turnbow via NANOG wrote:


They have been discussing it here in Italy as well.
The isp/telecommunication industry here is tryng to get Cos/pops/cabinets 
listed as critical infra and removed from rolling power cuts.


I would say plan for the worst, because there will always be some other 
department or governmental function that says they are more critical 
than the next one. And even if they may designate certain functions as 
critical, electrical distribution grids are not always built to that 
degree of granularity, and those critical functions are often caught in 
the crossfire as other non-critical loads are shed from the network.


And even after all that, if the blackouts need to intensify, all bets 
are off, since the main purpose then becomes preventing grid frequency 
drop, rather than servicing loads.




Here this is mainly ran from pops that have ups and generator systems so 
several hours to days of uptime depending on site.


If major data centres need to spend more on fuel than they planned for, 
I'd suggest making a generous allocation for an increase in co-lo costs 
for your next budget cycle, as the data centres will, invariably, pass 
those costs on the longer the city has to shed power from the grid.




OTOH I have seen providers daisy chain customer sites in a ring that crash 
miserably when 2 customers loose power isolating all in between sites.
But that is not the norm...


This is one of the reasons we refuse to turn customer sites into Metro-E 
PoP's, or PoP's of any kind.




Street cabinets for fttc services here have low times if any.
Same thing for mini dslams mounted on poles in the middle of nowhere.
0 to 2 hours for these.
Most have batteries/capacitors in the cabinet but not all and they are not 
designed for extended power outages 2 hours max.
Some are remotely powered from the CO, but that does not seem to be a thing 
anymore. Too costly
DSL ran from COs are protected as for fiber above.


A lot of this will be driven by what competitors do. If there is no 
competition that can keep their street cabinets going, the others won't. 
It's a great opportunity for anyone willing to make lemonade out of the 
situation.




Don't operate a 4g network, so take this info accordingly ,  but here it 
depends on the tower from what I have seen.
All towers I have seen have  battery backup , a lot have generators too.
I would say they have higher times than the fttc times above.


In dense metro's, mobile sites will be well invested. It starts to get 
tricky when you go out into the sticks.


Also, when the power goes out, so does the wi-fi. That means everybody 
moves their traffic away from the home wi-fi and on to the nearest cell 
tower. While radio bandwidth and signal coverage does not suffer that 
much, it hits the backhaul hard, between the tower and the mobile 
carrier's core. So nice flashing LTE/4G/5G signals on your phone 
translates to GPRS-esque performance. In some cases, we have seen mobile 
operators downgrade radio coverage to 3G, in order to manage this. Who 
knew 3G performed a bad as GPRS or EDGE, in 2023 :-)?


In the most extreme of case, the cell site could run out of power as 
well, as there isn't enough time for the batteries to recharge between 
outage cycles, or the field teams can't replenish fuel for the 
generators in time.


In the absolutely extreme cases (as we see here in South Africa, for 
example), cell sites can be raided and batteries stolen, especially if 
there is darkness all around. I would not expect this to be the case in 
the UK, especially if power outages are not the norm and people live a 
fairly middle-class life, but if I were Vodafone, for example, I'd have 
my risk department planning for such an eventuality already.


Mark.

Re: Typical last mile battery runtime (protecting against power cuts)

[Mark Tinka]

On 2/3/23 16:11, Israel G. Lugo wrote:



Hi folks,

At $day_job, I have a team of engineers who are oncall for critical 
services in the United Kingdom. For $reasons, the national power grid 
is announcing the possibility of rolling power cuts over the coming 
months. Right now it's "unlikely", but possible. If cuts do happen, 
it'll be 3+ hours, possibly several times/day.


I'm looking at the cost/benefit of deploying small UPSes at people's 
homes, to protect their network access when oncall. Just to power the 
home router (+ONT if FTTP), and keep a charged laptop. I figure 
anything smallish should be enough for a few hours.


Question is, how much battery runtime can I typically expect from 
ISPs' last mile infra.


People will have a random mix of DSL, FTTP, DOCSIS. Another 
alternative is tethering with 4G.


- For FTTP, I *think* (but am not sure) that the UK mostly uses PON, 
so guess it would be runtime of OLT and onwards

- For DSL: runtime of DSLAM cabinet and onwards
- For CATV: CMTS and onwards, maybe any active equipments in the HFC 
to the CPE?

- For 4G: BSS and onwards

Could anyone with last mile experience help with some ballpark 
figures? I.e. 15 min vs 8h or 8 days.


Living in South Africa where load shedding is the order of the day since 
the end of last year (and to continue for the next 2 years, at least, if 
not more), I can tell you that until network operators have had to deal 
with this, they are ill-prepared.


For equipment inside major data centres, you will be fine. But for 
equipment in commercial buildings, street cabinets, e.t.c., uptime will 
be directly related to how much faith operators have put into the 
national grid, which translates to some UPS, and whether the building or 
cabinet is serviced by a well maintained generator.


As for the home, a UPS is not a terribly good idea to keep the "wi-fi" 
going... typical UPS's use Lead Acid batteries which are shallow-cycle 
batteries that are not meant to be discharged below 50%. It's the usual 
disclaimer - UPS's are meant to give you time to save your work and 
shutdown, not provide extended backup.


If customers expect the power to be out for 3+ hours at a time, multiple 
times a day, I'd recommend getting a cheap 1.6kW inverter that can power 
a 24V 100Ah Li-Ion battery (either 1x 24V or 2x 12V in series). It's not 
a lot of energy, but if you are powering the CPE + ONU + IP phone, it's 
more than enough (you can easily squeeze 9hrs of continuous run-time on 
a single charge, maybe even more). While these inverters are slow to 
charge Li-Ion batteries (about 10A of charge current), the load is so 
minimal that the battery is being discharged even slower. So it works 
out, even with extended, multiple outages in a 24-hour cycle.


Operators running gear outside of major data centres will want to invest 
in large Li-Ion packs designed for the load and frequency of grid 
outages. Investing in Lead Acid batteries, while cheaper initially, 
will  become operationally expensive, as they don't do well with 
high-cycle counts, even the deep discharge ones. Not to mention, the 
rather poor energy density they possess for the amount of weight they carry.


Depending on the importance of the site, some solar power may be 
necessary, even though the UK is not the most well-lit country in the 
world. For such cases, you can augment the solar plant with a generator, 
mainly to recharge the batteries, rather than to power the load.


Mark.

Re: MX204 and MPC7E-MRATE EoL - REVOKED

[Mark Tinka]

On 1/27/23 00:50, Aaron Gould wrote:


Did you hear? EoL was revoked December 2022... I'm so glad, I like and 
use the MX204 and the MPC7E-MRATE




Yes, the decision was made in November of last year, but only 
communicated to customers in December.


Apparently, the shortage of chips for the MX204 and MPC7E is now 
resolved, and there is no longer any need to force customers to move to 
the MX304.


Mark.

Re: Large prefix lists/sets on IOS-XR

[Mark Tinka]

On 12/12/22 12:26, t...@pelican.org wrote:


That's a take on it I really hadn't considered.  I'm very aware that moving from a decade 
or two of legacy manual config to full data model/automation in a big bang is never going 
to work, but I'd been looking at what individual elements could be pulled out and 
automated with judicious use of "replace".  Never considered making the 
*entire* legacy config a starting point for the template, and then effectively working on 
automating replacing parts of that config file with data-driven versions of the same.

Food for thought, thanks for that.


Agree.

This is why when vendors come to market their new shiny 
NETCONF/YANG-based SDN thingie that will make my life easier, I sit back 
and smile :-).


Real life is very different from what we think "automation" should be. 
And as I mentioned on some list a year or two ago, "automation" means 
different things to different people. So rather than trying to box 
yourself into the word "automation", just find ways to make your life 
easier. Whether someone wants to call it automation or not, is 
irrelevant... well, until we can walk into a shop and buy Automation off 
the shelf.


Mark.

Re: Large prefix lists/sets on IOS-XR

[Mark Tinka]

On 12/9/22 16:38, Saku Ytti wrote:


I refrain from expressing my disillusionment with the utility of doing
IRR based filtering.


I won't (refrain).

We don't, for this very reason :-).

Mark.

Fwd: [apops] APRICOT 2023 Call for Presentations

[Mark Tinka]

FYI.

Mark.

 Forwarded Message 
Subject:[apops] APRICOT 2023 Call for Presentations
Date:   Sat, 15 Oct 2022 20:03:11 +1000
From:   Philip Smith 
Organization:   Asia Pacific Regional Conference on Operational Technologies
To: ap...@apops.net



Hi everyone,

Forwarding the APRICOT 2023 call for presentations on behalf of the PC 
Chairs.


Best wishes!

philip
--


APRICOT 2023
20th February - 2nd March, Manila, Philippines
https://2023.apricot.net

CALL FOR PRESENTATIONS
==

The APRICOT 2023 Programme Committee is now seeking contributions for
Presentations and Tutorials for the APRICOT 2023 Conference.

We are looking for presenters who would:

- Offer a technical tutorial on an appropriate topic;
- Participate in the technical conference sessions as a speaker;
- Convene and chair panel sessions of relevant topics;
- Lead informal Birds of Feather break out sessions.

Please submit on-line at:

http://papers.apricot.net/user/login.php?event=161

CONFERENCE MILESTONES
-

Call for Papers Opens: Now
Outline Programme Published: As Papers Confirmed
Final Deadline for Submissions: 30th January 2023
Final Program Published: 6th February 2023
Final Slides Received: 20th February 2023

*SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS, REGARDLESS OF
PUBLISHED DEADLINES*

PROGRAMME CONTENT
-

The APRICOT Conference Programme consists of three parts, these being
Tutorials, the Peering Forum, and Conference Sessions.

Topics proposed must be relevant to Internet Operations and
Technologies, for example:

- IPv4 / IPv6 Routing and Operations
- Routing Security, including RPKI and MANRS
- Internet backbone operations
- Peering, Interconnects and IXPs
- Content Distribution Network technology & operations
- Chip shortages impact on equipment acquisition and operations
- Research on Internet Operations and Deployment
- Pandemic impact on network deployment and operations
- Network Virtualisation
- Network Automation/Programming
- Network Infrastructure security
- IPv6 deployment on fixed and Wireless/Cellular networks
- DNS / DNSSEC and KINDNS
- Access and Transport Technologies
- Technical application of Web 3.0, public blockchains and cryptocurrency
- Content & Service Delivery and "Cloud Computing"


CfP SUBMISSION
--

Draft slides for both tutorials and conference sessions MUST be
provided with CfP submissions otherwise the submission will be
rejected immediately. For work in progress, the most current
information available at time of submission is acceptable.

All draft and complete slides must be submitted in PDF format only.
Slides must be of original work, with all company confidential marks
removed.

Final slides are to be provided by the specified deadline for
publication on the APRICOT website.

Prospective presenters should note that the majority of speaking slots
will be filled well before the final submission deadline. The PC may,
at their discretion, retain a limited number of slots up to the final
submission deadline for presentations that are exceptionally timely,
important, or of critical operational importance. Every 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.

Any questions or concerns should be addressed to the Programme
Committee Chairs by e-mail at:

pc-chairs at apricot.net

We look forward to receiving your presentation proposals.

Mark Tinka & Marijana Novakovic
APRICOT 2023 Programme Committee Chairs
--
___
Go to the apops mailing list on Orbit -- 
orbit.apnic.net/mailing-list/ap...@apops.net
Explore orbit.apnic.net, where the APNIC community connect, discuss and 
share information related to Internet addressing and networking.

To unsubscribe send an email to apops-le...@apops.net

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Mark Tinka]

On 11/20/22 19:02, Abraham Y. Chen wrote:


Dear Mark:

0)  I am surprised at your apparently sarcastic opinion.

1)  The EzIP proposal as referenced by my last MSG is the result of an 
in-depth system engineering effort. Since the resultant schemes do not 
rely on any protocol development, IETF does not need be involved. 
Especially, its first step of disabling one line of existing 
networking program code empowers any party to begin deploying EzIP 
stealthily for mitigating the IPv4 address pool depletion issues. Note 
that EzIP is a generic solution applicable to everyone, not limited to 
Africa.


2)  Of course, constructive criticism is always appreciated. However, 
unspecific comments that confuse and distract the readers only provide 
dis-service to those disadvantaged population who are enduring the 
handicaps of being the late-comers to the Internet.


My comment was not directed at you. Sorry.

I have nothing against the EzIP proposal. It just does not add any real 
value in solving the IPv4 depletion problem for the amount of effort 
required to implement it, in my view. I'd, rather, expend those 
resources on IPv6, 464XLAT, e.t.c.


Mark.

Re: Alternative Re: ipv4/25s and above

[Mark Tinka]

On 11/19/22 05:50, Abraham Y. Chen wrote:


Dear Owen:

1) "... Africa ... They don’t really have a lot of alternatives. ...": 
Actually, there is, simple and in plain sight. Please have a look at 
the below IETF Draft:


It's most amusing, to me, how Africa needs to be told how to be...

Some folk just can't help themselves.

Mark.

Re: ipv4/25s and above

[Mark Tinka]

On 11/18/22 13:44, Joe Maimon wrote:



its almost 2023. /31 support is easily mandatory. You should make it 
mandatory.


I don't make the gear.


How many customer addressing designs does that total, 2? So that would 
be 1 more than you have already? Dont buy it.


That's fine.




Its 2023, your folk should be able to handle addressing more advanced 
than from the 90s.


Customers will do what they do.



And your betting the future on IPv6?


Actually, yeah.


The only issue with it is traceroute although that isnt necessarily a 
problem.


We and some of our customers find that useful.




And the CPE sourced traffic should either be all internal or sourced 
from the loopback.


It's not my CPE, I don't get to make the rules.




OTOH CoPP protection becomes a lot easier when fewer of the CP 
addressing is globally routed.


As does not connecting any cables to the device.

Seriously, all good points. We just have more pressing issues to deal with.


Truth is the real issue isnt CPE support, its user support. Most 
users(even their "IT" folk) really cant wrap their brain around more 
than the bare basic concepts, if that much.


And you can simply say, IPv4 is limited, this is the base model 
addressing included with the service, if your inabilities are 
preventing you from using networking techniques that have been 
standardized and usable for decades, then feel free to pony up for 
either for your comfort level or for support of your inabilities.


Okay.


This is the crux. So long as you can obtain more, justifiable 
consumption is rewarded with additional resources, dis-incentivizing 
any addressing efficiency progress from the ancient /30 p2p + /29(or 
larger) routed block.


You may wish to lay groundwork to nibble backwards when runout occurs 
for you.


Its on Afrinic to try and preserve their pool if they wish to by doing 
things such as getting it across that progress in addressing 
efficiency is an important consideration in fulfilling requests for 
additional resources.


We aren't really going to expend too many resources on trying to delay 
the use of IPv6. I understand that I am speaking from a place of 
priviledge, having as much IPv4 as we do, but even then, we will connect 
as many as we connect using either "efficient" or "inefficient" 
techniques, and neither will prevent run-out, eventually.


We want to be able to keep servicing customers, long after we are gone. 
That is what we care about.





If they need more, they pay more and they get more. Most of the rest 
of the world is operating or moving to operate in that fashion.


It's fine for most of the world to do what it wants. I won't begrudge 
them that. Over here, we will do what we feel works for us.





You would still require them to submit a formal request documenting 
their need. And paying more is likely to mean that its a more honest 
request.


We do this already, only without asking them for cash.




But see the crux above. If your RiR isnt frowning on such behavior 
then its poor strategy to implement it.


I might have missed the part where RIR's tell me how to operate.




Although, if you can get away with it, allocating the /30 + /29 and 
implementing it in an easy-to-clawback approach might be a good strategy.


There is reasonable customer movement between competitors that address 
space comes and goes.



Thats a question of internal discipline without motivating external 
factors. Odds are those factors will arrive and I would advise 
preparedness for them.


Have you ever been in sales :-)?

Mark.

Re: ipv4/25s and above

[Mark Tinka]

On 11/17/22 19:55, Joe Maimon wrote:



You could instead use a /31.


We could, but many of our DIA customers have all manner of CPE's that 
may or may not support this. Having unique designs per customer does not 
scale well.




Or private/enterprise-private


Yeah, don't like that, although I understand why some operators use it.


or unnumbered and route them the single /32 to use for their NAT on 
say a loopback interface.


Same as the CPE issue I described above.


And the /29 ? I would reserve it but not assign it without a formal 
request.



We have some products that can be considered sub-DIA that do not come 
with the /29 as standard. Those tend to be the majority of the market.




Either you have lots of fallow ground or very few customers.


A bit of both.

Our main business is wholesale IP Transit. The Enterprise piece is 
growing, but we are not trying to save the world. It's a specific focus, 
and we don't do consumer.




I dont see how this strategy would work elsewhere.


To be honest, we'll keep using IPv4 for as long as we have it, and for 
as long as we can get it from AFRINIC. But it's not where we are betting 
the farm - that is for IPv6.



Your sales people are right. Since you can deliver quite usable 
service that enables them to operate just as they have before with a 
single /32, and with technical advantages to yourself, all the extra 
wasted integers should be bringing in value.


At the risk of using IP addresses to prop uo sales numbers, and then you 
run out sooner because one customer decided to pay lots of $$ for a /22, 
even when they don't need it. Not the kind of potato I want to taste, 
because we have seen that proposed far too many times to know it will 
become a reality when the commissions are due.


Mark.

Re: ipv4/25s and above

[Mark Tinka]

On 11/16/22 16:39, Dave Taht wrote:

I am kind of curious as to the distribution of connections to smaller
companies and other entities that need more than one ipv4 address, but
don't run BGP. So, for as an ISP or infrastructure provider, what is
the typical percentage nowadays of /32s /31s /30s... /25s of stuff
that gets run "elsewhere"?

Is there any correlation between the number of IPs a customer gets and
the amount of bandwidth they buy?

Obviously "retail", home use is /32s and there's an increasing amount
of CGNAT, but I can't help but imagine there are thousands of folk
running /27s and /29s for every /24 or /22 out there.

I've been paying 15/month for a /29 for forever, but barely use it.


For our DIA/Enterprise business, we offer customers a /30 for p2p link, 
and a /29 as initial standard for onward assignment within their LAN.


Interestingly, most customers will NAT on the p2p address space, and 
barely use the onward assignment. In such cases, link migrations cause 
issues, because customers bake their internal configurations against 
those p2p IP addresses, which are pegged to specific edge routers on our 
side that can't move due to our need to minimize the iBGP footprint in 
the network. It's not a major issue in absolute terms, but a headache 
nonetheless.


We can offer customers up to a /24 maximum (i.e., we will let the /29 
expand into a /24), and no more. If they need more than a /24, time to 
speak to AFRINIC.


We don't charge for address space. Our Sales people want us to, but we 
don't feel it makes sense. It's not a big-enough deterrent for us to 
keep IPv4 stock. And when we do run out of IPv4 space, it will be like 
having billions of $$ on a deserted island.


Mark.

Re: Jon Postel Re: 202210301538.AYC

[Mark Tinka]

On 10/31/22 00:41, Abraham Y. Chen wrote:



2)  To follow what you are saying, I wonder how could we think "out of 
the box" or go "back to the future", before it is too late for our 
world wide communications infrastructure to serve as a reliable daily 
tool without being a distraction constantly?


At the risk of being severely off-topic, this is an existential question 
that talks to the burden of priviledge.


Current society has such technological advancement, famine, drought and 
war are not top-of-mind for most people (even if these issues are for 
many), compared to millennia gone by.


The difficulty with modern-day priviledge is that many people cannot 
answer the "why" to our existence, because there is simply easy and 
abundant access to information, with comfort, that leaves so many 
without direction until much later in life. In millennia gone by, your 
purpose in life was to survive war, find food, find water, and keep your 
kin alive. The world is, for the most part, too comfortable for that, 
nowadays.


All that leads to is the "constant distraction" that we see today, more 
so with the kids, but also with many adults. The very thing that has 
propelled society in many useful ways, is also what is likely going to 
set us back a tad.


Mark.

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[Mark Tinka]

On 10/11/22 00:37, Matthew Petach wrote:




They became even more huffy, insisting that we were breaking the 
internet by not
following the correct routing for the more-specific /24s which were no 
longer present
in our tables.  No amount of trying to explain to them that they 
should not advertise
an aggregate route if no connectivity to the more specific 
constituents existed seemed
to get the point across.  In their eyes, advertising the /24s meant 
that everyone should

follow the more specific route to the final destination directly.



Certainly, an interesting, half-technical angle to consider when 
thinking of doing something like this.


Folk that are pushing out /24's with the expectation of the rest of the 
Internet steering traffic a certain way toward them, being surprised by 
the "brokenness" that can be created due to the decision to override 
"longest match" in favour of spending less cash.


Who has the right to complain the least, or the most, in such a situation?

    A: "So why don't you have a bigger router that can take our /24?"

    B: "Well, we don't have the money to afford taking a /24."

    A: "Ummh... but you are breaking BGP, and..."

    B: "Yeah... it's my Autonomous System. Sorry!"

As my South African friend would say, "It's wild".

Mark.

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[Mark Tinka]

On 10/10/22 17:26, William Herrin wrote:

The Internet FIB is around 900k IPv4 routes. You have years before
exhausting a 2.2M table.


Depends on what else they may be carrying in their IGP, MPLS domain, SR 
domain, e.t.c.


Mark.

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[Mark Tinka]

On 10/10/22 16:58, Edvinas Kairys wrote:


Hello,

We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has 
24x100G, but only 2.2mln route (FIB) memory entries. In a near future 
it will be not enough - so we're thinking to deny all /24s to save the 
memory. What do you think about that approach - I know it could 
provide some misbehavior. But theoretically every filtered /24 could 
be routed via smaller prefix /23 /22 /21 or etc. But of course it 
could be a situation when denied /24 will not be covered by any 
smaller prefix.


I wouldn't bank on that.

I am confident I have seen /24's with no covering route, more so for PI 
space from RIR's that may only be able to allocate a /24 and nothing 
shorter.


It would be one heck of an experiment, though :-).

Mark.

Re: Disney+ Contact

[Mark Tinka]

On 8/31/22 11:03, Brian Turnbow wrote:

Hi Mark


Anyone from Disney who can help with a geo issue on-list? We have customers in 
South Africa mapping to India. Thanks.

Did you try the emails in thebrotherswisp geo page?
I have had some success though the Techops emails.
Sometimes it does take a while for a response...

Disney+: E-mail them the trouble subnet at 
techops-distribut...@disneystreaming.com. Also, 
techops-servi...@disneystreaming.com will probably be where that sends you. 
Another possible email is disneyplusispsupp...@disneyplus.com


Many thanks, Brian. Most helpful.

Mark.

Disney+ Contact

[Mark Tinka]

Hi all.

Anyone from Disney who can help with a geo issue on-list? We have 
customers in South Africa mapping to India. Thanks.


Mark.

Re: SAFNOG-7: 3 Days to Go! Register Now to Attend

[Mark Tinka]

Hello all.

With just 3 days to go, we are all very excited to see you in Cape Town, 
next Tuesday.


Please refer to the highlights below for next week's meeting.

The Day 1 social - NAPAfrica's Beers for Peers - is now open for 
registration. Please do so here so you can reserve your place early 
enough. Entrance is free of charge:


https://www.teraco.co.za/events/beers-for-peers/

The Day 2 social will be held at the Grand Africa Cafe & Beach, in 
Granger Bay. Tickets to attend will be provided to registered 
participants, at the conference venue. Entrance is free of charge:


https://grandafrica.com/grand-africa-cafe-beach/venue/grand-africa-cafe-beach-entire-venue-solo-use/

See you all soon, and happy travels :-).

Mark.

On 8/19/22 15:05, Mark Tinka wrote:

Hello all.

With 10 days to go to the 7th edition of SAFNOG, we are delighted, and 
excited, to welcome you all to sunny and vibrant Cape Town, where we 
can all see each other after 2 years of social distancing.


We have put together a very exciting program that covers a number of 
new, trending, thoughtful, operational and technical topics from 
within our community. Here are some key highlights:


  * The arrival of the new Equiano cable system, and what it means for
the region, presented by Jonathan Davidson, Google.

  * A keynote on how value within the telecommunications space is
shifting, and what the modern telco may need to look like for the
future, by Edgar Kasenene, IDEX.

  * A panel on what the ongoing semi conductor shortages are doing to
the industry, represented by vendors, operators and distributors,
and hosted by yours truly.

  * The new paradigm in submarine cable design, using SDM (Spatial
Division Multiplexing), presented by Alan Hollander, Infinera.

  * ... and a whole lot more!

Check out the full agenda here:

https://safnog.org/event/agenda.html

If you haven't yet, please register to attend, and also book your 
hotel accommodation using SAFNOG's preferred rate, at:


https://safnog.org/

The Day 1 social will be Beers For Peers, hosted by NAPAfrica.

The Day 2 social will be hosted by Iris Network Systems.

If you have any questions, please send an e-mail to:

    secretariat at safnog dot org

We look forward to seeing you in Cape Town.

Happy travels!

Mark.

SAFNOG-7: 10 Days to Go! Register Now to Attend

[Mark Tinka]

Hello all.

With 10 days to go to the 7th edition of SAFNOG, we are delighted, and 
excited, to welcome you all to sunny and vibrant Cape Town, where we can 
all see each other after 2 years of social distancing.


We have put together a very exciting program that covers a number of 
new, trending, thoughtful, operational and technical topics from within 
our community. Here are some key highlights:


 * The arrival of the new Equiano cable system, and what it means for
   the region, presented by Jonathan Davidson, Google.

 * A keynote on how value within the telecommunications space is
   shifting, and what the modern telco may need to look like for the
   future, by Edgar Kasenene, IDEX.

 * A panel on what the ongoing semi conductor shortages are doing to
   the industry, represented by vendors, operators and distributors,
   and hosted by yours truly.

 * The new paradigm in submarine cable design, using SDM (Spatial
   Division Multiplexing), presented by Alan Hollander, Infinera.

 * ... and a whole lot more!

Check out the full agenda here:

https://safnog.org/event/agenda.html

If you haven't yet, please register to attend, and also book your hotel 
accommodation using SAFNOG's preferred rate, at:


https://safnog.org/

The Day 1 social will be Beers For Peers, hosted by NAPAfrica.

The Day 2 social will be hosted by Iris Network Systems.

If you have any questions, please send an e-mail to:

    secretariat at safnog dot org

We look forward to seeing you in Cape Town.

Happy travels!

Mark.

SAFNOG-7: CfP Announcement

[Mark Tinka]

Hello all.

The CfP (Call for Papers) for the SAFNOG-7 conference, due to take place 
in-person on the 30th - 31st August, 2022, at the Lagoon Beach Hotel in 
Cape Town, South Africa, is now open.


Please find more details about the CfP at the link below:

https://safnog.org/event/papers.html

We look forward to receiving your submissions, and to seeing you in Cape 
Town soon. Thanks.


Mark.

Re: Serious Juniper Hardware EoL Announcements

[Mark Tinka]

So there have been some developments re: this thread.

As it pertains to the both the MX204 and MX10003, Juniper have made the 
following amendments:


 * EoS = 2023.
 * End of new features = 2024.
 * End of bug fixes = 2028.
 * End of critical features = 2028.
 * EoL = 2029.

FWIW.

Mark.

Re: Serious Juniper Hardware EoL Announcements

[Mark Tinka]

On 6/18/22 15:04, Robert Webb wrote:


I just have one question?

Why are we discussing IP allocations and IANA in an email thread about 
EoL Juniper gear?


Something about having more time to fix other softer issues we've long 
ignored, since we won't be busy installing any hardware :-).


Mark.

Re: Serious Juniper Hardware EoL Announcements

[Mark Tinka]

On 6/17/22 14:47, Saku Ytti wrote:


I can't pinpoint HMC as a bad solution, yes we've had our share of HMC
issues, but we've also on JNPR and some other vendors previously
replaced all linecards due to memory issues, before stacked DRAMs were
a thing, memories are notoriously fragile.
I can pinpoint HMC as a huge risk due to no manufacturer :).

The memory issues are exacerbated by needing to reload the whole
linecard when one memory has issues, JNPR has now delivered on newer
images fixes where you can reduce both the collateral damage and
downtime by reloading individual PFEs (and connected memories).

I do think HMC was a solid engineering choice, and I am a bit annoyed
that it lost to HBM instead of co-existing with little different
optimization points. But that doesn't excuse the situation.


At the rate we are going, perhaps running Apple's M-chips for routers 
(to the extent possible) is not entirely unthinkable :-).


Mark.

Re: Serious Juniper Hardware EoL Announcements

[Mark Tinka]

On 6/14/22 18:06, JASON BOTHE via NANOG wrote:


Saw this coming a mile away. With chips and technology progressing despite 
ability to manufacture, I’m certain many are going to do this.


All this will do is keep these boxes off the open market, which will 
simply bump up open market prices, with no incentive for the majority of 
folk to buy directly from the OEM.


I suspect supply chain will improve within the next 12 months, but then 
regress and hit a massive crunch from around Q4'23 onward. How long for, 
I can't say...


Mark.

Serious Juniper Hardware EoL Announcements

[Mark Tinka]

So Juniper have gone ahead and announced the EoL of some key devices 
that, IMHO, are nowhere near past their prime:


    - MX204 (to be replaced by the MX304)
    - MX10003 (to be replaced by the MX304)
    - PTX1000 (to be replaced by the PTX10001)

Re: the PTX1000, I know it is a component issue that Juniper have 
mentioned is the reason for EoL'ing this. We bought a fair bit in the 
past 2 years, and technically, there is nothing wrong with them. We are 
going ahead with the PTX10001 as a replacement, because it works 
technically and otherwise.


Having both the MX10003 and MX304 in the same portfolio did not make any 
sense to me, and I did challenge Juniper on this over the past several 
weeks as to what their strategy for both platforms is. I guess we now 
have an answer :-\. Pity - we started buying the MX10003 last year, but 
I have no problem with the MX304 as long as the price continues to work.


The MX204 is pure shocker! Unless the MX304 will come with a 
license-based approach to run at MX204 pricing, that is Juniper shooting 
themselves in the foot.


This chip shortage issue is, I think, being used as a crutch to take the 
p*ss.


Mark.

Re: Upstream bandwidth usage

[Mark Tinka]

On 6/11/22 22:20, Karsten Thomann via NANOG wrote:



Does anyone know the Asian market where they are using E-PON?
After my very short search it seems they provide best effort up to 1G without
any real plans...


When I was in Malaysia years back, we did use ZTE for some EPON 
services. But we retired those and moved to GPON.


Mark.

Re: Upstream bandwidth usage

[Mark Tinka]

On 6/10/22 17:26, Kord Martin wrote:



Especially when you consider that XGSPON and GPON and coexist.


We've seen proposals from Huawei, for example, where OLT shelves can 
support both GPON and XG-PON line cards.


Just not seeing our market going in that direction yet.

Mark.

Re: Aftermarket switches that were manufactured in any sort of quantity?

[Mark Tinka]

On 6/10/22 17:13, Robert Blayzor via NANOG wrote:




Are they "cheap" or is everyone else just "overpriced". ?  Thats the 
real question. Of course it all comes down what you're willing to pay 
for it.


And almost always, you get what you pay for... or as the case may be, 
what you don't pay for.


Mark.

Re: Upstream bandwidth usage

[Mark Tinka]

On 6/10/22 12:01, Jared Mauch wrote:


You would be surprised.  The equipment isn't that expensive in
the grand scheme of things.


Fair point, it's not part of our scope at $day_job.

Most of the greenfields I'm seeing in my region are standard GPON, and 
I'm not hearing of existing deployments being upgraded to XG-PON. But 
then again, perhaps I don't have my hand on the pulse as much as I think 
I should do :-)...


Mark.

Re: Upstream bandwidth usage

[Mark Tinka]

On 6/10/22 10:09, Dave Bell wrote:

We are rolling out XGS-PON everywhere which is 10G symmetric. Just 
because the PON runs at 10G, doesn't mean you need to provision all of 
your customers at 10G.


We have a range of residential packages from 150Mbps up to 1Gbps 
symmetric. The ONT is the same in all situations. There is no SFP 
cost, due to it being a copper port. If we were to offer residential 
packages beyond 1G, a CPE swap would be required, but there is little 
demand for that... yet...


Indeed - XG-PON does not mean you have to deliver 10Gbps to customers. 
It just makes it easier to offer higher bandwidth that is symmetrical, 
at what-should-be a lower cost than Active-E, for more customers at the 
same time.


Mark.

Re: Upstream bandwidth usage

[Mark Tinka]

On 6/10/22 09:52, Vasilenko Eduard via NANOG wrote:


I did believe that it is about the cost of SFP on the CPE/ONT side: 5$ against 
7$ makes a big difference if you multiply by 100.

By the way, there are many deployments of 10G symmetric PON. It was promoted for 
"Enterprise clients".
CPE cost hurts in this case.
But some CPE could be 10GE and another 1GE upstream (10G downstream) on the 
same tree.


Yes, XG-PON.

Most FTTH operator stories I've heard of are still running regular GPON, 
thought.


Seems XG-PON has a high barrier-to-entry for el-cheapo home consumers.

Mark.

Re: Upstream bandwidth usage

[Mark Tinka]

On 6/9/22 21:19, Fletcher Kittredge wrote:



OVBI: Average upstream data usage has nearly tripled since 2018 



People love to share.

It's a pattern we began to see back in 2009, which was the biggest 
motivator for us to deliver FTTH services in select parks and dense 
residences, when Facebook and Youtube were taking off.


Mark.

Re: Aftermarket switches that were manufactured in any sort of quantity?

[Mark Tinka]

On 6/9/22 18:41, Drew Weaver wrote:


Hello,

We had been purchasing some used 48 port 1BaseT switches /w 6x 
QSFP28 ports for around $3000 until about 2021.


In 2021 the aftermarket pricing went from $3,000 each to $15,000 each.

Now these particular switches are selling for $20,000 each (and people 
are still buying them[?]…)


Obviously I cannot pay $20k for a used switch so I am trying to find 
alternatives that perhaps aren’t as rare.


I’m trying to determine whether this pricing is just based on the 
model I am trying to buy or if it is basically every switch from every 
MFG.


Just trying to see if anyone else has had any luck getting any 
hardware at around a fair price lately?


I’m aware of the macro-economic environment, inflation, chip 
shortages, etc.. Just looking for another option.




We are seeing this issue cropping up across the board, both by vendors 
increasing mark-ups due to the chip shortages, as well as the open 
market sellers increasing their own prices on pre-owned hardware due to 
demand.


My advice - take the box while you can, because the next time you ask, 
it will be triple the price.


The biggest benefit from buying on the open market, right now, is 
significantly reduced lead times, if that is something that is important 
to you and your business.


Mark.

Re: Upstream bandwidth usage

[Mark Tinka]

On 6/9/22 22:46, Michael Thomas wrote:



If it's so tiny, why shape it aggressively? Why shouldn't I be able to 
burst to whatever is available at the moment? I would think most users 
would be happy with that.


The issue is generally the underlying last mile access. Even GPON is not 
symmetric, although it offers higher bandwidth than legacy solutions.


Mark.

Re: Upstream bandwidth usage

[Mark Tinka]

On 6/9/22 22:26, Mel Beckman wrote:

With 430 GB versus 32 GV average down versus up usage today, according 
to your article, this is still not a case for symmetrical consumer 
bandwidth. Yes, the upstream usage increased slightly more than the 
downstream usage. But the ratio was still so big that it would take 
decades for them to join. I doubt they ever will. Consumers just don’t 
have that much days up to push yet, and probably never will. 


I don't think download rate will ever equal upload rate, never mind get 
close. But certainly, it has been growing for the past 15 or so years, 
and will continue to rise as the Internet continues to become a place of 
community than it originally has been.





Also, a lot of that Usage can be explained by video conferencing 
during Covid, which has dropped off significantly already.


That certainly has contributed, but I expect that there are more people 
uploading content for day-to-day life than for work.


Mark.

Re: Any sign of supply chain returning to normal?

[Mark Tinka]

On 5/20/22 14:44, Simon Lockhart wrote:


I've heard that some vendors are prematurely EoS/EoL'ing kit as a result of
the silicon shortages - and redesigning kit to use silicon that's easier to
get hold of.


This was my suspicion, because we started using this box in 2017. I 
can't remember when it launched, but I'd imagine a year or two earlier.


We have boxes from 2014 with other vendors still in service and fully 
supported. So we were not going to be bullied into new hardware we 
didn't need.


Mark.

Re: Any sign of supply chain returning to normal?

[Mark Tinka]

On 5/20/22 10:24, Saku Ytti wrote:


That's engineering, understanding what risks and compromises are worth
carrying. If you do it by the book, you're not even needed, just
0-rate AS/PS services to your RFP and the vendor is happy to do it by
the book for you.
And fully agreed, in many cases it makes sense to run boxes to the
ground until they physically stop working. You just need to figure out
how to handle the MTTR well.


We are going to need more 100Gbps data centre switching in other PoP's 
in the coming months, and we like the 7508E for this, even if Arista 
have EoL'ed it. So for those builds, we'll grab them off the open 
market, and cold spare with a full chassis in copy. Way cheaper than 
when we bought them from Arista, even with the ongoing mark-up on the 
pre-owned space.


Arista are also not developing anymore new or maintenance code for the 
supervisor that runs on the 7508E, but we are fine with that because 
this is not an Internet-facing box, and is only doing Layer 2 with 
features that will never change (802.1Q and LACP is about as advanced as 
it gets, for us).


Mark.

Re: MSA’s and network architecture

[Mark Tinka]

On 5/18/22 11:30, Etienne-Victor Depasquale wrote:



Agreed - but wouldn't it be fair to say that, nonetheless, the 
availability of an MSA

supports the development of network architecture?


Of course, it would. After all, we want two sides to be able to speak to 
each other, to create this Internet :-).





With an MSA, there is some limited, common basis for a discussion in
an ecosystem of vendors and network operators.
That should support development of architecture.


It's nice and stable as a technology stabilizes. But when the next thing 
needs to be built (400Gbps today, 800Gbps tomorrow, maybe 1Tbps in 5 
years or less), vendors like to compete on who can come up with the 
first (not the best) solution. Industry then catches up a while later.


Just look at what Cisco tried with the CPAK. While novel, didn't work 
out too well for them, and the customers that bought tons of them. But, 
fair point, CFP2 was still dithering, so...


We've seen the same with Apple, and how ship their devices with 
"unproven" tech. They've been lucky, so far...


Mark.

Re: Any sign of supply chain returning to normal?

[Mark Tinka]

On 5/19/22 18:15, Dave Taht wrote:


So I kind of view recycling routers, with newer software, as a great
way to clean up the present ecosystem. And if you  looked at the first
url I pasted above, with 4x more throughput, and 10x less latency, on
"obsolete", hw.


When I had my battle with Cisco over LDPv6 vs. SR(v6) in 2020, I told 
them that Covid has really changed the landscape, and people (read: 
their customers) no longer have money to spend like they did, for a 
multitude of reasons, not the top of which is a lack. of. money.


I said to them that they need to focus on helping customers answer their 
"why", and not continue with the old model of having sales meetings and 
assigning $$ values against customer names for the year, as if ants 
visit PoP's and chew routers down to smithereens as a matter of course.


People no longer have money to spend on things that don't add value. And 
while routers do add value, how vendors choose to make money from them 
beyond selling the hardware and providing decent support is what erodes 
that value, and customer trust.


Users will delete an app in 5 seconds if they launch it and it doesn't 
do what it claims in a way they perceive as value. Service providers 
will do the exact same thing to vendors that act like disappointing apps 
competing for space on your phone and space in your mind.


Mark.

Re: Any sign of supply chain returning to normal?

[Mark Tinka]

On 5/19/22 15:27, Dave Taht wrote:


As I've been saying for a while, instead of buying new kit, perhaps we
could spend some time on getting better software onto our older kit?
Getting stuff to multiplex better, be more reliable, last longer?


So we've been running Arista's 7508E devices as core switches in data 
centres to support 1Gbps, 10Gbps and 100Gbps internal cabling (purely 
Layer 2, no IP).


We suddenly got told that they are now EoS/EoL some time back (I 
probably should have done a better job tracking this, but I tend to rely 
on vendor notifications for that based on my Cisco/Juniper experience). 
So Arista advised we move to the 7508R3, which doesn't make sense for us 
because we are currently only using 2x slots from the chassis, and 
nowhere close to max'ing out the line card or switch fabric capacity.


It just didn't make sense to us to spend hundreds-of-thousands of $$ for 
no extra benefit in performance or technology (Layer 2 is very simple).


So we decided to keep the the 7508E, even if they are EoL. The box is 
brain-dead, runs fine, shifts bits nice and good, and hums along quietly.


I can't fathom why a box like that has already been EoL'ed. It isn't 
long in the tooth, and still has plenty of bite in it. But, we also need 
to use common sense, and for us, swapping it out just to maintain 
"support" isn't worth the cash. There are options for cold sparing...


Mark.

Re: Any sign of supply chain returning to normal?

[Mark Tinka]

On 5/19/22 16:07, NetEquity Sales wrote:

As someone who works within the "secondary market" for networking 
hardware, there is a ton of demand spilling over into the 
"pre-owned/vendor refurbished" market.


Market prices on pre-owned equipment are rapidly increasing in step 
with increased demand and dwindling supply.


Market prices on 1G - 10G switching products, wireless infrastructure 
devices, etc have been rising precipitously. Even semi "legacy" stuff 
going back 2-3 generations (EOL/EOS) from current gen have doubled, 
tripled, even quadrupled in price.


I've been involved in the hardware business for 20 years and the 
current market landscape is unprecedented.


And this is the case for Transport gear as well, not just IP/MPLS/Ethernet.

Mark.

Re: MSA’s and network architecture

[Mark Tinka]

On 5/18/22 08:39, Saku Ytti wrote:


We could also add an explanation to our proposals for the acronym. :)

In your fair proposal, MSA is related to network architecture as a way
to standardise pluggable (optics). But as always standards are
incomplete, ambiguous and do not guarantee interoperability, so it
will take some time for industry to decide what is 'correct'
interpretation of MSA. Implying when you buy early in life cycle new
optics, you may want to source more carefully and test, compared to
buying later in life cycle sourcing pluggables anywhere with 0 testing
is relatively low risk.


Unless you are truly desperate and/or happy to get stuck in vendor-land, 
always wise to be slightly behind the curve when it comes to optics.


Mark.

Re: MSA’s and network architecture

[Mark Tinka]

On 5/18/22 08:28, Etienne-Victor Depasquale via NANOG wrote:

Just to add a bit of fun to the mix - perhaps multi-source agreement 
was intended :)


Considered that, but that would be obvious - we need optics :-).

Mark.

Re: MSA’s and network architecture

[Mark Tinka]

On 5/18/22 03:55, Martin Hannigan wrote:




All,

Why do MSA’s matter as related to network architecture?


As in "Master Services Agreement"?

Mark.

Re: Juniper MX204 allow oversubscription?

[Mark Tinka]

On 5/16/22 20:27, Randy Carpenter wrote:


Yes... the MX304 is awesome, but the price is going to be crazy. Possibly ~10x 
MX204 if fully loaded.


For me, the MX304 should, really, be an alternative to the MX10003, and 
not an upgrade of the MX204.


Far easier to get more MX204's than even one MX304 :-).



What does the ACX7100 have in terms of FIB/RIB ? Juniper is making it very hard 
as of late to find that information. I'd be curious if the ACX could do brder 
router duties with multiple full BGP feeds (which the MX204 has no problem with 
at all)


The ACX7100 is an x86-based system with 32GB of RAM. It ships with a 
Broadcom J2 chip. Aggregate capacity is 4.8Tbps. FIB is 1 - 2 million 
entries.


There is a bunch of timing in the box, so you can guess whom it's aimed at.

Mark.

Re: Juniper MX204 allow oversubscription?

[Mark Tinka]

On 5/16/22 20:06, Aled Morris via NANOG wrote:




I was hoping the MX304 would be the upgrade, but it seems like 
overkill - 2U, modular with dual processors, up to 96 x 10/25 GbE, 48 
x 40/50/100, 12 x 400 GbE


Probably a bit more expensive than MX204 too.

There's also ACX7100-48L: 48x 10GE/25GE/50GE (SFP56), 6x 400GE (QSFP56-DD)


The ACX71000 is Broadcom.

Mark.

Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)

[Mark Tinka]

On 5/13/22 23:16, Jakob Heitz (jheitz) via NANOG wrote:



'RPKI-tested-only' will store all routes that encounter a 'validation-state' 
test
in the inbound route policy. In that case, when an RPKI server updates a VRP to 
the
router, it can re-run the inbound policy from the stored route and not require a
refresh request to be sent.

This option saves memory if you use a coarse filter in the route-policy before
the validation test. For example, you use a peer-locking filter to drop peer
routes from your customers before they hit the validation-state test. Then
a massive route leak won't chew up soft-reconfiguration memory.

If a validation-state test drops a route and that route is not stored by
soft-reconfiguration, then when the RPKI server updates any VRP, the router
needs to send a route-refresh request.

'RPKI-dropped-only' causes the dropped routes to be stored. This will prevent
the unnecessary route-refreshes described above. It does not prevent all
route-refreshes, but uses significantly less memory than 'RPKI-tested-only'


Jakob, thank you and your team for quickly implementing this. It is most 
appreciated.


I hope someone from the IOS XE team is working on it, too :-).

Mark.

Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)

[Mark Tinka]

On 5/12/22 23:40, Jakob Heitz (jheitz) via NANOG wrote:


To address the risk of somebody exhausting your memory by dumping a ton of 
routes on you,
we added two new options to "soft-reconfiguration inbound" in IOS-XR.

RPKI-dropped-only
Saves a copy of only the routes dropped by an RPKI validation-state test in 
neighbor-in route-policy.

RPKI-tested-only
Saves a copy of only the routes tested in an RPKI validation-state test in 
neighbor-in route-policy.

This was released in 7.3.1 in Feb 2021.

The bug CSCwb17937 was fixed in 7.5.2, just released. Fixed a few other things 
in 7.5.2 also.
Tomoya, apologies that you had a terrible time with it.


Awesome!

Mark.

Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)

[Mark Tinka]

On 5/11/22 18:53, Job Snijders via NANOG wrote:


Hi!

In current versions I think enabling “soft-reconfiguration-inbound 
always” (also described at
https://bgpfilterguide.nlnog.net/guides/reject_invalids/#cisco-ios-xr 
) should be enough.


Make sure to enable it on every EBGP peer you apply ROV to, or just 
all EBGP peers.


This knob slightly increase your own memory consumption, but makes 
your router more “neighbourly”! :-)


Just to add that this is useful on all eBGP speakers based on IOS XR.

It's not required in Junos, because Junos does this implicitly.

A draft RFC we co-authored attempts to offer a solution:

https://www.ietf.org/archive/id/draft-ietf-sidrops-rov-no-rr-01.txt

Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/6/22 11:26, Saku Ytti wrote:


You are always here. You always need to understand your scale and how
much resources you have available, what is possible and what is not.


Of course, if this was the case with the global Internet, we'd have far 
fewer problems making it work well than we do today :-).




Existence or non-existence of configuration toggle to affect this
doesn't make that situation worse or better.
It is not implied to be a tactical short-term fix, it depends and you
must understand what you are doing to determine your position in any
case.



You and I (and many others) have enough experience to know that many 
operations will either underestimate or not understand the technical 
abilities (or disabilities) of their platforms, as long as it works, for 
the most part. Things like FIB programming and FIB scaling are some of 
the least understood and least monitored abilities of any platform, 
amongst others.


And yes, there are platforms where having or not having the hack enabled 
does make a material difference on either side of the pendulum 
(especially in platforms with a small FIB, to begin with).


My point is to remind the OP that if little care was given to this issue 
before it occurred, they should increase their focus on it going 
forward, not in spite of the re-carving hack, but also because of it.


Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/6/22 10:09, Saku Ytti wrote:


This seems like a strange position. The device has 16MB+16MB jtree
segments. The first is IP, the second is filters (Broadly).

OP has 16MB of first used.
OP has <5MB of second used.

What if the platform had originally shipped with a different balance
between filters and IP, and OP would have never hit this problem?

It is easy to see in many scenarios filter growth is negligible toi 0,
IP growth is not. OP would technically have 70% FIB growth left, so
DFZ of about 1.7M, which puts him in the year >2030 (potentially far
beyond, but at least that).

I view the recarving as fixing poorly dimensioned memory use. And had
it shipped with more sensible carving this discussion didn't exist,
and no one would suggest they are in any sort of tactical situation.
Saying there is a problem is logical fallacy, what if your platform
shipped carving of 1 prefix, and rest for filters, and you could do
50M+50M by config toggle. By your logic, this would be a tactical
temporary fix. No, we need to understand what we are doing, what is
the problem, what the solution is, we cannot categorically say this is
a tactical fix.


My response is to be taken in the context of running a (large) network, 
and not the view of a single box.


We have run into issues with platforms that have shipped with FIB's in 
favour of IPv4 and less for IPv6 and MPLS labels. Shifted around, you 
could give up whatever is left for IPv6 and ACL's to give more to IPv4, 
but you then end up losing native IPv6 scalability. And, of course, 
whatever other permutation you may think of that leaves you in a 
babysitting scenario for the protocol(s) assigned to peasantry.


When considered against the backdrop of a (large) network, one has to 
also consider the FIB requirements for the IGP, MPLS label space, e.t.c. 
And not to mention that IPv6 will require more FIB space than IPv4, both 
for the IGP and BGP.


I'd love to say people's ACL's are simple, but who knows what folk 
populate into every RADIUS PPPoE session that they think filters are a 
solution for?


So yes, it is important to understand the limitations (or capabilities) 
of your specific platform, but also look at the overall picture of your 
entire backbone, and get a full understanding of what re-juggling FIB 
memory may mean in the short and long term; of course, bearing in mind 
that for some operators, short-term could also be 10 years or more.


So all I'm saying is if there is a hack like this to help you delay 
moving to newer hardware, go for it. But know your hardware in the 
global context of your network, which will require a lot more attention 
to avoid getting caught out when you least expect it. I'd be remiss if I 
suggested that "implement, move on and forget" is a normal way to treat 
this hack.


Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 21:50, Nick Olsen wrote:

His instance drove us crazy for a bit. The device would learn a route, 
show that it was installed (show routes) but traffic to said prefix 
would bounce net unreachable. We even pushed a static just for S's 
and that still didn't resolve it. It was a single prefix that a 
customer had reported. 


Start with the memory command first and see where that gets you. But 
keep a watchful eye out for this to happen again (as the DFZ grows). 
Eventually your only option will be to filter routes and rely on a 
default or upgrade.


These are the reasons why I was saying that while there may be some 
commands to move FIB allocations around, it's a lot of admin. because 
the DFZ is very dynamic, and FIB programming issues due to lack of slots 
that affect different prefixes in different ways can have you chasing 
your tail for weeks before you figure things out.


I think doing this should be a short-term solution as you make plans to 
get newer hardware. As a long-term strategy, it will tax day-to-day 
operations.


Mark.

Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 21:48, Nehul Patel wrote:


ok mark got it currently we are using the following DPCE Cards

DPCE-R-4XGE-XFP
DPCE-R-Q-4XGE-XFP

When we tried using the command set chassis memory-enhanced route on 
the current Junos version 10.4 it says the command is not supported


so we will need to upgrade the Junos to the newer version in order to 
try above command of it.


Odd, as this said it came alive in Junos 10.4:

https://www.juniper.net/documentation/us/en/software/junos/junos-overview/topics/ref/statement/memory-enhanced-edit-chassis.html

Mark.

Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 17:24, Nehul Patel wrote:


Ok Mark thank you for the suggestion we are currently running on the 
RE-S-1300 i am trying to check if juniper docs as the list of the DPCE 
with the I-Chip but not able to find it yet if you know DPCE model 
number let me know for it


If memory serves, I believe the DPC used I-chip for Layer 3, and EZ-chip 
for Layer 2 (Ethernet framing + MAC look-up).


Someone with a longer memory may need to chime in.

Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 07:34, Saku Ytti wrote:


And like Jordan said, you are out of resources but can extend them
with the command given, which should give you more run rate. You may
want to look in more detail how long you can keep running DPCE until
you're really out.


Certainly an option, but this requires quite a bit of babysitting, 
because as the DFZ oscillates, you can run into issues that send you 
into circles, largely unaware about FIB issues, especially when just a 
subset of routes are affected.


So yes, definitely an option, but the OP will need to watch the line 
cards like a hawk, and be ultra sensitive to debugging regular issues 
vs. FIB-related issues.


Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 05:08, Nehul Patel wrote:

Ok, thank you all for the feedback we are going to start with the 
Junos OS upgrade first on it but have to open the ticket with JTAC 
since currently on the juniper support website they have the Junos 
15.1 is available so not sure we can directly jump from 10.4 to 15.1 
maybe we have to do step by step upgrade on it. Any other suggestions 
will be helpful as well


By the way, the uptime on the Juniper MX chassis was 1589 Days on it.


Curious, what RE are you running?

If you have DPC's still, I'd assume something like the RE-S-1300 or 
RE-S-2000, but not sure.


I ask because I'm not how late the older RE's can go.

Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 04:11, Jordan wrote:


Your line cards (not RE's) are running out of route-storage memory.
As a short-term mitigation, you could try borrowing from segment 1,
normally dedicated to filters,

set chassis memory-enhanced route

but this option may not exist in the version of JunOS you're
running, which as already mentioned is very old.


This feature was introduced in 10.4, so he should have it.

And yes, it's only supported for DPC's (I-chip).

Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/4/22 21:56, Nehul Patel wrote:


Hi NANOG,

We are seeing some strange behavior on our Juniper MX240 Chassis it is 
randomly dropping the routes to the certain destination IP address 
getting the following errors on the MX240 Chassis


If Someone has seen these errors before please suggest how to resolve it


May  4 12:42:00 cr01 newsyslog[44735]: logfile turned over due to 
size>1024K
May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 5 (Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, 
err 5 (Invalid)

May  4 12:42:01   last message repeated 4 times
May  4 12:42:01   fpc0 RT: IPv6:0 - 2600:40fc:1011::/48 (add rt entry 
into jtree failed)
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto 
ipv6,len 48 prefix 2600:40fc:1011::/48 nh 1048576

May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2001:67c:20fc::/48 
(No memory) on FE 0
May  4 12:42:01   fpc0 RT: IPv6:0 - 2001:67c:20fc::/48 (add rt entry 
into jtree failed)
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto 
ipv6,len 48 prefix 2001:67c:20fc::/48 nh 1048576

May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 
2606:2800:e004::/48 (No memory) on FE 0
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 
2a05:3181:::/48 (No memory) on FE 0
May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, 
err 5 (Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 5 (Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 2 (PREFIX DELETE) failed, 
err 5 (Invalid)
May  4 12:42:02   fpc0 RT: Failed prefix add IPv4 - 79.120.22/24 (No 
memory) on FE 0
May  4 12:42:02   fpc0 RT: IPv4:0 - 79.120.22/24 (add rt entry into 
jtree failed)
May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto 
ipv4,len 24 prefix 79.120.22/24 nh 1048583
May  4 12:42:02   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 5 (Invalid)

May  4 12:42:02   fpc0 RT-HAL,rt_msg_handler,540: route process failed

May  4 09:33:17   fpc0 RSMON: Resource Category:jtree 
 Instance:jtree2-seg0 Type:free-pages Available:20 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:17   fpc0 RSMON: Resource Category:jtree 
 Instance:jtree2-seg0 Type:free-dwords Available:1280 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:18   fpc0 RSMON: Resource Category:jtree 
 Instance:jtree3-seg0 Type:free-pages Available:19 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:18   fpc0 RSMON: Resource Category:jtree 
 Instance:jtree3-seg0 Type:free-dwords Available:1216 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree0-seg0 Type:free-pages Available:16 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree0-seg0 Type:free-dwords Available:1024 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree1-seg0 Type:free-pages Available:15 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree1-seg0 Type:free-dwords Available:960 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree2-seg0 Type:free-pages Available:19 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:19   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree2-seg0 Type:free-dwords Available:1216 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:19   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree3-seg0 Type:free-pages Available:17 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:19   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree3-seg0 Type:free-dwords Available:1088 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:19   fpc2 RSMON: Resource Category:jtree 
 Instance:jtree0-seg0 Type:free-pages Available:15 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:19   fpc2 RSMON: Resource Category:jtree 
 Instance:jtree0-seg0 Type:free-dwords Available:960 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:19   fpc2 RSMON: Resource Category:jtree 
 Instance:jtree1-seg0 Type:free-pages Available:15 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:19   fpc2 RSMON: Resource Category:jtree 
 Instance:jtree1-seg0 Type:free-dwords Available:960 is less than LWM 
limit:104857, rsmon_syslog_limit()


Any suggestions will 

Re: Announcement of Experiments

[Mark Tinka]

On 5/1/22 23:59, Alexandros Milolidakis wrote:




If, for any reason, you want to opt out from us using your ASN for our 
experiments, you can do so in the following form before May 9:


https://forms.gle/ZvZaodndPhCqMvR89 



How do you intend to manage excluding tens-of-thousands of ASN's that do 
not want to be part of this experiment?


Mark.

Re: are underwater routers a thing?

[Mark Tinka]

On 3/18/22 06:21, Joel Jaeggli wrote:



The mean depth of the worlds oceans is around ~3700 meters below MSL 
which means most service calls involve deploying to the proximate 
location of the fault, fishing around for a while and then carefully 
re-laying  several kilometers of cable on a splice has been made. 
which typically takes weeks.


And lots, and lots of $$.

Mark.

Re: "Permanent" DST

[Mark Tinka]

On 3/15/22 21:40, Eric Kuhnke wrote:

If Canada doesn't do the same thing at the same time, it'll be a real 
hassle, dealing with a change from -8 to -7 crossing the border 
between BC and WA, for instance. It has to be done consistently 
throughout North America.


Rwanda and Uganda are bordering one another in East Africa - but are 1hr 
apart. It's the oddest thing, considering the sun rises and falls at the 
same time for both.


Mark.

Re: V4 via V6 and IGP routing protocols

[Mark Tinka]

On 4/4/22 15:45, Masataka Ohta wrote:



MPLS with nested labels, which is claimed to scale because
nesting represents route hierarchy, just does not scale because
source hosts are required to provide nested labels, which
means the source hosts have the current most routing table at
destinations, which requires flat routing without hierarchy or on
demand, that is, flow driven, look up of detailed routing tables
of destinations at a distance.


This detail is limited to PE devices (ingress/egress). You don't need to 
carry a BGP table in the P devices (core), as only label swapping is 
required.


Fair point, it is a little heavy for an edge box, but I imagine nearly 
any feature of consequence is going to be high-touch, high-impact, for 
the edge.


Those who have solved this problem with SR can comment, as we don't run it.

We did experiment with IS-IS hierarchy (L1 within the data centre and L2 
between them), but Route Leaking (copying L2 routes into L1) was a 
requirement in order to facilitate FEC creation (/32 for IPv4, /128 for 
IPv6). In the end, having a flat L2 domain was just simpler. It's been 
years, and on today's hardware, we've never ran into an issue carrying 
thousands of IS-IS IPv4/IPv6 routes this way.


Mark.

Re: V4 via V6 and IGP routing protocols

[Mark Tinka]

On 4/4/22 03:06, Dave Taht wrote:


I'm actually not here to start a debate... happy to learn that the v4
over v6 feature I'm
playing with actually exists in another protocol, mainly. I'm
critically dependent on
source specific routing, also, so I am hoping there's an isis or ospf
that can do
what I need, or now that I have more routers with enough memory, switch back
to an ibgp.


Are MPLS or SR too heavy a bat?



yes, and for smaller networks that are interconnecting, bgp can be
too heavyweight also.


I know tons of small networks using Mikrotik to run their BGP backbone. 
Seems to work :-).


Mark.

Re: V4 via V6 and IGP routing protocols

[Mark Tinka]

On 4/4/22 02:55, Dave Taht wrote:


it was how hard adding source specific routing to isis turned out to
be that turned me.
At the time I needed simple means to get ipv6 working on multiple
consumer uplinks.


I suppose the presence of MPLS (and SR) for many operators is probably 
why this use-case was not pushed hard by that community in the IGP.




I'm sad to hear that those two still have to co-exist. I'd given up on
how static
both routing protocols had become in light of my wireless requirements way
back then, also memory requirements. Babel had turned out to be the only
way to get teeny routers to route a few thousand ipv6 routes as well
as ipv4 over wifi mesh networks.



Given a good number of boxes are now based on x86 platforms, control 
plane management of the "classic" IGP's is not a major drama for a few 
thousand entries. One is more likely to run into FIB issues (as we have 
done).


It's possible that at least one operator is using OSPFv3 for both IPv4 
and IPv6, but they haven't come out publicly to announce this :-).


We (and many others) have been running IS-IS for both IP protocols, 
without major issue over the years.




I figured it had made zero penetration outside of that world despite
our efforts to get it into frr, bird, etc.


You're certainly right about that one...

Mark.