Subject: Re: Comments/questions on morin-fast-failover

From: Eric Rosen <[email-masked]>
Date: Mon, 05 Apr 2010 14:25:02 -0400

Sorry for taking so long to get back to this.

Eric> I also have a question about whether changing UMH can really be
Eric> considered "fast failover" under most circumstances.  If PE-R is
Eric> already joined to PE-S1's tunnel when PE-S2's tunnel fails, then PE-R
Eric> can certainly switch quickly from receiving (C-S,C-G) on one tunnel to
Eric> receiving it on the other.  But suppose PE-R is not already joined to
Eric> PE-S1's tunnel.

Yakov> The above is based on an incorrect assumption that PE-R "is not already
Yakov> joined to PE-S1's tunnel". To see why this assumption is incorrect,
Yakov> note the following from 4.1:

Yakov>      Note that, when a PE advertizes such a Standby C-multicast join
Yakov>      for an (S,G) it must join the corresponding P-tunnel.

But the draft appears to say the UMH selection procedures (section 3) are
independent of the Standby C-multicast Join procedures.  Are you saying that
one should not change UMH unless one is using the Standby C-multicast Join
procedures?  If so, the draft needs to be modified to reflect that.

If the intention is that the procedures of section 3 only apply when the
procedures of section 4 are being used, then the applicability restrictions
of section 4 ("limited to the case where the site that contains C-S is
connected to exactly two PEs ...  require all the PEs of that MVPN to follow
the single forwarder PE selection") should be discussed in a prior section.  

Yakov> using last hop link for determining that the tunnel is down (section
Yakov> 3.1.2) is applicable only when there is no fast restoration mechanism
Yakov> on that link.

That would make sense, but it isn't what the draft says.  To the contrary,
section 3.1.2 seems to say that if there is a fast restoration mechanism,
you can still use "last hop link" for determining that the tunnel is down,
but you need to set a timer so that you don't switch UMH before the FRR has
a chance to work.  That makes it seem like the timer is there to protect
against the failure of the FRR mechanism.

Yakov> automatically reconstituting the tunnel after the last hop link
Yakov> failure may take longer than it would take for the IGP to react to
Yakov> the link outage

I think that was my point ;-)

---

From: Thomas Morin <[email-masked]>
Date: Tue, 27 Apr 2010 17:20:25 +0200

Hi Eric,

As said during the meeting, we intend to revise the document to make it
more explicit which are the cases where Standby C-multicast Join
procedures and procedures for UMH selection based on tunnel status, may
depend on each other, and what gain there can be compared to the base
mVPN resiliency times in the different combinations.

Thanks for your comments,

-Thomas