Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Greg,

Most of changes are fine; though I suggest to replace the following:

   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
   considered up if one or more of the P2MP RSVP-TE LSPs to the same PE,
   identified by the P-tunnel Attribute, are in Up state.

With the following:

   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
   considered up if the sub-LSP to this downstream PE is in Up state.

Not all comments have been addressed, though. I trimmed some text below and highlighted the outstanding ones with “=============”. You may need to refer to my previous email for correlation/details.

Jeffrey

On Thu, Mar 14, 2019 at 3:04 AM Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>> wrote:
Thomas, Bob,

Some questions below for you. Some old, and some new.
 ==============================


Zzh> It’s not that the “rules … are not consistent”. It’s that by nature some PEs may think the tunnel is down while the others may think the tunnel is still up (because they’re on different tunnel branches), even when they follow the same rules. Traffic duplication in this case is also only with inclusive tunnels – so how about the following?

   Because all PEs may arrive at a different
   conclusion regarding the state of the tunnel,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used
   when using inclusive tunnels.
===============================
 Additionally, the text in section 3 seems to be more biased on Single Forwarder Election choosing the UMH with the highest IP address. Section 5 of RFC6513 also describes two other options, hashing or based on “installed UMH route” (aka unicast-based). It is not clear how the text in this document applies to hashing based selection, and I don’t see how the text applies to unicast-based selection. Some rewording/clarification are needed here.
GIM>> How would the use of an alternative UMH selection algorithm change documented use of p2mp BFD? Do you think that if the Upstream PE selected using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself no longer applicable?

Zzh> It’s not that the alternative UMH selection algorithm change documented use of p2mp BFD. It’s the other way around – tunnel state changes the selection result. I guess hashing can still be used (this document only controls what goes into the candidate pool). For unicast based selection I thought it’d no longer work, but then I noticed the following:

   o  second, the UMH candidates that advertise a PMSI bound to a tunnel
      that is "down" -- these will thus be used as a last resort to
      ensure a graceful fallback to the basic MVPN UMH selection
      procedures in the hypothetical case where a false negative would
      occur when determining the status of all tunnels

Zzh> So this should still work, although Ideally, the PE advertising the next best route should be considered before going to the last resort (of using the PE advertising the best route but whose tunnel is down).
========================================
zzh> BTW, the same applies to 3.1.7 as well.
GIM>> Agree

==================================

3.1.7.  Per PE-CE link BFD Discriminator

   The following approach is defined for the fast failover in response
   to the detection of PE-CE link failures, in which UMH selection for a
   given C-multicast route takes into account the state of the BFD
   session associated with the state of the upstream PE-CE link.

3.1.7.1.  Upstream PE Procedures

   For each protected PE-CE link, the upstream PE initiates a multipoint
   BFD session [I-D.ietf-bfd-multipoint] as MultipointHead toward
   downstream PEs.  A downstream PE monitors the state of the p2mp
   session as MultipointTail and MAY interpret transition of the BFD
   session into Down state as the indication of the associated PE-CE
   link being down.

Since the BFD packets are sent over the P2MP tunnel not the PE-CE link, my understanding is that the BFD discriminator is still for the tunnel and not tied to the PE-CE link; but different from the previous case, the root will stop sending BFD messages when it detects the PE-CE link failure. As far as the egress PEs are concerned, they don’t know if it is the tunnel failure or PE-CE link failure.

If my understanding is correct, the wording should be changed.
GIM>> There are other than stopping transmission of BFD control packets ways to distinguish two conditions for the egress PE. For example, the MultipointHead MAY set the State to AdminDown and continue sending BFD control packets. If and when PE-CE link restored to Up, the MultipointHead can set the state to Up in the BFD control packet.
===================== this needs more discussion =====
===== should be clear on which way is done – stop sending BFD message or use AdminDown
===== an PMSI may be used for many flows, which may use different PE-CE interfaces on the ingress PE. A downstream PE would not know which interface it should track for a particular flow.

   …  If the route to the
   src/RP changes such that the RPF interface is changed to be a new PE-
   CE interface, then the upstream PE will update the S-PMSI A-D route
   with included BGP-BFD Attribute so that value of the BFD
   Discriminator is associated with the new RPF link.

If the RPF interface changes on the upstream PE, why should it update the route to send a new discriminator? As long as there is a new RPF interface couldn’t the upstream PE do nothing but start tracking the new RPF interface?
GIM>> I'll defer this one to Thomas and Rob.
===========================================
Zzh> I re-read section 3.1.6 and 3.1.7 and have more questions 😊
Zzh> 3.1.6 seems to be about tracking tunnel itself while 3.1.7 is about tracking PE-CE interfaces. From an egress point of view, (how) does it know if the discriminator is for the tunnel or for PE-CE interface 1 or PE-CE interface 2? Does it even care? It seems to me that an egress PE would not need to care. If so, why are there different procedures for 3.1.6/3.1.7 (at least for the egress PE behavior)? Even for the upstream PE behavior, shouldn’t 3.1.6.1 apply to 3.1.7 as well?
GIM>> Added the following text to the first paragraph of section 3.1.7:
NEW TEXT:
The mechanism to communicate the mapping between the PE-CE link
and the associated BFD session is outside the scope of this document.

=============== the above added text does not address my questions

Regardless which way (the currently described way and my imagined way), some text should be added to discuss how the downstream would not switch to another upstream PE when the primary PE is just going through a RPF change.
GIM>>  Would appending the following text be acceptable to address your concern:
NEW TEXT:
   To avoid unwarranted switchover a downstream PE MUST gracefully handle the
   updated S-PMSI A-D route and switch to the use of the associated BFD
   Discriminator value.
================= how that is done needs to be discussed

4.  Standby C-multicast route

   The procedures described below are limited to the case where the site

   that contains C-S is connected to exactly two PEs. The procedures
   require all the PEs of that MVPN to follow the single forwarder PE
   selection, as specified in [RFC6513].


Why would it not work with more than two upstream PEs?
Why is it limited to single forwarder selection? What about unicast based selection?
GIM>> Again, asking for Thomas and Rob to help..
==========================



Juniper Internal