From nobody Fri Mar 1 13:13:46 2019 Return-Path: X-Original-To: rift@ietf.org Delivered-To: rift@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B597712F1AB; Fri, 1 Mar 2019 13:10:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rift@ietf.org, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147460373.6101.17275249410071571762.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:03 -0800 Archived-At: Subject: [Rift] rift - Requested session has been scheduled for IETF 104 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:15 -0000 Dear Zhaohui Zhang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rift Session 1 (2:00 requested) Wednesday, 27 March 2019, Morning Session I 0900-1100 Room Name: Grand Ballroom size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/rift.ics Request Information: --------------------------------------------------------- Working Group Name: Routing In Fat Trees Area Name: Routing Area Session Requester: Zhaohui Zhang Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: bier bess rtgwg lsr lsvr Second Priority: pim mboned idr spring pce teas mpls People who must be present: Tony Przygienda Alvaro Retana Zhaohui (Jeffrey) Zhang Jeff Tantsura Resources Requested: Special Requests: Please put YANG related sessions as third priority for conflict avoidance. --------------------------------------------------------- From nobody Sun Mar 3 11:06:06 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C97130DEF; Sun, 3 Mar 2019 11:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojz44aFwsdRE; Sun, 3 Mar 2019 11:06:02 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A32130DE9; Sun, 3 Mar 2019 11:05:58 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id a16so2479505edn.1; Sun, 03 Mar 2019 11:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L7o6UfgegvQtZtFSd8Kjodw6BwOFh2X2CzE1wAXk5IM=; b=AyTFwwt2/yb9ccz19yCdLqdkO7AOjMZR+O+nSJZitwNT7/mkv2lpHkt1Yz8nYsR1Rp pgspjv69NgXA5y6pL+6MkKcNc51vIUIxSyMtEhtLnqITIHSj8LVrVLn85j6hAALoMp1V eNKcWByZ7h1+41jQZFd/N0tag7hteJ5B9P8/OkGjsDjl6/0HW75T6HrfvVGoB8L9qIXm bF+RE0TELuMiGFLP15xw5284kIdRVJkkGtC+T0Vk6+9wcndX4319gLjUNclB7vUxH4IL LPs3rvLUcWo+XAz2uIJ4uzqRqwZvb6DDRdIo0jV6D656jQ+4g9C00DLbYOvZeyF/DG35 cIXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L7o6UfgegvQtZtFSd8Kjodw6BwOFh2X2CzE1wAXk5IM=; b=hSmgz18IZq2+WGsuzAnsMiFk4gLsg056zFx3yh+dpHzrfgQVr5dQ6IJfGOn/uGorBJ 0qlwfhY+LQYorfd10lR/uIhVVI2FTBURURYzWojISbr3xuCe8/EU9p6bRGiIimfrwQJJ AOn9hC8YUgXKbOxwv7pHJZ1td0fBfntseQvqWtCMpw75fQblpsGxnElMbit3whDqikV7 BnBaiZGRWJnkbd6PsviZsO5HSuOgx7mKjoAe3mO59UGFnl26CgWO7+tmv12UZkhqHIbC 4LdgDsToqf6053stz6Sx8RVGLRV9nlgxXFB/6fG+LYRWuhNqpzqJB7hoRZzDZCfAQcPP Hm5w== X-Gm-Message-State: APjAAAU2zCuVlOh6sP1fu1LUe+399LUBa4wP3Wq54JfH7xKL9PNJExUk iVRzWoogD4qH08zB020TFNJgS9uYdgoDfNXeMfE= X-Google-Smtp-Source: APXvYqwRXavzbcdFFQdpyZkpjdIJA5QsmWP1xrnfUnrMSCiDFRVHv0aLu8Ju9Tqd/vkusF5sxqVlps1FW46cIjb7d0Y= X-Received: by 2002:a50:ad13:: with SMTP id y19mr12584636edc.86.1551639956838; Sun, 03 Mar 2019 11:05:56 -0800 (PST) MIME-Version: 1.0 References: <0A0D8BBD-E6F3-4272-BD12-EB093AE7E8D4@gmail.com> In-Reply-To: <0A0D8BBD-E6F3-4272-BD12-EB093AE7E8D4@gmail.com> From: Tony Przygienda Date: Sun, 3 Mar 2019 11:05:20 -0800 Message-ID: To: Bruno Rijsman Cc: hackathon@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000725e0705833554c7" Archived-At: Subject: Re: [Rift] [RIFT] Routing in Fat Trees "chaos testing" hackathon at IETF 104 in Prague X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 19:06:06 -0000 --000000000000725e0705833554c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Preparing stuff here along instructions, ran it on a t2.micro (spot request is cheap and works well) b) no command line completion on interactive ;-{ c) the meta config file restricts to 3 levels only (5 stage folded), good enough for now but testing more than 3 levels is very interesting proposition for the future d) running the example I see tons of those 2019-03-03 18:35:08,355:ERROR:node.if.tx:[spine-2-2:veth-105g-4e] Error [Errno 111] Connection refused sending IPv6 TIE ProtocolPacket( and then 2019-03-03 18:35:08,274:ERROR:node.if.tx:[super-4:veth-4e-105g] Error [Errno 111] Connection refused sending IPv4 TIDE ProtocolPacket but I see no UDP losses Udp: 16103 packets received 88 packets to unknown port received 0 packet receive errors 16224 packets sent 0 receive buffer errors 0 send buffer errors Consequently I see on start often 2-3 pairs of leafs that can't ping each other, I did not analyze further, every time different pairs, sometimes all come up. monkey testing works fine ... Next iteration will be of course doing that once positive disaggregation is implemented in python RIFT ;-) I think @ hackathon first thing we have to write a simple script that collects the kernel routing tables & compares them for # expected entries since leaf-2-leaf has such a wide path diversity it's hard to debug, observe that due to ECMP hashing you can get a leaf being able to ping 2 other leafs in another pod but not the third since it takes different spine/superspine combination. Generally, to test connectivity on fabric well, you need a fan-out of UDP source/sink pairs that lead to exhaustive ECMP coverage (as well as tests quality of load balancing once we get to the bandwidth balancing in python RIFT) Yes, connectivity to spine loopbacks and so on has been discussed on the core team list and is in the draft (-04 is in publication queue) ... Generally, most robust IP fabric architecture is leaf-2-leaf since relying on every leaf being able to reach every spine leads unavoidably into exposing more and more topology towards the leafs with according scalabiltiy problems on the leafs. So, a fabric where every leaf can reach every leaf is in a sense "working fine" even if links are lost or some spines crash. That modulo bandwidth balancing since we want to account for load being balanced (unsurprisingly, RIFT does all that ;-) if we talk a single prefix (loopback) on a spine/superspine then PGP and even simpler stuff can work well but if we assume that specific superspines terminate lots prefixes and rely on leafs being able to reach them then the fabric "inverts" and scalbility is lost. Variants of the problem exist by e.g. having superspines exposing anycast addresses. Once deployment experience starts to come in I can see a "operational deployment" draft coming up (I think someone already suggested to write one) ... thanks --- tony On Mon, Feb 25, 2019 at 5:15 PM Bruno Rijsman wrote: > Hi everyone, > > At the Routing In Fat Trees (RIFT) IETF 104 hackathon in Prague we will b= e > working on "chaos monkey" testing of two RIFT implementations: the > RIFT-Python open source implementation and a vendor RIFT implementation. > > This hackathon is inspired by the concept of chaos engineering and in > particular by the chaos monkey tool, which intentionally and randomly shu= ts > down servers in a production environment. This is intended to build > confidence in the system's capability to withstand turbulent and unexpect= ed > conditions. > > In this hackathon we will do something similar for RIFT networks. We will > build a large fat tree network of RIFT routers. Then we will randomly > insert failures into the network and make sure that the network behaves > correctly. We will make sure the RIFT routers don't crash or otherwise > behave badly. And we will make sure that the routers forwarding tables an= d > link-state databases converge correctly. > > We will use (and possibly enhance) the chaos testing framework as well as > the visualization and verification tools that are already part of the > RIFT-Python open source project. > > Even if you are not much interested in the RIFT routing protocol, but you > are interested in testing large network topologies using container-like > technology, or in visualization tools, or in chaos testing, this might be > the right hackathon for you. > > *A detailed description of the planned activities at the hackathon is > available at: http://bit.ly/rift-hackathon-ietf-104 > * > > The project is listed on the IETF 104 hackathon wiki page: > https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon (info copied > below) > > Feel free to join us. > > Bruno Rijsman > > > Routing In Fat Trees (RIFT) Chaos Monkey Testing > > * Champions > * Tony Przygienda (will join in person) > * Bruno Rijsman (will join remotely) > * Project(s) > * =E2=80=8BRIFT is a STD track WG working on a modern IP fabric/DC rout= ing > protocol > * =E2=80=8BDetailed description of the planned activities at the hackat= hon at > http://bit.ly/rift-hackathon-ietf-104 > * We have two implementations now: > * RIFT-Python open source > * Vendor implementation > * The open source one has a chaos monkey framework in place we can us= e > to stress protocol implementations and interoperability between > them. > Unusual hackathon but that will be very, very useful for further > development and quality of implementations while breaking completel= y > new grounds (chaos testing on model based protocol specifications). > * Preconditions: > * Python knowledge > * Familiarity with the open source RIFT code on =E2=80=8B > https://github.com/brunorijsman/rift-python > * RIFT Specification in some detail =E2=80=8BRIFT draft > * Familiarity with creating virtual machines in AWS > > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift > --000000000000725e0705833554c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Preparing stuff here along instructions, ran it on a t2.micr= o (spot request is cheap and works well)

b) no command l= ine completion on interactive ;-{
c) the meta config file re= stricts to 3 levels only (5 stage folded), good enough for now but testing = more than 3 levels is very interesting proposition for the future
d) running the example I see tons of those

2= 019-03-03 18:35:08,355:ERROR:node.if.tx:[spine-2-2:veth-105g-4e] Error [Err= no 111] Connection refused sending IPv6 TIE ProtocolPacket(

<= /div>
and then

2019-03-03 18:35:08,274:ER= ROR:node.if.tx:[super-4:veth-4e-105g] Error [Errno 111] Connection refused = sending IPv4 TIDE ProtocolPacket

but I see no UDP = losses

Udp:
=C2=A0=C2=A0=C2=A0 16103 packe= ts received
=C2=A0=C2=A0=C2=A0 88 packets to unknown port received
= =C2=A0=C2=A0=C2=A0 0 packet receive errors
=C2=A0=C2=A0=C2=A0 16224 pack= ets sent
=C2=A0=C2=A0=C2=A0 0 receive buffer errors
=C2=A0=C2=A0=C2= =A0 0 send buffer errors

Consequently I see on= start=C2=A0 often 2-3 pairs of leafs that can't ping each other, I did= not analyze further, every time different pairs, sometimes all come up.

monkey testing works fine ... Next iteration wi= ll be of course doing that once positive disaggregation is implemented in p= ython RIFT ;-)

I think @ hackathon first thing= we have to write a simple script that collects the kernel routing tables &= amp; compares them for # expected entries since leaf-2-leaf has such a wide= path diversity it's hard to debug, observe that due to ECMP hashing yo= u can get a leaf being able to ping 2 other leafs in another pod but not th= e third since it takes different spine/superspine combination. Generally, t= o test connectivity on fabric well, you need a fan-out of UDP source/sink p= airs that lead to exhaustive ECMP coverage (as well as tests quality of loa= d balancing once we get to the bandwidth balancing in python RIFT)

Yes, connectivity to spine loopbacks and so on has been di= scussed on the core team list and is in the draft (-04 is in publication qu= eue) ... Generally, most robust IP fabric architecture is leaf-2-leaf since= relying on every leaf being able to reach every spine leads unavoidably in= to exposing more and more topology towards the leafs with according scalabi= ltiy problems on the leafs. So, a fabric where every leaf can reach every l= eaf is in a sense "working fine" even if links are lost or some s= pines crash. That modulo bandwidth balancing since we want to account for l= oad being balanced (unsurprisingly, RIFT does all that ;-) if we talk a sin= gle prefix (loopback) on a spine/superspine then PGP and even simpler stuff= can work well but if we assume that specific superspines terminate lots pr= efixes and rely on leafs being able to reach them then the fabric "inv= erts" and scalbility is lost. Variants of the problem exist by e.g. ha= ving superspines exposing anycast addresses. Once deployment experience sta= rts to come in I can see a "operational deployment" draft coming = up (I think someone already suggested to write one) ...

=
thanks

--- tony




On Mon, Feb 25, 2019 at 5:15 PM Bruno Rijsman <brunorijsman@gmail.com> wrote:
Hi everyone,
=C2=A0
At the Routing In Fat Trees (RIFT) IETF 104 hackat= hon in Prague we will be working on "chaos monkey" testing of two= RIFT implementations: the RIFT-Python open source implementation and a ven= dor RIFT implementation.

This hackathon is inspire= d by the concept of chaos engineering and in particular by the chaos monkey= tool, which intentionally and randomly shuts down servers in a production = environment. This is intended to build confidence in the system's capab= ility to withstand turbulent and unexpected conditions.

In this hackathon we will do something similar for RIFT networks. We = will build a large fat tree network of RIFT routers. Then we will randomly = insert failures into the network and make sure that the network behaves cor= rectly. We will make sure the RIFT routers don't crash or otherwise beh= ave badly. And we will make sure that the routers forwarding tables and lin= k-state databases converge correctly.

We will use = (and possibly enhance) the chaos testing framework as well as the visualiza= tion and verification tools that are already part of the RIFT-Python open s= ource project.

Even if you are not much interested= in the RIFT routing protocol, but you are interested in testing large netw= ork topologies using container-like technology, or in visualization tools, = or in chaos testing, this might be the right hackathon for you.
<= br>
A detailed description of the planned activities at the ha= ckathon is available at:=C2=A0http://bit.ly/rift-hackathon-ietf-104
<= div>
The project is listed on the IETF 104 hackathon wiki pag= e:=C2=A0https://trac.ietf.org/trac/ietf/meeting/wiki/104hackat= hon=C2=A0(info copied below)
=C2=A0
Feel free to jo= in us.

Bruno Rijsman


=
Routing In Fat Trees (RIFT) Chaos Monkey Testing

<= /div>
* Champions
=C2=A0 * Tony Przygienda <prz at juniper.net> (will join in= person)
=C2=A0 * Bruno Rijsman <brunorijsman at gmail.com> (will join remotely)
* Project(s)
=C2=A0 * =E2=80=8BRIFT is a STD track WG wor= king on a modern IP fabric/DC routing protocol
=C2=A0 * =E2=80=8B= Detailed description of the planned activities at the hackathon at=C2=A0
=C2=A0 *= We have two implementations now:
=C2=A0 =C2=A0 * RIFT-Python ope= n source
=C2=A0 =C2=A0 * Vendor implementation
=C2=A0 = =C2=A0 * The open source one has a chaos monkey framework in place we can u= se=C2=A0
=C2=A0 =C2=A0 =C2=A0 to stress protocol implementations = and interoperability between them.=C2=A0
=C2=A0 =C2=A0 =C2=A0 Unu= sual hackathon but that will be very, very useful for further=C2=A0
=C2=A0 =C2=A0 =C2=A0 development and quality of implementations while br= eaking completely=C2=A0
=C2=A0 =C2=A0 =C2=A0 new grounds (chaos t= esting on model based protocol specifications).
* Preconditions:<= /div>
=C2=A0 * Python knowledge
=C2=A0 * Familiarity with the= open source RIFT code on =E2=80=8Bhttps://github.com/brunorijsman/rift-pyth= on
=C2=A0 * RIFT Specification in some detail =E2=80=8BRIFT d= raft
=C2=A0 * Familiarity with creating virtual machines in AWS

____________________________________________= ___
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
--000000000000725e0705833554c7-- From nobody Sun Mar 3 23:10:20 2019 Return-Path: X-Original-To: rift@ietf.org Delivered-To: rift@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6A127598; Sun, 3 Mar 2019 23:10:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rift@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rift@ietf.org Message-ID: <155168341278.919.16836729421578911385@ietfa.amsl.com> Date: Sun, 03 Mar 2019 23:10:12 -0800 Archived-At: Subject: [Rift] I-D Action: draft-ietf-rift-rift-04.txt X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 07:10:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing In Fat Trees WG of the IETF. Title : RIFT: Routing in Fat Trees Author : The RIFT Team Filename : draft-ietf-rift-rift-04.txt Pages : 138 Date : 2019-03-03 Abstract: This document outlines a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol (1) deals with fully automated construction of fat-tree topologies based on detection of links, (2) minimizes the amount of routing state held at each level, (3) automatically prunes and load balances topology flooding exchanges over a sufficient subset of links, (4) supports automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing, (5) allows traffic steering and re-routing policies, (6) allows loop-free non-ECMP forwarding, (7) automatically re-balances traffic towards the spines based on bandwidth available and finally (8) provides mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence to e.g. bootstrap higher levels of functionality on nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rift-rift/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rift-rift-04 https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rift-rift-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 6 08:43:34 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8639512E039; Wed, 6 Mar 2019 08:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlJlq0uczsIs; Wed, 6 Mar 2019 08:43:31 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8938912AF83; Wed, 6 Mar 2019 08:43:30 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id a130so1529315lfa.10; Wed, 06 Mar 2019 08:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=21TS0UO5Brjk86uP1gr7NK6VB6Guvp29I9dgL/PZe+U=; b=HlhPTaaqCoTG8aBJ5F/FLGFgAGvoA+juTXwIH4QbswNlKShU5ti+dWynKRczR7n2eO buY/pbIH1jrPyW6ztAXZx4DEYyS0sRoKYTXF6Tx8IFqJQbL9t12v5EZYm1LctObzR8TO HDYqTYG4UJly2/ml+8IqqMsVcukQAr1cM1f4Ty8rQMj7Gfv9+AvPHuK53vgEQ3o1Y1eA 8LFFgX/JSXJ2Db15aCnTNECumlOFnFKLu+mCkWJXn7QzVKy0u7S68+c2UvOddg6UIbuR en4GcEvyUtRlwrx3Ip51luUlgy9BLRnxyauu8P0vnlk2WhD3uByNjVJGvVDHs85Fz49F 5VKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=21TS0UO5Brjk86uP1gr7NK6VB6Guvp29I9dgL/PZe+U=; b=mkWevmKerlYf1UKZIRTAJgHIMP2s/9lZoyCvMEOe4AJ2wzLfF/dGTEuk9fly17iHFc XpicOcfSMZt7lGUdXtmchsxspsVypqzs98sG16V2utOT2ODnFSy/w0bDq/kLZsi0vkU3 ZYKMd7ZC7xHzJttk9p2pLVfrTJEdFhSKtV9oVb3yzz3nh1VIwIneCc+ed/PIL0wcErvN +9d01jxw7loPUQSaD4fEnXyfKYUFWw7kwAvRewkL/Ck+mlRkZd0f3u+CSuhWn2SV+sFP rxVq8Gqvt88g88gUmd3mNoOPkW1Uv1kZklDlHPWN7o4q+tiTP5t6JVIbRaMLg3jpjedh BpZQ== X-Gm-Message-State: APjAAAWzX25EtX/DEPDlnGAYy5InLlzOpaW/X/nSLXYTZGYDlGdwCyEZ EF3cmFFXMb3dSJkW37x4jQB1IMogySSnGEGuIIIS9If+ X-Google-Smtp-Source: APXvYqwS62OQKTkAvy+3b5cfhOg3/lGdIgy79wGVHvQ0G6cacoUjcBY/9FHZ4Msjj53i1SeylEqH8GA0zfE3oUmEnnw= X-Received: by 2002:a19:4948:: with SMTP id l8mr4781832lfj.156.1551890607962; Wed, 06 Mar 2019 08:43:27 -0800 (PST) MIME-Version: 1.0 From: Greg Mirsky Date: Wed, 6 Mar 2019 08:43:18 -0800 Message-ID: To: rift-chairs@ietf.org, rift@ietf.org Cc: xiao.min2@zte.com.cn Content-Type: multipart/alternative; boundary="0000000000006b03b505836fb057" Archived-At: Subject: [Rift] Presentation slot request X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 16:43:33 -0000 --0000000000006b03b505836fb057 Content-Type: text/plain; charset="UTF-8" Dear Jeff and Jeffrey, we've started a new draft on the extended BFD that might be of interest to RIFT, particularly for the ZTP use case. Much appreciate the opportunity to present and discuss the new draft at the meeting in Prague: draft-mirmin-bfd-extended Presenter: Greg Mirsky Time: 15 min Regards, Greg --0000000000006b03b505836fb057 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Jeff and Jeffrey,
we've star= ted a new draft on the extended BFD=C2=A0that might be of interest to RIFT= , particularly for the ZTP use case. Much appreciate the opportunity to pre= sent and discuss the new draft at the meeting in Prague:

draft-mirmin-bfd-extended=C2=A0 =C2=A0 =C2=A0 Presenter: Greg Mirsky= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Time: 15 min

Regar= ds,
Greg
--0000000000006b03b505836fb057-- From nobody Wed Mar 6 09:32:00 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63505131218; Wed, 6 Mar 2019 09:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKhrXbWxlDRp; Wed, 6 Mar 2019 09:31:56 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825E1131221; Wed, 6 Mar 2019 09:31:56 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id g9so11051271eds.3; Wed, 06 Mar 2019 09:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sk8Cirec2vvuCYku/uFq+cCNHvPMroXg/9SXQSbKnL8=; b=HVrmLRiu8Hb5L2wQxfKHF5vg+MmdHdnQeb25f7wGiq4YZ2oo4JlDTgRlAkF+TQzJwq qHz+nGPfNwV6+dTeWsQHmRrV48oPen0ov4MJ0MEQ3xKs7mE9xdP1Gy7+YNFJPiBeDUlk T4+dUk8S4sF7hhfZ26dEYcn1AUU0iQus694xghFjDUYZQNfGxl5GyVAQ21eCunaY+FzD xVCVvV3DFzUXtGSbEAXZ6E1KKfWR+o1CQnEJvlxpVzMVWuXqTXTLuql7N3YgDnr6mjtk TKW/rzH5OgKxrGzRUBxK71K/4zKiA8K92qh/cwOKAA6dr37InyW676PCHHw7hSoFjySQ JQLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sk8Cirec2vvuCYku/uFq+cCNHvPMroXg/9SXQSbKnL8=; b=n+SXKiElVhsWfpgqWPGm6AaYmgUa771ZyixSug0Lase5dg3xMkx4D+iQDAS18Bbz5T qsz5cA0BfbVNciRuNUafyf48DID19LpFNPTJncJRZsE6OcreaLlZqZAgJSsBpFg6UQUW vRyNbWDHiRxCrlJIEyMV2juZETmwB8u5UTRs7be/89dqnMNgwtYyktB9JFHwhezb9rJv 9dSL7x6ZNgXk0PVL2NT4LINCUIBGFUC31aL6SuqjH+EU3SE7lUG9r5f7qptfgyUqcJTu VBg1jaMHy9n5QboU3eXwFkepEqGsolr7bAEKNeBeA2X9IpCGp0VMRvhyG6o4Mlb4Ym9+ lWLg== X-Gm-Message-State: APjAAAUd+D3lMjrM/OksmW8JpfipU2nwNnERzUWbAKxn63OivIh6A8jJ KR2AlbTWfCSmYopa4Mvr0+V5Bo50D30VHFkUEyE= X-Google-Smtp-Source: APXvYqzV/kjvxBpbVPTUtOzFdlsbgcVvI314CMi+g9BOawQPXFuiaRBHnkuzFu0mgM0hTxd5gM21jDB89zJrDsQC0eI= X-Received: by 2002:a17:906:90c6:: with SMTP id v6mr4740900ejw.241.1551893515026; Wed, 06 Mar 2019 09:31:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tony Przygienda Date: Wed, 6 Mar 2019 09:31:16 -0800 Message-ID: To: Greg Mirsky Cc: rift-chairs@ietf.org, rift@ietf.org, xiao.min2@zte.com.cn Content-Type: multipart/alternative; boundary="000000000000b146770583705de9" Archived-At: Subject: Re: [Rift] Presentation slot request X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 17:31:59 -0000 --000000000000b146770583705de9 Content-Type: text/plain; charset="UTF-8" very interested in the preso On Wed, Mar 6, 2019 at 8:43 AM Greg Mirsky wrote: > Dear Jeff and Jeffrey, > we've started a new draft on the extended BFD > that might > be of interest to RIFT, particularly for the ZTP use case. Much appreciate > the opportunity to present and discuss the new draft at the meeting in > Prague: > > draft-mirmin-bfd-extended Presenter: Greg Mirsky Time: 15 min > > Regards, > Greg > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift > --000000000000b146770583705de9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
very interested in the preso

On Wed, Mar 6, 2019 at 8:= 43 AM Greg Mirsky <gregimirsky@= gmail.com> wrote:
Dear Jeff and Jeffrey,
we&= #39;ve started a new draft on the extended BFD=C2=A0that= might be of interest to RIFT, particularly for the ZTP use case. Much appr= eciate the opportunity to present and discuss the new draft at the meeting = in Prague:

draft-mirmin-bfd-extended=C2=A0 =C2=A0 = =C2=A0 Presenter: Greg Mirsky=C2=A0 =C2=A0 =C2=A0 =C2=A0 Time: 15 min

Regards,
Greg
_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
--000000000000b146770583705de9-- From nobody Thu Mar 7 19:42:45 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A771513108C for ; Thu, 7 Mar 2019 19:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_fEiCU6NVrW for ; Thu, 7 Mar 2019 19:42:43 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5994131071 for ; Thu, 7 Mar 2019 19:42:42 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id x7so15274488eds.8 for ; Thu, 07 Mar 2019 19:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BwUnL0QrXHfnfnRDHk9bmz1orza1cRNcyugs6uh1q7M=; b=iWFHnvabN9+Iel2O4RtNNOeVwsdZt1ULkdVFSH56VBdCc5sPpGAKNHG0kKxbYHJAAs v5v6uVfVybYO/2RQsIemY0E/+cWYBW1f7wR++/nG+jmNEm1fjeIw2PtFr+Ygu5MfUXSK Jxod6y8oxMFP1Od5Ifrw03hrH6hlHd5oUHaGfnfV2R/ppNq3I90+mcCuTMvei57uiWTn xCbsBtFDOEl+xpU83adUZiguZUYDjr/VV/PwPLoSEZODdFHltqGFQeO3H8Ud6xzOyhg+ U3hAAhHVtRCLPcioepOQJT6S295Ms7ZwLjHLJjBPVXGoUXVge7QuPtggeN+DJ9S7vBB1 C/PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BwUnL0QrXHfnfnRDHk9bmz1orza1cRNcyugs6uh1q7M=; b=KUvRPVRcjLzX4ZTnfC1vTbTwmPdkrZ6DfJfRVj+sfbnfZxobZnS+1HFE7KlipUyM2Z GWz/PUyepNNUwC+cyDCz0q8aNhm6rJQbno3Fv4/FBI71NyzPRy6r49EXHUruEKJ0jywa ePeCTWB8JlL1U8xa13pmvaVQCdRqo9ZgQhrYAgcb7ShGnSFtaIrbaSWuXC9lPo7S6jJT IA5kO9JVGgQg/k2c+uDn2XBK51iaOUZA12Z6ijoHkJ/iZtxp3c18aNDDyGFm2U21bVqq v3s4DyzRNpskRJ7C6IhHiyowoVYLCkUXhvBlbWKLD6mULv/omaURMVybZTBkGUX44Pnb Bdfg== X-Gm-Message-State: APjAAAUSY4guH6GNiQ2q10/k6MCsCWL2OFsUXsxTqb4yMMR3TmUzzBra y6Kg1LEedv/J8MT7BO78gTjyP4PZ31ueSk3EHespWfFV X-Google-Smtp-Source: APXvYqz+tTMx15Ao2LoP8yQfFoYA96juCFCB53Rvj8RZpFk+TVfAbJ72sFxIAYT/hTQeBBvnYrSmHPAKGilnBSGZ2EE= X-Received: by 2002:a50:d8ce:: with SMTP id y14mr30542482edj.101.1552016561239; Thu, 07 Mar 2019 19:42:41 -0800 (PST) MIME-Version: 1.0 From: Tony Przygienda Date: Thu, 7 Mar 2019 19:42:05 -0800 Message-ID: To: rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000d17d4305838d03d8" Archived-At: Subject: [Rift] Today's core team meet ... X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 03:42:45 -0000 --000000000000d17d4305838d03d8 Content-Type: text/plain; charset="UTF-8" Small crowd met today to discuss current state of multicast in RIFT and where it's heading. Initial part is good, kind of gives in nutshell where we are, then it becomes very algorithmic ... I assume Pascal will give an overview in Prague anyway ... https://www.dropbox.com/sh/pkyidi3k2tr0yt7/AAC4QJV8T1kKknb3GkLihMmJa?dl=0 --- tony --000000000000d17d4305838d03d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Small crowd met tod= ay to discuss current state of multicast in RIFT and where it's heading= . Initial part is good, kind of gives in nutshell where we are, then it bec= omes very algorithmic ... I assume Pascal will give an overview in Prague a= nyway ...


--- tony=C2=A0


--000000000000d17d4305838d03d8-- From nobody Fri Mar 15 07:04:24 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10D4130E1C for ; Fri, 15 Mar 2019 07:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URP1Tj8gocUT for ; Fri, 15 Mar 2019 07:04:20 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E9512D4E9 for ; Fri, 15 Mar 2019 07:04:20 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2FDxdoL027439; Fri, 15 Mar 2019 07:04:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=cKrfG/EGuCiBiYHt89VQn5pLz4IENNoDkLudSGYS6DI=; b=DPT9JI9I1HOARdLnpCfE2cVmL98X5O0CXFUPVeinHvzACmRpG34dEjFI1eg3NynTeqli xbJdoVLVW3tM8H3AFNsg0CpW50bjIhDZWokixD16UxF3aS6wvsrNTap220/gNnABZGMN avYuGotsemZ0wMIX2EWpLs6Zw+w6NgPWYaEX/3c3TD/Qb8o/toFBLvYT8BQx72sC4T6R 6sS/unw16JZQqhuqEGbOlb5bVrkAhbAhvLbse25YW4rT0XFFntPjLfIuHb4sbk70L7NT EVeI/gU2mHD0OFGsv4FdH+lBCxxl2id9gNUyY69kM5RbP6OUz/3dAmeKzFVugW/XyHCa hQ== Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp2059.outbound.protection.outlook.com [104.47.48.59]) by mx0a-00273201.pphosted.com with ESMTP id 2r886jgg1c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Mar 2019 07:04:10 -0700 Received: from CO2PR05MB2455.namprd05.prod.outlook.com (10.166.95.137) by CO2PR05MB2485.namprd05.prod.outlook.com (10.166.95.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.11; Fri, 15 Mar 2019 14:04:08 +0000 Received: from CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::e84d:d580:fb0e:20ef]) by CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::e84d:d580:fb0e:20ef%7]) with mapi id 15.20.1709.011; Fri, 15 Mar 2019 14:04:08 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "rift@ietf.org" , Jeff Tantsura Thread-Topic: Preliminary Agenda Thread-Index: AdTbN7VUrOgm73pFTyCcbjrfYvfHYA== Date: Fri, 15 Mar 2019 14:04:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43986539-c198-4be2-5eb3-08d6a94f179c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:CO2PR05MB2485; x-ms-traffictypediagnostic: CO2PR05MB2485: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(346002)(366004)(396003)(376002)(189003)(199004)(497574002)(316002)(186003)(3480700005)(26005)(6506007)(110136005)(8936002)(966005)(71190400001)(2906002)(7116003)(52536014)(5660300002)(14454004)(86362001)(102836004)(99286004)(71200400001)(486006)(97736004)(66066001)(81166006)(476003)(106356001)(7696005)(221733001)(305945005)(68736007)(105586002)(8676002)(74316002)(81156014)(3846002)(14444005)(6116002)(2501003)(6436002)(53936002)(9686003)(6306002)(55016002)(4744005)(25786009)(478600001)(33656002)(7736002)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2485; H:CO2PR05MB2455.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 704xvV7Kv1UVxOZxS7wHANjxSjQIQLfTiNdWlh6c/3duSKY+JQu6lcSN6G5TCrv1fQa+FnRtzKzSwGBu0gNGRy9AH6pCLoDfD9dw5UOKNENlYjKZ+Zydj/N6ppipAisApJKW5f0o4ND0jzg8yVImwEDX9IUbQzm3crgRfbta9ADbSEk2ipjaw4jefkoCJq3A+tZ+6n6D+HKMV+06XqZ+qXLcsx/1TyVoJ7nGxBHkz8UX+mc8apWAPz1TrFzcC910Wgj555eqI5aRiQHjeSS+hXa8QfBiyMA3MN5AGuMGthsVCzx0jh81c6cx55YEg53eCOMhqzim01EFupsbOKBgZs3inKEYKPHbtV0SqF+UhN34QVuYwaGMHIbCiNEHtDIqfhtXwQa0UUOkXdsqTuwaj3oTCZVJ26eW4h+bhp6yreM= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 43986539-c198-4be2-5eb3-08d6a94f179c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 14:04:08.1937 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2485 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903150100 Archived-At: Subject: [Rift] Preliminary Agenda X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 14:04:23 -0000 Please check out the preliminary agenda: https://datatracker.ietf.org/meeti= ng/104/materials/agenda-104-rift-01 - WG Status & Admin; Chairs; 5 minutes - Update on base protocol Spec; Tony; 30 minutes - Update on Python implementation and Hackathon Chaos Monkey Testing; Tony/Bruno; 30 minutes - Multicast discussions; Jeffrey&Pascal 20 minutes - Draft-mirmin-bfd-extended; Greg Mirsky; 15 minutes Thanks! Jeff & Jeffrey From nobody Mon Mar 18 15:13:01 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACCD127133 for ; Mon, 18 Mar 2019 15:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netdef-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYDT8Gi8B_Ts for ; Mon, 18 Mar 2019 15:12:57 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D330613126C for ; Mon, 18 Mar 2019 15:12:57 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id d24so2124177otl.11 for ; Mon, 18 Mar 2019 15:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netdef-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:message-id :cc:to; bh=Zrgi7BmMorj9iwx0qXhNfgYHNNQoiih/kr8vsihq9b8=; b=DFsVGsVXz3pt6IFoLtT8pxY0Rl7CTeL3aLWaBQGyDFOBY3rt+VEne05FJc+qeDmegh wr1jRDWc56SlJR16ZDhQY3Ue4VQG/uceWuGPnz5kJZfZYF9RbWpbaZEvf11b452SE8Dw AYUvZdLpR2b5lmnoh+AqisGjuwXBJ3Ls3W8UhBZ0z8JwfdFS/2dkeqwFQAitdF8uaBkm PpymPnZcG0PNV//hUsxH7Dq/DDRr8hv+rDv8g28jwk5cKMrPGSrz6mapUEVJG5Pg/vDS +y+Crm93FTNm28iMmp9L1Lu3dNur9c/44oSITUZUPCkA4g3YLMQdRWZjb+LqImtiJ1Ij oLrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:cc:to; bh=Zrgi7BmMorj9iwx0qXhNfgYHNNQoiih/kr8vsihq9b8=; b=LaVjf1oizox+bPOLGNiBEwBWjwFcusshIeoZ20RuR4uIGI/10kLF2eDq+KcQRgaYqs QdAXAuEyphZEZxUeniSv1ob64Od9gnzcFzNrdqIec+SLj7E+OUfV6dwi94o2rCmdhvlI onYGPEgJ1Gjofht/qnjhxT4D2Ojy+JuhFoiKHfAVZl7v1445+azI5k8SbZwWc8YJk0Do oTVJrRfSNB/A0z0VWBTBtVwg9wmyb9B0OfvXrEG92t3nzF2DyUKxDWieUC6fkmXb4F1R jPnU28IhIw1POchSv+loIYp5BvlaPOqJg33ycXcPlzpPt6Hq1BttX0XmCG3ndd1bBPlB n57w== X-Gm-Message-State: APjAAAUUkhHSkftJCH1sWSt/DUthakZnoSM87rgjZlhHXXN0GSuhmPp9 s82Tf0cWbcV7eYdLPxC/Q4/OpQ== X-Google-Smtp-Source: APXvYqwPTmddDKf3TOeO/SmmHvyCu/p8tx35wQ9ZKflKYnjxxMOg1OIw5wPSNaxhdfqttA3vhjhYVQ== X-Received: by 2002:a9d:39b4:: with SMTP id y49mr5272864otb.328.1552947177064; Mon, 18 Mar 2019 15:12:57 -0700 (PDT) Received: from [192.168.1.80] (99-185-41-151.lightspeed.sntcca.sbcglobal.net. [99.185.41.151]) by smtp.gmail.com with ESMTPSA id 92sm3801647oti.60.2019.03.18.15.12.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Mar 2019 15:12:56 -0700 (PDT) From: Alistair Woodman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Mon, 18 Mar 2019 15:12:54 -0700 Message-Id: <230317C2-B4F8-4F49-8CBA-469D2552B86A@netdef.org> Cc: Bruno Rijsman To: rift@ietf.org X-Mailer: iPad Mail (14F89) Archived-At: Subject: [Rift] RIFT implementation in FRR... X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 22:13:00 -0000 All, The FRR community is considering an implementation of RIFT for FRR. We are l= ooking for sponsorship. Here is the general outline of the plan: 1) Code will be in C and open sourced. 2) The work would be done by NetDEF (a 501c3). 3) Bruno Rijsman will be the primary implementer. 4) The implementation will use the new northbound APIs in FRR and will hence expose YANG data structures. Anyone interested in considering sponsorship is encouraged to contact me dir= ectly. I will be in Prague from 3/20 to 3/29 for netdev 0x13, the Hackathon a= nd IETF 104 and I'm happy to meet in person to discuss the effort... /a= From nobody Fri Mar 22 09:15:45 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA7C1311AA for ; Fri, 22 Mar 2019 09:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.613 X-Spam-Level: * X-Spam-Status: No, score=1.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK9UGE_wcO53 for ; Fri, 22 Mar 2019 09:15:41 -0700 (PDT) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27549131156 for ; Fri, 22 Mar 2019 09:15:41 -0700 (PDT) Received: by mail-qk1-x743.google.com with SMTP id z13so1553966qki.2 for ; Fri, 22 Mar 2019 09:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6L0twGb8GXqYfeHI2Oqwa0D5UCWrN9ZvtVPtpA1e8Gk=; b=gyc7WUynFkDO1JsWSlHLpc1RdbmZC1wuOML1FVxXXas7PVwvK8REWo+R8al5Dm/A75 LyPyL0gu/BaSjgxutYPk6Sl/pBc+JCrLLTkqOOkZVvrDb2MHwfvaZ/7sTn6az4L/oyHT Lx4T2aCPe7SvvBiZn7l6BF+UytStPAIGNz0sRGBmtX6dr3wNTRNCTnC8MfbLwuZQvrAT JHmlcoaMbJnOAhgNV0QZg+MEcBx7bLyMw9RXpbPeMvjjm6yp4KttsKg2hM4akOYvBU9C lHC1fYi1j//hNXl9YEXD185tLJUtdMI19SCoKRFA5sV/huzfT9LrA4ME11j0Kwg53P5B 2Lqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6L0twGb8GXqYfeHI2Oqwa0D5UCWrN9ZvtVPtpA1e8Gk=; b=oCM5iTYbcerD5J/n5FmiRn5afcjAuDO+Ken74pDYLqkU7n5LJfeMZPCRit5vbIhrlo fNqE7YWwW6bQ/SUDD1tyaBZxxF/sWw+JcVICGfGmZ9O46FE1xIRiLM7c6/392dh4lux7 k6IJ4s60+4O9sAVsnPrNFVmI3BYprwrHBOK08FxZIdA5Sx8hq4F+mMwW1jrABnF9Ow6x Jl6fB5bKIOMx/nBEhgJDDrYIGgwn0ILqOKRMpLIxYGTkXMDVbuDqqEqz23ukxQBT3pqI 9s9dTExsRRkmFzHeAOERyEt7Z7iaMbM1bp5Ai7n+i7qEyOBBt/KA9UA2nSw18bWRb/Su +Aqw== X-Gm-Message-State: APjAAAWDh5qBlbWYrkVDd6MuCSbBd+GCGNNA5/wKR+1Fa4T77AlBEGa+ KDIn1lthAl4j7i0fjOwwBpo= X-Google-Smtp-Source: APXvYqyRZDAL6hAvx6e3A5sRZh3ggIwQ2HcMVonER2mGxXDNMG18hq+mVsVwoe8qhXCMifxTnZxc0Q== X-Received: by 2002:ae9:eb41:: with SMTP id b62mr8100785qkg.309.1553271339939; Fri, 22 Mar 2019 09:15:39 -0700 (PDT) Received: from [192.168.20.114] ([190.12.179.217]) by smtp.gmail.com with ESMTPSA id l129sm4620113qkb.44.2019.03.22.09.15.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 09:15:39 -0700 (PDT) From: Bruno Rijsman Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A28AFD7D-F8A0-4F85-B6BD-D28EC068B1EE" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 22 Mar 2019 13:15:34 -0300 In-Reply-To: Cc: rift@ietf.org To: Tony Przygienda References: <0A0D8BBD-E6F3-4272-BD12-EB093AE7E8D4@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Rift] [hackathon] [RIFT] Routing in Fat Trees "chaos testing" hackathon at IETF 104 in Prague X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 16:15:44 -0000 --Apple-Mail=_A28AFD7D-F8A0-4F85-B6BD-D28EC068B1EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 See >>> inline for responses. Question for you: is it possible / easy to run RIFT-Vendor as a = standalone node in a network namespace in AWS? I assume it is, but = have not yet tried it. That we we can do Python - Vendor interop = testing for larger topologies. This is something we should try in the = hackathon. > On Mar 3, 2019, at 4:05 PM, Tony Przygienda = wrote: >=20 > Preparing stuff here along instructions, ran it on a t2.micro (spot = request is cheap and works well)=20 >=20 > b) no command line completion on interactive ;-{=20 >>> Right, this is pretty annoying and it is on my TODO list to fix, but = bigger fish to fry first. > c) the meta config file restricts to 3 levels only (5 stage folded), = good enough for now but testing more than 3 levels is very interesting = proposition for the future >>> Good point. I added "Support generating 4-level / 7-state = topologies.=E2=80=9D to my TODO list. But first, I need to get 3-level / = 5-stage working more reliable. Currently there there is a pretty = persistent issue with ping failures and we need to get to the bottom of = that before we go bigger. (Discussed in more detail below). > d) running the example I see tons of those=20 >=20 > 2019-03-03 18:35:08,355:ERROR:node.if.tx:[spine-2-2:veth-105g-4e] = Error [Errno 111] Connection refused sending IPv6 TIE ProtocolPacket( >=20 > and then=20 >=20 > 2019-03-03 18:35:08,274:ERROR:node.if.tx:[super-4:veth-4e-105g] Error = [Errno 111] Connection refused sending IPv4 TIDE ProtocolPacket >>> Yes, this issue was discussed in detail on the RIFT core-team = mailing list. Search your inbox for an e-mail dated 6-Dec-2018 and = titled "[RIFT-TEAM] UDP send error issue (was Update: SPF is = code-complete)=E2=80=9D. I explained what the cause of the issue was and = your response was "Not an issue, implementation can do what it wants ;-) = flooding retx=E2=80=99s=E2=80=9D. I have an item on my TODO list to open = the UDP RX socket earlier in the FSM (as described in the email) but I = have not yet gotten around to implementing that. >=20 > but I see no UDP losses=20 >=20 > Udp: > 16103 packets received > 88 packets to unknown port received > 0 packet receive errors > 16224 packets sent > 0 receive buffer errors > 0 send buffer errors >=20 > Consequently I see on start often 2-3 pairs of leafs that can't ping = each other, I did not analyze further, every time different pairs, = sometimes all come up.=20 >>> I see that as well. This the main thing I / we need to concentrate = on next. Clearly, there is some pretty persistent issue with = convergence. Today (Friday), I will be enhancing the generated check.sh = script to check more things than just pings: I will add check to make = sure that all adjacencies are up, all LSDBs have the correct contents, = all routes are present, etc. etc. etc. That way we can more easily get = to the root of the issue. This is something that we could work on more = during the hackathon. We will need these more sophisticated tests are = part of the chaos monkey testing infrastructure before we move on to = larger 5-level / 7-stage topologies (those are simply too large to check = by hand)> >=20 > monkey testing works fine ... Next iteration will be of course doing = that once positive disaggregation is implemented in python RIFT ;-) >>> Yep. After IETF-104, disaggregation (positive and negative) is the = last remaining big ticket item (along with cleaning up a 100 or so small = TODO items). Once we have the enhanced automated checks in place that I = mentioned in the previous point, re-running and debugging the chaos = monkey tests with extra features (e.g. disaggregation) should be pretty = straightforward. >=20 > I think @ hackathon first thing we have to write a simple script that = collects the kernel routing tables & compares them for # expected = entries since leaf-2-leaf has such a wide path diversity it's hard to = debug, observe that due to ECMP hashing you can get a leaf being able to = ping 2 other leafs in another pod but not the third since it takes = different spine/superspine combination. Generally, to test connectivity = on fabric well, you need a fan-out of UDP source/sink pairs that lead to = exhaustive ECMP coverage (as well as tests quality of load balancing = once we get to the bandwidth balancing in python RIFT) >>> Agree 100%. This would be part of the =E2=80=9Cenhanced automated = checks=E2=80=9D that I mentioned previously. >=20 > Yes, connectivity to spine loopbacks and so on has been discussed on = the core team list and is in the draft (-04 is in publication queue) ... = Generally, most robust IP fabric architecture is leaf-2-leaf since = relying on every leaf being able to reach every spine leads unavoidably = into exposing more and more topology towards the leafs with according = scalabiltiy problems on the leafs. So, a fabric where every leaf can = reach every leaf is in a sense "working fine" even if links are lost or = some spines crash. That modulo bandwidth balancing since we want to = account for load being balanced (unsurprisingly, RIFT does all that ;-) = if we talk a single prefix (loopback) on a spine/superspine then PGP and = even simpler stuff can work well but if we assume that specific = superspines terminate lots prefixes and rely on leafs being able to = reach them then the fabric "inverts" and scalbility is lost. Variants of = the problem exist by e.g. having superspines exposing anycast addresses. = Once deployment experience starts to come in I can see a "operational = deployment" draft coming up (I think someone already suggested to write = one) ...=20 >>> I will mentioned =E2=80=9Clack of connectivity to spine loopbacks=E2=80= =9D as one of the lessons learned in my slide deck. Whether or not that = is a problem should be a point of discussion during the RIFT WG meeting. >=20 > thanks=20 >=20 > --- tony=20 >>> Looking forward to =E2=80=9Cseeing=E2=80=9D everyone tomorrow at the = hackathon. Reminder: please setup a zoom meeting or something similar; I = will be remote (Argentina). >=20 >=20 >=20 >=20 >=20 > On Mon, Feb 25, 2019 at 5:15 PM Bruno Rijsman > wrote: > Hi everyone, > =20 > At the Routing In Fat Trees (RIFT) IETF 104 hackathon in Prague we = will be working on "chaos monkey" testing of two RIFT implementations: = the RIFT-Python open source implementation and a vendor RIFT = implementation. >=20 > This hackathon is inspired by the concept of chaos engineering and in = particular by the chaos monkey tool, which intentionally and randomly = shuts down servers in a production environment. This is intended to = build confidence in the system's capability to withstand turbulent and = unexpected conditions. >=20 > In this hackathon we will do something similar for RIFT networks. We = will build a large fat tree network of RIFT routers. Then we will = randomly insert failures into the network and make sure that the network = behaves correctly. We will make sure the RIFT routers don't crash or = otherwise behave badly. And we will make sure that the routers = forwarding tables and link-state databases converge correctly. >=20 > We will use (and possibly enhance) the chaos testing framework as well = as the visualization and verification tools that are already part of the = RIFT-Python open source project. >=20 > Even if you are not much interested in the RIFT routing protocol, but = you are interested in testing large network topologies using = container-like technology, or in visualization tools, or in chaos = testing, this might be the right hackathon for you. >=20 > A detailed description of the planned activities at the hackathon is = available at: http://bit.ly/rift-hackathon-ietf-104 = >=20 > The project is listed on the IETF 104 hackathon wiki page: = https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon = (info copied below) > =20 > Feel free to join us. >=20 > Bruno Rijsman >=20 >=20 > Routing In Fat Trees (RIFT) Chaos Monkey Testing >=20 > * Champions > * Tony Przygienda > (will join in person) > * Bruno Rijsman > (will join remotely) > * Project(s) > * =E2=80=8BRIFT is a STD track WG working on a modern IP fabric/DC = routing protocol > * =E2=80=8BDetailed description of the planned activities at the = hackathon at=20 > http://bit.ly/rift-hackathon-ietf-104 = > * We have two implementations now: > * RIFT-Python open source > * Vendor implementation > * The open source one has a chaos monkey framework in place we can = use=20 > to stress protocol implementations and interoperability between = them.=20 > Unusual hackathon but that will be very, very useful for further=20= > development and quality of implementations while breaking = completely=20 > new grounds (chaos testing on model based protocol = specifications). > * Preconditions: > * Python knowledge > * Familiarity with the open source RIFT code on = =E2=80=8Bhttps://github.com/brunorijsman/rift-python = > * RIFT Specification in some detail =E2=80=8BRIFT draft > * Familiarity with creating virtual machines in AWS >=20 > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift = > _______________________________________________ > hackathon mailing list > hackathon@ietf.org > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fhackathon&data=3D02%7C01%7C%7Ca04585e204= 4e4aa6bbd108d6a00b514e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636872= 367812033330&sdata=3DonHIVdyEd8jrhEzwvC1Fx1CKAGMFg1fV%2B6Fn%2BolnqhM%3= D&reserved=3D0 --Apple-Mail=_A28AFD7D-F8A0-4F85-B6BD-D28EC068B1EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 See = >>> inline for responses.

Question for you: is it possible / easy = to run RIFT-Vendor as a standalone node in a network namespace in AWS? =  I assume it is, but  have not yet tried it.  That we we = can do Python - Vendor interop testing for larger topologies.  This = is something we should try in the hackathon.

On = Mar 3, 2019, at 4:05 PM, Tony Przygienda <tonysietf@gmail.com>= wrote:

Preparing stuff here along instructions, ran = it on a t2.micro (spot request is cheap and works well)

b) no command line = completion on interactive ;-{
>>> Right, this is pretty annoying and = it is on my TODO list to fix, but bigger fish to fry first.

c) the meta config file restricts to 3 levels only (5 stage = folded), good enough for now but testing more than 3 levels is very = interesting proposition for the = future

>>> Good point. I added "Support = generating 4-level / 7-state topologies.=E2=80=9D to my TODO list. But = first, I need to get 3-level / 5-stage working more reliable. Currently = there there is a pretty persistent issue with ping failures and we need = to get to the bottom of that before we go bigger.  (Discussed in = more detail below).

d) running the example I see tons = of those

2019-03-03 = 18:35:08,355:ERROR:node.if.tx:[spine-2-2:veth-105g-4e] Error [Errno 111] = Connection refused sending IPv6 TIE ProtocolPacket(

and then

2019-03-03 = 18:35:08,274:ERROR:node.if.tx:[super-4:veth-4e-105g] Error [Errno 111] = Connection refused sending IPv4 TIDE = ProtocolPacket
=
>>> Yes, this issue was discussed in = detail on the RIFT core-team mailing list. Search your inbox for an = e-mail dated 6-Dec-2018 and titled "[RIFT-TEAM] UDP send error issue = (was Update: SPF is code-complete)=E2=80=9D. I explained what the cause of the issue was = and your response was "Not an issue, implementation = can do what it wants ;-) flooding retx=E2=80=99s=E2=80=9D. I have an = item on my TODO list to open the UDP RX socket earlier in the FSM (as = described in the email) but I have not yet gotten around to implementing = that.


but I = see no UDP losses

Udp:
    = 16103 packets received
    88 packets to = unknown port received
    0 packet receive = errors
    16224 packets sent
    0 receive buffer errors
    0 send buffer errors

Consequently I see on start  often 2-3 pairs of leafs = that can't ping each other, I did not analyze further, every time = different pairs, sometimes all come up.
>>> I see that as well.  This the = main thing I / we need to concentrate on next. Clearly, there is some = pretty persistent issue with convergence.  Today (Friday), I will = be enhancing the generated check.sh script to check more things than = just pings: I will add check to make sure that all adjacencies are up, = all LSDBs have the correct contents, all routes are present, etc. etc. = etc.  That way we can more easily get to the root of the issue. =  This is something that we could work on more during the hackathon. =  We will need these more sophisticated tests are part of the chaos = monkey testing infrastructure before we move on to larger 5-level / = 7-stage topologies (those are simply too large to check by = hand)>


monkey = testing works fine ... Next iteration will be of course doing that once = positive disaggregation is implemented in python RIFT ;-)
>>> Yep. After IETF-104, disaggregation = (positive and negative) is the last remaining big ticket item (along = with cleaning up a 100 or so small TODO items).  Once we have the = enhanced automated checks in place that I mentioned in the previous = point, re-running and debugging the chaos monkey tests with extra = features (e.g. disaggregation) should be pretty = straightforward.


I think @ hackathon first thing we have to write a simple = script that collects the kernel routing tables & compares them for # = expected entries since leaf-2-leaf has such a wide path diversity it's = hard to debug, observe that due to ECMP hashing you can get a leaf being = able to ping 2 other leafs in another pod but not the third since it = takes different spine/superspine combination. Generally, to test = connectivity on fabric well, you need a fan-out of UDP source/sink pairs = that lead to exhaustive ECMP coverage (as well as tests quality of load = balancing once we get to the bandwidth balancing in python = RIFT)

>>> Agree 100%.  This would be part = of the =E2=80=9Cenhanced automated checks=E2=80=9D that I mentioned = previously.

Yes, connectivity to = spine loopbacks and so on has been discussed on the core team list and = is in the draft (-04 is in publication queue) ... Generally, most robust = IP fabric architecture is leaf-2-leaf since relying on every leaf being = able to reach every spine leads unavoidably into exposing more and more = topology towards the leafs with according scalabiltiy problems on the = leafs. So, a fabric where every leaf can reach every leaf is in a sense = "working fine" even if links are lost or some spines crash. That modulo = bandwidth balancing since we want to account for load being balanced = (unsurprisingly, RIFT does all that ;-) if we talk a single prefix = (loopback) on a spine/superspine then PGP and even simpler stuff can = work well but if we assume that specific superspines terminate lots = prefixes and rely on leafs being able to reach them then the fabric = "inverts" and scalbility is lost. Variants of the problem exist by e.g. = having superspines exposing anycast addresses. Once deployment = experience starts to come in I can see a "operational deployment" draft = coming up (I think someone already suggested to write one) ...
>>> I will mentioned =E2=80=9Clack of = connectivity to spine loopbacks=E2=80=9D as one of the lessons learned = in my slide deck.  Whether or not that is a problem should be a = point of discussion during the RIFT WG meeting.


thanks

--- = tony
>>> Looking forward to =E2=80=9Cseeing=E2=80= =9D everyone tomorrow at the hackathon. Reminder: please setup a zoom = meeting or something similar; I will be remote (Argentina).






On Mon, Feb = 25, 2019 at 5:15 PM Bruno Rijsman <brunorijsman@gmail.com> wrote:
Hi everyone,
 
At the Routing In Fat Trees (RIFT) IETF 104 hackathon in = Prague we will be working on "chaos monkey" testing of two RIFT = implementations: the RIFT-Python open source implementation and a vendor = RIFT implementation.

This hackathon is inspired by the concept of chaos = engineering and in particular by the chaos monkey tool, which = intentionally and randomly shuts down servers in a production = environment. This is intended to build confidence in the system's = capability to withstand turbulent and unexpected conditions.

In this hackathon we = will do something similar for RIFT networks. We will build a large fat = tree network of RIFT routers. Then we will randomly insert failures into = the network and make sure that the network behaves correctly. We will = make sure the RIFT routers don't crash or otherwise behave badly. And we = will make sure that the routers forwarding tables and link-state = databases converge correctly.

We will use (and possibly enhance) the = chaos testing framework as well as the visualization and verification = tools that are already part of the RIFT-Python open source = project.

Even = if you are not much interested in the RIFT routing protocol, but you are = interested in testing large network topologies using container-like = technology, or in visualization tools, or in chaos testing, this might = be the right hackathon for you.

A detailed description of = the planned activities at the hackathon is available at: http://bit.ly/rift-hackathon-ietf-104

The project is listed on = the IETF 104 hackathon wiki page: https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon&n= bsp;(info copied below)
 
Feel free to join us.

Bruno Rijsman


Routing In Fat Trees (RIFT) Chaos Monkey Testing

* Champions
  * Tony Przygienda <prz at juniper.net> (will join in person)
  * Bruno Rijsman <brunorijsman at gmail.com> (will join remotely)
* = Project(s)
  * =E2=80=8BRIFT is a STD track WG = working on a modern IP fabric/DC routing protocol
  * =E2=80=8BDetailed description of the planned = activities at the hackathon at 
    = http://bit.ly/rift-hackathon-ietf-104
  * We have two implementations now:
    * RIFT-Python open source
    * Vendor implementation
    * The open source one has a chaos monkey = framework in place we can use 
    =   to stress protocol implementations and interoperability between = them. 
      Unusual hackathon = but that will be very, very useful for further 
      development and quality of = implementations while breaking completely 
      new grounds (chaos testing on model = based protocol specifications).
* = Preconditions:
  * Python knowledge
  * Familiarity with the open source RIFT code on =E2=80=8B= https://github.com/brunorijsman/rift-python
  * RIFT Specification in some detail =E2=80=8BRIFT = draft
  * Familiarity with creating virtual = machines in AWS

_____________________________________________= __
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
_______________________________________________
hackathon = mailing list
hackathon@ietf.org
https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fhackathon&amp;data=3D02%7C01%= 7C%7Ca04585e2044e4aa6bbd108d6a00b514e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7= C1%7C0%7C636872367812033330&amp;sdata=3DonHIVdyEd8jrhEzwvC1Fx1CKAGMFg1= fV%2B6Fn%2BolnqhM%3D&amp;reserved=3D0

= --Apple-Mail=_A28AFD7D-F8A0-4F85-B6BD-D28EC068B1EE-- From nobody Fri Mar 22 11:02:56 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EAD1313D9 for ; Fri, 22 Mar 2019 11:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZUkaIFr4fjb for ; Fri, 22 Mar 2019 11:02:52 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F95F1313D6 for ; Fri, 22 Mar 2019 11:02:52 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id v32so3486299qtc.10 for ; Fri, 22 Mar 2019 11:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jdYC3LP0T7/wstlhNKfhqEPyvy5v7gvR3xTZmIb+BNY=; b=ZFw4LsL3Dl7wPmv7vkV0F71JjQ+6VGRtJCPTYEQgirTCtJInQpq8JpsVYsSoGEEsAs OMCj4XPefYiFjsf10iamLXsmPzwlZzSEuI/6P68SRu5CNeAOSNV45g/nS4bd4UhUG+5k FnLjqd9Cr+YxWHXkE2bNFkrKPwdrgOGGXsuObCMteZgE05uI8pNtTNjDgsMz4zpFjknD ZrSEB6O6Crk4vz5a3JtwW+q9P6xu5wrXDVWM0WqM50Q5C1spAiBSMns4dPlA9qyKp4V7 72M/qekIITZks33mSKG0pyamDLZyaOQTAIE8cqQ/8Ylod6RkKshpvr2nom1nV5riIeww f+OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jdYC3LP0T7/wstlhNKfhqEPyvy5v7gvR3xTZmIb+BNY=; b=OmlhuNn8F6aljesCkZvIghVmsN/izYgaJNpCTitE2+5VtmX/vv7mNosAayAD1RI9vC E0TJilnEeP0UjTtr8eI1WaN/uyTDWoshgVlx8BcpewLyXEtSWUbDVdgGAmgpaIIuMHsY ropj/3iZUxZJ7k0NKDQLb6rgo2sdbdhKaxGhq0ihESb8FllkwM8juxq2gHhsExae3T7v c6Upk1zrnHh8Cu/T9PLVYIO4sgenLT3OqxRSUV4piE9IFX4X9xSoTk7JdmPTQ1TKZdhG fWDOqs8JfRSAo/g58bYbT52swwsqegmThYK2lb4/I19fiouSSWFTzjlGk9Y1Lncr7f1N pWsg== X-Gm-Message-State: APjAAAULUbImDZDVxhh0DM4k8ts868vlEtAXJmw1QuEGMVjdUuCEqJlL 2rHzNnarehObNETBLTEFZuib+D3F X-Google-Smtp-Source: APXvYqzFCt8qKkc+S8PQosPkbgzSHPUhudozMqtyZpfE8c9ghIlwrWKH1FGhxkcd//IsY+ZD612TJw== X-Received: by 2002:a0c:d0bd:: with SMTP id z58mr9205126qvg.121.1553277771053; Fri, 22 Mar 2019 11:02:51 -0700 (PDT) Received: from [192.168.20.114] ([200.63.168.130]) by smtp.gmail.com with ESMTPSA id c207sm1566531qkg.14.2019.03.22.11.02.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 11:02:50 -0700 (PDT) From: Bruno Rijsman Message-Id: <1E97B76A-F32E-4108-BF18-42EEF8F3BEAC@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B1815312-6A0C-40A0-97C7-F866D5B5DA75" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 22 Mar 2019 15:02:46 -0300 In-Reply-To: Cc: rift@ietf.org To: Tony Przygienda References: <0A0D8BBD-E6F3-4272-BD12-EB093AE7E8D4@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Rift] [hackathon] [RIFT] Routing in Fat Trees "chaos testing" hackathon at IETF 104 in Prague X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 18:02:54 -0000 --Apple-Mail=_B1815312-6A0C-40A0-97C7-F866D5B5DA75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> but I see no UDP losses=20 >>=20 >> Udp: >> 16103 packets received >> 88 packets to unknown port received >> 0 packet receive errors >> 16224 packets sent >> 0 receive buffer errors >> 0 send buffer errors PS: Maybe you already did this, but just to be sure: when you look at = the UDP statistics, make sure you are looking at the correct network = namespace, for example: (env) root@ip-xx-xx-xx-xx:~/rift-python# ip netns exec netns-1001 = netstat --statistics --udp IcmpMsg: InType0: 160 InType3: 265 InType8: 160 InType11: 438 OutType0: 160 OutType3: 137 OutType8: 160 Udp: 11793 packets received 204 packets to unknown port received 0 packet receive errors 6019 packets sent 0 receive buffer errors 0 send buffer errors UdpLite: IpExt: InMcastPkts: 3365 OutMcastPkts: 3372 InOctets: 2386337 OutOctets: 1525221 InMcastOctets: 646036 OutMcastOctets: 643080 InNoECTPkts: 6577= --Apple-Mail=_B1815312-6A0C-40A0-97C7-F866D5B5DA75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

but I see no UDP losses

Udp:
    16103 packets = received
    88 packets to unknown port = received
    0 packet receive errors
    16224 packets sent
    0 receive buffer errors
    0 send buffer errors


PS: Maybe you already did this, = but just to be sure: when you look at the UDP statistics, make sure you = are looking at the correct network namespace, for = example:

(env) root@ip-xx-xx-xx-xx:~/rift-python# ip netns exec netns-1001 netstat = --statistics --udp
IcmpMsg:
  =   InType0: 160
  =   InType3: 265
  =   InType8: 160
  =   InType11: 438
  =   OutType0: 160
  =   OutType3: 137
  =   OutType8: 160
Udp:
  =   11793 packets received
  =   204 packets to unknown port received
    0 packet receive = errors
  =   6019 packets sent
  =   0 receive buffer errors
  =   0 send buffer errors
UdpLite:
IpExt:
  =   InMcastPkts: 3365
  =   OutMcastPkts: 3372
  =   InOctets: 2386337
  =   OutOctets: 1525221
  =   InMcastOctets: 646036
  =   OutMcastOctets: 643080
  =   InNoECTPkts: 6577
= --Apple-Mail=_B1815312-6A0C-40A0-97C7-F866D5B5DA75-- From nobody Fri Mar 22 15:05:54 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930CC13158A for ; Fri, 22 Mar 2019 15:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LmkANNEMQjX for ; Fri, 22 Mar 2019 15:05:50 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E32131589 for ; Fri, 22 Mar 2019 15:05:50 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id j89so2887117edb.9 for ; Fri, 22 Mar 2019 15:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wCALEb86jU6WxNtcupScqOQtzPSs7LZaX3Q47IywFoA=; b=p4nL/V4kK/tJckDWEw7D3enr+BUwhwgAWbuBY+fAuR+qoJCmcI4ns2hU6Y8ZGr8vWk BAJwbfU+n04aIJzGsLYppLGBdEnVc45drAQRuUeq5+4tK0RRcxqfufQQGWkDunxbvyLF p8buuZoKYClmU/nuripLAFHL/H7IHsax7sFEcIphanrgWxs6aeOOIaeLvBsGKcpBzqQM ajGnoBC/egHxcI84oTqVNb92QF5bTgvNTe2s9fCfiEJh3wyPPH9Ktxdbznz70mSGphY0 UUhfbPmvGFI7E2Skx/4+NjlO+6pKjo8vOo++qxoyasEws/OvG0+G4/fVI5ySxxT5b64+ kbjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wCALEb86jU6WxNtcupScqOQtzPSs7LZaX3Q47IywFoA=; b=GtJIV4m6Pktw/g92C1qTqPp9LN/lwxPqZkKROdLa/Mv325wQAUhXtrWVAFo4iKQfkG 6hzH5Yt5kxAZP9TsqGXiDfQo19U0a0OHg+aUIxIGsbSiiR43C+Ma63YHp797cZ9GAU6F +14NL7FmVaUqgIR3117WUWHueU67ggMwiLTzqbzUmShKV/KjdBTD8N3u0YIb2h3l5Eu9 ejqFlnHj/ZUemHphMafMdU2CQbKzwg+vLi1vocsWozeMPESM9bnghzfzOI3dJ/w5zU0U i0hg9ll5DmBzxXY3jQwG+0SMw6jiTnMAVCHYKLI4J7udb17wmyk0kovVnkHRKzNj8bAj 2FWw== X-Gm-Message-State: APjAAAXZhmtHxTEFJFG4CL/uiApA7iv+hva5zmUAFIVyjYukqLQJ9O3e G9vF4BbwFrk1e5Evt1wgz4g8ZERCtYvvIYqrLVPTrfoN X-Google-Smtp-Source: APXvYqzcstPaewy4L3un7xyS7kg+0xFTHe9Q2E6JBkIZmu/CxULpP9GialHxJcM/EZsnS0qAI/tOSgCz1j2Z8U2DRwA= X-Received: by 2002:a17:906:4c82:: with SMTP id q2mr6824210eju.215.1553292348665; Fri, 22 Mar 2019 15:05:48 -0700 (PDT) MIME-Version: 1.0 References: <0A0D8BBD-E6F3-4272-BD12-EB093AE7E8D4@gmail.com> In-Reply-To: From: Tony Przygienda Date: Fri, 22 Mar 2019 23:05:12 +0100 Message-ID: To: Bruno Rijsman Cc: rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000acb4690584b60efe" Archived-At: Subject: Re: [Rift] [hackathon] [RIFT] Routing in Fat Trees "chaos testing" hackathon at IETF 104 in Prague X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 22:05:53 -0000 --000000000000acb4690584b60efe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2019 at 5:15 PM Bruno Rijsman wrote: > See >>> inline for responses. > > Question for you: is it possible / easy to run RIFT-Vendor as a standalon= e > node in a network namespace in AWS? I assume it is, but have not yet > tried it. That we we can do Python - Vendor interop testing for larger > topologies. This is something we should try in the hackathon. > > not bringing it to hackathon. python itself will be enough work. we can get to the interop later > On Mar 3, 2019, at 4:05 PM, Tony Przygienda wrote: > > Preparing stuff here along instructions, ran it on a t2.micro (spot > request is cheap and works well) > > b) no command line completion on interactive ;-{ > > > >>> Right, this is pretty annoying and it is on my TODO list to fix, but > bigger fish to fry first. > > c) the meta config file restricts to 3 levels only (5 stage folded), good > enough for now but testing more than 3 levels is very interesting > proposition for the future > > > >>> Good point. I added "Support generating 4-level / 7-state topologies.= =E2=80=9D > to my TODO list. But first, I need to get 3-level / 5-stage working more > reliable. Currently there there is a pretty persistent issue with ping > failures and we need to get to the bottom of that before we go bigger. > (Discussed in more detail below). > > d) running the example I see tons of those > > 2019-03-03 18:35:08,355:ERROR:node.if.tx:[spine-2-2:veth-105g-4e] Error > [Errno 111] Connection refused sending IPv6 TIE ProtocolPacket( > > and then > > 2019-03-03 18:35:08,274:ERROR:node.if.tx:[super-4:veth-4e-105g] Error > [Errno 111] Connection refused sending IPv4 TIDE ProtocolPacket > > > >>> Yes, this issue was discussed in detail on the RIFT core-team mailing > list. Search your inbox for an e-mail dated 6-Dec-2018 and titled "*[RIFT= -TEAM] > UDP send error issue (was Update: SPF is code-complete)*=E2=80=9D. I expl= ained > what the cause of the issue was and your response was *"Not an issue, > implementation can do what it wants ;-) flooding retx=E2=80=99s=E2=80=9D*= . I have an item > on my TODO list to open the UDP RX socket earlier in the FSM (as describe= d > in the email) but I have not yet gotten around to implementing that. > > we need to talk that through Rtx'ing is fine but if the other side doesn't have a socket open we shouldn't be getting the "refused sending". Let's chat tommorow ... I'll come in afternoon around 2.30PM > > but I see no UDP losses > > Udp: > 16103 packets received > 88 packets to unknown port received > 0 packet receive errors > 16224 packets sent > 0 receive buffer errors > 0 send buffer errors > > Consequently I see on start often 2-3 pairs of leafs that can't ping eac= h > other, I did not analyze further, every time different pairs, sometimes a= ll > come up. > > > >>> I see that as well. This the main thing I / we need to concentrate o= n > next. Clearly, there is some pretty persistent issue with convergence. > Today (Friday), I will be enhancing the generated check.sh script to chec= k > more things than just pings: I will add check to make sure that all > adjacencies are up, all LSDBs have the correct contents, all routes are > present, etc. etc. etc. That way we can more easily get to the root of t= he > issue. This is something that we could work on more during the hackathon= . > We will need these more sophisticated tests are part of the chaos monkey > testing infrastructure before we move on to larger 5-level / 7-stage > topologies (those are simply too large to check by hand)> > > agreed, I think that's what we'll focus on first. > > monkey testing works fine ... Next iteration will be of course doing that > once positive disaggregation is implemented in python RIFT ;-) > > > >>> Yep. After IETF-104, disaggregation (positive and negative) is the > last remaining big ticket item (along with cleaning up a 100 or so small > TODO items). Once we have the enhanced automated checks in place that I > mentioned in the previous point, re-running and debugging the chaos monke= y > tests with extra features (e.g. disaggregation) should be pretty > straightforward. > > > I think @ hackathon first thing we have to write a simple script that > collects the kernel routing tables & compares them for # expected entries > since leaf-2-leaf has such a wide path diversity it's hard to debug, > observe that due to ECMP hashing you can get a leaf being able to ping 2 > other leafs in another pod but not the third since it takes different > spine/superspine combination. Generally, to test connectivity on fabric > well, you need a fan-out of UDP source/sink pairs that lead to exhaustive > ECMP coverage (as well as tests quality of load balancing once we get to > the bandwidth balancing in python RIFT) > > > >>> Agree 100%. This would be part of the =E2=80=9Cenhanced automated ch= ecks=E2=80=9D > that I mentioned previously. > > > Yes, connectivity to spine loopbacks and so on has been discussed on the > core team list and is in the draft (-04 is in publication queue) ... > Generally, most robust IP fabric architecture is leaf-2-leaf since relyin= g > on every leaf being able to reach every spine leads unavoidably into > exposing more and more topology towards the leafs with according > scalabiltiy problems on the leafs. So, a fabric where every leaf can reac= h > every leaf is in a sense "working fine" even if links are lost or some > spines crash. That modulo bandwidth balancing since we want to account fo= r > load being balanced (unsurprisingly, RIFT does all that ;-) if we talk a > single prefix (loopback) on a spine/superspine then PGP and even simpler > stuff can work well but if we assume that specific superspines terminate > lots prefixes and rely on leafs being able to reach them then the fabric > "inverts" and scalbility is lost. Variants of the problem exist by e.g. > having superspines exposing anycast addresses. Once deployment experience > starts to come in I can see a "operational deployment" draft coming up (I > think someone already suggested to write one) ... > > > >>> I will mentioned =E2=80=9Clack of connectivity to spine loopbacks=E2= =80=9D as one of > the lessons learned in my slide deck. Whether or not that is a problem > should be a point of discussion during the RIFT WG meeting. > > > thanks > > --- tony > > > >>> Looking forward to =E2=80=9Cseeing=E2=80=9D everyone tomorrow at the = hackathon. > Reminder: please setup a zoom meeting or something similar; I will be > remote (Argentina). > > I'll open zoom as soon I come in from my flight ... --000000000000acb4690584b60efe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 22, 2019 at 5:15 PM Bruno= Rijsman <brunorijsman@gmail.c= om> wrote:
See >>> inline for res= ponses.

Question for you: is it possible / easy to run R= IFT-Vendor as a standalone node in a network namespace in AWS?=C2=A0 I assu= me it is, but =C2=A0have not yet tried it.=C2=A0 That we we can do Python -= Vendor interop testing for larger topologies.=C2=A0 This is something we s= hould try in the hackathon.

not bringing it to hackathon. python itself will be enough work= . we can get to the interop later
=C2=A0
On Mar 3, 2019, at 4:05 PM, Tony= Przygienda <to= nysietf@gmail.com> wrote:

Preparing stuff here alo= ng instructions, ran it on a t2.micro (spot request is cheap and works well= )

b) no command line completion on interactive ;-{
<= /div>

&= gt;>> Right, this is pretty annoying and it is on my TODO list to fix= , but bigger fish to fry first.

c) the meta config file restricts to 3 levels only (5 stage f= olded), good enough for now but testing more than 3 levels is very interest= ing proposition for the future

>>> Good point. I added "Suppor= t generating 4-level / 7-state topologies.=E2=80=9D to my TODO list. But fi= rst, I need to get 3-level / 5-stage working more reliable. Currently there= there is a pretty persistent issue with ping failures and we need to get t= o the bottom of that before we go bigger. =C2=A0(Discussed in more detail b= elow).

d) running th= e example I see tons of those

2019-03-03 18:3= 5:08,355:ERROR:node.if.tx:[spine-2-2:veth-105g-4e] Error [Errno 111] Connec= tion refused sending IPv6 TIE ProtocolPacket(

and = then

2019-03-03 18:35:08,274:ERROR:node.if.tx= :[super-4:veth-4e-105g] Error [Errno 111] Connection refused sending IPv4 T= IDE ProtocolPacket

>>> Yes, this issue was discussed in detail on t= he RIFT core-team mailing list. Search your inbox for an e-mail dated 6-Dec= -2018 and titled "= [RIFT-TEAM] UDP send error issue (was Update: SPF is code-complete)=E2=80=9D. I explained what the caus= e of the issue was and your response was "Not an issue, impl= ementation can do what it wants ;-) flooding retx=E2=80=99s=E2=80=9D. I= have an item on my TODO list to open the UDP RX socket earlier in the FSM = (as described in the email) but I have not yet gotten around to implementin= g that.


we need= to talk that through Rtx'ing is fine but if the other side doesn't= have a socket open we shouldn't be getting the "refused sending&q= uot;. Let's chat tommorow ... I'll come in afternoon around 2.30PM =
=C2=A0

but I see no UDP losses
<= div>
Udp:
=C2=A0=C2=A0=C2=A0 16103 packets received
=C2= =A0=C2=A0=C2=A0 88 packets to unknown port received
=C2=A0=C2=A0=C2=A0 0= packet receive errors
=C2=A0=C2=A0=C2=A0 16224 packets sent
=C2=A0= =C2=A0=C2=A0 0 receive buffer errors
=C2=A0=C2=A0=C2=A0 0 send buffer er= rors

Consequently I see on start=C2=A0 often 2= -3 pairs of leafs that can't ping each other, I did not analyze further= , every time different pairs, sometimes all come up.
=

>>> I see= that as well.=C2=A0 This the main thing I / we need to concentrate on next= . Clearly, there is some pretty persistent issue with convergence.=C2=A0 To= day (Friday), I will be enhancing the generated check.sh script to check mo= re things than just pings: I will add check to make sure that all adjacenci= es are up, all LSDBs have the correct contents, all routes are present, etc= . etc. etc.=C2=A0 That way we can more easily get to the root of the issue.= =C2=A0 This is something that we could work on more during the hackathon.= =C2=A0 We will need these more sophisticated tests are part of the chaos mo= nkey testing infrastructure before we move on to larger 5-level / 7-stage t= opologies (those are simply too large to check by hand)>

=

agreed, I think that's wha= t we'll focus on first.
=C2=A0

monkey = testing works fine ... Next iteration will be of course doing that once pos= itive disaggregation is implemented in python RIFT ;-)

>>> Yep.= After IETF-104, disaggregation (positive and negative) is the last remaini= ng big ticket item (along with cleaning up a 100 or so small TODO items).= =C2=A0 Once we have the enhanced automated checks in place that I mentioned= in the previous point, re-running and debugging the chaos monkey tests wit= h extra features (e.g. disaggregation) should be pretty straightforward.

I think= @ hackathon first thing we have to write a simple script that collects the= kernel routing tables & compares them for # expected entries since lea= f-2-leaf has such a wide path diversity it's hard to debug, observe tha= t due to ECMP hashing you can get a leaf being able to ping 2 other leafs i= n another pod but not the third since it takes different spine/superspine c= ombination. Generally, to test connectivity on fabric well, you need a fan-= out of UDP source/sink pairs that lead to exhaustive ECMP coverage (as well= as tests quality of load balancing once we get to the bandwidth balancing = in python RIFT)
=
>>> Agree 100%.=C2=A0 This would be part of the =E2= =80=9Cenhanced automated checks=E2=80=9D that I mentioned previously.
=

Yes, connect= ivity to spine loopbacks and so on has been discussed on the core team list= and is in the draft (-04 is in publication queue) ... Generally, most robu= st IP fabric architecture is leaf-2-leaf since relying on every leaf being = able to reach every spine leads unavoidably into exposing more and more top= ology towards the leafs with according scalabiltiy problems on the leafs. S= o, a fabric where every leaf can reach every leaf is in a sense "worki= ng fine" even if links are lost or some spines crash. That modulo band= width balancing since we want to account for load being balanced (unsurpris= ingly, RIFT does all that ;-) if we talk a single prefix (loopback) on a sp= ine/superspine then PGP and even simpler stuff can work well but if we assu= me that specific superspines terminate lots prefixes and rely on leafs bein= g able to reach them then the fabric "inverts" and scalbility is = lost. Variants of the problem exist by e.g. having superspines exposing any= cast addresses. Once deployment experience starts to come in I can see a &q= uot;operational deployment" draft coming up (I think someone already s= uggested to write one) ...

>>> I will mentioned =E2=80=9Clack = of connectivity to spine loopbacks=E2=80=9D as one of the lessons learned i= n my slide deck.=C2=A0 Whether or not that is a problem should be a point o= f discussion during the RIFT WG meeting.

<= div dir=3D"ltr">

thanks

--= - tony

=
>>> Looking forward to =E2=80=9Cseeing=E2=80=9D everyon= e tomorrow at the hackathon. Reminder: please setup a zoom meeting or somet= hing similar; I will be remote (Argentina).


I'll open zoom as soon I come in from my f= light ...
--000000000000acb4690584b60efe-- From nobody Fri Mar 22 23:05:36 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4512785F for ; Fri, 22 Mar 2019 23:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCnbKH-3B0Ca for ; Fri, 22 Mar 2019 23:05:33 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521EB1277D8 for ; Fri, 22 Mar 2019 23:05:33 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id v21so3435315edq.4 for ; Fri, 22 Mar 2019 23:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=A6D+GhUdC6wF2CJyr3n7rUiU8if/unGFFt66Upm/LGg=; b=aCea/dcT2WS6QU2Y5fiRJ+Euq8QpprD4zBmYZJ1a3PiuYoWIrWc+LXvC6A92EDYNPG xF8a8GyCzw/9tCvK9zz9SYnammY+oYqcc7h7YWbTcXMcdjH45iXC1uYG7PbAaodrF2gU kr5XylrgdXZ7jk4e8D3DmgZr+ACA49aUHNQ5JDCjQ3sX5l6GLbCwX7dPZjcpMqKxBxX/ NBCYpxiS1PpcJ6bwDsAUqK8gK/eUSiL+JrXPOFlhAHfsXqZY1veYukaAaoqamkQHKp9x 65S4vCRh911r/ngxDUwn6qEcjmEDmIyRRsw69oKejK/mQYpD23ZFUFDnyBQK4FLTzHrA 1TBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=A6D+GhUdC6wF2CJyr3n7rUiU8if/unGFFt66Upm/LGg=; b=nUFNEwVdvhbMI6OspQsJ03TMLTV2RToFzxGt+1gfk7G5oth36783wzMh1cUsnTpaHX b/JpUNrvP6Kniw2knphsXP/LExHw7EjUv/wuQjECnBj4dYPY/k8EWuarNOGULuUuKYB0 CkA3lJXuz9wFLDBoHbDOc5xXKpFKti4QdwN7sj224RFxqlMDILxAcUGhIJPEwRE9Hf4Q KpsjE+kr4TT7KcsYOluY624Q3vpnChD2eCR7DQXHm7UQKn/iO6G1uBMkX74wCSpsT2Bv P2qm45PKaDnSNYjU2O58Q9OjmcCffCBcp3mxxXXM4IoQZqVxY4UCEmKH1lMdipUW4xjE 9JKQ== X-Gm-Message-State: APjAAAUcZeJaZPxEycXMOCq12U4i0OL28fDca+5bbY0dZBJoop/Q4shA T1tZ1QXIC1eIjjjJA9n6t6s5zovXSxNrHId/dkGe0fUU X-Google-Smtp-Source: APXvYqzTzjuf+JzBNDFBEfNJr7U+9Y2G2jMbPtmrqS7EOiUKSxRfcakloYpRJ/rA//7bLJbgjjmZvtFg1WgAa/pDa1Y= X-Received: by 2002:a17:906:d28c:: with SMTP id ay12mr7481688ejb.51.1553321131782; Fri, 22 Mar 2019 23:05:31 -0700 (PDT) MIME-Version: 1.0 From: Tony Przygienda Date: Sat, 23 Mar 2019 07:04:55 +0100 Message-ID: To: rift@ietf.org Content-Type: multipart/alternative; boundary="0000000000004839710584bcc2d7" Archived-At: Subject: [Rift] RIFT hackathon fires up on Sat 2.30pm X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 06:05:35 -0000 --0000000000004839710584bcc2d7 Content-Type: text/plain; charset="UTF-8" People are coming in from flights tad later so RIFT hackathon will be starting around 2PM today. I'll fire up a zoom meeting and get bigger amazon machine when I come in and post to the list so stay tuned ... thanks --- tony --0000000000004839710584bcc2d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
People are coming in from flights tad later so RIFT h= ackathon will be starting around 2PM today. I'll fire up a zoom meeting= and get bigger amazon machine when I come in and post to the list so stay = tuned ...

thanks

--- tony
--0000000000004839710584bcc2d7-- From nobody Sat Mar 23 05:17:39 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54D51274A1 for ; Sat, 23 Mar 2019 05:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFQvBRqq-00d for ; Sat, 23 Mar 2019 05:17:36 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0753A130EBE for ; Sat, 23 Mar 2019 05:17:36 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id q3so3874466edg.0 for ; Sat, 23 Mar 2019 05:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+2ukPlbNwK+M6oMUkZtdpXiENdmIjBMmhak1ZJzdY88=; b=bm1a3h/kqrlQeJKDFQmGCy8lAUdsAsumiTNJwTIXJfsZgiUj1sOFw9GJYEJq9R3y0E LJxaGNKJ2dweWx/4DlO1lbrrACnkUD6ccTWDBsP1vEGo+vW18O9Lfu76GaM2vlgE7O3k rEW2i3Eq369y27UH63s3VyCSqRFv65uN1yp9bNQ1O6GB0t0KrugWaeU/9nOF3frz18i4 uZWuWvELgMetysIjvTOef3hnd0DLI0G63P5oq2qs49ibk3UvCviwh+UHMVAg0uXKtJpx WTyYFtIAxAg2uoVgflDrgIP3mvpjAPfm4rHzCnrL5vB87kxef5SUvpi6633nn5zaC5YX ILeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+2ukPlbNwK+M6oMUkZtdpXiENdmIjBMmhak1ZJzdY88=; b=aM4v/E2Ls1cQk+CVWi9Bb4kL5uQtOcOWRWUoqyYMIIqF8zHhR7YeAjfuEovlKcam9T QRiniw+mGWxHVFSi7Og52K4Exob+i95ai7CtZ5fiL2I7yMCE7nhYLiFMdagIJ04ExVYL d5LoJMt5t2vOrH4WIn/DYXuKzko9RMUFVK91LmKna9vGlceYGFmwHCSH0O6ecC0W9zqf 00trNrLP6L3wjWIHVJPRufuRH5vYxNy4WfoiCND1DS0l+wl57xtOAvsfeldn3zYNWVSY GlDwTC27FgD4MyiGD0L3cnh0/jSthvz+4KXfuJXj99DR1chO8U4Eu+PuCIF67+pe+Ote mxgw== X-Gm-Message-State: APjAAAUZ/6sZfM47NuCbHx+bFQqEOhYAHXv1QNDMJsKuI8wR02GWOSOa mcRnPgOr2XCIajNiJZJQKjx8TqlPSLHQbkHsFgLYeaen X-Google-Smtp-Source: APXvYqwumsC+7ptOi4PsIBxuyTb7jwJqyk3pG8uvYPc55KUILoV8RwC8K+h1lOUhgnF0znAm6Wol8+JMjEBVej9yZuE= X-Received: by 2002:a50:8818:: with SMTP id b24mr9875582edb.86.1553343454552; Sat, 23 Mar 2019 05:17:34 -0700 (PDT) MIME-Version: 1.0 From: Tony Przygienda Date: Sat, 23 Mar 2019 13:16:59 +0100 Message-ID: To: rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000d2a66c0584c1f4c9" Archived-At: Subject: [Rift] RIFT table & zoom up X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 12:17:38 -0000 --000000000000d2a66c0584c1f4c9 Content-Type: text/plain; charset="UTF-8" OK, we're here @ the very end of the room right ... Zoom meeting open, please join to connect ... I'll be on in a minute or two ... Bootstrapping the bigger amazon host https://zoom.us/j/7093181681?pwd=Ykk1ekI3N2FJMStwVFM5YjJpZTNiUT09 --000000000000d2a66c0584c1f4c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, we're here @ the very end of= the room right ...

Zoom meeting open, please= join to connect ...

I'll be on in a minu= te or two ...

Bootstrapping the bigger amazon= host=C2=A0

--000000000000d2a66c0584c1f4c9-- From nobody Wed Mar 27 11:12:05 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A254E12031D for ; Wed, 27 Mar 2019 11:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_PtJzGkQXge for ; Wed, 27 Mar 2019 11:12:01 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F42F120315 for ; Wed, 27 Mar 2019 11:12:01 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id o129so10479899qke.8 for ; Wed, 27 Mar 2019 11:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=v8t/wwNfCuOiYjCPH6lqMEYrk1+FT+ClMZGualaHf1Q=; b=XXRUn0/ezuSSQeQVohl6vhbshw8h1YKmUy2IzD3xSQWa1UbjvYQ2QwgKAqycgl6ohS 4aGlzqB/5KCxkeGSgMNn+jXzPPIfXdphfxuzigs1dI8qxKbM72D/gbzjR4FIMHBvpPdC ioHwjtdPcyQNllKtP8q0RMSAofiHJslWv9cv/Cx8VB4nZHfEdHZfPqikHWwJB4UfNm1Z ZQgC1xtCmSFTXXZwfchYNJ/MLHHPRKNDvCiPwtkPSgcxUkZHXpkb4mTHxoGjAfSSBIfI OUOId3fzubbHQ+2YTu0brRRPBbNAhW8+rIZpWXBNlMTRCeFemLAHNVkTfdQqEpS35TRB 6fCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=v8t/wwNfCuOiYjCPH6lqMEYrk1+FT+ClMZGualaHf1Q=; b=D2N13IQvAz6TtjPjeXM5Sl7J8siP433ikDWxil39m560XYvJakQ2TbnCd1Hrn23Fqq kK7IZlmrFRDZfzA86Fm4lanphbyrv0nG899PX0jcQn/HlpoSf+JXKGl0jdUYN6zBgns0 Kv2AXQnQxCwWYP4wMJ9gTVaYP24o+rkS3xwqXunha785KpU9OMU/bxl0IVnRzQPj9bSJ 3enqI/ty8D610vlxZqvfKHBK8L6r4yM6PHjkoNxPt3gfSDXoHlQ2G5BSkD+BpAo9snfe xQSQl/EdH73GzGDFIxrujNavvr0V9pNJXdPC90v6wDkA85+0HQyFLJtCrRB66u5luf8S RNxA== X-Gm-Message-State: APjAAAWlEiRRYXkn0dI+68ujR0i/BnNG90ujorveJjWy4WMLRzizPZFl wXwOftZalpHCvuz717LKwByYSaq4l6Y= X-Google-Smtp-Source: APXvYqzbyww7/HvsbkzvwUMJFqi+HvoNXQSx3Lbd37+qcc8LFGgDAJDa+9fgVup8MZo6Kv+YvI4KwQ== X-Received: by 2002:a37:4801:: with SMTP id v1mr30898890qka.312.1553710319853; Wed, 27 Mar 2019 11:11:59 -0700 (PDT) Received: from [192.168.20.114] ([200.63.168.130]) by smtp.gmail.com with ESMTPSA id n1sm13628377qkd.28.2019.03.27.11.11.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 11:11:59 -0700 (PDT) From: Bruno Rijsman Content-Type: multipart/alternative; boundary="Apple-Mail=_538A7086-C080-4C54-89AA-5BFBBBBEF5FF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <6A764A00-CC2A-4D89-A242-BDAB420B2734@gmail.com> Date: Wed, 27 Mar 2019 15:11:56 -0300 To: rift@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Rift] [RIFT-TEAM] RIFT-Python initial implementation of positive disaggregation is complete X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 18:12:04 -0000 --Apple-Mail=_538A7086-C080-4C54-89AA-5BFBBBBEF5FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Note: as requested in the RIFT working group meeting at the IETF 104 in = Prague earlier today, I am sending this e-mail to the RIFT IETF WG = mailing list (instead of the RIFT core design team mail list, as was = previously the practice). The initial implementation of positive disaggregation in RIFT-Python = is = now complete. For more details, see the feature guide: = http://bit.ly/rift-python-pos-disagg = =E2=80=94 Bruno= --Apple-Mail=_538A7086-C080-4C54-89AA-5BFBBBBEF5FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Note:= as requested in the RIFT working group meeting at the IETF 104 in = Prague earlier today, I am sending this e-mail to the RIFT IETF WG = mailing list (instead of the RIFT core design team mail list, as was = previously the practice).

The initial implementation of positive disaggregation = in RIFT-Python is now complete.
For more details, see the feature = guide: http://bit.ly/rift-python-pos-disagg

=E2=80=94 = Bruno
= --Apple-Mail=_538A7086-C080-4C54-89AA-5BFBBBBEF5FF-- From nobody Thu Mar 28 02:26:32 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6210012025F for ; Thu, 28 Mar 2019 02:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjIZisO0gJtP for ; Thu, 28 Mar 2019 02:26:28 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A5F12025B for ; Thu, 28 Mar 2019 02:26:28 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id p20so22198317qtc.9 for ; Thu, 28 Mar 2019 02:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=Xmi9HlrF6lUoiz+fsKRx5vjkRjjv8bUP3ZxP5tKd1iE=; b=mEqntvmJdTR4TnUxmRQBLc/yCBKEHnYkf25KLYMg/gnrvym1gcjOLfrrvXNuseEs0/ BFRZqzNSETt1uJMURxsssZ3NMg/B9dM2l/BTuAJxmrBx7crW9RabMlhlozDTa32rMXBb EfqnxJE2HamkoFzIU56buZekY/7kYYor2emn5hpqyfDMkKqCRVfB+TDxvPRxndOqn1Rc IOE2XW7FBobZoFk3xq9gxJuosGNQOzzyxarimASFO6FGZqHdI5wvmqQaUcQKSP0y1skj 5qzSKdHkIGCj7xaeaI8KQfj+c6I8PWQIhiTI8IuhEn4wm2fSSAFPsz9OMh9PQHvJOz05 1i5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=Xmi9HlrF6lUoiz+fsKRx5vjkRjjv8bUP3ZxP5tKd1iE=; b=OJG3xa1nWUSX/E2ZY1BSR3GXNF2ofQv3Kmge9HvnqQxpSHWx2wLCPD/28SPMZ8JmhC OQMjWo0zgJgVlfky1WgxKLH1CCj9CvjguQK8Ir6sxkug/sKQBKsHvHoXIfpO4/CVWDbK 1YauTCBSjeWN7EgtCvwIS4lBidGtrST5GZvsok4kDMyzWWbCoH3n+2Qu/vYHycbAL5x8 v9hGqTiQK0CzA7YrFsArpaQGpY3cqdCexXLCBBXCeruJZESbGenhpOlwfUQr5vhHEAOg 4/+yRCSXCgwCuUJ5WvJBmZm7lkEuvjHCXG9HIyMuTIa3V9TxfuqkAQROD9S5bmZaoOtu eYqg== X-Gm-Message-State: APjAAAUEAhwH7lepPtHzTYzJtJYc0Pgz+RoF7a3fSf6Qq8+1AAhw8lQ0 i027W0712pIPEI0pbxYclt0= X-Google-Smtp-Source: APXvYqz2O/7XuCvDzb7DSUt4GLfAVKu+mwpGEhlbh+/Mjz72uAs5Ce/ehtxLm8GRyM6CJvlM8hGnEQ== X-Received: by 2002:ac8:1497:: with SMTP id l23mr11963863qtj.296.1553765187164; Thu, 28 Mar 2019 02:26:27 -0700 (PDT) Received: from [192.168.20.114] ([200.63.168.130]) by smtp.gmail.com with ESMTPSA id e15sm11917871qkl.80.2019.03.28.02.26.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 02:26:26 -0700 (PDT) From: Bruno Rijsman Content-Type: multipart/alternative; boundary="Apple-Mail=_166EEF5B-3CDB-4BDD-8C77-47F5F1125F5F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <99F95A9E-E9DC-45F9-A5F8-845F66C8A019@gmail.com> Date: Thu, 28 Mar 2019 06:26:23 -0300 Cc: rift@ietf.org To: Pascal Thubert X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Rift] [RIFT-TEAM] Questions about negative disaggregation X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 09:26:32 -0000 --Apple-Mail=_166EEF5B-3CDB-4BDD-8C77-47F5F1125F5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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.=20 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=E2=80=9D which sounds like the east-west = ToF links need to be included in the special SPF calculation. -- Bruno --Apple-Mail=_166EEF5B-3CDB-4BDD-8C77-47F5F1125F5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=9D which sounds like the east-west ToF links need to be = included in the special SPF calculation.

-- Bruno



= --Apple-Mail=_166EEF5B-3CDB-4BDD-8C77-47F5F1125F5F-- From nobody Thu Mar 28 03:15:42 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CFD120268 for ; Thu, 28 Mar 2019 03:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW5DjR7xa5ud for ; Thu, 28 Mar 2019 03:15:36 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982B312024B for ; Thu, 28 Mar 2019 03:15:35 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id h22so16680576edw.7 for ; Thu, 28 Mar 2019 03:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AYiRNd06OfUIpoM3HZjZyTsn2Np7a9dISCnodr4xbdg=; b=grGkuKekfJseh4GsCUTuMv5RY+/5lQFT5No6YLlyaxYu17U6XAlJAdxcEJUzABk7uI Tglv/mAs0WSU6n/1RX59J4dRQseWpFDOhzl0NIPTLxiD/J0vHh5I4jJdKyeBkWA2wkpY tB/HaJvvTKxhu2S3+Y9Jy0lBubDJdaMym2fzo2WPcUcdBb8dYirhkeq8PesMrYC0gN8R eS7glQLROh6KnPNJa/7t2YLyS319xUrVgByxsjfvyzuktCxz+26S2EeTyfWtH7foWZOV 2UarJjPOoOmuWHwMc2QMEczgG0nzdNeQ5VOy3ZMsU5mKki4oXgY7UOBWpa5VxgiV7uS/ FsZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AYiRNd06OfUIpoM3HZjZyTsn2Np7a9dISCnodr4xbdg=; b=Cd0xdNP46KpVjVs9PPSjOGhxBAKXDqvaxzYzexN6iUocV4PzQFeH8WgCnLyA/e7zc2 EZbfaAmoj8x8m/gcOpgRGwaSiIfgBK7x7Rt2jRJnB9uIS7Xxkti1TUicsxqRuUTUCp0f sXWKS5G02557CPUkOXWJIkvhtF2fhOkTQS+XvLIgAU3I6SVfZ5Wg35C4U3AAC2ukq7QF kBOj2Jkc/F4LVYuBu2ljA+ue3mqBttXI82PEXc+El8znsr/ZfCpkQonNui61qdeXogMN fWp9rbu23QIVbrTKr5AKiokZQJW1+mr+/cs4IHhxdMI32yVaEKcUzwzkqw4EKE9tYFvO vW4w== X-Gm-Message-State: APjAAAVRPgcXG6j6hqub05SXQYuq838/Jq4lna9ERpi5wPoLq9651URE j0Y7HD+AIzNq8G6gwzdoLd8y4ROapKJmMweTCFs= X-Google-Smtp-Source: APXvYqyHasEnmi9ysJgvIUAlJ+05mFcQk5vDdkcZmHh4c7I+KOflvgMBtMrFxUhqMyznC8aCMM9sK6rTWV+3FSI/Bng= X-Received: by 2002:a50:85c3:: with SMTP id q3mr24314492edh.140.1553768134202; Thu, 28 Mar 2019 03:15:34 -0700 (PDT) MIME-Version: 1.0 References: <6A764A00-CC2A-4D89-A242-BDAB420B2734@gmail.com> In-Reply-To: <6A764A00-CC2A-4D89-A242-BDAB420B2734@gmail.com> From: Tony Przygienda Date: Thu, 28 Mar 2019 11:15:04 +0100 Message-ID: To: Bruno Rijsman Cc: rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000b3da72058524d565" Archived-At: Subject: Re: [Rift] [RIFT-TEAM] RIFT-Python initial implementation of positive disaggregation is complete X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 10:15:40 -0000 --000000000000b3da72058524d565 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable git pull time ;-) That was fast ... -- tony On Wed, Mar 27, 2019 at 7:12 PM Bruno Rijsman wrote: > Note: as requested in the RIFT working group meeting at the IETF 104 in > Prague earlier today, I am sending this e-mail to the RIFT IETF WG mailin= g > list (instead of the RIFT core design team mail list, as was previously t= he > practice). > > The initial implementation of positive disaggregation in RIFT-Python > is > now complete. > > For more details, see the feature guide: > http://bit.ly/rift-python-pos-disagg > > =E2=80=94 Bruno > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift > --000000000000b3da72058524d565 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
git pull time ;-) That was fast ...
-- tony

On Wed, Mar 27, 2019 at 7:12 PM Bruno Rijsma= n <brunorijsman@gmail.com&= gt; wrote:
Note: as requested in the RIFT working= group meeting at the IETF 104 in Prague earlier today, I am sending this e= -mail to the RIFT IETF WG mailing list (instead of the RIFT core design tea= m mail list, as was previously the practice).

The initia= l implementation of positive disaggregation in=C2=A0RI= FT-Python=C2=A0is now complete.

For more detai= ls, see the feature guide:=C2=A0http://bit.ly/rift-python-pos-disagg
=
=E2=80=94 Bruno
_________________________________= ______________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
--000000000000b3da72058524d565-- From nobody Thu Mar 28 03:20:46 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D66E120468 for ; Thu, 28 Mar 2019 03:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCmxHyTk-69p for ; Thu, 28 Mar 2019 03:20:33 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4107812026D for ; Thu, 28 Mar 2019 03:20:21 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id p20so16215956eds.6 for ; Thu, 28 Mar 2019 03:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mUo+tUKOqp3PgrgwedeQ6NnmUsPiBnxjSkQlNYCELnw=; b=lVcdrAXqPdMv2gvlNYah6QmprFb3048a3Cij85rUlQ8wEdv1NZNi85flpSt3yQtzpQ R7Wknji6/EDjVS10/NO99nTPkrSwQ+4qJoLCMVhQoFkycLUpWxrLknD80jqJR7RVRJJp Nk+Fjh9SbaUKxgHUD64jEDArRipkmbYYma4E+DQQEMEssSBeq9OEhIoSOWleHivRuiBu dRrazV3zFWyKx6G6R05stxdzmeanvaNMiLfX44vjbnVioq9f7MnfGzSD8KmXTc0ryGap 3PiGxR2Y5iqbGAyMzi37NRJ42831cnFLy6QkWKhjSaGnjtQSQ9DxUKzfyVvwF7HefXXh Mp0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mUo+tUKOqp3PgrgwedeQ6NnmUsPiBnxjSkQlNYCELnw=; b=Sfe53Hf9NdZVjXzfYMz7s49pMFeEDJjDYFbjvls/N0Qe4/m2lKf95clGhOSVXPev00 GXial66a4QYHGqYvrBnUmv9ju1iomdGJTGTjHqiWWPYIeqUTDvEGqlcrP3YMjEF3OlnC y+e1borpZhDzgwnaTrB9p71aud2pvJSjxFgYFkMkwKFYJ5cVbBQh3b+TEYh5gjkNfXM3 vkrUTvL1ZizR6h8m6rIgOCJcE+GiR9q2FNBE3LK2t5AjcMCuWg1pAfW79Mqln6ybY5aq 2Xh3E9EcBOtuSV1g+Vg/G3qk8rtOsb58BKwXWSOkp8c9eza/CpOYx/kALDLQGoY+MakA S81Q== X-Gm-Message-State: APjAAAXZp7FngulBhmm5LZMMgjtyPPoTmfo7EqQDjiLYsEUGSmgU0DPC XyLDzcnvPuYNeAFlNd2muXUCmJNiwqYsdm4I9xg= X-Google-Smtp-Source: APXvYqyfWBjg3CUbZmhJKkupz50QxhD5L8tm5vDR4WjE15YCBCG20JNm77PNPI4vANmx5TL+bG7jGvcIhDFtJDX1qVY= X-Received: by 2002:a50:8561:: with SMTP id 88mr12468456edr.101.1553768419853; Thu, 28 Mar 2019 03:20:19 -0700 (PDT) MIME-Version: 1.0 References: <99F95A9E-E9DC-45F9-A5F8-845F66C8A019@gmail.com> In-Reply-To: <99F95A9E-E9DC-45F9-A5F8-845F66C8A019@gmail.com> From: Tony Przygienda Date: Thu, 28 Mar 2019 11:19:50 +0100 Message-ID: To: Bruno Rijsman Cc: Pascal Thubert , rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba8b69058524e6dc" Archived-At: Subject: Re: [Rift] [RIFT-TEAM] Questions about negative disaggregation X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 10:20:43 -0000 --000000000000ba8b69058524e6dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >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 wrote: > 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 wi= ll > 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 o= f > 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 t= he > 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 th= at > 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 b= e > 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 ... *i= ncluding > ToF links*=E2=80=9D 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 --000000000000ba8b69058524e6dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From demand perspective I think it w= ould be better to start on authentication envelope first
rest inline

--- tony

On = Thu, Mar 28, 2019 at 10:26 AM Bruno Rijsman <brunorijsman@gmail.com> wrote:
Hi Pascal (CC RIFT mailing list per WG request),

I am about to get started on implementing negative disaggregation.<= /div>

Per my usual modus operandi, now that I start thin= king about actual code, I have more questions about the draft.
Section 5.2.5.2.3. (Computation of Negative Disaggregates) des= cribes two steps for generating the negative prefixes. I don't fully un= derstand the first step.=C2=A0

It sounds like runn= ing some special variation of SPF which will find some extra prefixes (rela= tive to a normal SPF run) and those extra prefixes will be the negative pre= fixes:

=C2=A0The first = origination reason is a computation that uses all the node
=C2=A0N-TIEs to build the set of all reachable = nodes by reachability
=C2=A0com= putation over the complete graph and including ToF links. The
<= div>=C2=A0computation uses the node itself as ro= ot. This is compared with the
= =C2=A0result of the normal southbound SPF as described in Section 5.2.4.2.<= /font>
=C2=A0The difference are the fa= llen leafs and all their attached prefixes
=C2=A0are advertised as negative prefixes southbound if the nod= e does not
=C2=A0see the prefix= being reachable within southbound SPF.

My = questions are:

(1) Could you please provide more d= etails on how this special variation of SPF is different from the normal SP= F, 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 t= o normal S-SPF. Diff is fallen leafs

suggest=C2=A0= better language
=C2=A0
(2) Should this special flavor of SPF be run on all nodes, or only on spe= cific nodes (e.g. only the Top-of-Fabric nodes)? I am asking because the ot= her step takes care of propagating the negative prefixes south-wards.
=


only ToF really
<= /div>
=C2=A0
(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 b= oth at the same time and that they augment each other (if so, how)?

implementation choice. If you impoleme= nt ToF and want to support multi-plane negative is a must, otherwise not ne= eded.
=C2=A0

= (4) I am confused about what happens in a multi-plane network where the eas= t-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 disa= ggregation cannot fix.=C2=A0 But are we saying that such blackholes will be= fixed by negative disaggregation?=C2=A0 I think that is indeed what the dr= aft is saying, but then I am confused by the sentence "a computation that ...=C2=A0including ToF links=E2=80=9D which sounds like the east-west ToF l= inks need to be included in the special SPF calculation.

-- Bruno

=C2= =A0lack of E-W ToF links cannot be detected since it looks to a ToF then li= ke 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 s= ee. This is implementation smarts and I don't think should/can be manda= ted by the spec
--000000000000ba8b69058524e6dc-- From nobody Thu Mar 28 04:40:14 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979721202A1 for ; Thu, 28 Mar 2019 04:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DyCUjEEy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xn4EvYF9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcbtpFpUlKXE for ; Thu, 28 Mar 2019 04:40:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A73120295 for ; Thu, 28 Mar 2019 04:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19522; q=dns/txt; s=iport; t=1553773208; x=1554982808; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b4VqvvMOxjZmlGamWJN7vn/lolLcq6d8Pcw03fWp4Qc=; b=DyCUjEEyAAdKBgTTwAyKESvTS8yUskTCKdykP9bziZwjANFgDB9J+evn sGjIsD0G9LzWyUmaNxNNC1l9NHFr9KALaFKq1Z4Jvsj0NT8NzvULkfu1q Eu1Hu579h+ZnZKJmi2/GIbfmOqk6CJdpJJOW4gnN7TebqFlh20FV5ceXG 4=; IronPort-PHdr: =?us-ascii?q?9a23=3Ay+46fRz23bqcpLzXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAABdsZxc/5FdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGBDi8kLANodAQLJ4QOg0cDjyqMD4kNhEmCUgN?= =?us-ascii?q?UDQEBLIRAAheFGyI3Bg0BAQMBAQkBAwJtHAyFSwYjChMBASwLAQ8CAQg/AwI?= =?us-ascii?q?CAh8RFBECBAENBQiDG4ERTAMVAQKebgKKFHGBL4J4AQEFhQgNC4IMCIEvAYR?= =?us-ascii?q?chlUXgUA/gRABRoFOUC4+ghqCLIMIMYImijU+ggmEIpNaNgkCkAaDWYIDhgK?= =?us-ascii?q?IWYMug1iHVIdFi3UCBAIEBQIOAQEFgWMigVZwFTuCbIIKDBeDS4pTcoEojk0?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.60,280,1549929600"; d="scan'208,217";a="322359871" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Mar 2019 11:40:07 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2SBe76A015419 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Mar 2019 11:40:07 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 06:40:06 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 07:40:05 -0400 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 28 Mar 2019 06:40:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b4VqvvMOxjZmlGamWJN7vn/lolLcq6d8Pcw03fWp4Qc=; b=Xn4EvYF9agKnCh952GlxvuSLn9bETVkQZutAOQlgNrF8Km8UOH2WUXHA6v+YATUoflhz/wczqEjRj4Je+ed21hhFB2xU2udOSWxR/ckHuW6GTJYrMcyo0MyWX8IUNI2Vf4SmhkM7o3Ys8YRKAmzqDKSQtERwM8gqomvQYgQzJZk= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4109.namprd11.prod.outlook.com (10.255.181.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Thu, 28 Mar 2019 11:40:03 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Thu, 28 Mar 2019 11:40:03 +0000 From: "Pascal Thubert (pthubert)" To: Tony Przygienda , Bruno Rijsman CC: "rift@ietf.org" Thread-Topic: [Rift] [RIFT-TEAM] Questions about negative disaggregation Thread-Index: AQHU5UhqzIIjSKzdF0u6F8VqldunwaYg1PwAgAANvFA= Date: Thu, 28 Mar 2019 11:39:41 +0000 Deferred-Delivery: Thu, 28 Mar 2019 11:39:30 +0000 Message-ID: References: <99F95A9E-E9DC-45F9-A5F8-845F66C8A019@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1005::263] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 28bc39c9-ae6e-4f5f-1a24-08d6b3721e82 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB4109; x-ms-traffictypediagnostic: MN2PR11MB4109: x-microsoft-antispam-prvs: x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(376002)(136003)(346002)(52084003)(189003)(199004)(86362001)(2906002)(11346002)(46003)(97736004)(186003)(14454004)(53546011)(102836004)(486006)(446003)(790700001)(6116002)(476003)(6506007)(74316002)(7736002)(478600001)(25786009)(8936002)(4326008)(106356001)(105586002)(53936002)(81166006)(256004)(52536014)(5660300002)(110136005)(7696005)(55016002)(236005)(316002)(76176011)(6306002)(54896002)(8676002)(33656002)(81156014)(6246003)(5024004)(6666004)(14444005)(229853002)(9686003)(99286004)(71200400001)(68736007)(6436002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4109; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: L/cI8WYQxtay9vnsyn+x15hZjgN3c5fqr8VPLsz3nA4LMqlpW2LiB5sbG204NkSkjiwwALoctEsu1xvL8bCsmLP3C2JnLGB399fxplUJvYViNtjfmHT3Cdu9SWKWmIFmczufC4hInLSGGzlESL8M0NeTDAIB19ig8U+3bzkTMBVgXS2TSdBBSyXmsf8IlxeDNXgns7I91Ig45/i7XH/eDkHwBMTRD1JhGajnPvAwAqGgN+IphzsbT30yD/K3HscybKOZXJwztx7E6+pB80NneuvXnSAMWPbLK/ME+lahCHpZRRIdTAIrELV382y2Mc1o61GFbb5XBoC9RK4+tl1izcsvKjfkhpGFK6bUlaTS0QD7BUWiPkVGQlkLAaQlPIP8vPkvUAWy1NCobxYWfT4e8zq2LeYzsJkWONg+cqq6zl0= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565D2D34A12285EFCD8D537D8590MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 28bc39c9-ae6e-4f5f-1a24-08d6b3721e82 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 11:40:03.7018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4109 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Rift] [RIFT-TEAM] Questions about negative disaggregation X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 11:40:11 -0000 --_000_MN2PR11MB3565D2D34A12285EFCD8D537D8590MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gVG9ueSBhbmQgQnJ1bm86DQoNClBsZWFzZSBzZWUgYmVsb3cNCg0KQWxsIHRoZSBiZXN0 DQoNClBhc2NhbA0KDQoNCk9uIFRodSwgTWFyIDI4LCAyMDE5IGF0IDEwOjI2IEFNIEJydW5vIFJp anNtYW4gPGJydW5vcmlqc21hbkBnbWFpbC5jb208bWFpbHRvOmJydW5vcmlqc21hbkBnbWFpbC5j b20+PiB3cm90ZToNCkhpIFBhc2NhbCAoQ0MgUklGVCBtYWlsaW5nIGxpc3QgcGVyIFdHIHJlcXVl c3QpLA0KDQpJIGFtIGFib3V0IHRvIGdldCBzdGFydGVkIG9uIGltcGxlbWVudGluZyBuZWdhdGl2 ZSBkaXNhZ2dyZWdhdGlvbi4NCg0KUGVyIG15IHVzdWFsIG1vZHVzIG9wZXJhbmRpLCBub3cgdGhh dCBJIHN0YXJ0IHRoaW5raW5nIGFib3V0IGFjdHVhbCBjb2RlLCBJIGhhdmUgbW9yZSBxdWVzdGlv bnMgYWJvdXQgdGhlIGRyYWZ0Lg0KDQpTZWN0aW9uIDUuMi41LjIuMy4gKENvbXB1dGF0aW9uIG9m IE5lZ2F0aXZlIERpc2FnZ3JlZ2F0ZXMpIGRlc2NyaWJlcyB0d28gc3RlcHMgZm9yIGdlbmVyYXRp bmcgdGhlIG5lZ2F0aXZlIHByZWZpeGVzLiBJIGRvbid0IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGZp cnN0IHN0ZXAuDQoNCkl0IHNvdW5kcyBsaWtlIHJ1bm5pbmcgc29tZSBzcGVjaWFsIHZhcmlhdGlv biBvZiBTUEYgd2hpY2ggd2lsbCBmaW5kIHNvbWUgZXh0cmEgcHJlZml4ZXMgKHJlbGF0aXZlIHRv IGEgbm9ybWFsIFNQRiBydW4pIGFuZCB0aG9zZSBleHRyYSBwcmVmaXhlcyB3aWxsIGJlIHRoZSBu ZWdhdGl2ZSBwcmVmaXhlczoNCg0KIFRoZSBmaXJzdCBvcmlnaW5hdGlvbiByZWFzb24gaXMgYSBj b21wdXRhdGlvbiB0aGF0IHVzZXMgYWxsIHRoZSBub2RlDQogTi1USUVzIHRvIGJ1aWxkIHRoZSBz ZXQgb2YgYWxsIHJlYWNoYWJsZSBub2RlcyBieSByZWFjaGFiaWxpdHkNCiBjb21wdXRhdGlvbiBv dmVyIHRoZSBjb21wbGV0ZSBncmFwaCBhbmQgaW5jbHVkaW5nIFRvRiBsaW5rcy4gVGhlDQogY29t cHV0YXRpb24gdXNlcyB0aGUgbm9kZSBpdHNlbGYgYXMgcm9vdC4gVGhpcyBpcyBjb21wYXJlZCB3 aXRoIHRoZQ0KIHJlc3VsdCBvZiB0aGUgbm9ybWFsIHNvdXRoYm91bmQgU1BGIGFzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDUuMi40LjIuDQogVGhlIGRpZmZlcmVuY2UgYXJlIHRoZSBmYWxsZW4gbGVh ZnMgYW5kIGFsbCB0aGVpciBhdHRhY2hlZCBwcmVmaXhlcw0KIGFyZSBhZHZlcnRpc2VkIGFzIG5l Z2F0aXZlIHByZWZpeGVzIHNvdXRoYm91bmQgaWYgdGhlIG5vZGUgZG9lcyBub3QNCiBzZWUgdGhl IHByZWZpeCBiZWluZyByZWFjaGFibGUgd2l0aGluIHNvdXRoYm91bmQgU1BGLg0KDQpNeSBxdWVz dGlvbnMgYXJlOg0KDQooMSkgQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIG1vcmUgZGV0YWlscyBv biBob3cgdGhpcyBzcGVjaWFsIHZhcmlhdGlvbiBvZiBTUEYgaXMgZGlmZmVyZW50IGZyb20gdGhl IG5vcm1hbCBTUEYsIGFuZCB3aHkgaXQgeWllbGRzIHRoZSBuZWdhdGl2ZSBwcmVmaXhlcz8NCg0K SSB0aG91Z2h0IGl0IHdhcyB3cml0dGVuIGRvd24gdGhhdCBvbmUgcnVucyBhIHNvdXRoYm91bmQg dXNpbmcgdGhlIEUtVyBsaW5rcyBAIFRvRiBsZXZlbCAodG8gY3Jvc3MgaW50byBvdGhlciBwbGFu ZXMpIGFuZCBjb21wYXJlcyB0aGF0IHRvIG5vcm1hbCBTLVNQRi4gRGlmZiBpcyBmYWxsZW4gbGVh ZnMNCg0Kc3VnZ2VzdCAgYmV0dGVyIGxhbmd1YWdlDQoNCg0KICAqICAgUGFzY2FsOiBJIHRoaW5r cyB0aGlzIGJvaWxzIGRvd24gdG86DQoNCsOYICAgIGFuZCBpbmNsdWRpbmcgVG9GIGxpbmtzDQoN CsOYICAgICA9Pg0KDQrDmCAgICBhbmQgaW5jbHVkaW5nIEUvVyBsaW5rcyB0aGF0IGNvbnZleSB0 aGUgZGVzdGluYXRpb25zIHRoYXQgYXJlIHJlYWNoYWJsZSBieSBvdGhlciBub2RlcyBhdCB0aGUg c2FtZSBsZXZlbC4NCg0KKDIpIFNob3VsZCB0aGlzIHNwZWNpYWwgZmxhdm9yIG9mIFNQRiBiZSBy dW4gb24gYWxsIG5vZGVzLCBvciBvbmx5IG9uIHNwZWNpZmljIG5vZGVzIChlLmcuIG9ubHkgdGhl IFRvcC1vZi1GYWJyaWMgbm9kZXMpPyBJIGFtIGFza2luZyBiZWNhdXNlIHRoZSBvdGhlciBzdGVw IHRha2VzIGNhcmUgb2YgcHJvcGFnYXRpbmcgdGhlIG5lZ2F0aXZlIHByZWZpeGVzIHNvdXRoLXdh cmRzLg0KDQoNCm9ubHkgVG9GIHJlYWxseQ0KDQoNCiAgKiAgIFBhc2NhbDogSW4gcHJhY3RpY2Ug cHJvYmFibHkgc28uIEJ1dCBjb25zaWRlcmluZyB0aGUgY3JhZnRlZCB0ZXh0IGluIGRlZmF1bHQg cm91dGUgb3JpZ2luYXRpb24gaW4gc2VjdGlvbiA1LjIuMy44LCBJIHRoaW5rIHRoZSBzYW1lIGxv Z2ljIGFwcGxpZXMgYW5kIHNob3VsZCBiZSB3cml0dGVuIGFzIHN1Y2guDQogICogICBJZiBhIG5v ZGUgZGVjaWRlcyB0byBvcmlnaW5hdGUgYSBkZWZhdWx0IHJvdXRlIGJ5IDUuMi4zLjggKElPVyBp dCBpc3N1ZXMgaXQgYnV0IGRpZCBub3QgaW5oZXJpdCBmcm9tIG5vcnRoIGJ5IGl0ZW0gMyBpbiB0 aGUgcG9zc2libGUgcmVhc29ucykgdGhlbiBpdCBzaG91bGQgYWxzbyBkaXNhZ2dyZWdhdGUuDQoN Cg0KDQo= --_000_MN2PR11MB3565D2D34A12285EFCD8D537D8590MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcw Ljg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDozNTk0NzYyMTE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xMzc0ODk4NDYyIC0yMTQ1MjQ1NDAwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjgu MHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6QXJp YWw7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjQuMHB0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjAwLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MjM2LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI3Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDozMDguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozNDQuMHB0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzgwLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdp bi1sZWZ0OjQxNi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhlbGxvIFRvbnkgYW5kIEJydW5vOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugc2Vl IGJlbG93PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCB0aGUgYmVzdDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5QYXNjYWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMjgsIDIwMTkgYXQgMTA6MjYgQU0gQnJ1bm8g Umlqc21hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJydW5vcmlqc21hbkBnbWFpbC5jb20iPmJydW5v cmlqc21hbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUGFzY2Fs IChDQyBSSUZUIG1haWxpbmcgbGlzdCBwZXIgV0cgcmVxdWVzdCksPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gYWJvdXQgdG8gZ2V0IHN0 YXJ0ZWQgb24gaW1wbGVtZW50aW5nIG5lZ2F0aXZlIGRpc2FnZ3JlZ2F0aW9uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXIgbXkgdXN1YWwg bW9kdXMgb3BlcmFuZGksIG5vdyB0aGF0IEkgc3RhcnQgdGhpbmtpbmcgYWJvdXQgYWN0dWFsIGNv ZGUsIEkgaGF2ZSBtb3JlIHF1ZXN0aW9ucyBhYm91dCB0aGUgZHJhZnQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gNS4yLjUuMi4z LiAoQ29tcHV0YXRpb24gb2YgTmVnYXRpdmUgRGlzYWdncmVnYXRlcykgZGVzY3JpYmVzIHR3byBz dGVwcyBmb3IgZ2VuZXJhdGluZyB0aGUgbmVnYXRpdmUgcHJlZml4ZXMuIEkgZG9uJ3QgZnVsbHkg dW5kZXJzdGFuZCB0aGUgZmlyc3Qgc3RlcC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc291bmRzIGxpa2UgcnVubmluZyBzb21l IHNwZWNpYWwgdmFyaWF0aW9uIG9mIFNQRiB3aGljaCB3aWxsIGZpbmQgc29tZSBleHRyYSBwcmVm aXhlcyAocmVsYXRpdmUgdG8gYSBub3JtYWwgU1BGIHJ1bikgYW5kIHRob3NlIGV4dHJhIHByZWZp eGVzIHdpbGwgYmUgdGhlIG5lZ2F0aXZlIHByZWZpeGVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwO1RoZSBmaXJzdCBvcmlnaW5hdGlvbiByZWFz b24gaXMgYSBjb21wdXRhdGlvbiB0aGF0IHVzZXMgYWxsIHRoZSBub2RlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDtOLVRJRXMgdG8gYnVp bGQgdGhlIHNldCBvZiBhbGwgcmVhY2hhYmxlIG5vZGVzIGJ5IHJlYWNoYWJpbGl0eTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Y29tcHV0 YXRpb24gb3ZlciB0aGUgY29tcGxldGUgZ3JhcGggYW5kIGluY2x1ZGluZyBUb0YgbGlua3MuIFRo ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Y29tcHV0YXRpb24gdXNlcyB0aGUgbm9kZSBpdHNlbGYgYXMgcm9vdC4gVGhpcyBpcyBjb21w YXJlZCB3aXRoIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7cmVzdWx0IG9mIHRoZSBub3JtYWwgc291dGhib3VuZCBTUEYgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gNS4yLjQuMi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwO1RoZSBkaWZmZXJlbmNlIGFyZSB0aGUgZmFsbGVu IGxlYWZzIGFuZCBhbGwgdGhlaXIgYXR0YWNoZWQgcHJlZml4ZXM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwO2FyZSBhZHZlcnRpc2VkIGFz IG5lZ2F0aXZlIHByZWZpeGVzIHNvdXRoYm91bmQgaWYgdGhlIG5vZGUgZG9lcyBub3Q8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwO3NlZSB0 aGUgcHJlZml4IGJlaW5nIHJlYWNoYWJsZSB3aXRoaW4gc291dGhib3VuZCBTUEYuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBx dWVzdGlvbnMgYXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4oMSkgQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIG1vcmUgZGV0YWlscyBvbiBo b3cgdGhpcyBzcGVjaWFsIHZhcmlhdGlvbiBvZiBTUEYgaXMgZGlmZmVyZW50IGZyb20gdGhlIG5v cm1hbCBTUEYsIGFuZCB3aHkgaXQgeWllbGRzIHRoZSBuZWdhdGl2ZSBwcmVmaXhlcz88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHRob3VnaHQgaXQgd2FzIHdyaXR0ZW4gZG93biB0aGF0IG9uZSBydW5z IGEgc291dGhib3VuZCB1c2luZyB0aGUgRS1XIGxpbmtzIEAgVG9GIGxldmVsICh0byBjcm9zcyBp bnRvIG90aGVyIHBsYW5lcykgYW5kIGNvbXBhcmVzIHRoYXQgdG8gbm9ybWFsIFMtU1BGLiBEaWZm IGlzIGZhbGxlbiBsZWFmczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5zdWdnZXN0Jm5ic3A7IGJldHRlciBsYW5ndWFnZSA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxl PSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo5Mi4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlBh c2NhbDogSSB0aGlua3MgdGhpcyBib2lscyBkb3duIHRvOjxvOnA+PC9vOnA+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207dGV4dC1p bmRlbnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmFuZCBp bmNsdWRpbmcgVG9GIGxpbmtzDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTt0ZXh0LWluZGVudDowY207bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPiZuYnNwOz0mZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowY207dGV4dC1pbmRlbnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPmFuZCBpbmNsdWRpbmcgRS9XIGxpbmtzIHRoYXQgY29udmV5IHRoZSBkZXN0 aW5hdGlvbnMgdGhhdCBhcmUgcmVhY2hhYmxlIGJ5IG90aGVyIG5vZGVzIGF0IHRoZSBzYW1lIGxl dmVsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oMikgU2hvdWxkIHRoaXMgc3BlY2lhbCBmbGF2 b3Igb2YgU1BGIGJlIHJ1biBvbiBhbGwgbm9kZXMsIG9yIG9ubHkgb24gc3BlY2lmaWMgbm9kZXMg KGUuZy4gb25seSB0aGUgVG9wLW9mLUZhYnJpYyBub2Rlcyk/IEkgYW0gYXNraW5nIGJlY2F1c2Ug dGhlIG90aGVyIHN0ZXAgdGFrZXMgY2FyZSBvZiBwcm9wYWdhdGluZyB0aGUgbmVnYXRpdmUgcHJl Zml4ZXMgc291dGgtd2FyZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NS4yNXB0Ij5vbmx5IFRvRiByZWFsbHkgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20i IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6OTIuMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5QYXNjYWw6IEluIHByYWN0aWNl IHByb2JhYmx5IHNvLiBCdXQgY29uc2lkZXJpbmcgdGhlIGNyYWZ0ZWQgdGV4dCBpbiBkZWZhdWx0 IHJvdXRlIG9yaWdpbmF0aW9uIGluIHNlY3Rpb24gNS4yLjMuOCwgSSB0aGluayB0aGUgc2FtZSBs b2dpYyBhcHBsaWVzIGFuZCBzaG91bGQgYmUgd3JpdHRlbiBhcyBzdWNoLjxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo5Mi4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPklmIGEgbm9kZSBkZWNpZGVzIHRvIG9yaWdpbmF0ZSBh IGRlZmF1bHQgcm91dGUgYnkgNS4yLjMuOCAoSU9XIGl0IGlzc3VlcyBpdCBidXQgZGlkIG5vdCBp bmhlcml0IGZyb20gbm9ydGggYnkgaXRlbSAzIGluIHRoZSBwb3NzaWJsZSByZWFzb25zKSB0aGVu IGl0IHNob3VsZCBhbHNvIGRpc2FnZ3JlZ2F0ZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB3565D2D34A12285EFCD8D537D8590MN2PR11MB3565namp_-- From nobody Thu Mar 28 05:53:52 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54361202A3 for ; Thu, 28 Mar 2019 05:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf2kUjMUcIcs for ; Thu, 28 Mar 2019 05:53:49 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B5E120260 for ; Thu, 28 Mar 2019 05:53:49 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id y5so12001960qkc.11 for ; Thu, 28 Mar 2019 05:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZnvjiDdsaNLETINMLwQT6KYz2IIdypWxhgHZWav1Jkc=; b=vQUqJryCVc2R9Cl/7GV4Vf5pOkoLqpAq9iQUc9lotxjwy8KnWfsHFBO5zIPNubB0A1 zHk3gecYQW/gsGkTOXz05pA2D2PXtPlQHCHmFOTCX3FPYkWCGg1L0duHRsKJ6JHxU5dD y/B7lrXEU/CuoO0azcotqMyFt5aqZJw1fOFFQE2uUr03vpzceBVDSFmxTNo/hs3r91/5 e8VZF9/PhPHHBpYs39N8Yoz8XUuThBG9dOLuSiVEuXzGI9m1S0L6Y53hF6AxiIAddGTl oV5bWoaeBqW41BalFmi4UKNCP0HTp02YLurQQbCuLDmamkIIsfN4SulGeewJYXIVMg6Y ivhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZnvjiDdsaNLETINMLwQT6KYz2IIdypWxhgHZWav1Jkc=; b=MZWBubwzedCDF9DIrNz1H2NNYLWkJT0YTVLuJCsqvS2gzo8WEzLkbCA4mKBc6QLQS9 nlRCPKbF9wylMfwp9AyZAPUcREP/PafJ/nA/eXxhmob/Bwy1rnVwh9MZEMqJsI55qZNt Pfcl20hQ6Z/tYxZYEwTu8+ZHmmKMm4yP7ZIfnzJ8zklt5qL9BiAi5QVpNlaRJZ7djVhj B0LIjeHeVqtNJAFBXEbFX1VTeeEGhSBkv3UXxhv7B9q9z1xF1Ei/eCJ3dRQNPEDF9kuI u3ef1cKXVfPbwocfSFfMr+MKzqqKGCr0wePh6pZmLUQeywTfBI4VhkhwQrtZ8/3u7EeB 2mCg== X-Gm-Message-State: APjAAAXoKbY9isPmAVQn1fK/wkOekgsw3VmROkt9WjkaNpqW1MxaKWbS J5Ep/MXxwtNkZtmv0qoTVOA= X-Google-Smtp-Source: APXvYqxjXKh7aDwQj8Okmg6j78bXiw98CY5XaxMMdr76khEGmypUSquQhUVoZUm0/OGda+oLTPt6XA== X-Received: by 2002:a05:620a:15f5:: with SMTP id p21mr33493013qkm.5.1553777628610; Thu, 28 Mar 2019 05:53:48 -0700 (PDT) Received: from [192.168.20.114] ([200.63.168.130]) by smtp.gmail.com with ESMTPSA id d17sm13387565qtl.43.2019.03.28.05.53.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 05:53:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Bruno Rijsman In-Reply-To: Date: Thu, 28 Mar 2019 09:53:44 -0300 Cc: "rift@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <747D6C88-CAFE-4557-9AC1-E782AC6F1A09@gmail.com> References: <99F95A9E-E9DC-45F9-A5F8-845F66C8A019@gmail.com> To: Pascal Thubert , Tony Przygienda X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Rift] [RIFT-TEAM] Questions about negative disaggregation X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 12:53:51 -0000 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 nobody Thu Mar 28 06:04:08 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B141202A3 for ; Thu, 28 Mar 2019 06:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob9jQ6UBooy0 for ; Thu, 28 Mar 2019 06:04:00 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26928120141 for ; Thu, 28 Mar 2019 06:04:00 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id x14so14483884eds.1 for ; Thu, 28 Mar 2019 06:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BeAAjgxff9QZrQ/oCxPxQNomz3hW/in9oyhaxI6nJnQ=; b=QmgU8156Z3x94wLcbgFZiMKA8/jCdc1DXdw8v2w9II7BeixxfRE9ylhcQl/pDsVtun Hy019OPixUS4ZNOCx14qkjKy75QhVArqzYGl0nJ5dyeodDgau5T++gjCXl4bx10PvaEK PJEw+rBRcVS6Djr6CfIgp3QHCU6LMRk2rlQCSq6iy5slBxsQAA9PmDoNlQS877tx41+4 aNArhz6qVJsT20bK0qxu5Upta90Or3DexeS8etAj+4hdGPhmzbZFPVA4rjGhFmgKiD5r 3QnoC2zIKV5fnWDVzXAQ/Hrtt7be478hXxp6K/75KTFFtpS/gUHlzDWKak8TVZ6cGpbx 2/SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BeAAjgxff9QZrQ/oCxPxQNomz3hW/in9oyhaxI6nJnQ=; b=jrv78GWGhBq+YjBWUXOSkTU//iKVNDESi00g4yK21nElXtU8O9Lu9HxdddapVkpXKO mQL+Xh1gYlkxfbuy0QgCtEF+v2uGk1p1HBVJA3Ad5byM9QY3U7ThJyDOb9K7aO7lZqJq +CTNJpwr1gCzLVV53gyU1iVS+ZMtzOT/3Kc0FmEW+e9AbT567GGcm87cwJLR7prrxDAS OpFTHN/ZnLg7K3XW8YAKkDWllz02OeCVsIaklUN5QYy19EgvN58hCr/sJUBrxJY2vgZ9 3WVJPTYvenq8DeWK1wWCNK3qXtSSBkZBiucxzZlvKuV8u99fO0/cKMoqb4qMet33+dS6 bQbg== X-Gm-Message-State: APjAAAUXlBJiAjA2x2MQzgezm7FW3VioOrp78jE9YNlI1TOoZnSY0gqI hQOI/IH5aLZjhOF9hedjUmW24TQ4tQCAWhScxyI= X-Google-Smtp-Source: APXvYqxbZ3fXrskLeX9Fkk++uoIeLn9RgRcngQmP9pSWvNeUOo3D2xZSIL2mH1qkarKiUiYfRIfghC8XvNNPToJasvg= X-Received: by 2002:a50:8561:: with SMTP id 88mr13006727edr.101.1553778238746; Thu, 28 Mar 2019 06:03:58 -0700 (PDT) MIME-Version: 1.0 References: <99F95A9E-E9DC-45F9-A5F8-845F66C8A019@gmail.com> <747D6C88-CAFE-4557-9AC1-E782AC6F1A09@gmail.com> In-Reply-To: <747D6C88-CAFE-4557-9AC1-E782AC6F1A09@gmail.com> From: Tony Przygienda Date: Thu, 28 Mar 2019 14:03:20 +0100 Message-ID: To: Bruno Rijsman Cc: Pascal Thubert , "rift@ietf.org" Content-Type: multipart/alternative; boundary="000000000000faf41b0585272f8f" Archived-At: Subject: Re: [Rift] [RIFT-TEAM] Questions about negative disaggregation X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 13:04:06 -0000 --000000000000faf41b0585272f8f Content-Type: text/plain; charset="UTF-8" On Thu, Mar 28, 2019 at 1:53 PM Bruno Rijsman wrote: > 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? > > give me a holler 1:1 and we'll synchronize, I forgot what keys we agreed on already ... > > --000000000000faf41b0585272f8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 28, 2019 at 1:53 PM Bruno= Rijsman <brunorijsman@gmail.c= om> wrote:

--000000000000faf41b0585272f8f-- From nobody Fri Mar 29 13:41:31 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65815120356 for ; Fri, 29 Mar 2019 13:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1VJiT7iRRH7 for ; Fri, 29 Mar 2019 13:41:26 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7720B120362 for ; Fri, 29 Mar 2019 13:41:25 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id z16so4201732qtn.4 for ; Fri, 29 Mar 2019 13:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OtYKHJv4X+2R6VZtkudIlR57MDvL35ZIy90M7W3hMaw=; b=BORnnICFwRGNkrdO70FxnMY0YXVgW8kFYZCgpWkHN5dNkAqPuv1FaMXJby6DfMX+Bb ebDpwa+GeHfAx7QnO2+EllxwFchmAzsXJK9B0iHkX9Diehvpzhx65Iaa63F2A93IgWmA /HqtcNzSKqLgfY9o4LQbQ8Z/xJphIACbx/83EaLdt+tyoeEmvALmSudd4In9A67RQM2V LkujmC4aIzfB8pGUUtcbDzhVqrg/PcVeX8/TGe5omTBcTk37D8ccfCrRQlZ9KqyVYPKD 9pilPCzh6ScEPUhKPzs1edJp6Zs0PmQeE+QEMqVNwMkxtPOqx8jtbN1oKYq4+qenTg1n wqtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OtYKHJv4X+2R6VZtkudIlR57MDvL35ZIy90M7W3hMaw=; b=fhfFozpeq6Z86fVwr6rs2awmjs9dtJKgLoasUk3wy7yW3GFxPlXAYJwB2AnPnT994L AvX6JgdGH2fw81zWKq5UofvKAAhcs7PH3dsokPQR7MsP9cDiBCIaBQwq9tSPT3NN5uc6 E6tLc/Nh5adUyiOtcTMXxMFVEQTNeCzbAVDt1WA96paqo5D/VUYD8bB7OQQARwUzQKMs l6FZlD3Q5r0JIVa6XG8bJaslMrXbD7LAZfYy1GWFg4BFdVmo7P1G4MLe5ZC9MHF22nPC yOW+UuK3mbMIBYV3dVS16pO1L3N3Hy0P9+pTv/TauTjNhMSvhctRHTX1SblQbuAvRF54 JNrw== X-Gm-Message-State: APjAAAW1WGiKBerQCHWuDdaFqwSXPfb6OUJ1bBHz92psOwRjdStolpFK Swp9wxzsHVITLttn3of3Cqc= X-Google-Smtp-Source: APXvYqwiV5rLO066tEHak0TzTIBP1jSOekxO81nXgDzuiZn9PqIULQKXFiC3BpcZZQI5kSO/Zd1FvA== X-Received: by 2002:aed:35b0:: with SMTP id c45mr43417200qte.144.1553892084423; Fri, 29 Mar 2019 13:41:24 -0700 (PDT) Received: from [192.168.20.114] ([200.63.168.130]) by smtp.gmail.com with ESMTPSA id 11sm2278335qtu.5.2019.03.29.13.41.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 13:41:23 -0700 (PDT) From: Bruno Rijsman Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9C77DDF0-2B52-4EFD-BBF6-DE47AFD5738B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 29 Mar 2019 17:41:19 -0300 In-Reply-To: Cc: Pascal Thubert , "rift@ietf.org" To: Tony Przygienda References: <99F95A9E-E9DC-45F9-A5F8-845F66C8A019@gmail.com> <747D6C88-CAFE-4557-9AC1-E782AC6F1A09@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Rift] [RIFT-TEAM] Questions about negative disaggregation X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 20:41:29 -0000 --Apple-Mail=_9C77DDF0-2B52-4EFD-BBF6-DE47AFD5738B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tony> I forgot what keys we agreed on already =E2=80=A6 I think we agreed on SHA256. I plan to make it configurable with SHA256 as the default. I plan to also include a =E2=80=9Cno-authentication=E2=80=9D option = where I set the hash to zero on TX and don=E2=80=99t 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/experi= ment.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= --Apple-Mail=_9C77DDF0-2B52-4EFD-BBF6-DE47AFD5738B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tony> I forgot what keys we agreed on already =E2=80=A6

I think we agreed on = SHA256.

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

I plan to also include a = =E2=80=9Cno-authentication=E2=80=9D option where I set the hash to zero = on TX and don=E2=80=99t 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/ma= ster/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
= --Apple-Mail=_9C77DDF0-2B52-4EFD-BBF6-DE47AFD5738B-- From nobody Fri Mar 29 13:51:57 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F50D120366 for ; Fri, 29 Mar 2019 13:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFc1vFGRb4Sn for ; Fri, 29 Mar 2019 13:51:52 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221A912036F for ; Fri, 29 Mar 2019 13:51:52 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id b74so2200236qkg.9 for ; Fri, 29 Mar 2019 13:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=q7QFD0Chhq+MCtxTLwPuj0TeVN9/nzIKPxnqOHyGznQ=; b=ko2ovW1pU2uXXcuG1K1VeLA9REpXQC6vnuZJjqgqL3uBTGDGPeOu33IlWlogngtHMT Ih0pQqozokKfLam8gj72qntcu6VG3SlW8UVOwHMPYfwj0W2C5kFu8zTMJyIeXOEqAdBy mEDsEFNe5yFJ69aFWqkyjHf1+A0aH3Mhi5LTDl01FeNcpM4MTOZ7zOJ1SoHWoayDKUx/ XQd5R5UuC9/wUTALsmmIEtEAQaDK73oarF5VxCKqVnYA+B89cVbUt4npveBLEiFZwfZA 0UM6JsC/Rl2R1oNpmR/K1+AcC3XDEnDr4pLLmjg9iagQM3ofKHyCguTe9rMTIiZglLEs vlaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=q7QFD0Chhq+MCtxTLwPuj0TeVN9/nzIKPxnqOHyGznQ=; b=FInlLVbp2ox98QnqCTeR3R6HXR37fx70Q4ZcM+GxrExCgJyq8fKrfIWsvsw4l6LLHu GGbo0EaSuIytLJQAMC9SXehQVInqeFuR90p11xlUc5dy7vGbUpNO3cNA/vWFfUIL3rut suHtlAYZdP6bcNplmiYXjH3q/YzWRe9bNhmqWHLmfeR97iE2bnxy3mSTYVvWMQjp3gzL BsIRI0/Otba9cQiQO2ETsGWnyV1ZVi8OXf0Cxx0MdP6OKGE0tfWazwCjZIr22mGpKWNY 9weo09jZHrBEIbQhvGy4md2rbMeP2sMm3VGrTYTHO5tL+YsRBLC0393AV0gDnw+S4Sfa fNOg== X-Gm-Message-State: APjAAAXZgD6o+v397d2FN/8SZ3y36ETbHLc4wHcWxifzWeHa9zjuQKBi L15NPFytyw1MDfmg715P9NY= X-Google-Smtp-Source: APXvYqxCQ7gfg/IlzQjFgVzA3cyt+EvBYnPXJ3gKvjMwYen0aPoZd/XvY+JzQE6DNzgQOHeqBkdEdA== X-Received: by 2002:a37:f511:: with SMTP id l17mr36246160qkk.296.1553892710962; Fri, 29 Mar 2019 13:51:50 -0700 (PDT) Received: from [192.168.20.114] ([200.63.168.130]) by smtp.gmail.com with ESMTPSA id d205sm1694906qkg.66.2019.03.29.13.51.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 13:51:50 -0700 (PDT) From: Bruno Rijsman Message-Id: <4129EC37-7A77-4EDF-A145-3312E74F9B7D@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E0B758BE-03B8-492A-9365-96F70C1C09FC" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 29 Mar 2019 17:51:47 -0300 In-Reply-To: Cc: Pascal Thubert , "rift@ietf.org" To: Tony Przygienda References: <99F95A9E-E9DC-45F9-A5F8-845F66C8A019@gmail.com> <747D6C88-CAFE-4557-9AC1-E782AC6F1A09@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Rift] [RIFT-TEAM] Questions about negative disaggregation X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 20:51:55 -0000 --Apple-Mail=_E0B758BE-03B8-492A-9365-96F70C1C09FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hmmmm=E2=80=A6. I may be doing it the wrong way, I haven=E2=80=99t = included a key yet. Disregard these results for now until further = notice. > On Mar 29, 2019, at 5:41 PM, Bruno Rijsman = wrote: >=20 > Tony> I forgot what keys we agreed on already =E2=80=A6 >=20 > I think we agreed on SHA256. >=20 > I plan to make it configurable with SHA256 as the default. >=20 > I plan to also include a =E2=80=9Cno-authentication=E2=80=9D option = where I set the hash to zero on TX and don=E2=80=99t verify on RX. >=20 > 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/experi= ment.py = ): >=20 > 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 --Apple-Mail=_E0B758BE-03B8-492A-9365-96F70C1C09FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hmmmm=E2=80=A6. I may be doing it the wrong way, I haven=E2=80=99= t included a key yet. Disregard these results for now until further = notice.

On Mar 29, 2019, at 5:41 PM, Bruno Rijsman = <brunorijsman@gmail.com> wrote:

Tony> I forgot what = keys we agreed on already =E2=80=A6

I think we agreed on SHA256.

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

I plan to also include a = =E2=80=9Cno-authentication=E2=80=9D option where I set the hash to zero = on TX and don=E2=80=99t 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/ma= ster/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

= --Apple-Mail=_E0B758BE-03B8-492A-9365-96F70C1C09FC-- From nobody Fri Mar 29 14:33:29 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67F61202F5 for ; Fri, 29 Mar 2019 14:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjmuaQvD4BJk for ; Fri, 29 Mar 2019 14:33:25 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6962D1202C0 for ; Fri, 29 Mar 2019 14:33:25 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id q3so3279497edg.0 for ; Fri, 29 Mar 2019 14:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N5jbcJ0n5UOJUfYGNpUtIbr40ek3hAbm6pp+XqhMseU=; b=CbtwPxEhuy8reYwW37rdTXtdeD1tggQbCQPA0Rwg+yMOLq92ciq6cAHOlNqEdrIypU PVQrSjorFUD6P/wV0jkFY6hkEmqMA0WS/7ix3wD0lZLfWjRJLmEPbhzEKBo9mm/7frB8 AHeQC+oVlLUYT4G1e+As3gmfpMPfeS1FVBlOz9oMdf/gVVxqTS41CEMONaAelv390s55 WgU1DurR3S1T/lx7SPscQB/H0ihEalbd3AF+FoIZT3dsFGJWTmDpcxwnj0OuQrz5OGvY IBDTU1VguZk+SUAEnHmDFTZja3OfhXU3XUtfb38db5KBXSGQLDnMjhHm/KjxBxuGv/UR UWkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N5jbcJ0n5UOJUfYGNpUtIbr40ek3hAbm6pp+XqhMseU=; b=LMtw3+F+bfGlfMK/ZJEl9a5Q7TyITr0FtamWfaJXdc/h0wPFbQ0qUA02cLAQAlcC14 rtY19XnxCK50uYBNqvWqOSxVIuXd/lWV7gEK5GRT7SkVAwC1ewSMemlBN+mcHXbmBUfc GgqtOv9dUkDx9reZ4P0jimqSOQSo35KORcsDbzY+y3soHviHU2d0aUlbKl9XKDa6E3vU 3ADq71r5UFWQYMQRDfNPR7Z1XhfxTOYFxTncNA3MmaviEfx3bV8/bN3fUst+VeaGOhCH OMOaVFbzirIEL6ZN7MtvOWuzymShOZXcUjPFpNDXU1BDunKZukDAD3r/YmufZq782C62 0Fhw== X-Gm-Message-State: APjAAAX4BJWUHn3YepWLVW4kKTsc9xefbdpEhZYhZCzTnMe1v5BE/LXb JT3C3SO61FgkADzs4r+PUY6n6r/JQIYr8cGcFXUU70DV X-Google-Smtp-Source: APXvYqx8U+jyeo6NxRFVZeyG/c9GVqwNYx5R6AK7npmmbClknGZ1czfHtjtkGLvvMH9sJANvF8PqB5WtHp99vQw4+38= X-Received: by 2002:a50:8707:: with SMTP id i7mr34084322edb.160.1553895203999; Fri, 29 Mar 2019 14:33:23 -0700 (PDT) MIME-Version: 1.0 References: <99F95A9E-E9DC-45F9-A5F8-845F66C8A019@gmail.com> <747D6C88-CAFE-4557-9AC1-E782AC6F1A09@gmail.com> In-Reply-To: From: Tony Przygienda Date: Fri, 29 Mar 2019 22:32:55 +0100 Message-ID: To: Bruno Rijsman Cc: Pascal Thubert , "rift@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a7135a0585426b0a" Archived-At: Subject: Re: [Rift] [RIFT-TEAM] Questions about negative disaggregation X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 21:33:28 -0000 --000000000000a7135a0585426b0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable yepp, looked it up, it was symmetric sha256 On Fri, Mar 29, 2019 at 9:41 PM Bruno Rijsman wrote: > Tony> I forgot what keys we agreed on already =E2=80=A6 > > I think we agreed on SHA256. > > I plan to make it configurable with SHA256 as the default. > > I plan to also include a =E2=80=9Cno-authentication=E2=80=9D option where= I set the hash > to zero on TX and don=E2=80=99t 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/exper= iment.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 > --000000000000a7135a0585426b0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yepp, looked it up, it was symmetric sha256

<= div class=3D"gmail_quote">
On Fri, Mar= 29, 2019 at 9:41 PM Bruno Rijsman <brunorijsman@gmail.com> wrote:
Tony&= gt; I forgot what keys we agreed on already =E2=80=A6

I = think we agreed on SHA256.

I plan to make it confi= gurable with SHA256 as the default.

I plan to also= include a =E2=80=9Cno-authentication=E2=80=9D option where I set the hash = to zero on TX and don=E2=80=99t 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 prod= uce this is in=C2=A0https://github.com= /brunorijsman/python-hash-experiments/blob/master/experiment.py):
=

Algo=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Data size =C2=A0 Hashes/sec
----------=C2=A0 ----------=C2=A0 ----------=
MD-5=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10 =C2=A0 =C2=A0 524,341
SHA-1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 10 =C2=A0 =C2=A0 417,749
SHA-224 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10 = =C2=A0 =C2=A0 343,344
= SHA-256 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10 =C2=A0 =C2=A0 297,514<= /span>
SHA-384 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 10 =C2=A0 =C2=A0 376,318
SHA-512 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 10 =C2=A0 =C2=A0 296,688
SHA3-224=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10 =C2=A0 =C2= =A0 579,367
SHA3-256= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10 =C2=A0 =C2=A0 542,269
SHA3-384=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 10 =C2=A0 =C2=A0 372,937
SHA3-512=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1= 0 =C2=A0 =C2=A0 566,793
BLAKE-2B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10 =C2=A0 =C2=A0 542,47= 8
BLAKE-2S=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10 =C2=A0 =C2=A0 721,195
MD-5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 100 =C2=A0 =C2=A0 441,754
SHA-1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 100= =C2=A0 =C2=A0 394,913
SHA-224=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 100 =C2=A0 =C2=A0 360,662=
SHA-256=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 100 =C2=A0 =C2=A0 331,191
SHA-384=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 100 =C2=A0 =C2=A0 321,690
SHA-512=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 100 =C2=A0 =C2= =A0 380,822
SHA3-224 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 100 =C2=A0 =C2=A0 556,320
SHA3-256 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 100 =C2=A0 =C2=A0 523,758
SHA3-384 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 100 =C2=A0 =C2=A0 5= 17,561
SHA3-512 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 100 =C2=A0 =C2=A0 293,001
BLAKE-2B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 100 =C2=A0 =C2=A0 871,899
BLAKE-2S =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 100 =C2=A0 =C2=A0 809,5= 48
MD-5 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,000 =C2=A0 =C2=A0 194,658
SHA-1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 1,000 =C2=A0 =C2=A0 189,145
SHA-224=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,000 =C2=A0 =C2=A0 = 123,435
SHA-256=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,000 =C2=A0 =C2=A0 124,261
SHA-384=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 1,000 =C2=A0 =C2=A0 144,571
SHA-512=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,000 =C2=A0 =C2=A0 140,11= 1
SHA3-224 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 1,000 =C2=A0 =C2=A0 120,112
SHA3-256 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,000=C2=A0 = =C2=A0 =C2=A0 89,740
S= HA3-384 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,000=C2=A0 =C2=A0 =C2=A0 80,310=
SHA3-512 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 1,000=C2=A0 =C2=A0 =C2=A0 67,202
BLAKE-2B =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,000 =C2=A0 =C2= =A0 275,804
BLAKE-2S = =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,000 =C2=A0 =C2=A0 199,762
MD-5=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 10,000=C2=A0 =C2=A0 =C2=A0 30,987
SHA-1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10,000=C2=A0 = =C2=A0 =C2=A0 35,767
S= HA-224 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10,000=C2=A0 =C2=A0 =C2=A0 16,882=
SHA-256 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 10,000=C2=A0 =C2=A0 =C2=A0 16,962
SHA-384 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10,000=C2=A0 =C2= =A0 =C2=A0 21,517
SHA-= 512 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10,000=C2=A0 =C2=A0 =C2=A0 21,110
SHA3-224=C2=A0 =C2=A0 =C2=A0 = =C2=A0 10,000=C2=A0 =C2=A0 =C2=A0 14,694
SHA3-256=C2=A0 =C2=A0 =C2=A0 =C2=A0 10,000=C2=A0 =C2=A0 = =C2=A0 13,710
SHA3-384= =C2=A0 =C2=A0 =C2=A0 =C2=A0 10,000=C2=A0 =C2=A0 =C2=A0 10,718
<= div style=3D"margin:0px;font-stretch:normal;font-size:14px;line-height:norm= al;font-family:Menlo;background-color:rgb(255,255,255)">SHA3-512=C2=A0 =C2=A0 =C2=A0 =C2=A0= 10,000 =C2=A0 =C2=A0 =C2=A0 7,154
BLAKE-2B=C2=A0 =C2=A0 =C2=A0 =C2=A0 10,000=C2=A0 =C2=A0 =C2=A0= 35,085
BLAKE-2S=C2=A0= =C2=A0 =C2=A0 =C2=A0 10,000=C2=A0 =C2=A0 =C2=A0 27,761
<= /div>
--000000000000a7135a0585426b0a-- From nobody Sun Mar 31 16:29:41 2019 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A34912006E for ; Sun, 31 Mar 2019 16:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvaYnUVtT09F for ; Sun, 31 Mar 2019 16:29:37 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A76120005 for ; Sun, 31 Mar 2019 16:29:37 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id v21so6577815edq.4 for ; Sun, 31 Mar 2019 16:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bRRnccmBhxL9dCTllc3v5In46Ao4zIgWd/U2GY2TbO0=; b=sJ7ab4rwGMdmYl2iv8vZHhb1QjomFzbNW1wyEuhzljFhPLr4IRhGBoWYsF2KmerpKm KCBGqJDKKdpdXtt4A9bB/x6lbLkGdQoO6RQ5egKBqhFgUbCzerBaQfs8cgboRR8cno8p Y3G2TRtMJHMOhB7J/INLmnqxNUu45zGcj+UvKydvNjytjtpw7RFbRVY7zmFydP1Qrklr ve2luBOYNgRpxxaCqXwSO7kbsmR9mM8MAtChBgE57sgi8EjNfBTPv2Ocka88zTHcCWQ9 Jzc4cuYE30MRgo4DgtYcY+LGNPP5nV3mxug2SxgbJBrsOwsRg5waZRCROWYKq80AGVRp bisg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bRRnccmBhxL9dCTllc3v5In46Ao4zIgWd/U2GY2TbO0=; b=NU1gHUs0a6XoZwVT0O+3tpXmOSOMRCJ/4/re7LmcPmib/NOBMvKieFar+1UFVPNiAH 7L1kRWmUxdXuTsxH/foklvDGJEbkpfGe1/8IzKChH4PDvk3ARY8IJ5ACLLzcfHw532JX /UV+ov4VhC0a3f9TjrqKAnDVEWRkM6yhtmj9ijFRYKZDRXlKR8fQYfhtrtSQnZ5xqQkz m7Ev4nrH2fruUk17x9s7zvrKKjmDc22Q46AYQOaVmfwcxqI+3+rd8JI6HkJduXfesVN1 qVZzEsTTOwKbafBcFW9DLqKAtAwGY2bAh/jxtANmS8VTU8sP6RViWQj33G4Z66isezo5 vSHw== X-Gm-Message-State: APjAAAX16RRByIXR8Cew7DPtiU/W+gA4o7PSDmeC3Za/y7o8hrnP10Et vDpMfe2O9HWj9bzyGbtqK7DO0VTJGouIO1fmA+NxHDH1 X-Google-Smtp-Source: APXvYqxiXrPJsC1qWmDVpvL+2r9JnVbVB5RCAAwUUpEfB+lgDlx59Uj0Hmb4WowHqkIuMG3E+TgIOkKuQhjTjuAPoxA= X-Received: by 2002:a50:8561:: with SMTP id 88mr25299869edr.101.1554074975820; Sun, 31 Mar 2019 16:29:35 -0700 (PDT) MIME-Version: 1.0 From: Tony Przygienda Date: Mon, 1 Apr 2019 01:29:11 +0200 Message-ID: To: rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000e362a705856c46a2" Archived-At: Subject: [Rift] Per request weekly design team zoom invite (again ;-) X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 23:29:40 -0000 --000000000000e362a705856c46a2 Content-Type: text/plain; charset="UTF-8" Despite posting it multiple times before I have been asked @ this IETF again by two people where the invite for the weekly is. So here it goes Thu, 8AM PST Tony Przygienda is inviting you to a scheduled Zoom meeting. Topic: RIFT meetings Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://zoom.us/j/7093181681?pwd=Ykk1ekI3N2FJMStwVFM5YjJpZTNiUT09 Password: port911 One tap mobile +16699006833,,7093181681# US (San Jose) +19292056099,,7093181681# US (New York) Dial by your location +1 669 900 6833 US (San Jose) +1 929 205 6099 US (New York) Meeting ID: 709 318 1681 Find your local number: https://zoom.us/u/abfvdsnkib --000000000000e362a705856c46a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Despite posting it multiple times be= fore I have been asked @ this IETF again by two people where the invite for= the weekly is. So here it goes

Thu, 8AM PST

Tony Przygienda is inviting you to a scheduled Zoom= meeting.

Topic: RIFT meetings
Time: This is a recurring meeting = Meet anytime

Join Zoom Meeting
https://zoom.us/j/7093181681?= pwd=3DYkk1ekI3N2FJMStwVFM5YjJpZTNiUT09

Password: port911

= One tap mobile
+16699006833,,7093181681# US (San Jose)
+19292056099,,= 7093181681# US (New York)

Dial by your location
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 +1 669 900 6833 US (San Jose)
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +1 929 205 6099 US (New York)
Meeting ID:= 709 318 1681
Find your local number: https://zoom.us/u/abfvdsnkib

--000000000000e362a705856c46a2--