Indeed. If you have unreliable registrations, and a registration is lost, then subsequent notifications would be lost as well. The entire service could yield no results. What is the use case?
On the bright side, you can always claim that the service is already deployed and you just happened to lose all registrations. :) T > On Jan 24, 2022, at 9:30 AM, Robert Raszuk <[email protected]> wrote: > > > Are you sure this is operationally a good idea ? > > It's cool when registrations and up notifications will not get lost. But I > would not like to be the one troubleshooting a network when some > registrations or up notifications packets get lost ... It sounds like a > nightmare to me. > > Best, > R. > > On Mon, Jan 24, 2022 at 6:25 PM Greg Mirsky <[email protected] > <mailto:[email protected]>> wrote: > Frankly, I don't see that registrations, at least for the node liveness use > case, require using reliable transport. If the registration is lost, the > faster convergence doesn't work for that node but the existing slower > mechanism still does the job done. I want to note that I'm not proposing > replacing any of the transport options listed in the document but adding > optional unreliable transport. > > Regards, > Greg > > On Mon, Jan 24, 2022 at 9:16 AM Tony Li <[email protected] > <mailto:[email protected]>> wrote: > Hi Greg, > > > > 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. > > > Ok, yes, theoretically, notifications do not strictly require reliable > delivery and thus could be done with another mechanism. However, > registrations MUST be done reliably. Supporting two separate simultaneous > transports seems expensive and painful. > > Tony >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
