Hi Authors, I see that you care about security - I see an authentication header in the proposed packet. The currently adopted way is to use hash. Hash MUST be slow by design (at least a few milliseconds, better tens) or else it would be easy to break it. If the hash is becoming fast (because of hardware improvement) - it must be replaced by a new algorithm that would become slow again (or else there would be no security). It is the reason why "packet design" had always measured hundreds of milliseconds for LSP propagation through small IGP (3-4 hops) because every control plane must calculate hash twice to check/sign routing update. If I understand the purpose of your draft - it is not tolerable to distribute the load information with a sub-second delay. It is what you may get for this protocol too.
It is possible to use symmetric encryption (something like AES) instead of hash. It would greatly improve the latency (to tens of milliseconds), but it would not eliminate the control plane processing time per hop. As we remember a few milliseconds was a tough target for BFD implemented in the control plane. Hence, I believe that you have no choice except to use multi-hop multicast (normal multicast). I understand how scary is the proposition to develop multicast for DC, but looking at the target application - I believe you have no choice, you need to bypass the control plane of intermediate routers for message delivery. The update should go at the same time (through the data plane) for all routers in the domain. Moreover, limiting the multicast scope on the network perimeter (filtering at "limited domain" is so much a trend), you may completely omit authentication - simplify the solution a little bit. Services are in overlay anyway - the untrusted traffic is isolated. Best Regards Eduard Vasilenko Senior Architect Network Algorithm Laboratory Tel: +7(985) 910-1105
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
