home *** CD-ROM | disk | FTP | other *** search
-
- 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
-
- Generic Internet Service Specification BOF (GISS)
-
- Tony Bates gave a brief overview of a project to try to produce a
- specification for a ``Generic Internet Service Specification''. The
- primary emphasis of this work is at the ``provider/provider'' interface
- rather than at the ``user/provider'' interface. The goal is to make it
- easier for new service providers to understand and interwork with
- various other service providers. The plan is to have a specification
- document that will need to be updated and also highlight areas for
- further study or beyond scope.
-
- A pointer was raised to the FYI16 document which could be augmented
- slightly to cover the ``user/provider'' interface in a less ``U.S.''
- centric approach. However, this is not the primary focus of this
- current specification.
-
- Within the brainstorming session some concerns were raised as to whether
- such a document could mandate items that a service provider should
- provide. The document would raise issues rather than mandating
- anything. It was clear that the document would have to be revised on a
- regular basis. A list of ``first-pass'' items for the specification
- were worked through. Many of the items could easily fall into more than
- one category. The first pass list will cover the following items:
-
-
- o Routing issues
- o Addressing
- o Information Provision
- o Operations
- o Connectivity
- o Engineering and Maintenance
- o Attachment
- o Generic Services Coordination
- o Other networks
- o AUP (more than routing)
- o Remote/Local management
-
-
- Tony Bates will draft the details and circulate to the giss list. those
- wishing to join the giss list they can do so by sending a message to:
- giss-wg-request@ripe.net
-
-
- 1
-
-
-
-
-
- Dan Long, John Curran and David Conrad will act as reviewers. Daniel
- Karrenberg will follow up on the revision of FYI 16.
-
- It was decided not to ask for an IETF working group at this stage. The
- draft will be sent out to the ORAD list and see whether or not there is
- enough interest to create a working group.
-
- MBONE Engineering and Operations BOF (MBONE)
-
- Initially some general issues were discussed.
-
- The Mbone is dangerous, but the applications are very useful. Critical
- problems are largely due to the lack of tools to manage the mbone. The
- meeting discussed different approaches to deal with problems from
- various groups involved in the mbone community such as network
- operators, network subscribers and end users. The Group unanimous
- agreed that it is bad practice of network operators to support mbone
- tunnels into other regions to solve the problem that a subscriber does
- not get satisfactory service from his network operator.
-
- The meeting continued with discussing the new encapsulated tunneling
- code. The original code is a seriously bastardized use of LSRR
- seriously violating the IP specifications. The new mrouted supports
- both, defaulting to encapsulation. There was talk of adding clean
- source routing options to the encapsulating code such that network
- operators could prevent tunnels from moving to fall back infrastructure
- during network failures.
-
- Most of the rest of the meeting was spend drafting a wish list. Some of
- the items are appropriate for a future meeting of this BOF or WG. Other
- items are appropriate for specific groups or projects involved in
- multicast research. The items are ordered by priority within each
- section, but the sections are independent of each other. Throughout the
- discussion it was understood that resources are tight, and in many cases
- we were asking people to contribute effort without additional support.
-
- The wish lists were presented to both the AVT Working Group and to the
- Operational Requirements Area Directorate (ORAD). There was general
- agreement that the items on the wish list are desirable and appropriate,
- but nobody agreed to implement anything.
-
- There were some network operators present at the ORAD meeting who were
- upset that the MBONE BOF did not become a WG or take stronger positions
- regarding operational practices. However most of these people were
- operators who had chosen not to participate in the mbone, and were
- therefore not in control of its impact on their own facilities.
-
- BGP Deployment Working Group (BGPDEPL)
-
- BGP-4 deployment:
-
-
-
- 2
-
-
-
-
-
- ANS/NSFnet/GATED BGP4 is working in a test mode.
-
- CISCO BGP4 is under still under development.
-
- 3-COM Expects to support BGP4 in early this fall.
-
- Wellfleet Anticipates rolling out BGP4 support this
- summer.
-
- Telebit/EuropaNet No current plans for BGP4 deployment.
-
-
-
- CIDR core plans (Alternet, CIX, EBONE, NSFnet/ANS, NSI, PSI, Sprint):
-
-
- 1. Start deploying BGP4 code as soon as possible.
- 2. NSI (or some alternative) starts announcing one aggregated network.
- 3. Additional CIDR core members start aggregating networks.
- 4. Aggregation is officially ``turned on'' in the Internet.
-
-
- The members of the CIDR core are progressing as fast a possible, and are
- well coordinated among themselves.
-
- CIDR configuration issues:
-
- There is some controversy over how to do global configuration checking.
- In addition, how can we one ensure topology matches policy? Merit
- presented a preliminary plan for aggregation support in the NSFnet.
- This support would: 1) accept aggregate routes from a midlevel. or 2)
- would accept site routes from a midlevel, and aggregate on the midlevels
- behalf. A strawman database format proposal is documented in the
- ``Inter-domain Routing Policy Description and Sharing'' Internet-Draft
- (draft-yu-rpd.00.txt).
-
- The representatives from RIPE pointed out that the existing U.S.
- databases, including the current Merit configuration database and the
- above proposal are not adequate to solve international routing problems.
- In particular none can be used to determine which backbone (CIDR core
- member) is the preferred path to a given US network.
-
- The sense of urgency came primarily from concerns about configuration
- management and database issues. Although there is still a lot of work
- to be done to complete the BGP4 roll out, it seems to be a fairly well
- understood problem except for configuration management. CIDR and BGP4
- do impose some new requirements on the databases but the majority of the
- issues center around topology and AUP enforcement. For theses reasons
- it makes sense to broaden the scope of this Working Group from just BGP
- deployment to the wider task of fostering sanity in topology, routing
- policy, and configuration databases.
-
- Network OSI Operations Working Group (NOOP)
-
- 3
-
-
-
-
-
- Russell Blaesing talked about his Transport MIB. He is going to put his
- implementation up for anonymous ftp. He is also going to submit a new
- version of the draft because the old one expired. The Group decided
- that it don't know if the MIB needed variables added or removed, so we
- will put it out there and see how it works.
-
- The Essential Tools for the OSI Internet was discussed. With some minor
- changes it is going to be submitted as a Proposed Standard. The Echo
- draft will also be submitted as a Proposed Standard.
-
- Work is going to be put into trying to keep the OSI infrastructure up
- and operational. Sue Hares is going to have one of her folks put the
- EON tunnel configuration up for anonymous ftp along with information
- about reachable CLNS hosts throughout the Internet. She will also try
- to get someone to start pinging these hosts (via CLNS) and sending mail
- if there are outages.
-
- The deployment of TUBA was discussed. Several implementations are
- available and folks are interested in trying them.
-
- The Group concluded that unless there is more work that needs to be done
- with the deployment of TUBA that NOOP will probably suspend their work
- for a time until they are needed again.
-
- Operational Requirements Area Directorate (ORAD)
-
- The ORAD mandates were discussed. It was agreed that ORAD was a good
- forum for discussing operational related items among network service
- providers. Thus the purpose of the meeting should be to coordinate
- operation of individual networks, not to change each networks own
- policy.
-
- It was pointed out that many Standard RFC's have fallen through the
- cracks towards complete implementation without operational concerns have
- been addressed. John Curran agreed to make sure that at least a
- fraction of new RFC's are read for operational impact. Bill Manning
- agreed to do some reviewing, but cannot do the whole job himself.
-
- There is a need for a working group to deal with a policy routing
- description language, Many of the routing efforts (BRG, SDRIP, etc.,)
- are defining a need for a common routing policy language. ORAD needs to
- form a liaison with the protocol developers to help define such a
- language.
-
- The Operations Area working groups were discussed and a new scheme were
- proposed by Dan Long. The intentions and actual planning according to
- this scheme will continue on email.
-
- The need for a tunnel coordination working group was discussed. There
- are MBONE tunnels which could be removed. TUBA tunnels may in the
- future need coordination for the same reasons. ORAD did not see a need
- for such a working group in the immediate future.
-
-
- 4
-
-
-
-
-
- CIDR issues were treated with respect to timeliness. Will CIDR
- deployment be in time before router hard- and software start to hit the
- limits or has this already begun to happen. There is a need to find
- adequate measurements here. ANS is doing some investigation within this
- area.
-
- Operational Statistics Working Group (OPSTAT)
-
- Reports on current effort in deploying the OPSTAT model (RFC1404)
- revealed some work. RIPE NCC have a tool known as Monster which could
- be adapted but manpower is lacking. Craig Haney from Sprint has written
- a PERL parser. Some other efforts are also known. FARNET had promised
- funding if a site could be found to take on the implementation work.
-
- Some problems with the RFC1404 storage format were reported and it was
- decided to make the necessary changes to fix them.
-
- Henry Clark from OARnet has done some implementation work of the OPSTAT
- client/server draft specification. This was discussed and Ittai
- Hershman/ANS reported on a similar tool implemented by Merit. The
- specification of the client/server query language was extensively
- discussed.
-
- Finally it was agreed that the SNMP/MIB people should be contacted with
- respect to variables needed in statistical gathering but which as of
- today are not present in the Internet Standard MIB.
-
-
-
- 5
-