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
