Re: [Idr] [spring] Error Handling for BGP-LS with Segment Routing

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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>