Hi Greg, > I got to think about the benefits of using reliable transport for > notifications. If I understand the use case correctly, the proposed mechanism > allows for a faster convergence but is supplemental to slower BGP > convergence. If that is the case, it seems that if a subscriber to the > service missed a notification, the situation would not be worse than it is > today as that node will catch up with "luckier" neighbors eventually. I think > that a discussion of adding the UDP transport to the list of transport > options is a reasonable proposition and might add a useful model to the > proposed mechanism.
The great benefit of using a reliable transport is that there is no need to build reliability into the protocol. Thus, there is no such thing as a ‘missed’ notification. If a client has registered for a prefix, it will get a notification. Yes, it may be delayed. Moving the transport to a reliable one will not change that. Delay happens for a reason. Those reasons will not change with a different transport. Going to a purely UDP transport and building reliability on top of it would be simply recreating the transport protocol, which would be redundant. That said, if you have a burning need to send UDP packets, it should be noted that QUIC is already providing a reliable transport on top of UDP, so you could opt for that in your implementation. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
