Hi Alvaro, > 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. > Ok let's bring this section you partially quoted:
6.1.1 <https://tools.ietf.org/html/rfc7752#section-6.1.1>. Operations Existing BGP operational procedures apply. No new operation procedures are defined in this document. It is noted that the NLRI* information present in this document carries purely application-level data that has no immediate corresponding forwarding state impact. As such, any churn in reachability information has a different impact * than regular BGP updates, which need to change the forwarding state for an entire router. Furthermore, it is anticipated that distribution of this NLRI will be handled by dedicated route reflectors providing a level of isolation and fault containment between different NLRI types. The way I interpret author's intention above was only to say that if you experience a BGP-LS churn on any BGP speaker which is used to carry it the impact will not result in RIB/FIB install - as for such BGP speakers the carried data is of opaque nature as NLRIs are by definition not to be processed by BGP subsystem. 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. > Well I think you are mixing the potential impact of BGP speakers which happen to carry BGP-LS from overall impact to the network which may be fully or partially derived from content of BGP-LS update messages. To the best of my knowledge BGP-LS always assumed that carried data will be used on controllers for something real :) I think we all agree that BGP-LS keeps the original promise and its NLRIs do not interfere with local BGP reachability in the domain. The deployments may be done not in "anticipated" way of using dedicated RRs but I guess this was expected from the beginning too. So now the real bigger question is why one SAFI in BGP would be allowed to carry forwarding information and other SAFI would not ? Say SAFI 4 defined in RFC3107 piggybacks labels (clearly forwarding state) as part of IPv4 NLRI. SAFI 128 adds VPN labels (also pretty much forwarding information). SAFI 71 carries some opaque information which are to be used by controllers. Yet say BFD SAFI may be used in new ways on RS-ers also to modify set of paths used in data plane etc ... bottom line is that every extension we are putting in routing protocols have some impact on forwarding state in the network be it directly installed by routers, by controllers, by route servers or even by applications which decided based on the received info to install new paths to new alternative application level destinations. And as always I must say that I would like to see BGP-LS being removed from BGP4 port 179 and replaced by alternative ways to get IGP information distributed to controllers, but I just do not see how stated in the subject of this thread "Error Handling of BGP" could be used as a good reason for it. Best wishes, Robert 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 >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
