[GTER] Uso de IPv4 nos enlaces ponto a ponto

[Douglas Fischer]

Boa tarde Danton!

Quando disse que eu usei endereços de TEST-NET em endereçamento de enlaces,
não disse que seria uma coisa indicada!
Foi uma quebra de protocolo! Uma escolha consciente que afetava
EXCLUSIVAMENTE o ASN que eu estava atendendo.

Não recomendo que se faça isso!
Mas já me quebrou o galho...

Com relação aos pontos "prejudiciais" do texto que você citou:
Pelo que pude entender, isso faz referencia ao teste em qualidade de link
em sí durante momento de produção, e não ao endereçamento IP utilizado.
Não consigo imaginar uma condição(exceto multicast) em que o endereçamento
utilizado seja prejudicial à comunicação de rede.



Em qua, 6 de mar de 2019 às 20:21, Danton Nunes <danton.nunes at inexo.com.br>
escreveu:

> Pessoal,
>
> A RFC6814 de 2012 tem o interessante título "Applicability Statement for
> RFC 2544: Use on Production Networks Considered Harmful"
>
> Acho bom dar uma lida nos argumentos lá levantados, diz a seção 5:
>
> 5.  Advisory on RFC 2544 Methods in Production Networks
>
>     The tests in [RFC2544] were designed to measure the performance of
>     network devices, not of networks, and certainly not production
>     networks carrying user traffic on shared resources.  There will be
>     undesirable consequences when applying these methods outside the
>     isolated test environment.
>
>     One negative consequence stems from reliance on frame loss as an
>     indicator of resource exhaustion in [RFC2544] methods.  In practice,
>     link-layer and physical-layer errors prevent production networks from
>     operating loss-free.  The [RFC2544] methods will not correctly assess
>     Throughput when loss from uncontrolled sources is present.  Frame
>     loss occurring at the SLA levels of some networks could affect every
>     iteration of Throughput testing (when each step includes sufficient
>     packets to experience facility-related loss).  Flawed results waste
>     the time and resources of the testing service user and of the service
>     provider when called to dispute the measurement.  These are
>     additional examples of harm that compliance with this advisory should
>     help to avoid.  See Appendix A for an example.
>
>     The methods described in [RFC2544] are intended to generate traffic
>     that overloads network device resources in order to assess their
>     capacity.  Overload of shared resources would likely be harmful to
>     user traffic performance on a production network.  These tests MUST
>     NOT be used on production networks and as discussed above.  The tests
>     will not produce a reliable or accurate benchmarking result on a
>     production network.
>
>     [RFC2544] methods have never been validated on a network path, even
>     when that path is not part of a production network and carrying no
>     other traffic.  It is unknown whether the tests can be used to
>     measure valid and reliable performance of a multi-device, multi-
>     network path.  It is possible that some of the tests may prove valid
>     in some path scenarios, but that work has not been done or has not
>     been shared with the IETF community.  Thus, such testing is
>     contraindicated by the BMWG.
>
> -- Danton
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação