Re: *IX administrative and technical frameworks discussion paper.
- Date: Wed, 16 Feb 1994 21:54:44 -0500
] From: Bernhard.Stockman@localhost
] Subject: *IX administrative and technical frameworks discussion paper.
] Date: Sun, 23 Jan 94 13:40:46 +0100
] To the coming EEPG meeting in Amsterdam I have tried to address some
] of the administrative and technical aspects of traffic exchange
] installations. Find a very draft paper below. It shall be clearly
] pointed out that this paper is far from complete. I have tried to use
] experiences from EBONE and PIPEX (Peter Dawe) to create some ideas on
] what can be said about this such installations. It is my hope,
] although very late distributed, that we can initiate an improvement of
] the text at the EEPG meeting.
Sorry for the belated comments... Feel free incorporate or discard these
notes as appropriate.
] 2.1 Management of an IX installation
] Is there a need to have a dedicated legal entity defined taking the
] responsibility and, if so, how is this implemented? If not, where
] will decisions regarding an IX installation as such be taken?
] In general the management of an IX has to guarantee that there is
] - no discrimination between users.
] - no discrimination of traffic.
] - no discrimination between carriers
I think that you'd like to say is:
- no discrimation based upon the ultimate traffic source
- no discrimation based upon the ultimate traffic destination
- no discrimation based upon the immediate traffic source
- no discrimation based upon the immediate traffic destination
] 2.2 General cost principles and models
] The joint venture for the provision of IX service is a not for
] profit organization (?). The opposite may create a situation with
] inflation of low quality IX installation and by that be
] counterproductive to the IX general ambitions of high quality of
] service and manageable routing between ISP's.
Depending on the country of the IX service, It is possible that the
provider of IX service may not legally be a not-for-profit organization
and carry commercial traffic.
You may want to carefully consider including this guideline.
] 2.2.2 Cost recovery models
] There exist today a variety of ideas on how to charge for Internet
] services. Which model(s) should be used for IX connectivity?
] - free of charge
] - voluntary contribution,
] - a levy, flat fixed rate,
] - a levy, flat rate depending on e.g. connected bandwidth?
] Should only serial connections to an IX be allowed? If not, how is
] the problems with LAN connected members solved with respect to
] connected bandwidth equivalence? ...
The question is not "serial connections" as much as it is one of identical
speed connections. Is is possible to recast the question in this form?
] 3.1.5 Mounting of equipment
] As much as possible of the needed IX equipment shall be placed in
] the same rack. The goal is to make the IX installation as compact
] as possible to minimize the risk of interruptions caused by accident
] while working on other equipment housed in the same location.
] The IX equipment shall be installed in 19-inch cabinets which have
] both front and back doors that can be closed. There shall be enough
] air-flow through the cabinet to take away all the heat produced by
] the housed equipment with the doors closed.
19-inch open racks ("relay racks") are very popular in some environments,
as they provide ready access to equipment from all sides and eliminate
circulation as a source of equipment failure.
] 3.1.7 Full operational coverage
] An IX installation shall be operational 24*365, that is it shall
] provide access at 24*365 and provide operational staff at 24*365.
] In case of malfunctioning, repair and/or replacement of
] malfunctioning equipment belonging to the IX installation or, by its
] placement, having impacts on the IX service performance, shall be
] completed within 4 hours.
4 hours is a *long* time...
] 3.3 Routing requirements
] IX common service must support basic routing requirement to be able
] to interoperate with IX member equipment to provide a stable and
] manageable routing environment. This means that an IX route server
] has to support
] - modern policy based routing protocols (today BGP-4 and IDRP),
] - full routing (it must be allowed to default within the IX
] - promptly updates from routing registry databases,
If "it must be allowed to default within the IX installation" means that
the route server is considered an acceptable default route for traffic,
I am not in favor of this.
] 3.5 Other requirements
] There may be situations when there is a need for an optimized basic
] network application service that could be facilitated by the
] installation of certain hard- and software at an IX. Obvious
] examples are TTS server, NTP servers, MBONE servers, DNS servers,
] general network information servers, etc. (See also Aggarval for
] basic network services).
See also GISD...
] 5.1 Requirement on member connectivity and traffic
] - Minimum connection 1 year, resign only on 1/2 year boundaries.
] - Must connect to ALL IX's? (locally/regionally/globally?)
] 5.3 Requirement on member network management and security
] - 24*365 member NOC contact (or disconnection on fault?)
] - Active membership of CERT
Perhaps "must participate in _a_ computer emergency response team" as opposed
to CERT in particular (there are non-CERT security response teams...)