On December 18, 2018 at 6:23:19 PM, Robert Raszuk ([email protected]) wrote:
Robert: Hi! What comes as #1 question to your points is a comparison of SR controller with regular BGP RR. I think it is safe to assume that error handling on SR controller would be no more aggressive then on RRs. So if there is error the updates may be dropped on the RRs itself, logged and proper NOC alarm generated. IMO this is no different regardless if you use SR with BGP-LS or just plane regular BGP routing. In general, I agree that error handling should be the same regardless of the type of BGP speaker (RR, controller, PE, whatever). So unless your goal here is to point out the deficiency of BGP error handling RFC I am not sure what is so specific to BGP-LS and SR. No, the goal is not to point at any deficiency in the error handling RFC. I just replied to Bruno saying: " I don’t want to rehash the discussion from rfc7606 about the types of approached and whether there should be more or not (or what those could be)…. I’m just pointing out that I think the current approach is not the right one for all applications.” When BGP-LS was defined, it was noted that the "information present in this document carries purely application-level data that has no immediate corresponding forwarding state impact.” I think that SR has a direct impact on the forwarding state of the network. That is what is specific about BGP-LS+SR. To be clear, this thread is about using BGP-LS with applications that have an impact on forwarding/route selection in the network, like SR (Bruno pointed at lsvr and there may be others). It is not about about the error handling approaches (rfc7606) or BGP sessions in general…just that specific application. Thanks for helping me clarify what I mean. Hopefully this makes more sense. ;-) Alvaro.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
