Hi Ice, Thank you for the reply. Yes, it is not flip-flop, but unnecessary switch. Overall, I think this is a useful draft.
Thanks Lizhong IJsbrand Wijnands <[email protected]> wrote 2012/11/09 00:00:58: > Hi Lizhong, > > > I have one concern with the DTNP mechanism. When a node receives a > DTNP from its primary UMH and the node has a secondary UMH for which > no DTNP had been received beforehand, it unblocks its secondary UMH. > But later it received DTNP from a secondary UMH, then the node again > has to block its secondary UMH, right? > > It would be common that the node will receive DTNP from primary > UMH earlier than secondary UMH, then there would be a flip flop in a > transient time. Have you considered this issue before? > > Yes, this is a situation where the MoFRR router can't repair the > failure, because the upstream path was shared by the primary and > backup path. The MoFRR router may switch to the secondary UMH > unnecessary (for a short time), but it will not flip-flop. The MoFRR > router keeps track of getting a DTNP on both primary and secondary > (section 3.2). If this happens, the DTNP will be forwarded > downstream to allow an other downstream MoFRR router to repair the > failure. If there is no other MoFRR router, it means MoFRR did not > provide full coverage to remedy the failure. > > Thx, > > Ice. > > > > > Thanks > > Lizhong > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 23 Oct 2012 22:03:05 +0200 > > > From: IJsbrand Wijnands <[email protected]> > > > To: [email protected] > > > Subject: draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > > Message-ID: <[email protected]> > > > Content-Type: text/plain; charset=us-ascii > > > > > > Hi Folks, > > > > > > I like to encourage the WG to read through this draft so that we can > > > have productive discussion at the IETF. > > > > > > In short, this draft proposes two enhancements to Multicast Only > > > Fast ReRoute (draft-ietf-rtgwg-mofrr-00). > > > > > > 1. A router on the tree that detects a failure on its upstream (RPF) > > > interface injects a Downstream Tree Notification (DTN) down the tree > > > to notify (potential) downstream MoFRR routers. When a downstream > > > MoFRR router has received such notification, it will switch to the > > > backup path. The notification is sent as data down the tree and > > > forwarded as 'normal' data by non-MoFRR routers. In order to allow > > > Fast Convergence to happen, originating and processing of the TN > > > message must happen in the data-plane, similar to how BFD packets > > > are processed in the data-plane. The big different with BFD is that > > > TN packets are not periodic, but only triggered when a failure happens. > > > > > > 2. With normal MoFRR, packets are received over two diverse paths to > > > the MoFRR router. While in many cases this is not considered to be a > > > problem, there are situations where the additional bandwidth may be > > > worth saving. For this cases we are proposing to join the backup > > > path in 'standby' mode, such that forwarding state is programmed, > > > but no data is actually forwarded. When a failure has happened on > > > the tree (detected by Downstream TN or directly connected link > > > failure) an Upstream Tree Notification (UTN) is originated up the > > > tree to reset the non-forwarding state. This notification is also > > > originated and processed in the data-plane. Note, this is optional > > > functionality. The main advantage of this draft comes from option 1. > > > > > > Thx, > > > > > > Andras, Jeff and Ice. > > > > > > > > > > > > > > > Begin forwarded message: > > > > > > > From: [email protected] > > > > Subject: I-D Action: draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > > > Date: 15 Oct 2012 21:22:11 GMT+02:00 > > > > To: [email protected] > > > > Reply-To: [email protected] > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > > > > Title : Tree Notification to Improve Multicast Fast Reroute > > > > Author(s) : IJsbrand Wijnands > > > > Andras Csaszar > > > > Jeff Tantsura > > > > Filename : draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > > > Pages : 18 > > > > Date : 2012-10-15 > > > > > > > > Abstract: > > > > This draft proposes using dataplane triggered notifications in order > > > > to support multicast fast reroute methods in various ways. Sending > > > > such notifications down the tree can be used to trigger fail-over in > > > > nodes not adjacent to the failure. Sending such dataplane > > > > notification up the tree can help to activate pre-built standby > > > > backup tree segments. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-wijnands-rtgwg-mcast-frr-tn > > > > > > > > There's also a htmlized version available at: > > > > http://tools.ietf.org/html/draft-wijnands-rtgwg-mcast-frr-tn-00 > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
