Subject: Re: draft-wijnands-rtgwg-mcast-frr-tn-00.txt

From: Lizhong Jin<[email-masked]>
Date: Thu, 8 Nov 2012 19:32:48 +0800

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-masked]>
> To: [email-masked]
> Subject: draft-wijnands-rtgwg-mcast-frr-tn-00.txt
> Message-ID: <[email-masked]>
> 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-masked]
> > Subject: I-D Action: draft-wijnands-rtgwg-mcast-frr-tn-00.txt
> > Date: 15 Oct 2012 21:22:11 GMT+02:00
> > To: [email-masked]
> > Reply-To: [email-masked]
> > 
> > 
> > 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-masked]
> > 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
> > 
> 
> 
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 8 Nov 2012 11:00:58 -0500

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.

> > >    Title           : Tree Notification to Improve Multicast Fast Reroute

---

From: Lizhong Jin<[email-masked]>
Date: Mon, 12 Nov 2012 20:29:45 +0800

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-masked]> 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
> > 
> > 
> > > 
> > > 
Reroute