On December 18, 2018 at 6:10:21 PM, [email protected] ( [email protected]) wrote:
Bruno: Hi! .... 1) shouldn’t BGP-LS error handling be also discussed in the LSVR WG? https://tools.ietf.org/html/draft-ietf-lsvr-bgp-spf-03#section-5.7 does not seem to cover this. And this document was under WGLC till yesterday. Yes, good point. I wanted to focus on SR’s use, but I think you’re right to point out that other applications may have the same needs. I think/hope that people on the lsvr list are also on the idr list (at least), so I’ll forward a pointer to this thread just in case. 2) Regarding BGP-LS error handling, it’s not clear to me that “treat as withdraw” would be “safer” than “Attribute Discard”. “Session reset” is safer from an inconsistency standpoint but definitely also “has a direct effect on how traffic is forwarded in the network” and a sever one. [Not sure about the ending “…and a sever one”.] I agree. 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. 3) > The BGP-LS extensions for SR (e.g. draft-ietf-idr-bgp-ls-segment-routing-ext) are, as explained in that draft, used so that "an external component (e.g., a controller) then can collect SR information from across an SR domain and construct the end-to-end path (with its associated SIDs) that need to be applied to an incoming packet to achieve the desired end-to-end forwarding." > To me, that obviously implies that use of BGP-LS for SR has a direct effect on how traffic is forwarded in the network. Does any one see it differently? a) IMHO that implication would be the same without SR, e.g., with RSVP-TE. In fact, the effect on how traffic is forwarded is coming from the PCE computation using partial/incorrect topology information, not how the forwarding is enforced. b) IMHO RFC7606 was more concerned about forwarding loops/black holing –especially for IBGP-, rather than changing the path of the traffic.. (as ““treat as withdraw “ or “sessions reset” would also have “a direct effect on how traffic is forwarded in the network”.) Note that the latter quote is not from RFC760 which uses the terms “no effect on route selection or installation” which is a bit different. Interpreting the difference between “a direct effect on how traffic is forwarded in the network” and “no effect on route selection or installation” is part of the reason this topic is not straight forward. To me, in the BGP-LS+SR context, because the controller *installs* the source route at the ingress router, the two phrases apply. However, other interpretations are possible…which is one of the reasons for this thread. For example, during the rfc7752 discussion, a point was made that the controller (being at the receiving end of the BGP session) would not have to worry about the effects of attribute discard because any loss of information would not have an effect on how it (the controller) selected or installed routes. That argument is not completely flawed (the controller does not use the BGP-LS itself for routing), but (my personal opinion) is that the use of the information (in later programming the network) is what is important. c) Coming back to SR, quickly looking at the ToC, the discard of the SID simply means that the SID can”t be used by the SR source/ingress node. The discard of the SR node attribute means that the node can’t be used to forward a global segment. The use of flex-algo is a bit more touchy as discarding the support for a flex algo will change the routing along this flex algo. But only from the perspective of the BGP-LS consumer, so this would not create forwarding loops/black hole, but only a non expected routing path. Which ToC? You’re right…but only if the information is discarded when it was initially learned. If the error occurs later, when the information was changing for example, there is the possibility that the controller will want to use a node that shouldn’t be used any more….or be calculating not-the-best-routes. Sub-optimal routes are not great and may not matter too much (compared to loops, for example), but some users may have specific business objectives (application performance, for instance) tied to the definition of the paths…it will be important to them. 4) I haven’t checked but it’s not clear to me that IS-IS has a perfect (better?) error handling. If you want to discuss this, please do it in the lsr WG. :-) .... 5) BGP-LS and IS-IS have chosen a different granularity to advertise the LSDB (per link/node vs oer LSP) which very likely will result in a different error handling hence a different vision of the topology. This looks like day 1 design choice for BGP-LS, so difficult to address. Yes… Thanks! Alvaro.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
