Hi Robert, thank you for clearly stating the question I was implying - Is the reliable distribution of notifications a requirement or recommendation? I think it is the latter. In some scenarios and use cases, for example, when the pub-sub provides the critical service that doesn't have a backup mechanism, using the reliable distribution required.
Regards, Greg On Mon, Jan 24, 2022 at 9:09 AM Robert Raszuk <rob...@raszuk.net> wrote: > Hi Greg, > > Granted you are correct, but only if we consider p2p distribution and low > level triggers. You are also correct if we would just be continue to use > PULSE style. But Tony's proposal is fundamentally different. It does not > send PULSE and forgets. It distributed node liveness both down and up > state. > > So if we however consider a real network with multi hop distribution and > we consider that the use case here is to distribute this extra state on a > pub-sub basis then reliable delivery is a must. > > So why not reuse what's out there already instead of building our own ? > > Thx a lot, > R. > > On Mon, Jan 24, 2022 at 6:01 PM Greg Mirsky <gregimir...@gmail.com> wrote: > >> Hi Tony and Robert, >> thank you for your responses to my notes. I should have been more clear >> in explaining the rationale for adding the UDP transport option to the >> list. Reliability comes at a cost. If the system already has a mechanism >> that guarantees convergence a faster, lightweight though not reliable >> mechanism seems like a reasonable model. >> >> Regards, >> Greg >> >> On Mon, Jan 24, 2022 at 7:38 AM Tony Li <tony...@tony.li> wrote: >> >>> >>> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
