timbru/draft-sidrops-publication-server-bcp

BCP document for running Publication Server and RRDP/Rsync repo

draft-sidrops-publication-server-bcp's Issues

Clarify the text to make sure that people do not get the impression that CDNs are mandatory

I got feedback at IETF from someone that they interpreted the document as strongly recommending using a CDN. I do not think this is our shared opinion. I think our opinion is that this is a strong option but that the service quality equivalent (or maybe has more grey failures) than a very solid distribution infrastructure.

Recommend rrdp servers to offer gzip/deflate content encoding

write to avoid CDNs that bill for midgress traffic

We should probably warn that the efficiency of RRDP is low with CDNs that charge for midgress traffic.

Recommend that rrdp files are hosted on the same FQDN as RRDP

Based on private conversation and Job Snijders' message https://mailarchive.ietf.org/arch/msg/sidrops/ulvAvJMjmgHfvN23BcmFTEh5ZB4/

On the topic of the publication best practises, it might be good to
strongly recommend that RRDP notification file, delta files, and
snapshot file all be hosted on the same FQDN. But, AFAIK, the RRDP
specification doesn't actually require this.

I would recommend:

• All files for RRDP on the same FQDN
• Follow redirect for notification.xml but NOT for other files

Some CDNs use redirects. I think that these two recommendations allow you to use a CDN that does redirect.

Recommend use of conditional requests (server, client)

Add BCP with regard to load-balancers

Add the best current practices with regard to load-balancers. Specifically:

• Some CDN edge locations may use keep alive.
• Others may time out/reconnect
  • Some CDNs may also use direct connections from nodes for IPv6, but use a proxy for IPv4

When failing over, old connections can stick to the old instance for a long time. For part, or all requests.

Worse, if you use a CDN without one central cache, each edge location may end up having a different view.

Best workaround known:

• Monitor for origin error rate for CDNs that support this (a short list)
• Limit HTTP keepalive to a short window + limited number of requests

Acknowledgements

[ ] Erik Auerswald contributed SHOULD not -> SHOULD NOT

Fix the links to krill-sync/rpki-core/rsyncit

• https://github.com/NLnetLabs/krill-sync
• https://github.com/RIPE-NCC/rpki-core/
• https://github.com/RIPE-NCC/rsyncit

CDNs MUST ignore GET parameters

Recommend that CDNs MUST ignore get parameters.