CURRENT_MEETING_REPORT_
Reported by Ken England/ Boston University and Karen Roubicek/ BBN
Connectivity Tool Demonstrations
Metin Feridun made a brief announcement of demonstrations of the
``Connectivity Tool'' that he has been working on. The CT is designed
to present a network detective of modest skills with a suite of analysis
tools and built-in technique to make the problem of tracking down
internet connectivity easier.
Last Meeting
At the last (first) meeting of UCP-WG, Craig Partridge, Elise Gerich,
and Karen Bowers each made presentation of a point of view on modeling
the operations of the Internet. Unfortunately, none of these worthy
thinkers was able to attend the IETF this time, so the host had to make
due with unworthy re-presentations of these ideas and copious reference
to notes from postings that these thinkers had made to the ucp list,
prior to this meeting. Perhaps the original ideas came across anyway.
Craig Partridge's Model
Craig Partridge's model was reviewed. Karen Roubicek coined the term
``UCP Central'' to denote the national ``center'' with an 800 number,
and this term was extended to include elements of following models.
Craig identified at least four elements of an architecture:
o UCP Central (the 800 number service)
o Site Entity
o A User (of this system under study)
o A Regional Entity (tentatively put forth for study)
Elise Gerich's Model
Elise identified some structure within the ``UCP Central Entity'' [note
that terminology is deliberately vague, in order to avoid excessive
connotative baggage -kwe]
In addition to recognizing Site and User Entities, like Craig's model,
Elise put some structure to the UCP Central Entity, by postulating:
o National Center (we called it UCP Central)
o (Six) Regional Centers
1
and corresponding structure.
Karen Bowers' Model
Unfortunately for us, Karen has left the Internet community and was
unable to write up a description of her model. The host was inadequate
to the task of recalling her model, but members of the audience who had
been impressed by her words last time recalled that Karen had allowed a
richer connectivity from Site to Site or from Regional to Regional in
her model.
Synthesis
Some common points arise from these models and beg some questions:
We must define a User Entity and consider how these Users, who may be
end-users or may be lower level representatives of end-users, such as
campus NOCniks; enter this system, how they interact with this system we
are defining, and how their problems are staged and addressed.
Assumptions of available tools and skills depends on who we assume the
User is.
We have to consider centralized (UCP Central) versus decentralized
(Site/Regional Entity) issues, and clearly delineate responsibilities
and interactions. We must consider the authority of the UCP Central and
how it is derived.
We must consider the nature of the Site and Regional Entities; are they
Network Operations Centers, or Network Information Centers, or both, or
neither? Let us call these entities Network Service Centers (NSCs) for
the moment, and withhold evaluation of what they really are.
General Discussion
Who is it that owns these facilities? Who are the players; the
campuses, the regionals, the backbones, the commercial service
providers, etc?
How will these entities; these Users and NSCs; be coordinated?
How do we resolve problems that the participants in this model cannot
solve, such as host interoperability problems? Are there others that
must get involved to solve these sorts of problems?
We need a means of filtering out chronic problems, ones that have been
identified, but are not yet solved, or are unsolvable by our system.
2
Trouble Ticket Systems
Trouble ticket systems came up as something that seems to be an integral
part of the solution of UCPs.
Matt Mathis commented that we need a protocol for managing ownership of
trouble tickets, that we need some centralization for dealing with
problems (UCP Central), but we must have filters so that UCP Central
does not have to deal with too many routine problems. We also need to
make sure that tickets don't ``evaporate'' and we could use a meta-UCP
protocol for evaluating how well individual UCPs were handled by the
system. We also need to discriminate equipment failures from
infrastructure or engineering problems, which this system may not be
able to handle. We also have to consider how the User is notified of
progress on his Ticket.
Further Synthesis
What can we glean from what everyone has said so far?
1. We need to put a boundary around the problem; around the system we
are trying to define.
2. ``Users'' are outside this system boundary. ``Network Service
Centers'' are entities that are within the boundary of our system
and our model.
3. Users need a ``protocol'' or procedure for how they interact with
this system. Let us call this the P1 protocol; User-to-NSC.
4. NSCs need a ``protocol'' or procedure for how they interact among
themselves. Let us call this the P2 protocol; NSC-to-NSC.
5. At a minimum, we need to define what a ``User'' is, what an ``NSC''
is, and what the P1 and P2 protocols are. Work in this direction
will undoubted lead to further modeling requirements.
We need to consider at least these steps in the process:
o diagnosis of the problem
o the resolution process
o closure
o connectivity versus interoperability problems
Someone described the AT&T trouble ticket model, and noted that the
person in the system that was ``closest'' to the end-user was
responsible for updating the user on progress and for closure, but that
the ticket database was centralized and centrally managed.
There was discussion of the P2 protocol and how it related to lines of
authority and contractual relationships. There was a feeling that an
instatiation of a P2 link between two NSCs was an agreement to work
together in a certain way on UCPs.
The handling of a ticket between NSCs is bi-lateral. Should NSCs be
certified to generate tickets? Should they be certified to accept
3
tickets? Would one level of NSC be a ``generate only'' NSC while other
NSCs could be ``accept/generate'' NSCs?
Every contact from a User (via the P1 protocol) must be logged and
tracked by this system. The system must be conservative, it must not
lose track of any calls (tickets) and it must reach closure on each
ticket. What constitutes closure? All closures must be reported back
to the User (via P1) and the User must be able to get status reports as
the User requires (again via P1).
What are the minimum capabilities of an NSC? They should include:
o contact points (phone numbers, e-mail addresses, ...)
o hours of operation (when can the NSC be activated?)
o what do they do (ie, level of functionality)
o referrals (where do they refer UCPs via P2?)
o closure (they must be able to close open tickets via P1)
el Chiappa jnc@PTT.LCS.MIT.EDU
Steve Deering deering@pescadero.stanford.edu
Dave Forster
Richard Fox sytek!rfox@sun.com
Karen Frisa karen@kinetics.com
Steve Hubert hubert@cac.washington.edu
Van Jacobson van@helios.ee.lbl.gov
Stev Knowles stev@ftp.com
Yoni Malachi
yoni@cs.stanford.edu
Keith McCloghrie
sytek!kzm@hplabs.HP.COM
Leo J. McLauglin III ljm@twg.com
Jeff Mogul
mogul@decwrl.dec.com
John Moy
jmoy@proteon.com
Mike Patton
MAP@LCS.MIT.EDU
Drew Perkins
ddp@andrew.cmu.edu
Stephanie Price
cmcvax!price@hub.ucsb.edu
Michael
Reilly
reilly@nsl.dec.com
Greg
Staz
satz@cisco.com
Tim
Seaver tas@mcnc.org
Frank Slaughter fgs@shiva.com
Richard Smith smiddy@pluto.dss.com
Brad
Strand bstrand@cray.com
Cal
Thixton cthixton@next.com
John
Veizades
What is the role of UCP Central on routine UCPs? Should UCP Central get
copies of all tickets from all NSCs? Should UCP Central be primarily
mail based, as far as tracking tickets?
What is the nature of a ticket? The ticket must be structured such that
it leads to a proper analysis of the problem. This implies a certain
minimum of information. Can tickets be structured to include fields, as
in a database? Guy Almes made the point that in talking about a
distributed trouble ticket system, we are essentially trying to create a
distributed database system. Perhaps we can glean some insight on how
to structure P2 and create a coherent distributed trouble ticket system
from distributed database design? Can we create a trouble ticket
grammar? Should the trouble tickets be textual, so that they can be
moved via mail, not requiring a database query language or other special
protocol?
Educating End Users
Martyne Halgren of Cornell contributed a memo to the ucp list prior to
this meeting, addressing issues regarding educating end-users, and
described NETHELP and NETLEARN tools to accomplish the education
process. Unfortunately, the entire session needed to be devoted to a
discussion of the larger picture, and there was no time to delve into
the end-user part of the model. Martyne's contribution was held for
follow-up discussion at a later time.
4
Session Closure
The host outlined a minimum of three things that need work:
o NSC Requirements
o the P1 protocol
o the P2 protocol
The host twisted arms:
Matt Mathis agreed to work on NSC requirements, the P1, and the P2
protocols. Guy Almes agreed to work with Matt on the P2 issue. Dan
Jordt also indicated willingness to contribute.
Follow-up discussion and postings of work in progress will be to the ucp
list ``ucp[-request]@nic.near.net''.
5
ATTENDEES
Guy Almes almes@rice.ed
Glee Cady ghc@merit.edu
Tom Easterday tom@nisca.ircc.ohio-state.edu
Kent England kwe@bu.edu
Metin Feridun mferidun@bbn.com
Martyne Hallgren martyne@tcgould.tn.cornell.edu
Gene Hastings hastings@psc.edu
Tom Holodnik tjh@andrew.cmu.edu
Wendy Huntoon huntoon@a.psc.edu
Dan Jordt danj@cac.washington.edu
Marilyn Martin martin@cdnnet.ca
Matt Mathis mathis@pele.psc.edu
Berlin Moore prepnet@andrew.cmu.edu
Donald Morris morris@ucar.edu
Dave O'leary oleary@noc.sura.net
Lee Oattes oattes@utcs.utoronto.ca
Mike Patton map@lcs.mit.edu
Marc-Andre Pepin pepin@crim.ca
Paul Pomes paul-pomes@uiuc.edu
Karen Roubicek roubicek@nnsc.nsf.net
Jim Sheridan jsherida@ibm.com
Dana Sitzler dds@merit.edu
Pat Smith psmith@merit.edu
Mary Stahl stahl@nisc.sri.com
Louis Steinberg louiss@ibm.com
Allen Sturtevant sturtevant@ccc.nmfecc.gov
Edward Vielmetti emv@math.lsa.umich.edu
Carol Ward cward@spot.colorado.edu
Aileen Yuan aileen@gateway.mitre.org
6