Hi Alvaro, From: Alvaro Retana [mailto:[email protected]] Sent: Wednesday, December 19, 2018 6:58 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf. org; SPRING WG Subject: RE: [spring] Error Handling for BGP-LS with Segment Routing
On December 18, 2018 at 6:10:21 PM, [email protected]<mailto:[email protected]> ([email protected]<mailto:[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”.] Sorry, I meant « more severe” (serious). IOW the impact on the traffic is more important. 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. I think RFC 7606 had primarily IP/Internet routes in mind. Within an AS, different IBGP nodes could have a different opinion regarding the error (especially if the error is on the receiver side) which would create difference in route installation and forwarding inconsistencies such as persistent forwarding loops 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? Table of content of https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext 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. :-) I have already been involved in discussions regarding error handling… I know that the subject is difficult and the opinions are diverse (partly because perspectives are different). One have to choose its battles. I’m happy to share the load with you ;-) --Bruno ... 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. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
