Subject: [Rift] [RIFT-TEAM] Questions about negative disaggregation

From: Bruno Rijsman <[email-masked]>
Date: Thu, 28 Mar 2019 06:26:23 -0300

Hi Pascal (CC RIFT mailing list per WG request),

I am about to get started on implementing negative disaggregation.

Per my usual modus operandi, now that I start thinking about actual code, I have more questions about the draft.

Section 5.2.5.2.3. (Computation of Negative Disaggregates) describes two steps for generating the negative prefixes. I don't fully understand the first step. 

It sounds like running some special variation of SPF which will find some extra prefixes (relative to a normal SPF run) and those extra prefixes will be the negative prefixes:

 The first origination reason is a computation that uses all the node
 N-TIEs to build the set of all reachable nodes by reachability
 computation over the complete graph and including ToF links. The
 computation uses the node itself as root. This is compared with the
 result of the normal southbound SPF as described in Section 5.2.4.2.
 The difference are the fallen leafs and all their attached prefixes
 are advertised as negative prefixes southbound if the node does not
 see the prefix being reachable within southbound SPF.

My questions are:

(1) Could you please provide more details on how this special variation of SPF is different from the normal SPF, and why it yields the negative prefixes?

(2) Should this special flavor of SPF be run on all nodes, or only on specific nodes (e.g. only the Top-of-Fabric nodes)? I am asking because the other step takes care of propagating the negative prefixes south-wards.

(3) Do you envision that a RIFT network would choose between either positive disaggregation or negative disaggregation, or do you envision that a RIFT network would run both at the same time and that they augment each other (if so, how)?

(4) I am confused about what happens in a multi-plane network where the east-west Top-of-Fabric links shown in figure 16 are absent. The draft is clear to say that such a network can have blackholes which positive disaggregation cannot fix.  But are we saying that such blackholes will be fixed by negative disaggregation?  I think that is indeed what the draft is saying, but then I am confused by the sentence "a computation that ... including ToF links” which sounds like the east-west ToF links need to be included in the special SPF calculation.

-- Bruno

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 28 Mar 2019 11:19:50 +0100

>From demand perspective I think it would be better to start on
authentication envelope first

rest inline

--- tony

On Thu, Mar 28, 2019 at 10:26 AM Bruno Rijsman <[email-masked]>
wrote:

> Section 5.2.5.2.3. (Computation of Negative Disaggregates) describes two
> steps for generating the negative prefixes. I don't fully understand the
> first step.
>
> It sounds like running some special variation of SPF which will find some
> extra prefixes (relative to a normal SPF run) and those extra prefixes will
> be the negative prefixes:
>
> (1) Could you please provide more details on how this special variation of
> SPF is different from the normal SPF, and why it yields the negative
> prefixes?
>
> I thought it was written down that one runs a southbound using the E-W
links @ ToF level (to cross into other planes) and compares that to normal
S-SPF. Diff is fallen leafs

suggest  better language

> (2) Should this special flavor of SPF be run on all nodes, or only on
> specific nodes (e.g. only the Top-of-Fabric nodes)? I am asking because the
> other step takes care of propagating the negative prefixes south-wards.
>
>
only ToF really

> (3) Do you envision that a RIFT network would choose between either
> positive disaggregation or negative disaggregation, or do you envision that
> a RIFT network would run both at the same time and that they augment each
> other (if so, how)?
>

implementation choice. If you impolement ToF and want to support
multi-plane negative is a must, otherwise not needed.

>
> (4) I am confused about what happens in a multi-plane network where the
> east-west Top-of-Fabric links shown in figure 16 are *absent*. The draft
> is clear to say that such a network can have blackholes which positive
> disaggregation cannot fix.  But are we saying that such blackholes will be
> fixed by negative disaggregation?  I think that is indeed what the draft is
> saying, but then I am confused by the sentence "a computation that ... *including
> ToF links*” which sounds like the east-west ToF links need to be included
> in the special SPF calculation.
>
> -- Bruno
>

 lack of E-W ToF links cannot be detected since it looks to a ToF then like
it would be a single plane fabric. Presence of other planes can however be
detected if nodes south advertise N-neighbors that the ToF doesn't see.
This is implementation smarts and I don't think should/can be mandated by
the spec

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 28 Mar 2019 11:39:41 +0000

Hello Tony and Bruno:

Please see below

All the best

Pascal

On Thu, Mar 28, 2019 at 10:26 AM Bruno Rijsman <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pascal (CC RIFT mailing list per WG request),

My questions are:

I thought it was written down that one runs a southbound using the E-W links @ ToF level (to cross into other planes) and compares that to normal S-SPF. Diff is fallen leafs

suggest  better language

  *   Pascal: I thinks this boils down to:

Ø    and including ToF links

Ø     =>

Ø    and including E/W links that convey the destinations that are reachable by other nodes at the same level.

only ToF really

  *   Pascal: In practice probably so. But considering the crafted text in default route origination in section 5.2.3.8, I think the same logic applies and should be written as such.
  *   If a node decides to originate a default route by 5.2.3.8 (IOW it issues it but did not inherit from north by item 3 in the possible reasons) then it should also disaggregate.

---

From: Bruno Rijsman <[email-masked]>
Date: Thu, 28 Mar 2019 09:53:44 -0300

Tony, Pascal, (CC RIFT-WG-ML)

Okay, I think I am on the same page as both of you now.

Just so that there are no misunderstandings, this is my plan:

1) I will do the security envelope first. Tony - which version of Juniper RIFT do I need for interop testing? Is the bitbucket repo up-to-date with your latest and greatest code?

2) I will do negative disaggregation as follows:

  a) Have a configuration knob to chose between positive-only, negative-only, postive-and-negative (positive-only is default).

  b) I will only run the special negative SPF on the ToF nodes.

  c) I will run the negative propagation rules on all nodes (although it will have no effect on the ToF nodes).

  d) In multiplane-topologies, you need negative *AND* east-west TOF links to avoid black holes. Lack of east-west TOF links will prevent detection of fallen leaves. Hence,if negative is enabled, then if a ToF node detects a same-level-node (using reflected Node-TIEs) which is not reachable using the special SPF (which indicates missing east-west links), then it will report a warning (show command and log).

3) All of this will happen "later". First, I am taking a breather to absort all the materials from the IETF meeting (particuarly QIRG).

Sound good?

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 28 Mar 2019 14:03:20 +0100

On Thu, Mar 28, 2019 at 1:53 PM Bruno Rijsman <[email-masked]>
wrote:

> 1) I will do the security envelope first. Tony - which version of Juniper
> RIFT do I need for interop testing? Is the bitbucket repo up-to-date with
> your latest and greatest code?
>
>
give me a holler 1:1 and we'll synchronize, I forgot what keys we agreed on
already ...

---

From: Bruno Rijsman <[email-masked]>
Date: Fri, 29 Mar 2019 17:41:19 -0300

Tony> I forgot what keys we agreed on already …

I think we agreed on SHA256.

I plan to make it configurable with SHA256 as the default.

I plan to also include a “no-authentication” option where I set the hash to zero on TX and don’t verify on RX.

Here are the hashes that are readily available in Python, and their performance in terms of hashes per second as a function of the data size (code to produce this is in https://github.com/brunorijsman/python-hash-experiments/blob/master/experiment.py <https://github.com/brunorijsman/python-hash-experiments/blob/master/experiment.py>):

Algo        Data size   Hashes/sec
----------  ----------  ----------
MD-5                10     524,341
SHA-1               10     417,749
SHA-224             10     343,344
SHA-256             10     297,514
SHA-384             10     376,318
SHA-512             10     296,688
SHA3-224            10     579,367
SHA3-256            10     542,269
SHA3-384            10     372,937
SHA3-512            10     566,793
BLAKE-2B            10     542,478
BLAKE-2S            10     721,195
MD-5               100     441,754
SHA-1              100     394,913
SHA-224            100     360,662
SHA-256            100     331,191
SHA-384            100     321,690
SHA-512            100     380,822
SHA3-224           100     556,320
SHA3-256           100     523,758
SHA3-384           100     517,561
SHA3-512           100     293,001
BLAKE-2B           100     871,899
BLAKE-2S           100     809,548
MD-5             1,000     194,658
SHA-1            1,000     189,145
SHA-224          1,000     123,435
SHA-256          1,000     124,261
SHA-384          1,000     144,571
SHA-512          1,000     140,111
SHA3-224         1,000     120,112
SHA3-256         1,000      89,740
SHA3-384         1,000      80,310
SHA3-512         1,000      67,202
BLAKE-2B         1,000     275,804
BLAKE-2S         1,000     199,762
MD-5            10,000      30,987
SHA-1           10,000      35,767
SHA-224         10,000      16,882
SHA-256         10,000      16,962
SHA-384         10,000      21,517
SHA-512         10,000      21,110
SHA3-224        10,000      14,694
SHA3-256        10,000      13,710
SHA3-384        10,000      10,718
SHA3-512        10,000       7,154
BLAKE-2B        10,000      35,085
BLAKE-2S        10,000      27,761

---

From: Bruno Rijsman <[email-masked]>
Date: Fri, 29 Mar 2019 17:51:47 -0300

Hmmmm…. I may be doing it the wrong way, I haven’t included a key yet. Disregard these results for now until further notice.

> On Mar 29, 2019, at 5:41 PM, Bruno Rijsman <[email-masked]> wrote:
>

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 29 Mar 2019 22:32:55 +0100

yepp, looked it up, it was symmetric sha256

On Fri, Mar 29, 2019 at 9:41 PM Bruno Rijsman <[email-masked]>
wrote:

> Here are the hashes that are readily available in Python, and their
> performance in terms of hashes per second as a function of the data size
> (code to produce this is in
> https://github.com/brunorijsman/python-hash-experiments/blob/master/experiment.py
> ):
>