Hi Robert, On 31 Dec 2012, at 12:49, Robert Raszuk wrote:
> 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. The previous discussions on this subject would seem to indicate that there are a significant number of cases where treat-as-withdraw is seen as the best approach for both non-Internet and Internet deployments. In my view, the presence of other paths for particular NLRI does not necessarily imply that they are equally viable (for both capacity and cost reasons) - so maintaining as much of the network in the normal operating state seems the most beneficial approach. To do this we need some form of NLRI-level error handling. There are undoubtedly some deployment scenarios where it is not what the operator wants for their network - and this may be the case for your example(s). The requirements draft is not asserting that this is a MUST and should be the default -- but rather outlining the motivation for those operators who want error handling that applies to particular NLRI, as well as the tools that are needed to make such error handling deployable. If your preference is to err more on the side of caution (as an operator, or an implementor) then there is no reason that one could not always just have session-level error handling, with Enhanced GR deployed within your network. I think we need to have both approaches - and note the caveats around each. At the moment, the approach of having no choice for operators is concerning to me. Kind regards, r. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
