Operational Requirements Area
Director(s):
o Phill Gross: pgross@nis.ans.net
o Bernhard Stockman: boss@ebone.net
Area Summary reported by Bernhard Stockman/SUNET
BGP Deployment and Application Working Group (BGPDEPL)
The BGPDEPL Working Group met for one session during this IETF chaired
by Matt Mathis.
Of the approximately 5000 networks which are currently reachable, almost
3000 are being announced with EGP2. This situation is pretty bleak.
There is only a short time available to test and deploy BGP-4, and
operators who have not yet deployed BGP-3, will face additional
difficulties phasing out EGP-2. It is desirable for all network
operators to have BGP experience as soon as possible.
Proposed deployment schedule for BGP-4/CIDR:
1/93-3/93 BGP-4 interoperability testing with the ANS testing
facility (See below - all vendors are invited to
participate).
3/93 BGP-4 capable code deployed in the production NSFnet
backbone. Begin testing by propagating some test CIDR
networks through the backbone.
6/93 Start aggregating *production* networks in the backbone.
12/93 Completely phase out all EGP-2 on NSFnet DMZs.
There was some discussion about how this interacts with the new network
assignment rules and schedule specified in RFC1366 and RFC1367. The
first aggregation of production networks (scheduled for June 1993) will
be a flag day for any site requiring full routing tables and not running
BGP-4.
Jordan Becker (ANS) estimated that full route aggregation will reduce
the current routing tables by about 30%, because the old address
assignment policies tended to allocate addresses in blocks anyhow.
cisco's next scheduled code freeze is February 1993, so even if bug-free
BGP-4 code exists today, the earliest it will appear in General
Availability products is October 1993. All customers who need BGP-4
before then must run pre-GA code.
1
Benchmarking Methodology Working Group (BMWG)
The BMWG Group met during one session Chaired by Scott Bradner. The
Group discussed various test frame formats to be used in conjunction
with earlier described network device testing methods as described in
RFC 1242.
Some router vendors have announced inadequate performance metrics with
no consistent way defined for measuring of router performance.
In some network devices, packet forwarding has priority above other
functions which could result in loss of learning tree for bridges and
loss of routing information for routers when the device is loaded.
The Working Group discussed Performance impacts of filter lists.
Various sizes of filter lists have been tested. Some vendors use
hash-search where there is no significant difference in performance
between various sizes of filter lists. When linear search is used the
amount of list entries is proportional to the performance impact.
Finally the Working Group discussed the performance impact of network
management. It was noted that some network products do not update the
SNMP MIB database as often as the hardware updates its counters. There
may thus be a discrepancy between what actually is going on and how this
is reflected in the MIB database.
Network Status Report (NETSTAT) and Network Joint Management Working
Group (NJM)
o Mark Knopper, Merit, Jordan Becker, ANS - NSFnet: Transition T1 ->
T3 ongoing. In October, 18.9 billion packets carried on T3 while
T1 steadily decreasing Number of nets is 7354 whereof 2566 is
foreign networks. OSI traffic 600000 - 1000000 packets per month
during March to October 1992, August and September close to zero
though. T3 not yet ready to forward native CLNP which will be
carried encapsulated in IP. Of NSFnet/ANSnet configured networks
nearly six thousands are actively announced. Around 90 percent of
the networks are using T3 as primary.
- The T3 backbone implementation. Dummy AS support for load
splitting. Up to 5 high speed interfaces per router with 20
kpps in and out per interface and total of 50 kpps per router.
Max performance is 22 Mbps in each direction at 270 byte
packetsize. One way router hop delay = 0.165 msec which gives
cross country router delay (8 hops) of 1.35 msec and a total
cross country delay of 35 msec. A ping version using NTP for
microsecond resolution is used. The dismantling of T1 backbone
lines starts 12 Feb.
- T3 Network Status. Announced corrections in peer behavior.
Engineering changes in internal routing to minimize delay
through T3 net. Map with delay numbers will be available
2
on-line. Deployment underway of encapsulated CLNP across T3,
to enable decommissioning of T1 very soon. Announced
deployment of BGP4 in spring. Invited vendors & operators to
use ANS testnet.
Support for CIDR is planned to start January 93.
o DECNET IV support
- Multiproto routers
- Elimination of upgrade of tail circuits
- Multinet DECNET in TCP encap support
- Throughput on T1 over 200 Kbps
- Gradual transition (if any) to DECNET V
- Native DECNET not considered due to sever loss of performance
depending on DECNET resend algorithm.
o Milo Medin - NASA Science Internet: Awaiting US Department of
Commerce clearance for connection to Russia. NASA portion of
DoE/NASA ATM will ' initially include Langley, Lewis, Goddard,
Ames, JPL.
o Bernhard Stockman - EBONE: Deploying security access scheme in
EBONE routers - combination of kerberos and TACACS. Plan for link
from Stockholm to Bonn.
o Bob Collet - Sprint: Sprint operates three logically distinct IP
networks - domestic US, Atlantic-Europe-Mideast, and Pacific.
Exclusively Cisco routers showed new maps with new perspectives.
o Rich Fisher - GSFC: Satellite data collection & redistribution to
distant research and processing centers.
o Tony Hain - ESnet: ATM project sites Livermore, LBL, LANL, Fermi,
Oak Ridge, SuperCollider All local loops will be fiber.
o Mark Knopper - ERNET: Networking in India Funded by Indian
governmental and UN plan to ``upgrade'' to vsat connections
domestically to overcome shortcomings in domestic infrastructure.
Operational Requirement Area Directorate (ORAD)
The meeting discussed requirements of ORAD and its members. ORAD is
expected to guide other working groups and review documents with special
attention to operational needs. Current Operations Area working group
Chairs could be part of ORAD, but this is not implicitly required. To
make ORAD have broad coverage it will be necessary to invite operators
who have not traditionally participated in IETF meetings.
The meeting concluded that ORAD should not start off too big but
3
initially concentrate on document review and presentation of issues to
working groups.
Finally, the Group discussed various operational aspects of the ongoing
audio and video multicast from IETFs. MBONE routers shall be positioned
as high as possible in the topology. An ORAD operations recommendation
was discussed. A variety of actions to improve the current MBONE
implementation were identified. Tests shall happen before IETFs, which
include announcements of tunneling and requests to be made further in
advance of conferences, and a strict cut-off date after which there will
be no more tunnels.
Operational Statistics Working Group (OPSTAT)
Before this meeting the Internet-Draft on a model for operational
statistics had been submitted as an Informational RFC. This time the
Working Group restarted the work on the client/server based protocol for
retrieval of statistical data. Most of the simple commands where kept
as is while the more complex part were significantly modified. Some
discussion centered around where the selection processing should be
done. For example, should the conditionals be processed on the server
or client? Great economies could be realized by processing the
conditional on the server versus downloading all data to the client and
processing it there. Some discussion revolved around the SQL-ness of
the select command. Consensus not to make it more complex than it
already is. As the storage format in the above mentioned RFC has
changed since the client/server specification was initially drafted it
was necessary to change some part of the client/server command language
to reflect this. Finally the Goals and Milestones section of the OPSTAT
Charter was reviewed and updated.
User Connectivity Problems Working Group (UCP)
The Group had previously defined a data structure that would enable
Trouble Ticket hand-offs between NOCs. Paul Zawada had written an
ASN.1-like description of the fields in this data structure.
Kaj Tesink drafted a document describing how some hand-off fields could
be represented in electronic mail messages. The Group discussed this
and agreed that the document needs to be revised to reflect more of the
previously-defined hand-off fields. The goal is to allow trouble
tickets to be mailed between NOCs both with and without internal trouble
ticket systems. The format should be simple enough to enable humans to
enter the data and yet regular enough to permit parsing. Paul and Kaj
will work on this and get it out as an Internet-Draft. At that time,
several groups agreed to experiment with the exchange format and to
create a template to facilitate manual participation.
The UCP Internet-Draft on a Trouble Ticket Tracking System, originally
written by Matt Mathis, had been discussed and revised heavily by the
Group and it has now expired. Dan Long has volunteered to draft a new
version which reflects the current consensus of the Group. This will
4
also be published as an Internet-Draft.
The Group also discussed the current status of various publicly
available internal Trouble Ticket systems.
5