Re: *IX administrative and technical frameworks discussion paper.

[John Curran <]

--------
] 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
]       installation), 
]     - 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?)

Unrealistic requirement...

] ...
]  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...)

/John