On ne peut pas éliminer simplement :
- La pile ATM parce qu'elle est, quoi qu'on en dise, trés complexe et doit
maintenant traiter des flux vidéo dont les contraintes temporelles sont
serrées ( sinon ..... freezes, pixellisation ... et toussa)
- La pile Ip elle aussi ne se limite pas à Tcp/Udp/Icmp . Si on veux
pouvoir faire comme les grands, il faut aussi qu'elle intègre les fonctions
d'OAM par exemple pour ne citer que ça.
- Tu peux aussi te passer de la redondance de carte abonné, et coté
backbone du secours de l'interface réseau et/ou de la redondance de lien.
- Tu peux te passer des alimentations secourues et dupliquées
- Tu peux aussi te contenter d'un manager de réseau en "ligne de commande"
et te passer de SNMP et d'un GUI
- Tu peux oublier le traitement des alarmes, des statistiques , des
logiciels de dignostic matériels
-Tu peux dire que tu vas gérer les upgrades "à la sauvage" sans te
préoccuper des interruptions de service. Ca fait un software management pas
cher :-)
Bref, non, pour ces raisons et pour plein d'autres encore, un DSLAM
d'aujourd'hui n'est pas une machine simple, il suffit de parcourir des
datasheets détaillées des constructeur pour s'en convaincre.
Et pour faire ces machines de A à Z excepté les chips spécialisés, il faut
bien plus que 13 personnes sachant qu'une bonne partie d'entre elles sont
occupées à développer (et là, je le conçoit sans peine) des applications
spécifiques de gestion (bases de données par exemple) le tout avec 1 à 2%
du chiffre d'affaire de la boutique.
Là, pour le coup, tu es sur mon terrain: à partir du moment où tu colles
un OS suffisament ouvert sur une machine, typiquement un linux ou un
*BSD, quel que soit le rôle de la machine, faire le nécessaire pour que
SNMP puisse monitorer/administrer ce que tu veux, c'est simple.
Tout est simple quand il suffit de le dire :-)
Bref, si je comprend bien, en prenant des *systèmes connus*, tout serait
trés simple. En fait, tu rejoins un peu ce que je dis.... non ?
Et allons au bout du raisonnement sur un mode humoristique : prenons des
LIM 72 lignes "déja connues", un backplane "déja connu " lui aussi, des
cartes d'interface en arrière "déja connues", un chassis déja connu mais
re-designé, saupoudrons d'alims du commerce, greffons une management unit
board déja connue , chargons des softs déja connus mais adaptés et .. en
avant la musique.
Tout devient simple à ceci prés que ça ne s'apelle pas concevoir mais
intégrer :-))
Pas seulement. Par exemple, avec le temps, tu te retrouves avec de
nombreuses versions de ton firmware (disons les versions 1 à 5). Un vrai
équipementier doit se poser la question, et donc faire des tests, et
prévoir des procédures, pour tous les changements de version, que ce
soit en upgrade ou en downgrade, ça fait une combinatoire énorme.
Si c'est pour ton réseau propre, tu n'as à prévoir que les passage de n
à n+1: tu peux imposer des procédures d'exploitation plus strictes.
En fait, les softs évoluent de N vers N+1, rarement de N+1 vers N ( échec
d'upgrade ou anomalie du N+1 )
C'est surtout la partie soft que tu ne peux pas simplifier. Or en
matière de réseau, il existe vraiment beaucoup de choses d'ores et déjà
disponibles en soft. Sur ce type d'équipement, ce n'est pas tellement le
hard qui apporte l'innovation fonctionnelle.
En gros je suis d'accord à la réserve prés que c'est le hardware qui
apporte la performance et le soft la richesse fonctionelle. L'un va
rarement sans l'autre sinon on pourrait faire tourner XP sur un 386 :-)
On ne peut pas éliminer simplement :
- La pile ATM parce qu'elle est, quoi qu'on en dise, trés complexe et doit
maintenant traiter des flux vidéo dont les contraintes temporelles sont
serrées ( sinon ..... freezes, pixellisation ... et toussa)
- La pile Ip elle aussi ne se limite pas à Tcp/Udp/Icmp . Si on veux
pouvoir faire comme les grands, il faut aussi qu'elle intègre les fonctions
d'OAM par exemple pour ne citer que ça.
- Tu peux aussi te passer de la redondance de carte abonné, et coté
backbone du secours de l'interface réseau et/ou de la redondance de lien.
- Tu peux te passer des alimentations secourues et dupliquées
- Tu peux aussi te contenter d'un manager de réseau en "ligne de commande"
et te passer de SNMP et d'un GUI
- Tu peux oublier le traitement des alarmes, des statistiques , des
logiciels de dignostic matériels
-Tu peux dire que tu vas gérer les upgrades "à la sauvage" sans te
préoccuper des interruptions de service. Ca fait un software management pas
cher :-)
Bref, non, pour ces raisons et pour plein d'autres encore, un DSLAM
d'aujourd'hui n'est pas une machine simple, il suffit de parcourir des
datasheets détaillées des constructeur pour s'en convaincre.
Et pour faire ces machines de A à Z excepté les chips spécialisés, il faut
bien plus que 13 personnes sachant qu'une bonne partie d'entre elles sont
occupées à développer (et là, je le conçoit sans peine) des applications
spécifiques de gestion (bases de données par exemple) le tout avec 1 à 2%
du chiffre d'affaire de la boutique.
Là, pour le coup, tu es sur mon terrain: à partir du moment où tu colles
un OS suffisament ouvert sur une machine, typiquement un linux ou un
*BSD, quel que soit le rôle de la machine, faire le nécessaire pour que
SNMP puisse monitorer/administrer ce que tu veux, c'est simple.
Tout est simple quand il suffit de le dire :-)
Bref, si je comprend bien, en prenant des *systèmes connus*, tout serait
trés simple. En fait, tu rejoins un peu ce que je dis.... non ?
Et allons au bout du raisonnement sur un mode humoristique : prenons des
LIM 72 lignes "déja connues", un backplane "déja connu " lui aussi, des
cartes d'interface en arrière "déja connues", un chassis déja connu mais
re-designé, saupoudrons d'alims du commerce, greffons une management unit
board déja connue , chargons des softs déja connus mais adaptés et .. en
avant la musique.
Tout devient simple à ceci prés que ça ne s'apelle pas concevoir mais
intégrer :-))
Pas seulement. Par exemple, avec le temps, tu te retrouves avec de
nombreuses versions de ton firmware (disons les versions 1 à 5). Un vrai
équipementier doit se poser la question, et donc faire des tests, et
prévoir des procédures, pour tous les changements de version, que ce
soit en upgrade ou en downgrade, ça fait une combinatoire énorme.
Si c'est pour ton réseau propre, tu n'as à prévoir que les passage de n
à n+1: tu peux imposer des procédures d'exploitation plus strictes.
En fait, les softs évoluent de N vers N+1, rarement de N+1 vers N ( échec
d'upgrade ou anomalie du N+1 )
C'est surtout la partie soft que tu ne peux pas simplifier. Or en
matière de réseau, il existe vraiment beaucoup de choses d'ores et déjà
disponibles en soft. Sur ce type d'équipement, ce n'est pas tellement le
hard qui apporte l'innovation fonctionnelle.
En gros je suis d'accord à la réserve prés que c'est le hardware qui
apporte la performance et le soft la richesse fonctionelle. L'un va
rarement sans l'autre sinon on pourrait faire tourner XP sur un 386 :-)
On ne peut pas éliminer simplement :
- La pile ATM parce qu'elle est, quoi qu'on en dise, trés complexe et doit
maintenant traiter des flux vidéo dont les contraintes temporelles sont
serrées ( sinon ..... freezes, pixellisation ... et toussa)
- La pile Ip elle aussi ne se limite pas à Tcp/Udp/Icmp . Si on veux
pouvoir faire comme les grands, il faut aussi qu'elle intègre les fonctions
d'OAM par exemple pour ne citer que ça.
- Tu peux aussi te passer de la redondance de carte abonné, et coté
backbone du secours de l'interface réseau et/ou de la redondance de lien.
- Tu peux te passer des alimentations secourues et dupliquées
- Tu peux aussi te contenter d'un manager de réseau en "ligne de commande"
et te passer de SNMP et d'un GUI
- Tu peux oublier le traitement des alarmes, des statistiques , des
logiciels de dignostic matériels
-Tu peux dire que tu vas gérer les upgrades "à la sauvage" sans te
préoccuper des interruptions de service. Ca fait un software management pas
cher :-)
Bref, non, pour ces raisons et pour plein d'autres encore, un DSLAM
d'aujourd'hui n'est pas une machine simple, il suffit de parcourir des
datasheets détaillées des constructeur pour s'en convaincre.
Et pour faire ces machines de A à Z excepté les chips spécialisés, il faut
bien plus que 13 personnes sachant qu'une bonne partie d'entre elles sont
occupées à développer (et là, je le conçoit sans peine) des applications
spécifiques de gestion (bases de données par exemple) le tout avec 1 à 2%
du chiffre d'affaire de la boutique.
Là, pour le coup, tu es sur mon terrain: à partir du moment où tu colles
un OS suffisament ouvert sur une machine, typiquement un linux ou un
*BSD, quel que soit le rôle de la machine, faire le nécessaire pour que
SNMP puisse monitorer/administrer ce que tu veux, c'est simple.
Tout est simple quand il suffit de le dire :-)
Bref, si je comprend bien, en prenant des *systèmes connus*, tout serait
trés simple. En fait, tu rejoins un peu ce que je dis.... non ?
Et allons au bout du raisonnement sur un mode humoristique : prenons des
LIM 72 lignes "déja connues", un backplane "déja connu " lui aussi, des
cartes d'interface en arrière "déja connues", un chassis déja connu mais
re-designé, saupoudrons d'alims du commerce, greffons une management unit
board déja connue , chargons des softs déja connus mais adaptés et .. en
avant la musique.
Tout devient simple à ceci prés que ça ne s'apelle pas concevoir mais
intégrer :-))
Pas seulement. Par exemple, avec le temps, tu te retrouves avec de
nombreuses versions de ton firmware (disons les versions 1 à 5). Un vrai
équipementier doit se poser la question, et donc faire des tests, et
prévoir des procédures, pour tous les changements de version, que ce
soit en upgrade ou en downgrade, ça fait une combinatoire énorme.
Si c'est pour ton réseau propre, tu n'as à prévoir que les passage de n
à n+1: tu peux imposer des procédures d'exploitation plus strictes.
En fait, les softs évoluent de N vers N+1, rarement de N+1 vers N ( échec
d'upgrade ou anomalie du N+1 )
C'est surtout la partie soft que tu ne peux pas simplifier. Or en
matière de réseau, il existe vraiment beaucoup de choses d'ores et déjà
disponibles en soft. Sur ce type d'équipement, ce n'est pas tellement le
hard qui apporte l'innovation fonctionnelle.
En gros je suis d'accord à la réserve prés que c'est le hardware qui
apporte la performance et le soft la richesse fonctionelle. L'un va
rarement sans l'autre sinon on pourrait faire tourner XP sur un 386 :-)
Walter wrote:
On ne peut pas éliminer simplement :
- La pile ATM parce qu'elle est, quoi qu'on en dise, trés complexe et doit
maintenant traiter des flux vidéo dont les contraintes temporelles sont
serrées ( sinon ..... freezes, pixellisation ... et toussa)
Faux. Pas dans le contexte free. Le réseau est entièrement ethernet/IP
jusqu'au DSLAM. La partie ATM restante est ridiculement simple. Dans un
modèle plus générique, si tu veux pouvoir transporter la vidéo en ATM,
il te faut effectivement une pile ATM très complexe.- La pile Ip elle aussi ne se limite pas à Tcp/Udp/Icmp . Si on veux
pouvoir faire comme les grands, il faut aussi qu'elle intègre les fonctions
d'OAM par exemple pour ne citer que ça.
La pile IP d'un linux ou d'un *BSD est amplement suffisante. Rien à
implémenter, c'est déjà tout pret.- Tu peux aussi te passer de la redondance de carte abonné, et coté
backbone du secours de l'interface réseau et/ou de la redondance de lien.
Sur les cartes abonnés, tant qu'on ne sait pas brancher une ligne de
cuivre à deux endroits, la redondance ne sert à rien. Pour la sortie, là
aussi, les OSs classiques savent faire.- Tu peux te passer des alimentations secourues et dupliquées
Au pire, oui. Ceci dit, celui-là, il vaut mieux éviter.- Tu peux aussi te contenter d'un manager de réseau en "ligne de commande"
et te passer de SNMP et d'un GUI
Le GUI, clairement, sert peu pour un réseau de cette taille-là. Par
contre CLI+SNMP pour piloter les déploiements automatiquement, c'est pas
compliqué à implémenter (d'autant que ça existe en tout fait).- Tu peux oublier le traitement des alarmes, des statistiques , des
logiciels de dignostic matériels
Pour le diag matériel, dans la mesure où le concepteur et l'exploitant
sont la même entreprise, c'est pas choquant. Pour le reste, là encore,
ça existe déjà en tout pret.-Tu peux dire que tu vas gérer les upgrades "à la sauvage" sans te
préoccuper des interruptions de service. Ca fait un software management pas
cher :-)
Hmmm... Pas forcément gènant ça. D'ailleurs les grands équipementier
ne font pas tellement mieux. Je n'ai jamais manipulé de DSLAM, mais sur
les routeurs et switchs que j'ai croisé, tous constructeurs confondus,
un upgrade firmware, c'est toujours une interruption de service.Bref, non, pour ces raisons et pour plein d'autres encore, un DSLAM
d'aujourd'hui n'est pas une machine simple, il suffit de parcourir des
datasheets détaillées des constructeur pour s'en convaincre.
Encore une fois, on est d'accord sur ce point. Mais un DSLAM
non-générique reste un produit simple. De la même manière qu'un système
d'exploitation dédié à un usage est plus petit qu'un système générique.
Ou, si tu préfères une autre approche: prend un DSLAM du marché, et
regarde ce qui est utilisé par un opérateur donné sur son réseau. Il
utilisera probablement 10-15% des fonctionnalités. Si tu fais la somme
de tous les opérateurs, toutes les fonctionnalités sont sans doute
utiles, mais un seul opérateur n'utilise jamais toutes les
fonctionnalités. Si tu fais l'équipement "sur mesure", tu n'implémentes
que les 10% dont tu as besoin.Et pour faire ces machines de A à Z excepté les chips spécialisés, il faut
bien plus que 13 personnes sachant qu'une bonne partie d'entre elles sont
occupées à développer (et là, je le conçoit sans peine) des applications
spécifiques de gestion (bases de données par exemple) le tout avec 1 à 2%
du chiffre d'affaire de la boutique.
Bof bof. Ça dépend vraiment énormément du mode de fonctionnement de
l'équipe et de la boite.Là, pour le coup, tu es sur mon terrain: à partir du moment où tu colles
un OS suffisament ouvert sur une machine, typiquement un linux ou un
*BSD, quel que soit le rôle de la machine, faire le nécessaire pour que
SNMP puisse monitorer/administrer ce que tu veux, c'est simple.
Tout est simple quand il suffit de le dire :-)
Je ne me contente pas de le dire. Je l'ai fait. Et je t'assure, c'est
simple.Bref, si je comprend bien, en prenant des *systèmes connus*, tout serait
trés simple. En fait, tu rejoins un peu ce que je dis.... non ?
En partie, oui.Et allons au bout du raisonnement sur un mode humoristique : prenons des
LIM 72 lignes "déja connues", un backplane "déja connu " lui aussi, des
cartes d'interface en arrière "déja connues", un chassis déja connu mais
re-designé, saupoudrons d'alims du commerce, greffons une management unit
board déja connue , chargons des softs déja connus mais adaptés et .. en
avant la musique.
Tout devient simple à ceci prés que ça ne s'apelle pas concevoir mais
intégrer :-))
Je ne sais pas trop où tu fixes la limite entre la conception et
l'intégration. Quand on fait un décodeur télé avec dedans:
- un linux pour l'OS
- un chip connu pour la décompression Mpeg
- le design de référence du constructeur du chip pour la carte mère
c'est de l'intégration ou de la conception?
Parce que, clairement, c'est ce que font les fabricants de décodeurs du
marché. (Je connais un peu mieux l'aspect terminal client que l'aspect
DSLAM, j'ai eu l'occasion d'en croiser quelques uns).Pas seulement. Par exemple, avec le temps, tu te retrouves avec de
nombreuses versions de ton firmware (disons les versions 1 à 5). Un vrai
équipementier doit se poser la question, et donc faire des tests, et
prévoir des procédures, pour tous les changements de version, que ce
soit en upgrade ou en downgrade, ça fait une combinatoire énorme.
Si c'est pour ton réseau propre, tu n'as à prévoir que les passage de n
à n+1: tu peux imposer des procédures d'exploitation plus strictes.
En fait, les softs évoluent de N vers N+1, rarement de N+1 vers N ( échec
d'upgrade ou anomalie du N+1 )
J'ai vu le cas plusieurs fois dans ma courte carrière. C'est rare, mais
ça arrive quand même régulièrement. Un équipementier ne peut pas le
négliger, alors que quelqu'un qui fabrique pour ses besoins propres peut
se le permettre.C'est surtout la partie soft que tu ne peux pas simplifier. Or en
matière de réseau, il existe vraiment beaucoup de choses d'ores et déjà
disponibles en soft. Sur ce type d'équipement, ce n'est pas tellement le
hard qui apporte l'innovation fonctionnelle.
En gros je suis d'accord à la réserve prés que c'est le hardware qui
apporte la performance et le soft la richesse fonctionelle. L'un va
rarement sans l'autre sinon on pourrait faire tourner XP sur un 386 :-)
Certes. M'enfin, un équipement réseau, ça ne fait pas tant de choses que
ça. La quantité de CPU sur un équipement réseau est sans comparaison
possible avec celle d'un simple ordinateur de bureau bas de gamme.
Walter <NoSpam@wanadoo.fr> wrote:
On ne peut pas éliminer simplement :
- La pile ATM parce qu'elle est, quoi qu'on en dise, trés complexe et doit
maintenant traiter des flux vidéo dont les contraintes temporelles sont
serrées ( sinon ..... freezes, pixellisation ... et toussa)
Faux. Pas dans le contexte free. Le réseau est entièrement ethernet/IP
jusqu'au DSLAM. La partie ATM restante est ridiculement simple. Dans un
modèle plus générique, si tu veux pouvoir transporter la vidéo en ATM,
il te faut effectivement une pile ATM très complexe.
- La pile Ip elle aussi ne se limite pas à Tcp/Udp/Icmp . Si on veux
pouvoir faire comme les grands, il faut aussi qu'elle intègre les fonctions
d'OAM par exemple pour ne citer que ça.
La pile IP d'un linux ou d'un *BSD est amplement suffisante. Rien à
implémenter, c'est déjà tout pret.
- Tu peux aussi te passer de la redondance de carte abonné, et coté
backbone du secours de l'interface réseau et/ou de la redondance de lien.
Sur les cartes abonnés, tant qu'on ne sait pas brancher une ligne de
cuivre à deux endroits, la redondance ne sert à rien. Pour la sortie, là
aussi, les OSs classiques savent faire.
- Tu peux te passer des alimentations secourues et dupliquées
Au pire, oui. Ceci dit, celui-là, il vaut mieux éviter.
- Tu peux aussi te contenter d'un manager de réseau en "ligne de commande"
et te passer de SNMP et d'un GUI
Le GUI, clairement, sert peu pour un réseau de cette taille-là. Par
contre CLI+SNMP pour piloter les déploiements automatiquement, c'est pas
compliqué à implémenter (d'autant que ça existe en tout fait).
- Tu peux oublier le traitement des alarmes, des statistiques , des
logiciels de dignostic matériels
Pour le diag matériel, dans la mesure où le concepteur et l'exploitant
sont la même entreprise, c'est pas choquant. Pour le reste, là encore,
ça existe déjà en tout pret.
-Tu peux dire que tu vas gérer les upgrades "à la sauvage" sans te
préoccuper des interruptions de service. Ca fait un software management pas
cher :-)
Hmmm... Pas forcément gènant ça. D'ailleurs les grands équipementier
ne font pas tellement mieux. Je n'ai jamais manipulé de DSLAM, mais sur
les routeurs et switchs que j'ai croisé, tous constructeurs confondus,
un upgrade firmware, c'est toujours une interruption de service.
Bref, non, pour ces raisons et pour plein d'autres encore, un DSLAM
d'aujourd'hui n'est pas une machine simple, il suffit de parcourir des
datasheets détaillées des constructeur pour s'en convaincre.
Encore une fois, on est d'accord sur ce point. Mais un DSLAM
non-générique reste un produit simple. De la même manière qu'un système
d'exploitation dédié à un usage est plus petit qu'un système générique.
Ou, si tu préfères une autre approche: prend un DSLAM du marché, et
regarde ce qui est utilisé par un opérateur donné sur son réseau. Il
utilisera probablement 10-15% des fonctionnalités. Si tu fais la somme
de tous les opérateurs, toutes les fonctionnalités sont sans doute
utiles, mais un seul opérateur n'utilise jamais toutes les
fonctionnalités. Si tu fais l'équipement "sur mesure", tu n'implémentes
que les 10% dont tu as besoin.
Et pour faire ces machines de A à Z excepté les chips spécialisés, il faut
bien plus que 13 personnes sachant qu'une bonne partie d'entre elles sont
occupées à développer (et là, je le conçoit sans peine) des applications
spécifiques de gestion (bases de données par exemple) le tout avec 1 à 2%
du chiffre d'affaire de la boutique.
Bof bof. Ça dépend vraiment énormément du mode de fonctionnement de
l'équipe et de la boite.
Là, pour le coup, tu es sur mon terrain: à partir du moment où tu colles
un OS suffisament ouvert sur une machine, typiquement un linux ou un
*BSD, quel que soit le rôle de la machine, faire le nécessaire pour que
SNMP puisse monitorer/administrer ce que tu veux, c'est simple.
Tout est simple quand il suffit de le dire :-)
Je ne me contente pas de le dire. Je l'ai fait. Et je t'assure, c'est
simple.
Bref, si je comprend bien, en prenant des *systèmes connus*, tout serait
trés simple. En fait, tu rejoins un peu ce que je dis.... non ?
En partie, oui.
Et allons au bout du raisonnement sur un mode humoristique : prenons des
LIM 72 lignes "déja connues", un backplane "déja connu " lui aussi, des
cartes d'interface en arrière "déja connues", un chassis déja connu mais
re-designé, saupoudrons d'alims du commerce, greffons une management unit
board déja connue , chargons des softs déja connus mais adaptés et .. en
avant la musique.
Tout devient simple à ceci prés que ça ne s'apelle pas concevoir mais
intégrer :-))
Je ne sais pas trop où tu fixes la limite entre la conception et
l'intégration. Quand on fait un décodeur télé avec dedans:
- un linux pour l'OS
- un chip connu pour la décompression Mpeg
- le design de référence du constructeur du chip pour la carte mère
c'est de l'intégration ou de la conception?
Parce que, clairement, c'est ce que font les fabricants de décodeurs du
marché. (Je connais un peu mieux l'aspect terminal client que l'aspect
DSLAM, j'ai eu l'occasion d'en croiser quelques uns).
Pas seulement. Par exemple, avec le temps, tu te retrouves avec de
nombreuses versions de ton firmware (disons les versions 1 à 5). Un vrai
équipementier doit se poser la question, et donc faire des tests, et
prévoir des procédures, pour tous les changements de version, que ce
soit en upgrade ou en downgrade, ça fait une combinatoire énorme.
Si c'est pour ton réseau propre, tu n'as à prévoir que les passage de n
à n+1: tu peux imposer des procédures d'exploitation plus strictes.
En fait, les softs évoluent de N vers N+1, rarement de N+1 vers N ( échec
d'upgrade ou anomalie du N+1 )
J'ai vu le cas plusieurs fois dans ma courte carrière. C'est rare, mais
ça arrive quand même régulièrement. Un équipementier ne peut pas le
négliger, alors que quelqu'un qui fabrique pour ses besoins propres peut
se le permettre.
C'est surtout la partie soft que tu ne peux pas simplifier. Or en
matière de réseau, il existe vraiment beaucoup de choses d'ores et déjà
disponibles en soft. Sur ce type d'équipement, ce n'est pas tellement le
hard qui apporte l'innovation fonctionnelle.
En gros je suis d'accord à la réserve prés que c'est le hardware qui
apporte la performance et le soft la richesse fonctionelle. L'un va
rarement sans l'autre sinon on pourrait faire tourner XP sur un 386 :-)
Certes. M'enfin, un équipement réseau, ça ne fait pas tant de choses que
ça. La quantité de CPU sur un équipement réseau est sans comparaison
possible avec celle d'un simple ordinateur de bureau bas de gamme.
Walter wrote:
On ne peut pas éliminer simplement :
- La pile ATM parce qu'elle est, quoi qu'on en dise, trés complexe et doit
maintenant traiter des flux vidéo dont les contraintes temporelles sont
serrées ( sinon ..... freezes, pixellisation ... et toussa)
Faux. Pas dans le contexte free. Le réseau est entièrement ethernet/IP
jusqu'au DSLAM. La partie ATM restante est ridiculement simple. Dans un
modèle plus générique, si tu veux pouvoir transporter la vidéo en ATM,
il te faut effectivement une pile ATM très complexe.- La pile Ip elle aussi ne se limite pas à Tcp/Udp/Icmp . Si on veux
pouvoir faire comme les grands, il faut aussi qu'elle intègre les fonctions
d'OAM par exemple pour ne citer que ça.
La pile IP d'un linux ou d'un *BSD est amplement suffisante. Rien à
implémenter, c'est déjà tout pret.- Tu peux aussi te passer de la redondance de carte abonné, et coté
backbone du secours de l'interface réseau et/ou de la redondance de lien.
Sur les cartes abonnés, tant qu'on ne sait pas brancher une ligne de
cuivre à deux endroits, la redondance ne sert à rien. Pour la sortie, là
aussi, les OSs classiques savent faire.- Tu peux te passer des alimentations secourues et dupliquées
Au pire, oui. Ceci dit, celui-là, il vaut mieux éviter.- Tu peux aussi te contenter d'un manager de réseau en "ligne de commande"
et te passer de SNMP et d'un GUI
Le GUI, clairement, sert peu pour un réseau de cette taille-là. Par
contre CLI+SNMP pour piloter les déploiements automatiquement, c'est pas
compliqué à implémenter (d'autant que ça existe en tout fait).- Tu peux oublier le traitement des alarmes, des statistiques , des
logiciels de dignostic matériels
Pour le diag matériel, dans la mesure où le concepteur et l'exploitant
sont la même entreprise, c'est pas choquant. Pour le reste, là encore,
ça existe déjà en tout pret.-Tu peux dire que tu vas gérer les upgrades "à la sauvage" sans te
préoccuper des interruptions de service. Ca fait un software management pas
cher :-)
Hmmm... Pas forcément gènant ça. D'ailleurs les grands équipementier
ne font pas tellement mieux. Je n'ai jamais manipulé de DSLAM, mais sur
les routeurs et switchs que j'ai croisé, tous constructeurs confondus,
un upgrade firmware, c'est toujours une interruption de service.Bref, non, pour ces raisons et pour plein d'autres encore, un DSLAM
d'aujourd'hui n'est pas une machine simple, il suffit de parcourir des
datasheets détaillées des constructeur pour s'en convaincre.
Encore une fois, on est d'accord sur ce point. Mais un DSLAM
non-générique reste un produit simple. De la même manière qu'un système
d'exploitation dédié à un usage est plus petit qu'un système générique.
Ou, si tu préfères une autre approche: prend un DSLAM du marché, et
regarde ce qui est utilisé par un opérateur donné sur son réseau. Il
utilisera probablement 10-15% des fonctionnalités. Si tu fais la somme
de tous les opérateurs, toutes les fonctionnalités sont sans doute
utiles, mais un seul opérateur n'utilise jamais toutes les
fonctionnalités. Si tu fais l'équipement "sur mesure", tu n'implémentes
que les 10% dont tu as besoin.Et pour faire ces machines de A à Z excepté les chips spécialisés, il faut
bien plus que 13 personnes sachant qu'une bonne partie d'entre elles sont
occupées à développer (et là, je le conçoit sans peine) des applications
spécifiques de gestion (bases de données par exemple) le tout avec 1 à 2%
du chiffre d'affaire de la boutique.
Bof bof. Ça dépend vraiment énormément du mode de fonctionnement de
l'équipe et de la boite.Là, pour le coup, tu es sur mon terrain: à partir du moment où tu colles
un OS suffisament ouvert sur une machine, typiquement un linux ou un
*BSD, quel que soit le rôle de la machine, faire le nécessaire pour que
SNMP puisse monitorer/administrer ce que tu veux, c'est simple.
Tout est simple quand il suffit de le dire :-)
Je ne me contente pas de le dire. Je l'ai fait. Et je t'assure, c'est
simple.Bref, si je comprend bien, en prenant des *systèmes connus*, tout serait
trés simple. En fait, tu rejoins un peu ce que je dis.... non ?
En partie, oui.Et allons au bout du raisonnement sur un mode humoristique : prenons des
LIM 72 lignes "déja connues", un backplane "déja connu " lui aussi, des
cartes d'interface en arrière "déja connues", un chassis déja connu mais
re-designé, saupoudrons d'alims du commerce, greffons une management unit
board déja connue , chargons des softs déja connus mais adaptés et .. en
avant la musique.
Tout devient simple à ceci prés que ça ne s'apelle pas concevoir mais
intégrer :-))
Je ne sais pas trop où tu fixes la limite entre la conception et
l'intégration. Quand on fait un décodeur télé avec dedans:
- un linux pour l'OS
- un chip connu pour la décompression Mpeg
- le design de référence du constructeur du chip pour la carte mère
c'est de l'intégration ou de la conception?
Parce que, clairement, c'est ce que font les fabricants de décodeurs du
marché. (Je connais un peu mieux l'aspect terminal client que l'aspect
DSLAM, j'ai eu l'occasion d'en croiser quelques uns).Pas seulement. Par exemple, avec le temps, tu te retrouves avec de
nombreuses versions de ton firmware (disons les versions 1 à 5). Un vrai
équipementier doit se poser la question, et donc faire des tests, et
prévoir des procédures, pour tous les changements de version, que ce
soit en upgrade ou en downgrade, ça fait une combinatoire énorme.
Si c'est pour ton réseau propre, tu n'as à prévoir que les passage de n
à n+1: tu peux imposer des procédures d'exploitation plus strictes.
En fait, les softs évoluent de N vers N+1, rarement de N+1 vers N ( échec
d'upgrade ou anomalie du N+1 )
J'ai vu le cas plusieurs fois dans ma courte carrière. C'est rare, mais
ça arrive quand même régulièrement. Un équipementier ne peut pas le
négliger, alors que quelqu'un qui fabrique pour ses besoins propres peut
se le permettre.C'est surtout la partie soft que tu ne peux pas simplifier. Or en
matière de réseau, il existe vraiment beaucoup de choses d'ores et déjà
disponibles en soft. Sur ce type d'équipement, ce n'est pas tellement le
hard qui apporte l'innovation fonctionnelle.
En gros je suis d'accord à la réserve prés que c'est le hardware qui
apporte la performance et le soft la richesse fonctionelle. L'un va
rarement sans l'autre sinon on pourrait faire tourner XP sur un 386 :-)
Certes. M'enfin, un équipement réseau, ça ne fait pas tant de choses que
ça. La quantité de CPU sur un équipement réseau est sans comparaison
possible avec celle d'un simple ordinateur de bureau bas de gamme.
