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
