Re: [Rift] RIFT protocol implementation
Tony Przygienda <tonysietf@gmail.com> Thu, 14 May 2020 00:05 UTC
Return-Path: <tonysietf@gmail.com>
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 1D2653A082A for <rift@ietfa.amsl.com>; Wed, 13 May 2020 17:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 FpZFtARNOodw for <rift@ietfa.amsl.com>; Wed, 13 May 2020 17:05:14 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 BBEF43A07BD for <rift@ietf.org>; Wed, 13 May 2020 17:05:14 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id e8so466323ilm.7 for <rift@ietf.org>; Wed, 13 May 2020 17:05:14 -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=AFYqIEiwCgM16y+tnaspjBC28gbyy69gELdYpcN0dtw=; b=KfaNOgU98g6PDfOPdTguW6H7d9RHu2ciEph+m425QGitbqseexajtYRnrehWi7Uoro ZOIeIDt8BiL5gjah4IQkexDbyp9e0EA+GQZRUMGHLXOoMjNrb6bBnDDce02RYtUSJ5W5 hYQGAadgnFw32lhtTHeN13luKz3tFPxXZhT4dwYAh0oe6YKwzChU7QnK6BQ3mxBzw0cb bk2AM+XIw5rOCXv5lun4fDVgINOViRjSYRIqDe9oPlLsu+zC7Zlbpkoo05oOFmeU51yP Mlw5ogogcCL6wCDBZnGO35YDOWOmt9QrVmZYGJE6qkMI86sV64YnQ+5+A0fIl8dvMe1p JCFw==
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=AFYqIEiwCgM16y+tnaspjBC28gbyy69gELdYpcN0dtw=; b=FvrYGv/BEr0bArsEjUIF/n9FMB2cbIzHiK3qRhJDeod3jWjNYvmHmX85rzgFUN2N3u bZvCr4+0f/uY+usyRSEaB0DsCGTuJnhl2QhFVmvkQhc9HU1vyZdgUldFzjlhFmgGITS3 NBxhjBhT5T3iXdEuyY9hQPQ3mGQnWwppM9scsVTz5FbbEMacwW0Px48L97yR+hMduyFx B+zH6Gx5/tN0GsuAvfMzNmTqAX5IlR4NmizkivZ4kO8CWGS9KuuasNAppN7QCe0/mOWf kTcXkqisSRO+DobA8y+zv992HbjVzjcTfpnnIlhODghq6vEzRzgHEGPFaVzPWS4AKQvW 7G4g==
X-Gm-Message-State: AOAM533Ud8nvrbt9MRORCZkwpJvvQorGPe+s0aL5Eb2n1xbh77yu0wnm VLVmokPc4d+ReqlUKjYTUNzhDsgxJ0s2bcAF+LU=
X-Google-Smtp-Source: ABdhPJwcKtwn8fIILG1thA1fU1vAslDNAmK3Fsyb78z6xDAhEmyNC3el7wwJjNOyn4fF5XJm7PpIGgp4zkmKCwc3Kuk=
X-Received: by 2002:a92:a053:: with SMTP id b19mr1900820ilm.156.1589414713803; Wed, 13 May 2020 17:05:13 -0700 (PDT)
MIME-Version: 1.0
References: <AM6PR04MB432519F740317CFE30ED33C8C1420@AM6PR04MB4325.eurprd04.prod.outlook.com> <8a55226e-d428-f195-cfb5-c427229eb081@os.uniroma3.it> <87FBCCFA-A2E9-41EA-9C8F-BC87AAF1A9CF@gmail.com> <5b48347b-4156-bc4e-dcb2-14ec70159ee6@os.uniroma3.it> <E824E104-63BF-415E-BBBB-8A6EF7FAE332@gmail.com> <2528b464-c368-6e31-54c7-6ff200b6dafb@os.uniroma3.it> <A24BFF42-9AAE-4837-85EA-ACD55BDCEF41@gmail.com> <8977A74B-B0AE-430D-9817-2608952DDCF7@juniper.net> <CA+wi2hN2LziBFx68VEk5HLEVv3Jwj+0uWiZdf=QzJKfaXY1CTw@mail.gmail.com> <fe29024c-7170-97f5-fe3c-d381ef1d62d2@os.uniroma3.it> <C8542AB2-9C17-42FF-8DD8-1AB3C8C65159@juniper.net> <b82cfbc9-6531-cb3a-a7b2-01ed723f37b4@fing.edu.uy> <CA+wi2hOYT-xzh89=SkGexbqV_ZuEqnUD7nSc35veTR=Q+=KEnA@mail.gmail.com> <9b6c08ec-dbb1-234e-5b10-d16426923394@fing.edu.uy> <CA+wi2hPT_19kZ7t1D6BhPBxcjJMyarw5yq3YZ9OHrQ265QEWPw@mail.gmail.com> <CA+wi2hMa46PeDcCWdg_tdMJOpmoLW8sGoHwYKsu30aWDRi=KWg@mail.gmail.com> <547029fd-d545-5e67-8fd2-0b560d6ce82b@fing.edu.uy>
In-Reply-To: <547029fd-d545-5e67-8fd2-0b560d6ce82b@fing.edu.uy>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Wed, 13 May 2020 17:03:42 -0700
Message-ID: <CA+wi2hMpU10XCg1SSo-1_fxOpZt0MRg4LZoFxv3efQS6+3JtyA@mail.gmail.com>
To: Leonardo Alberro Zimmermann <lalberro@fing.edu.uy>
Cc: rift@ietf.org, Bruno Rijsman <brunorijsman@gmail.com>, Eduardo Grampin <grampin@fing.edu.uy>, Alberto Castro <acastro@fing.edu.uy>, Maximiliano Lucero <mlucero@fing.edu.uy>, agustina.parnizari@fing.edu.uy
Content-Type: multipart/alternative; boundary="0000000000006acadb05a590735f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/PcMJ9KDO_OFRC6yMqbXsv_kQNXA>
Subject: Re: [Rift] RIFT protocol implementation
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2020 00:05:18 -0000
well, it makes most sense if you have something that can actually deser/ser a thrift object into something a generic formatted in wireshark can put out. that way there is prety much zilch manual code. The ser/deser in C++ for thrift is very good, also in python, I tried some other languages but not C. In case of doubt ping Luca Deri in Parma pls, he's a dear old friend from Labs times and one of the original wireshark authors AFAIK -- tony On Wed, May 13, 2020 at 10:44 AM Leonardo Alberro Zimmermann < lalberro@fing.edu.uy> wrote: > this is an approach that we were discussing recently, I think we take this > way due to our goals (a functional disector of TIE packets in order to do > some experiments with the Roma Tre team) but the rest of the team (cc) > could correct me :) > > Regards, > Leonardo > El 12/5/20 a las 19:51, Tony Przygienda escribió: > > and quick question, why didn't you just push the binary into thrift > backend to deserialize? People may send compressed binary formats etc and > the encoding may change. Point of the modelling exercise > > -- tony > > > On Tue, May 12, 2020 at 3:48 PM Tony Przygienda <tonysietf@gmail.com> > wrote: > >> multiple people were looking JUST for this. >> >> maybe next interim implementation experience. this was lighting fast ;-) >> >> -- tony >> >> >> On Tue, May 12, 2020 at 3:47 PM Leonardo Alberro Zimmermann < >> lalberro@fing.edu.uy> wrote: >> >>> Hello all, >>> >>> regarding the development of a wireshark dissector for RIFT, we are >>> happy to introduce you our work. It is available at >>> https://gitlab.com/fing-mina/datacenters/rift-dissector >>> >>> RIFT C dissector is a complete Wireshark dissector for decoding RIFT >>> protocol. The code identifies all the RIFT packets and builds a complete >>> dissection for the TIE ones. This dissector has been tested with the >>> current implementations of RIFT. >>> >>> Regards, >>> Leonardo >>> El 26/3/20 a las 13:23, Tony Przygienda escribió: >>> >>> Leonardo, that is a great project. Observe that depending on language >>> backend/thrift compiler different streams may represent the same encoding >>> so it's good to test it against more than one implementation. We should get >>> streams that has all possible LIEs and TIEs in it. >>> >>> If you run juniper standalone public package >>> https://www.juniper.net/us/en/dm/free-rift-trial/ you can easily build >>> a 2x2 yaml topology and just snoop on a UDP port. I suggest snooping a >>> v6/v4 links from a spine to a leaf. that will give you all the LIEs and >>> node TIEs and default prefixes. If you break a link via CLI you will get >>> disaggregation as well. If you struggle with that, ping me ... >>> >>> Having said that you can do all that with open source as well (but >>> observe we didn't pull open source to -11 draft yet which had some schema >>> changes albeit minor). you can pull the schema yourself with Bruno's help >>> or I'll get to it one of these days ;-) ... >>> >>> Architecturally, since RIFT will evolve and possibly move to newer major >>> schemas, I would suggest you provision for the possibility to put into >>> wireshark multiple schema files, basically you'd need to compile multiple >>> directories in differnt namespaces and use the correct one depending on the >>> major you found on packet envelope (you can always use the newest minor you >>> support on the major, they are always compatible). >>> >>> --- tony >>> >>> >>> >>> On Thu, Mar 26, 2020 at 7:17 AM Leonardo Alberro Zimmermann < >>> lalberro@fing.edu.uy> wrote: >>> >>>> Hi everyone, >>>> >>>> as a part of this project we are developing a wireshark dissector for >>>> RIFT. The dissection for the security envelope is ready and tested. Now we >>>> are working on the Serialized RIFT Model Object dissection and for >>>> preparing the testing we are looking for a "known" trace, i.e we need a few >>>> packets and the exact values of these fields in the Thrift model. So if >>>> anyone can help us we'll be grateful. >>>> >>>> Regards, >>>> Leonardo. >>>> El 18/3/20 a las 13:34, Antoni Przygienda escribió: >>>> >>>> Forwarding the discussion to the rift ietf list for further exposure & >>>> since I generally think it will be possibly more productive in a wider >>>> forum. Roma Tre University is working on Bruno’s open source and there’s a >>>> bunch of interesting tools they’re developing as well as you can read >>>> below. >>>> >>>> >>>> >>>> --- tony >>>> >>>> >>>> >>>> *From: *Mariano Scazzariello <mscazzariello@os.uniroma3.it> >>>> <mscazzariello@os.uniroma3.it> >>>> *Date: *Wednesday, March 18, 2020 at 9:10 AM >>>> *To: *Bruno Rijsman <brunorijsman@gmail.com> <brunorijsman@gmail..com> >>>> *Cc: *Antoni Przygienda <prz@juniper.net> <prz@juniper.net>, Leonardo >>>> Alberro Zimmermann <lalberro@fing.edu.uy> <lalberro@fing.edu.uy>, >>>> "tommasocaiazzi@gmail.com" <tommasocaiazzi@gmail.com> >>>> <tommasocaiazzi@gmail.com> <tommasocaiazzi@gmail.com>, >>>> "lorenzoariemma@gmail.com" <lorenzoariemma@gmail.com> >>>> <lorenzoariemma@gmail.com> <lorenzoariemma@gmail.com>, Giuseppe Di >>>> Battista <giuseppe.dibattista@uniroma3.it> >>>> <giuseppe.dibattista@uniroma3.it> >>>> *Subject: *Re: RIFT protocol implementation >>>> >>>> >>>> >>>> Hi everyone, >>>> thanks for the extremely detailed suggestions! I have a lot of stuff >>>> which I can use to work on the implementation. Also thanks Tony for giving >>>> me further useful tips. >>>> >>>> Also, I'm happy that we agree on almost every implementation detail and >>>> I agree with your suggested variations (like the flag for the >>>> spf_run_direction method). >>>> >>>> About point C, I did not write anything since it seems quite easy to >>>> extend the Thrift model. If I have any issues, I'll surely ask you for some >>>> help. I also wrote a point D (which is how to handle the negative >>>> disaggregation in the RIB/FIB when received), but I read the Pascal slides >>>> (I add the link >>>> <https://urldefense.com/v3/__https:/bitbucket.org/riftrfc/rift_draft/src/master/negative*20disaggregation.pptx__;JQ!!NEt6yMaO-gk!QBFQP3Ec6u0elEKgEFaAEndcjyQntJXvMg0h2TfAH6kn4JLUaMb3FOYpDQOltw$> >>>> here, so everyone can access them easily) and the steps used in that >>>> presentation are the same that I thought. >>>> >>>> I still have some doubts about the special SPF run: >>>> *2) We will also need a new member field orig_neg_disagg_prefixes (once >>>> again of type set, I think) that contains the negatively disaggregated >>>> prefixes that are autonomously being originated based on the detection of >>>> fallen leafs based on the difference between the normal and special SPF >>>> run.* >>>> You are proposing to postpone the RIB/FIB update after the special SPF >>>> run (which can detect additional fallen leaf nodes). This is right, but >>>> should this only occur on ToF nodes? If we consider a node X, which is not >>>> a ToF, that receives a negative disaggregation TIE, it should only add the >>>> prefix in the *prop_neg_disagg_prefixes *set and check if it received >>>> this prefix from all its parent nodes and propagate it if required. Then it >>>> should proceed to update its RIB/FIB, without running the special SPF. Am I >>>> right? >>>> >>>> About the flooding oscillations, Tony writes "Your best protection is >>>> scaled, randomized tests". Here at Roma Tre University we developed a tool >>>> called Kathará >>>> <https://urldefense.com/v3/__https:/www.kathara.org/__;!!NEt6yMaO-gk!QBFQP3Ec6u0elEKgEFaAEndcjyQntJXvMg0h2TfAH6kn4JLUaMb3FOZujrrECA$> >>>> which is able to emulate network scenarios using Docker containers. >>>> Recently, we also developed a Fat Tree Generator, that automatically >>>> generates a fat tree topology starting from the fundamental parameters of a >>>> Fat Tree (K_LEAF, K_TOP and R) that can be run in Kathará. It also >>>> auto-configures the routing protocol on each node (of course, we also >>>> included the RIFT-Python implementation). So we can generate Fat Tree >>>> topologies of any size and run tests on it to verify functional and >>>> behavioral aspects (and also gather routing information such as PDU size >>>> and count). We are also developing a Fat Tree Test Framework (in >>>> collaboration with Leonardo and the team at UY university) which implements >>>> typical data center network scenarios (such as link failure, node failure, >>>> fallen leaf, partitioned fabric and so on) to run integration tests on it. >>>> For example, we can check if the routing table of a node is equal to the >>>> expected one after a failure (e.g. loss of a multipath or a prefix). With >>>> this tool we can surely run randomized tests (at any scale, since Kathará >>>> supports Kubernetes) to ensure that no flooding oscillations occur. >>>> >>>> I agree to move the discussion on the RIFT WG mailing list. Maybe >>>> someone of you should introduce us and explain what we're doing. >>>> >>>> Thanks everyone for your time, >>>> Mariano. >>>> >>>> _______________________________________________ >>>> RIFT mailing listRIFT@ietf.orghttps://www.ietf.org/mailman/listinfo/rift >>>> >>>> >>> _______________________________________________ >>> RIFT mailing listRIFT@ietf.orghttps://www.ietf.org/mailman/listinfo/rift >>> >>>
- Re: [Rift] RIFT protocol implementation Antoni Przygienda
- Re: [Rift] RIFT protocol implementation Leonardo Alberro Zimmermann
- Re: [Rift] RIFT protocol implementation Tony Przygienda
- Re: [Rift] RIFT protocol implementation Leonardo Alberro Zimmermann
- Re: [Rift] RIFT protocol implementation Tony Przygienda
- Re: [Rift] RIFT protocol implementation Tony Przygienda
- Re: [Rift] RIFT protocol implementation Leonardo Alberro Zimmermann
- Re: [Rift] RIFT protocol implementation Tony Przygienda
- Re: [Rift] RIFT protocol implementation Bruno Rijsman
- Re: [Rift] RIFT protocol implementation Tony Przygienda
- Re: [Rift] RIFT protocol implementation Bruno Rijsman
- Re: [Rift] RIFT protocol implementation Tony Przygienda
- Re: [Rift] RIFT protocol implementation Leonardo Alberro Zimmermann
- Re: [Rift] RIFT protocol implementation Oliver Steudler