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

[Greg Mirsky <[e-mail]>]

Hi Jeffrey,
thank you for your consideration and the detailed comments with great
suggestions. Please find my answers below under GIM3>> tag. Attached is the
diff to highlight the updates.

Regards,
Greg

On Tue, May 7, 2019 at 7:43 AM Jeffrey (Zhaohui) Zhang <[e-mail]>
wrote:

> 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.
>
GIM3>> Accept with one question. As this is the first sentence in the
section, what is the PE we refer to as "this downstream PE"? Should we use
"a downstream PE"?

>
>
> 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]> 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.
>
> GIM3>> Got it, thx. Would s/may/could/ be acceptable to avoid questions
about RFC2119-like language?


> ===============================
>
>  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).
>
> GIM3>> I hope I've got the idea. Below is the updated text (second becomes
third and your proposal - second):
NEW TEXT:
   o  Second, the PE advertising the next best route is to be
      considered.

   o  Third, 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> 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.
>
> GIM3>> Thank you for helping me to understand the problem with PE-CE and
p2mp BFD. I've updated the paragraph is 3.1.7, I've found the better method
to indicate the PE-CE link failure to the downstream. Also, stress that
though it is likely that PE-CE association be 1:1, it is outside the scope
of the draft. Please let me know if the new text addresses your questions:
NEW TEXT:
   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.
   According to section 6.8.17 [RFC5880], failure of a PE-CE link MAY be
   communicated to the downstream PE by setting the bfd.LocalDiag of the
   p2mp BFD session associated with this link to Concatenated Path Down
   and/or Reverse Concatenated Path Down.  The mechanism to communicate
   the mapping between the PE-CE link and the associated BFD session is
   outside the scope of this document.


>
>
>    …  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
>
> GIM3>> I think that this is implementation issue and we just point to the
recommended behavior without prescribing what steps must be taken to
achieve it.

>
>
> 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
>