Yours is a good operational point, Robert. I wonder what others might think.
Regards, Greg On Mon, 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]> 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]> 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
