Hi Acee, Thanks a lot for your comments on the drafts.
You are right that the problem could be caused by the cases you described, and there might be other cases of improper LSA flushing. No matter what the root cause is, the purpose of the problem statement draft is to emphasize the consequence of this kind of problem. Such severe impact is a big headache to the operators, which makes them want more robust protocol in addition to fixing the problematic routers after the problem happens in their network. Your suggestion about rate-limiting the non-self-originated flushing makes sense to me. This can be complementary to the solution in draft-dong-ospf-flush-mitigation. Every router in the domain needs to avoid bringing trouble to the network, also it needs to protect itself from being knocked down due to other's fault. Thus IMO a complete solution needs to cover both the sender side and the receiver side. What do you think? Best regards, Jie From: Acee Lindem (acee) [mailto:[email protected]] Sent: Thursday, November 24, 2016 1:05 AM To: Dongjie (Jimmy) <[email protected]>; [email protected] Cc: Zhangxudong (zhangxudong, VRP) <[email protected]>; [email protected] Subject: Re: [OSPF] Solicit comments to OSPF LSA flushing problem statement and mitigation solution Hi Jie, Sorry we didn't have time to adequately cover the problem and solution in the OSPF WG meeting. As I understand the two use cases which the problem statement is targeted at are: 1. Timer bugs - either in he system or local to the OSPF process that result in the LSA reaching MaxAge in faster than the refresh interval (which some implementations violate and most carrier-class implementations jitter). 2. LS Update packet corruption impacted the LSA Age field but not the rest of the LSA (as this would be detected by the LSA checksum). At the time of the first polling, many felt that these two problems were both due to bugs and we shouldn't modify the protocol to address them. If the WG decides to work on this problem, I would prefer solutions that focus on the OSPF router max aging the LSAs as opposed to every router in the domain. In other words, what I would advocate is rate-limiting the max aging of LSAs with more aggressive rate limiting for LSAs that are not self-originated. We already have some guidance on rate limiting in section 7.4 of RFC 7503. This could be more formalized with the same amount of state preservation as your proposal (https://www.ietf.org/id/draft-dong-ospf-flush-mitigation-00.txt). Thanks, Acee From: OSPF <[email protected]<mailto:[email protected]>> on behalf of Jie Dong <[email protected]<mailto:[email protected]>> Date: Wednesday, November 16, 2016 at 11:57 PM To: OSPF WG List <[email protected]<mailto:[email protected]>> Cc: "Zhangxudong (zhangxudong, VRP)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [OSPF] Solicit comments to OSPF LSA flushing problem statement and mitigation solution Dear all, Due to time limit, at the OSPF meeting we didn't have much time to discuss the two drafts related to OSPF LSA flushing problem. The coauthors would like to encourage comments and discussion about both the problem statement and the mitigation solution. Here is the link to the slides: https://www.ietf.org/proceedings/97/slides/slides-97-ospf-ospf-maxage-flooding-00.pdf Best regards, Jie/Zhenqiang/Xudong
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
