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

[Greg Mirsky <[e-mail]>]

Hi Jeffrey,
hope everything is well with you. I hope you can find time to review the
proposed changes to address your comments.

Best regards,
Greg

On Sat, May 11, 2019 at 12:23 PM Greg Mirsky <[e-mail]> wrote:

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