🚀 go-pugleaf

In article <1nal1rINN43r@ensta.ensta.fr> wolf@ensta.ensta.fr
(Christophe Wolfhugel) writes:
>devill@chenas.inria.fr (Yves Devillers):
>> L'ideal dans ce genre de situation serai que RENATER genere au plus vite un
>> ICMP "NETWORK UNREACHABLE",
>
	o oui, un truc simple, standard, pour avertir les programmes
	en cours.

>Et que dans la foulee, un ticket d'inaccessibilite [...]
> [...] (une autre foulee) un traceroute renvoyait des noms [...]
> [...] d'avoir au-moins (au hasard):
> [...]
>*  inria-rocq.renater.fr      <- Ca c'est le CISCO de FT chez le client INRIA
> [...]Une mention du debit des liaisons serait egalement tres informatives
> Comme ca lors d'une panne je peux rapidement savoir si celle-ci est
> du ressort de FT ou du client.

	o hmm, prenons-garde a ne pas passer du centralisme-democratique au
	consumerisme-bureaucratique :-

	Tout est utile certes, mais que nous faut-il au minimum, sur un reseau
	comme RENATER, a vocation "recherche" :

	1) Un signal bien-connu, systematique en cas d'incident. Un message
	ICMP semble suffisant pour commencer. A partir de ce signal
	chaque site pourra implanter sa propre politique de tolerance aux
	pannes et de suivi des incidents.

	2) Une tres bonne qualite du service de base IP, il est preferable de
	mettre toute l'energie disponible sur l'amelioration constante des
	debits et de la fiabilite que sur un mecanisme complexe de diffusion
	des causes d'incidents et de suivi administratif.

	3) Un historique des incidents et quelques statistiques, lisibles par
	ftp, sur un host RENATER.  Cela permettrait d'avoir un suivi des
	incidents, au moins a posteriori, en cas de besoin... 

Guy Vaysseix
CEPH/Genethon