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

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

Looks good!

Thanks.
Jeffrey

From: BESS <[e-mail]> On Behalf Of Greg Mirsky
Sent: Tuesday, August 20, 2019 1:38 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Robert Kebler <[e-mail]>; EXT - [e-mail] <[e-mail]>; [e-mail]; BESS <[e-mail]>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

Hi Jeffrey,
many thanks for the most detailed explanation. Please find my notes and answers in-line tagged GIM5>>. Also, trimmed text to clear issues that we agree has been resolved already.

Attached is the new working version of the draft and the diff to highlight the changes.

Regards,
Greg

On Fri, Aug 9, 2019 at 1:38 PM Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

I've trimmed some text. Please see zzh3> below.

Zzh2> I checked the surrounding text in this draft and section 5.1.3 in RFC6513. I believe section 3 of this document, before its subsection 3.1 should be re-written as following:
...
Zzh2> The reason is that for the candidate set is not ordered - it's just a set to select from (either based on IP address or hashing).
GIM4>> Many thanks, Jeffrey! Please check the working verion or diff and let me know if I've correctly applied the changes.

Zzh3> There is an extra "o":

   o  The first two options select the Upstream PE from a candidate PE
      set either based on IP address or a hashing algorithm.  When used
      together   with the optional procedure of considering the P-tunnel
      status as in   this document, a candidate upstream PE is included
      in the set if it either:

   o  <-- EXTRA
GIM5>> I think I've managed to clear it.

      A.  advertise a PMSI bound to a tunnel, where the specified tunnel
          is not known to be down or up



3.1.7.  Per PE-CE link BFD Discriminator
 ...
 Zzh2> Because you still want to track the tunnel state (in addition to pe-ce interface state), you would need at least two discriminators - one for the tunnel and one for the PE-CE link. However, the new "BGP- BFD attribute" defined in this spec only accommodates one discriminator (and my understanding is that you can't have more than one of the same attribute).
GIM4>> It is implied that the PE-CE link is monitored by p2p BFD session, most likely as described in RFC 5881 for single-hop BFD. That would not require bootstrapping.

Zzh3> I was saying that if you use "Per PE-CE link BFD Discriminator", then ...
Zzh2> The simplest solution is that just use the same discriminator (vs. per PE-CE link discriminator). With that, the ENTIRE section 3.1.7 (including its subsections) become the following:
GIM4>> I'm confused by "use the same Discriminator". The root advertises its Discriminator to the downstream PEs. The value is only locally unique for the root, not for any downstream PE. For a PE-CE link, if BFD is used, each PE must pick its locally unique value to use it as My Discriminator. CE uses that value in Your Discriminator field and thus the PE demultiplexes p2p sessions using its locally unique value in the Your Discriminator field. Note that p2mp BFD session among the root and the downstream PEs is such that PEs receives BFD control packets with the value of Your Discriminator field zeroed, and PEs use a different mechanism to demultiplex p2mp BFD sessions (as described in RFC 8562).

Zzh3> I meant that you don't use PE-CE link specific discriminator (e.g. value1 for the tunnel status, value2 for PE-CE link1 and value3 for PE-CE link2). Whether you track the PE-CE link status or not, you just include the discriminator that corresponds to the tunnel. I don't mean that all PEs use the same discriminator.

3.1.7 Tracking upstream PE-CE link status

   In case the PE-CE link on an upstream PE failed, even though the provider tunnel is still up,
   It is desired for the downstream PEs to switch to a backup upstream PE. To achieve that,
   If the upstream PE detects that its PE-CE link fails, it SHOULD set the bfd.LocalDiag of the
   p2mp BFD session to Concatenated Path Down and/or Reverse Concatenated Path Down,
   unless it switches to a new PE-CE link immediately (in that case the upstream PE will start tracking
   the status of the new PE-CE link).
   When a downstream PE receives that bfd.LocalDiag code, it treats as if the tunnel itself
   failed and tries to switch to a backup PE.
GIM4>> Would the downstream PE be switching to the backup Provider Tunnel, not to a backup PE? If yes, that option already listed in section 3.1.7.2

Zzh3> No.
Zzh3> Take one step back. When we don't track PE-CE link status on the ingress PE, we only care about the tunnel status. If it is down, we don't use the corresponding PE. There is no "backup tunnel". There is only a "backup upstream PE".
Zzh3> Now add the PE-CE link to the picture. Even if the tunnel remains up but if the PE-CE link is down, we don't use that upstream PE anymore. From the downstream PE's point of view, there is no difference whether it is the tunnel down or upstream PE-CE link down. It should not care.
Zzh3> That's why I say that the ENTIRE section of 3.1.7 should be replaced with my proposed text. No more 3.1.7.1 and 3.1.7.2.
GIM5>>  I agree and hopefully the new section 3.1.7 captured your proposal and addressed this concern. One question though. The text recommends that the upstream PE notifies the downstream PEs of PE-CE link failure "unless it switches to a new PE-CE link immediately". As we know, nothing happens immediately. Should we tie it to the value of bfd.DesiredMinTxInterval for the p2mp BFD session? One interval or multiplied by bfd.DetectMult? Or leave it outside of BFD by saying "within the separately defined time interval"?


Jeffrey


Juniper Business Use Only


Juniper Business Use Only