Subject: (usr-tc) State of the Hub (part 2)(take 2)

From: Jeff Mcadams <[email-masked]>
Date: Mon, 10 Jan 2000 22:42:24 +0000

(cont. from previous message due to message size limitations)

I have received no reports, either positive or negative about the
current state of 3Com support contract rules.  A perusal of relevant
3Com web sites seems to indicate that some progress has been made on
this issue.  If you go to 3Com's web site, to the support section, and
click on 3Com Care service offerings, under Maintenance Services, you'll
see a section entitled "Unbundled Services."  There are sub-sections for
InfoPak telephone support (which is at the time of this writing a broken
link), software updates (all of the latest software upgrades for a year
for one low price...this has promise), Advanced Hardware Replacement
(one contract covers multiple pieces of equipment...new equip. can be
added at a pro-rated cost...this has potential *if* you can pick and
choose which hardware is covered and are not required to cover all your
hardware with the same coverage), and Multi-Year Warranty (also a broken
link at the time of writing).  I have a call in to my great sales-rep
Tom Goodman to get more in depth information about the requirements of
these service offerings (and prices), and will post what information I
get when I get it.

This covers the major outstanding issues that I'm aware of.  Some
further discussion points that have been brought up in the past are
discussed below.

Customer involvement in software development.  I've not seen much
progress here, it seems that most software development on the TC
equipment is still done with very little connection to customer requests
(very cathedral style, with apologies to ESR).  There has been recent
calls for more participation on the beta list for TCS 4.0, I
wholeheartedly encourage this...unfortunately, I haven't had the
opportunity to work with the beta software as I would like.  The beta
list (and I'm under the beta NDA, so I need to be a little careful here
;) seems primarily to be a list for customer feedback to 3Com folks
about the problems we're having.  It would be nice, (and this isn't just
restricted to the beta list) to have the possibility to be part of the
discussion about how things get implemented.  Had more customer input
been solicited, perhaps we wouldn't have ended up with ip pool
aggregation reserving a network and broadcast address unnecessarily, and
similar types of issues...none are critical, but all would make the TC
equipment that much nicer to use.  Another access server type of feature
request to be re-iterated (this has been a long term request)...the
ability to define, by an administrator, what traffic will reset the idle
timer on a port.  The ability to set this via RADIUS would be an added
bonus.

Beaurocracy (and I'm still not sure if I'm spelling this right).  There
seems to have been made a *little* progress in this area, however, this
requires a disclaimer.  I, personally, apparently, have achieved
some...ah...notoriety within 3Com...particularly in the Rolling Meadows
facilities.  As such, I must consider the possibility that I've been
getting contact with people within 3Com that its not common to have
direct customer contact with.  :)  Even this, however, is an
improvement.  Perhaps this gives me the opportunity to be a sort of
liason between 3Com and 3Com's customers.  I fear that I'm sounding
cocky ("I have better contacts than you do"), and assure you that this
isn't my intention.  I'd rather people have direct contact...I have
plenty of things on my plate to do that the time taken up being such a
liason could be used elsewhere, but if I do have better contacts, and
can be useful as a sort of liason, I'm certainly willing to do so for
the betterment of 3Com-customer relations.  :)

Direction.  Specifically with the HiPer Arc card (which is where I'm
particularly knowledgeable within the TC product group), it seems that
3Com is beginning to see the possibilities that the HiPer Arc (at least)
provides beyond just being a dial-up access server.  Again, I have to be
careful here because of the restrictions of the beta NDA...but the
direction of the development seems to be towards making the HiPer Arc a
full-fledged router.  Some things that need to be worked on still:
- 3500 route limit needs to be removed, or at least upped
- more routing protocols...OSPF is a great start...more needed (BGP?)
- OSPF needs to be able to be an ABR
- more control over routing protocols...summarization, redistribution
- route selection still somewhat buggy (Mike Andrews is the expert on
    these problems ;)
And some things that I think are important, but not necessarily to the
point of being *needed*:
- bridging
- QoS...this is apparently a company wide push for 3Com...so I suspect
    its going to be done in a big way
- wider array of interface types
And, just for kicks, a gee-whiz cool feature that the TC lends itself
to:
- packet bus interface...the ability to treat the internal packet of the
    chassis as an interface in the Arc...some cool things can be done
    when this is combined with bridging support above

Even as an access server, the Arc needs to be developed to adapt to
changing times.  As modem and ISDN access becomes less and less
prevelent with the proliferation of broadband, the Arc needs to adapt.
There seems to be some work on this front (again, TCS 4.0 beta), the
bridging support mentioned above is needed for this as many DSL
providers transport DSP and other broadband access methods to ISP via a
bridging over frame-relay or bridging over ATM.  The Arc already has
support for frame and ATM, but can't (from what I've seen) do bridging
over top of it.

I encourage people to submit their own feature requests, etc. to the
list and/or me.  I've been keeping some notes recently for inclusion
into this and future "State of the Hub" messages.  :)  Like I said...I'm
willing to take up the role of liason between 3Com and customers if
that's necessary/desireable, let me know.  I also encourage feedback to
me and to this forum regarding this message and others of mine.  My
philosophy is that I own my words.  I'll take responsibility for what I
say, I encourage forwarding of my messages on to people who would
benefit from my messages, all I ask is that you keep attribution and
contact info in tact so that I can continue to take responsibility for
my words.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Kevin Benton <[email-masked]>
Date: Tue, 11 Jan 2000 01:18:31 +0000

<musing>
If 3Com is listening, as I've mentioned to TG in the past, like to see
3Com come out with a DS3 <-> CT1/PRI interface internal to the hub.  Even
if it'd take up an entire chassis to do it, it'd be really cool to be able
to plug in twin coax on the back of a chassis and be done with it, turning
things up as needed but working on the DS3 level instead of having a mess
of wires running around everywhere from the DS3 interface to the mux, to
the dsx panel to the DSP's, etc.  I don't know if the packet or TDM bus is
designed to handle that much data, however.  I would hope that it is.
Heck, I wouldn't mind having a DS3 card which would interface to the DSP's
across the TDM bus as long as we could get dual PRI or dual T1 DSP's in
place.  Wouldn't that be cool?  :)  It would mean making those LED's a bit
smaller so we could see if span 1 is working vs span 2 on the dual DSP.

Let's see... 28 / 2 = 14.  If the DS3 card took up one one slot, that'd be
15 slots with the DSP's.  Hmmm :)  One for the serving gateway card, and
one for the NMC... :)  Sounds like just the right size to me...  Am I the
only one who thought of this?  :)

The only real disadvantage to doing this is putting so many eggs in one
basket with the chassis being required to be up.  If we were going to do
this, we'd definitely have spare DS3 equipment on hand and thanks to a
very nice arrangement with our telco, they've installed an FLM150 in our
offices where we have DS3 and that's their responsiblity.  As far as dual
DSP's, we'd probably keep a couple on hand along with spare power supplies
and a chassis.

If we were going to put that much $ into a box, though, I'd definitely
want to be able to peel off some of those DS1's into external RJ45's to be
used by other CSU/DSU's so we could put DAP customers, etc. on it.
</musing>

Kevin

E-Mail:  [email-masked]
Web:     http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 11 Jan 2000 01:46:52 +0000

Thus spake Kevin Benton
>I don't know if the packet or TDM bus is designed to handle that much
>data, however.  

Unfortunately, I believe the answer to that is, no, it isn't designed to
handle that much data.  The TDM bus on the chassis has (if I remember
correctly) 512 timeslots...a fairly significant number short of the 672
needed to handle DS3 ingress.  :/

Now, in theory, you could change the clocking in the chassis and crank
the number of timeslots higher, and assuming that 3Com has
overengineered the TDM bus like they did the rest of the chassis, this
might even be feasible.  I'm certainly not a guru when it comes to this
area, so I don't know for sure, but I wouldn't rule it out.  The
downside of this is that you probably would not be able to have any of
the current cards that use the TDM bus in a chassis with cards that
would use the faster TDM bus as they pull their clocking off the bus
itself and the current crop of cards (unless they're also rather
overengineered) couldn't handle the higher speed clocking.  Minor
drawback, and one that I, for one, would certainly be willing to live
with.

There are probably other obstacles to this that I'm not aware of, but
the theory seems pretty simple.  :)

The thought that I had was that you had a master/slave ds3 card
setup...master in one chassis took the ds3 in, split off half the
channels and sent them across the packet bus to the DSP cards, then the
other half of the channels were daisy chained to another chassis where
it connects to another ds3 ingress card and the rest of the channels
were handled.  Shoot, if this were done right, you could then
daisy-chain that over to a third chassis as a full hot-spare
chassis...if one of the first two chassis failed, the calls would get
passed through to the third.

I discussed all of this with Tom Goodman when I was up for Networks3, so
there's at least one person in 3Com who I've talked to about these
ideas.  :)

>only one who thought of this?  :)

Ai...not sure I like the idea of a full ds3 worth of calls terminating
on a gateway card with no hot spare available.  :/

>basket with the chassis being required to be up.  

Particularly the gateway card (HiPer Arc, or whatever a beast that could
handle 600 calls would be called).

>used by other CSU/DSU's so we could put DAP customers, etc. on it.

I've thought that the DSP's should be more general purpuse anyway.  Take
the DSP NAC, and rather than making it a T1/PRI/modem board, use that
mondo processing power there (and with 3 PPC's, its got plenty) give it
a T3 NIC and let it do packet T3.  Then you could also use those PPC's
as a distributed route-cache/forwarding engine, or a compression or
encryption engine.  Certainly it would at least do the framing work that
it currently does with PPP.  Its quite possible that you could even
relegate the HiPer Arc to being a control engine type of thing, where
the routing protocols and such are processed by the Arc, a forwarding
table is built which is then pushed out to the DSP cards which do the
actual forwarding.  This isn't exactly unheard of in other vendor
products as it is.  :)  Most vendors are going to a processing engine,
and one or more forwarding engines...certainly a DSP/Arc equipped
chassis has more than enough processing power available to handle a huge
amount of throughput/pps.  Careful coding should let you have
transparent failover of the Arcs that way too.  You could at least do
this for plain packet forwarding...you'd lose telnet sessions to the
Arc, probably BGP sessions (assuming BGP is available then), but with a
draft I saw the other day...kind of like a soft restart of BGP...you
could prevent that from stopping packet forwarding even.

There are so many possibilities here...I don't think any one person can
conceive of them all...that's one of the reasons that I've been trying
to get people to post some blue-sky thinking here...give 3Com some ideas
of what could be possible.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-