Hi Ice, 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?
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
