| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1057.1 | don't tie port ID to wire too tightly | PRUNES::GASSMAN | | Tue May 28 1991 14:30 | 15 |
| While not the answer to this question, it's a good chance to bring up
a concept that is reality in managing networks. Relating the circuit
ID, such as DEMSA Circuit 2 to a TO-FROM name, such as LKG-RYO will
cause the manager unneeded headaches. Most communication racks include
a patch panel, and there is a very loose association with the actual
router port with the telephone line. Ports are switched for testing,
problem isolation, and to rotate in spare cards. The primary important
piece of data is that the circuit is still connected... a secondary
piece of data is that the router port ID - or the actual topology - has
been switched. That normally is a 'oh by the way' event - not a
'red alert' event. The old Observer product, and the current NMCC product
both lack this understanding - DECmcc should make sure it is taken into
account.
bill
|
| 1057.2 | Finally the customer decides ... | KETJE::PACCO | | Tue May 28 1991 14:58 | 13 |
| When you have racks of lines... the way of managing networks can and
will most likely be different compared to a customer who has only one
DECrouter in 1 location. We should "suggest" how "we" would like to
organise a network, although also within Digital you will not find 1
single school, bet we have to understand that it is the CUSTOMER
HIMSELF who will decide finally what HE wants, and how HE wil implement
HIS network. I see our mission as to provide the best and most
consitent set of products, but we have to leave the final decision to
the BUYER. Therefore lets be consistent in everything we do, lets not
impose what anyhow is a peanuts detail.
Dominique.
|
| 1057.3 | Will be fixed. | TOOK::ANWARUDDIN | Anwar | Wed May 29 1991 11:24 | 4 |
| re .0
This will be fixed in the next version of the Performance Analyzer.
It will not be a restriction anymore.
|
| 1057.4 | another view | TOOK::MATTHEWS | | Thu May 30 1991 10:41 | 15 |
| I would like to reinforce what Bill said in .2. Customers start off
with hard wired scenarios which match the software engineers view.
However, as they grow and become more sophisticated, they start
using patch panels and redundant hardware. It blows simple nameing
conventions to hell. It also makes customers want functionality
that is baroque and unnecessary if they would just change their
mind set. Yes, I agree that we need to let the customer decide,
BUT WE NEED TO EDUCATE THE CUSTOMER. I am not suggesting a single
dictated solution, I am suggesting a solution that supports the
insertion of maintenance hardware and a willingness to educate
the customer so that we become his ADVISOR. This gives us account
control. Just blindly following the customer's requests is as
foolish as trying to dictate a single wrong headed answer.
wally
|
| 1057.5 | don't underestimate the customer | ENUF::GASSMAN | | Thu May 30 1991 23:33 | 7 |
| Many of our customers ARE educated... patch panels are found at most
large networks I've seen outside the company. Yes, the small site with
a single router will be different - but the management system needs to
handle customers with a higher degree of sophistication that most of us
imagine.
bill
|
| 1057.6 | | EISNCG::OLEARY | | Fri May 31 1991 10:53 | 14 |
|
I agree very much with Bill's comments. We constantly fought with this
kind of problem with Observer and NMCC. Not only does this impact
network monitoring, but also configuration management. By the way,
this scenario is not just limited to patch panel environments. Many
customers will deploy several routers (hardwired), leaving several
ports available/open. Troubleshooting line problems and many other
issues (load balancing, network reconfiguration, etc) can result in
circuits being moved.
You'll find that customers who place any value on their network will
use patch panels and A/B switches.
Mike
|