[FRnOG] [TECH] RFC 8093: Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243

2017-02-17 Par sujet Stephane Bortzmeyer 
http://www.bortzmeyer.org/8093.html



Auteur(s) du RFC: J. Snijders (NTT)

Chemin des normes




Ce très court RFC ne fait pas grand'chose : il marque juste comme « à 
ne pas utiliser » ("deprecated") un certain nombre d'attributs BGP.

BGP est le protocole de routage de l'Internet. En permanence, les 
routeurs s'envoient des annonces de routes, annonces portant certains 
attributs (RFC 4271, section 5) qui précisent des caractéristiques de 
la route. La liste de ces attributs figure dans un registre IANA 
. Les attributs cités dans ce RFC sont marqués comme 
officiellement abandonnés. Ce n'est pas qu'ils ne servaient pas : au 
contraire, ils étaient « squattés » en étant annoncés bien qu'ils 
n'aient jamais fait l'objet d'un enregistrement formel. Mieux valait 
donc les marquer dans le registre.

Mais pourquoi est-ce que des gens peuvent utiliser des attributs non 
enregistrés ? Parce qu'il n'y a pas de police de l'Internet (en dépit 
de raccourcis franchements abusifs, par exemple de certains 
journalistes qui écrivent que « l'ICANN est le régulateur de l'Internet 
»). Personne ne peut donner des ordres à tous les routeurs, et les 
faire appliquer.

Bref, il y a des mises en œuvre de BGP qui fabriquent des annonces avec 
des attributs non enregistrés. C'est la vie. Mais c'est ennuyeux car 
cela peut entrainer des collisions avec de nouveaux attributs qui, eux, 
suivent les règles. C'est ainsi que l'attribut LARGE_COMMUNITY du RFC 
8092 avait d'abord reçu la valeur numérique 30 avant qu'on s'aperçoive 
que cette valeur était squattée par un autre attribut (merci, 
Huawei)... Résultat, les routeurs squatteurs, quand ils recevaient des 
annonces avec un attribut LARGE_COMMUNITY ne lui trouvaient pas la 
syntaxe attendue et retiraient donc la route de leur table de routage 
(conformément au RFC 7606). LARGE_COMMUNITY a donc dû aller chercher un 
autre numéro (32), et 30 a été ajouté au registre, pour indiquer « 
territoire dangereux, squatteurs ici ». Le même traitement 
 a été appliqué aux attributs 31, 129, 241, 242 et 243, qui 
étaient également squattés.

Le groupe de travail à l'IETF s'est demandé s'il n'aurait pas mieux 
valu « punir » les squatteurs en allouant délibérement le numéro 
officiel pour un autre attribut que le leur mais cela aurait davantage 
gêné les utilisateurs de l'attribut légitime que les squatteurs, qui 
avaient déjà une base installée.

  


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] TCP mangling et net-neutrality

2017-02-17 Par sujet fdr 
Salut,

J'avais posé une question similaire il y a 4 ans, à propos du champ TOS...

cf. 
http://frnog.frnog.narkive.com/sUEVeaPW/misc-jusqu-ou-va-la-neutralite-du-net

J'ai pas eu vraiment de réponse... et que dire d'un champ "technique" auquel on 
voudrait donner une signification
"fonctionnelle" ?

F.



Le 15/02/2017 à 22:11, Jérôme Nicolle a écrit :
> Plop,
>
> Ce post pour une seule simple question : d'après vous, est ce que
> réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de
> tunneling, est une fonction compatible avec l'obligation de neutralité
> du transporteur de paquets ?
>
> Merci d'avance pour vos réflexions !
>

-- 
  FdRC - Formation - Développement - Recherche - 
Conseils
SARL au capital de 11434 Euros - APE 721Z
15 rue Roger Mompezat 31500 TOULOUSE
Web : www.fdrconseil.fr
Wap : wap.fdrconseil.fr
Email : f...@fdrconseil.com
Tél : +33 (0)5 62 47 56 36
Fax : +33 (0)5 62 47 56 35
Enum : 6.3.6.5.7.4.2.6.5.3.3.e164.fr
FdR Conseil est partenaire d'Etoile Dièse (www.etoilediese.fr) 



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [MISC] Petit DC d'intérieur

2017-02-17 Par sujet Xavier ROCA 
Bonjour,

 

Deux de nos projets  vont nécessiter d’avoir pas mal de serveurs et donc
prendre pas mal d’espace.

On a déjà un local sécurisé pouvant contenir 5 baies mais si on le rempli
c’est la puissance disponible en froid qui n’est pas vraiment a la hauteur.

 

Oui on pourrait mettre cela en DC, mais non ce n’est pas de la prod et vu le
prix m²/mois en DC, ce n’est actuellement pas envisager pour ces phases la.

A moins qu’il y en ait un ici qui brade très très fortement son espace avec
une super connectivité, la on pourra envisager la chose.

 

On a pas mal d’espace a nous et on envisage plusieurs scénarios mais je
sèche complet sur la version qui serait la plus adapté.

On a de l’espace en RdC de type beau garage ou l’on pourrait installer des
microDC  de Vertiv ou un Mini DC du style StarDC Marilyn

Ou une centaine de m² a l’étage sur une structure conçu d’origine pour
accueillir des baies >1500Kg/m².

Qui pourraient éventuellement passer a 200m²

Pour le refroidissement a la rigueur a eau si c’est en circuit fermé.

L’échange Air/air me semble plus approprié sur nos locaux.

Ou la trigénération gaz qui me semble une bonne idée.

D’ailleurs, s’il y a en un qui a un contact chez GRDF pour leur solution.

 

Bref le besoin est petit mais peut évoluer sur quelque chose de plus gros.

Est-il économique judicieux de partir surdimensionné car on fera des
économies lors de l’évolution ?

 

S’il y a des commerciaux dans le sud qui veulent venir faire des offres
merci de passer en MP.

 

Le besoin c’est tout comme un DC mais en version économique et indoor car
difficile dans l’immeuble industriel ou l’on est de faire cela sur nos
places de parking

Energie principale (EDF), Energie secondaire et secours…

Refroidissement avec peut être récupération du chaud pour les bureaux
l’hiver.

Sinon l’été clim des bureaux avec le surplus de puissance froid J

Détection et extinction Incendie.

 

Si vous avez des idées ou du vécu sur le même type de situation je suis
preneur.

 

Merci

 

Xavier

 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] TCP mangling et net-neutrality

2017-02-17 Par sujet Radu-Adrian Feurdean 
On Thu, Feb 16, 2017, at 20:27, Pierre Colombier wrote:
> Bonjour,
> 
> Il y a pas mal de réseaux où l'abus de firewall paranos qui filtrent 
> icmp fait que le path mtu discovery ne marche pas.
> 
> du coup, on a pas vraiment d'autres choix que de réécrire le mss si on 
> veut communiquer avec eux.
> 
> A ce propos, il me manque une boite à outil pour déterminer facilement 
> la "vraie" MTU entre 2 points.
> Je dis la "vraie" parce que ce je voudrais pouvoir détecter un tunnel 
> qui fragmente/recombine et qui induit de brusques variations de latence 
> quand on passe le seuil de fragmentation.

Bonjour,

En tant que "transporteur", ca ne doit pas etre *ton* souci.
Si tu veut que *tes* services communiquent avec un tel reseau, tu es un
des deux bouts de la communication, et tu peux faire ce que tu veux.
Pareil si ce n'est pas *ton reseau* proprement dit, mais que tu es en
charge de son exploitation.
Si tu es un FAI qui vend un service d'acces a internet partant d'un
"site client", tu peux argumenter qu'une telle operation, faite au plus
pres du site client, beneficie au client et est necessaire pour le bon
fonctionnement du service.
Si tu est juste "transporteur" (transit provider, L1/L2 transport
provider), c'est "touche pas au payload".

Et meme pour les cas d'abus de firewall, tu peux toujours dire que le
probleme c'est de l'autre cote. En IPv6 il y a meme RFC4890 qui decrit
ce qui peut et ce qui ne doit pas etre filtre cote ICMP(v6).


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] TCP mangling et net-neutrality

2017-02-17 Par sujet Raphael Jacquot 



On 02/16/2017 11:09 PM, Marc Salvi wrote:

La problématique est que l'internet à été défini sur un MTU IP de 1500.


non, un certain média a une longueur de trame maximale spécfiée à 1500 
octets, nuance


Raphaël


---
Liste de diffusion du FRnOG
http://www.frnog.org/