Re: (PM) PM4? (fwd)

MegaZone (megazone@megazone.org)
Fri, 26 Feb 1999 14:47:28 -0800 (PST)

Once upon a time Jeff Haas shaped the electrons to say...
>But as certain people have said, the PM3 is pretty close to the end of
>its effective life for additional features. Multiple IP pools,

I don't believe anyone from Lucent has said this. FLASH isn't even
close to being full on the PM-3 last I knew. I think it is more a marketing
decision - I'm sure RIPv2 could be on the PM-3, along with multiple IP
Pools. But it isn't unusual for featurure differentiation to be done with
different levels of product.

>which were requested ages ago, will only be added to the PM4. VoIP,
>ATM, DS3, etc. will only exist on the PM4. Lucent (not Livingston)

Well, this is a HW issue - the PM-4 has the bandwidth to handle these.

>o You run one copy of comos for each blade. This makes IP pools messy.
> I haven't played with more than a single card yet so I don't know how
> routing aggregation on the chassis works - or if it does.

I understand that ComOS 4.1 addresses this - IP Pools are now global and
centralling managed, so you don't do it per slot.

>o The multiple copies mean you have to manage things on a per card basis.
> While Livingston's java tools are getting better, managing the PM4 is
> still messy. (I like CLI)

Actually I think it is one image per *type* of blade, and each blade
loads it from the management blade.

But they are configured seperately. I think this will converge with time,
as with the IP Pools.

>o Port density isn't quite there yet.

My understanding is that the new 16000 family DSPs are Quad-Modem and have
internal memory, and are only a bit larger than the 16xx's used today.
Tripling density is supposed to happen. Personally I think if they could
get 14 T1 density (instead of 12) it would be perfect - 28 T1s per T3, so
a Tri-T3 card + 6 Interface blades is a full load. And it is nice and
even. Sure, 12 per means 7 blades for 3 T3 - but it doesn't work for
other multiples evenly. It comes down to what will fit I suppose.

1 3T3, 6 14T1, 2 NMC - one slot open, perhaps an Ethernet Switch/Hub blade
or an OC-3 backhaul.

>o Failure is limited to a blade. While this is nice, it also means that
> you have to nail an entire blade to fix a problem. Other
> high-density NAS products separate the interface (DS1/DS3, etc.)
> cards from the modem cards so that you could disable the modems
> and swap them separately. This issue is only going to get nastier
> as port density goes up.
> (I will admit that in the face of DSL and ISDN that this is a specious
> argument.)

With T3 the modems will be on seperate cards - it demuxes to the T1 cards.

>One of the niceties that you get is that you don't do multi-chassis
>stuff (MCPPP, NFAS) etc via ethernet broadcast. But I think you
>are limited to your PM4 chasis - you can't span chassis anyway.
>This is mostly an issue for MCPPP and not NFAS.

I *think* that 4.1 addresses multi-chassis PPP and multi-chassis NFAS - but
I'm not positive.

>Excluding beta stuff that people want, the modem code is the number
>one issue that affects current owners of PM products. There's also

No argument there.

As for redundant management blades my understanding is that 4.1 will bring
cold standby - where you can have two blades in the chassis, and if the
first fails the unit can come back up on the second. But it means losing
the sessions and restarting. And that 4.2 will be hot-standby, where
failover will be transparent.

In the long run I'd love to see load-sharing. Especially with higher
densities, so that you can use both Ethernet interfaces to share the load.

-MZ

-- 
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
"A little nonsense now and then, is relished by the wisest men" 781-788-0130
<URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>