[Lsr] FW: New Version Notification for draft-ketant-lsr-ospf-bfd-strict-mode-00.txt
Hello All, We've posted a draft for BFD operations for OSPF. Would appreciate review and feedback from the LSR and BFD WGs. rfc6213 addresses similar problem for IS-IS. Thanks, Ketan -Original Message- From: internet-dra...@ietf.org Sent: 05 March 2019 00:00 To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) Subject: New Version Notification for draft-ketant-lsr-ospf-bfd-strict-mode-00.txt A new version of I-D, draft-ketant-lsr-ospf-bfd-strict-mode-00.txt has been successfully submitted by Ketan Talaulikar and posted to the IETF repository. Name: draft-ketant-lsr-ospf-bfd-strict-mode Revision: 00 Title: OSPF BFD Strict-Mode Document date: 2019-03-04 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-ketant-lsr-ospf-bfd-strict-mode-00.txt Status: https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/ Htmlized: https://tools.ietf.org/html/draft-ketant-lsr-ospf-bfd-strict-mode-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode Abstract: This document specifies the extensions to OSPF that enables a router and its neighbor to signal their intention to use Bidirectional Forwarding Detection (BFD) for their adjacency using link-local advertisement between them. The signaling of this BFD enablement, allows the router to block and not allow the establishment of adjacency with its neighbor router until a BFD session is successfully established between them. The document describes this "strict-mode" of BFD establishment as a prerequisite to OSPF adjacency formation. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] I-D Action: draft-ietf-ospf-sr-yang-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Data Model for OSPF SR (Segment Routing) Protocol Authors : Derek Yeung Yingzhen Qu Jeffrey Zhang Ing-Wher Chen Acee Lindem Filename: draft-ietf-ospf-sr-yang-06.txt Pages : 25 Date: 2019-03-06 Abstract: This document defines a YANG data model that can be used to configure and manage OSPF Segment Routing. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NDMA) as described in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-sr-yang-06 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-sr-yang-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sr-yang-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Multiple failures in Dynamic Flooding
It takes too long when Hello packet is lost. Repairing split flooding topology needs to be fast. Fortunately, lost hello packets are a relatively rare occurrence. While repairing the flooding topology needs to be done expediently, attempting to do so and triggering a cascade failure of the network is counter-productive. Given this alternative, a bit of extra delay when adding a new system to the network, or trying to recover from multiple failures seems wise. Rushing and making things worse does not. The first priority must remain network stability. [Les:] Just to put this minor issue to rest… It would also be possible for the node making the temporary flooding request to send hellos at a faster rate (say once a second rather than once every 10 seconds) until it sees that the neighbor is sending LSP/SNP updates. This just isn’t a significant issue. Les ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Multiple failures in Dynamic Flooding
Hi Huaimo, > > I’m sorry that you don’t find it useful. Determining the split is trivial: > > when you receive an IIH, > > it has a system ID of the another system in it. If that other system is not > > currently part of the > > flooding topology, then it is quite clear that it is disconnected from the > > flooding topology. > > Repairing the split is done by enabling temporary flooding on the new link. > > For an adjacency between two nodes is up, the Hello packets exchanged between > them will not change node/system IDs in them. > How do you determine that other system is not currently part of the flooding > topology? The IIH includes the system ID. See ISO 10589 v2, section 9.7, field “source Id”. The local system will have a copy of the flooding topology and can easily see if the neighbor was present as of the last FT computation. If not, then it should be added (modulo rate limiting). The local system can also examine it’s own LSDB. If there is no LSP for the neighbor, then it would seem highly likely that there is a disconnect and the neighbor should again be added (modulo rate limiting). We are not requiring it, but a system could also do a more extensive computation and compare the links between itself and the neighbor by tracing the path in the FT and then confirming that each link is up in the LSDB. > > There is an issue here that we have not yet resolved, which is the rate > > that new links should be > > temporarily added to the flooding topology. Some believe that adding any > > new link is the > > correct thing to do as it minimizes the recovery time. Others feel that > > enabling too many links > > could cause a flooding collapse, so link addition should be highly > > constrained. We are still > > discussing this and invite the WG’s opinions. > > The issue is resolved by the solutions in draft-cc-lsr-flooding-reduction. > One solution is below, where the given distance can be adjusted/configured. > If we want every node to flood on all its links, we let the given > distance to a big number. If we want the nodes within 2 hops to a failure > to flood on all their links, we set the given distance to 2. >“In one way, when two or more failures on the current flooding >topology occur almost in the same time, each of the nodes within a >given distance (such as 3 hops) to a failure point, floods the link >state (LS) that it receives to all the links (except for the one from >which the LS is received) until a new flooding topology is built.” As we have discussed, this is not a solution. In fact, this is more dangerous than anything else that has been proposed and seems highly likely to trigger a cascade failure. You are enabling full flooding for many nodes. In dense topologies, even a radius of 3 is very high. For example, in a LS topology, a radius of 3 is sufficient to enable full flooding throughout the entire topology. If that were stable, we would not need Dynamic Flooding at all. > Another solution is just adding minimum links temporarily on the flooding > topology to repair the split flooding topology until a new flooding topology > is built. Agreed. Which links constitute the minimum? In a general topology, with arbitrary failures that are not distributed globally, how do we make a distributed decision about which links to enable? This is the problem that we are trying to solve. And we have no oracle to tell us The Right Answer. > The link can be enabled for “temporary flooding” by the node without using > any TLV or Hello with the TLV. There are cases where it is far easier for the neighbor to realize that it is disconnected than for the local system to realize that the neighbor is disconnected. Thus, it is easier to allow one system to request temporary addition. > The TLV in Hello packet just requests for adding “temporary flooding” on the > link. The other information is accessed by the node locally. The TLV in Hello > packet does not help for corner case. In the case where a node is rebooted, a > new link attached to a new node may apply. If the node that rebooted has 1000 interfaces, which interfaces should be temporarily added? Adding all of them is likely to trigger a cascade failure. The TLV allows us to signal which ones should be enabled. > >All adjacencies are a single hop in both IS-IS and OSPF. Yes, Hello packets > >may be lost. > >Fortunately, they are periodically transmitted, thus the next transmission > >will also contain the > > TLV. If IIH’s are getting lost at a significant rate, then the adjacency > > will not (and should not) > >come up. Thus, the request for temporary flooding will propagate to the > >neighbor in all cases > >that matter. > > It takes too long when Hello packet is lost. Repairing split flooding > topology needs to be fast. Fortunately, lost hello packets are a relatively rare occurrence. While repairing the flooding topology needs to be done
[Lsr] Configuration of LSR routers in WRT dynamic flooding
Huaimo wrote: > > Tony wrote: > > > >There is no need for a backup leader. If the area leader is partitioned > >from the topology, then > > leader election is repeated, resulting in a new leader. Again, no > > configuration is required. > > The above does not talk about topology split, but about the leader down. > After a user/operator has configured some things on the leader, and the > leader has got them and distributed them in some form, and then some time > later, the leader goes down, a new leader is selected. In this case, will the > new leader take and maintain the configurations or the information derived > from the configurations done on the old leader.I Operators configure their routers using their management systems. When an operator chooses a distributed algorithm they SHOULD configure that choice consistently in their network if they don't expect changes based on leader election. This is something that can be stated in the document if it must be. Yes, misconfiguration is possible due to NMS bugs, in which case it may be reasonable for the LSR protocol to detect and signal this misconfiguration. We do not want to build a bunch of complexity into LSR protocols to treat misconfigurations as the normal state of things, as it is not. Thanks, Chris. > Best Regards, > Huaimo > signature.asc Description: Message signed with OpenPGP ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Let's use new email threads for suggested changes. One thread per suggested change/problem to keep things easier to follow. Thanks, Chris. signature.asc Description: Message signed with OpenPGP ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
