Hi Rob, > we are still questioning the validity of the problem space.
I am not sure where do you draw such impression from ? I think we are all clear that there is problem .. from time to time a bleeding wound appears. However it seems that there is serious concern if the cure proposed is the right one. It appears that the treat-as-withdraw is a piece of duck tape so the rest of the body can sort of function. One could argue that while for some this may even work if the wound is small, imagine such duck tape being applied on 1 meter wound ? Moreover such cut will not recover under duck tape. So to me it seems this is a valid debate if it is better to reset the guy and send him to hospital for proper bandage or stitching while counting on the co-pilot(s) (other BGP sessions) to seamlessly carry the services for customers in the mean time. I think your draft and even the proposed solution is the best for the current BGP4 transport of messages for the cases where some bug is remote and you would likely end-up resetting perhaps all of your upstream sessions .. no doubt. But we have no way of knowing that network wide and I think this one of the problems. Clearly in this case it is better to put even duck tape on the pilots so they can try to land rather then sit and watch the plane crash. Actually real life example: I have discovered last week in one of BGP implementation that BGP conditional advertisement will not kick in till the trigger (check condition) disappears completely from BGP table even if it's next hop is no longer present in global RIB. One could call this a bug, but it is one example where while today I can automatically prefer other exit when session goes down with treat-as-withdraw and keep-the-session-up this will no longer work as trigger route will happily continue to sit in BGP table. And with treat-as-withdraw being default in some cases after new software upgrade your expected BGP behavior will change. I doubt you will find this example described in the release notes too ;) Best, R. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
