From nobody Tue Oct 1 23:20:17 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 72AEB120041 for ; Tue, 1 Oct 2019 23:20:14 -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_HELO_NONE=0.001, 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 7-qIV_b8bltk for ; Tue, 1 Oct 2019 23:20:12 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 8323D120026 for ; Tue, 1 Oct 2019 23:20:12 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id n26so25765323ioj.8 for ; Tue, 01 Oct 2019 23:20:12 -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=RwbU+F4LbhRcH+kZRyXaQKqgCCepl/WsnGQnch8hRHI=; b=fOabTxyWgdZjQLMazdhS0XgMpxZSM4gn+F48UDzEwqzQ5GRzUKrZs2egS7hLHz3KDi lR0dYxNGN3Aqpi9ckNB77hXLbJMEf95mtDI9EtSloUdxGl2sUkhndvz7cwmAl3ERzwmZ x5sFRdfPIUen/3f6Hz3UsrQjkGwf/JAet1sm0v0BtYtb0Dl0F/xdIvqnu+F/Uo/wKkz8 o6j5gV0dIqNEPVHvAW8bsa2hCaTyeonRM+4zBWYrOeKAC1au7cqLdKh3d/6ISZyTufJ5 SX04qGmXxipsg6va7NCuhFhfRT/QuASuOngWk0h9NfD53GZJlSIlLnw/khtZTFlRDtVY fssA== 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=RwbU+F4LbhRcH+kZRyXaQKqgCCepl/WsnGQnch8hRHI=; b=U5+915rc9znDxs8NuGMQ8gvXfWRPAyilcCCPCgLbERx834K7iFXHZqHQOYoGxk7bSt aguoq01UTVg9nW+qH4fRwhJ6hKA5SQ4suxbpVhLt3rrB+UM9phe4pScaOc7OQCVQPCol Y88FQJV2Mf8AjxyqPCUirOw6/zcJiNjbU7c52tkqIZoRqt3LKYDABDsG2mLNyriAalsH XTHby9ccH8WWYIpE10qNgaQ/WWQgg/KPkGOiVa2tvbLI8fIZS6T5Agvkqin4X0ZIikmW FEfER4+LVBidqd67ycIfWEit+KBAqbq6/Ve1lm1REVUXXlaxUFbT/Neasxo5Ex6kN3Du 2CZw== X-Gm-Message-State: APjAAAUMLG5hATD+29VletfkeZxMZgjY4/p7k0tJbcnMUBrosFyyPyxM wjQI93RridRSJHo96GTdprM/pP6rdhmCAfRx0fIlb6CqAyo= X-Google-Smtp-Source: APXvYqxdkmIJQtkuaXKMgQTBYx/7u6Vo+joHVlJcQR1kTHbLNkPOFegfF4UZ/mcrGFdEfpW7fH9FDikmowgf6gTtiFw= X-Received: by 2002:a92:c0d2:: with SMTP id t18mr2265747ilf.239.1569997211701; Tue, 01 Oct 2019 23:20:11 -0700 (PDT) MIME-Version: 1.0 From: Tony Przygienda Date: Tue, 1 Oct 2019 23:19:35 -0700 Message-ID: To: rift@ietf.org Content-Type: multipart/alternative; boundary="0000000000001a15400593e77680" Archived-At: Subject: [Rift] FYI 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, 02 Oct 2019 06:20:15 -0000 --0000000000001a15400593e77680 Content-Type: text/plain; charset="UTF-8" RIFTers, open source version has been pulled up to the newest -08 LC schema and successfully interop'ed with juniper implementation, usual link https://github.com/brunorijsman/rift-python --0000000000001a15400593e77680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
RIFTers, open source version has been pulled up to th= e newest -08 LC schema and successfully interop'ed with juniper impleme= ntation, usual link

--0000000000001a15400593e77680-- From nobody Thu Oct 3 06:39:11 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 54D321208E4; Thu, 3 Oct 2019 06:39:09 -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_HELO_NONE=0.001, 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 EmDOMBuNA8l0; Thu, 3 Oct 2019 06:39:07 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 143E012006B; Thu, 3 Oct 2019 06:39:07 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id r17so7273296wme.0; Thu, 03 Oct 2019 06:39:06 -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=dqI2AcxcnJNm7PkWVoDRk+5pqv4tiZymkJtCzCo6bv8=; b=A87vrWVxFkUfq7mkYDiM1WS5cIxk+O15wzrTMo3gDPKVQUPsPm3O9jbQVIhzCo9zoS K9Ou0eWxchW5IJCtRq2pBSSJRBhMtCBlbL6h3OrrnG/PO2oyJq5KYuiD0WxBv76P2dUV YfaY4xmeAreIcOwohwxNuoJpiXdAHzDCxyZ7CEHbEqggCqkvkPGDWsP799mvHC9xqTff KSW7PR7JULstgIwwJZee2fsc/VowNN1Rf/5VGj3qEXjvbVrt1xWfTtYOYnuc1BM+fxFB LFCNA/izXTZ903PLpZl7R4S/opiwiycKbgUbcjxp30sa0AY7gm9wMRDE7amhPOInYLZl SvMQ== 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=dqI2AcxcnJNm7PkWVoDRk+5pqv4tiZymkJtCzCo6bv8=; b=kuK9JkO5EersvY5BKqGsE3sEze4AfOvre8RGv8C95A4BEstB4sZA/5PntxbFTj/xh6 o8sOX19ul2lHxvOMVGFb5ORvP7rbbPYq6ajh7kIYWmTzTQByOL4YQeMeXqV2gpinHGKH OhiXXBDYvGNXCOVPDjwSlFzy0r6kwFfvZpNSVEzNpFxXEVnw7hyUGd/3PbbiE9HTp/+T 2x7nE0zh6H/eu5mKdrE3MxP6AbCymVDaS02fRzoAtD9WPYdyv4WjwhWQ2c9ItKK9QuZE /5RS1p1lm5JyrB8J9vgigdhhBel8lf24cp1DxS51RYjBMTkkCFlrI0Hl93Z08Pr99LX1 TSow== X-Gm-Message-State: APjAAAXQyReD1+yz0eiG6t+K12pTcngjr2JE5c7Ja+KTWSY1iwDWoD5T 7xvOPIgVBzhItT7Bi0zBfO74Dhg8qgM8VHaEkrY= X-Google-Smtp-Source: APXvYqzxDQOJFW5WG1khH2CXbNbEicHyGWPHMrqNQ2TbtlL7aNlxxxzLsbebd7Ng1NB2W7PDrYcbc8/YXtjbacAWf+k= X-Received: by 2002:a05:600c:48b:: with SMTP id d11mr2117533wme.153.1570109945475; Thu, 03 Oct 2019 06:39:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ilya Vershkov Date: Thu, 3 Oct 2019 16:38:53 +0300 Message-ID: To: "Jeffrey (Zhaohui) Zhang" Cc: Jeff Tantsura , "rift@ietf.org" , "rift-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008ef873059401b5d9" Archived-At: Subject: Re: [Rift] WGLC, IPR and Implementation polling for draft-ietf-rift-rift-08 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, 03 Oct 2019 13:39:10 -0000 --0000000000008ef873059401b5d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 not aware of any undisclosed IPR Ilya On Fri, 13 Sep 2019 at 22:40, Jeffrey (Zhaohui) Zhang wrote: > Hi RIFTers, > > This email starts WG Last Call, IPR and implementation polling for our > base spec draft-ietf-rift-rift-08. It ends on 9/27. > > Please thoroughly review the document and voice your support/objection. > > If you=E2=80=99re a co-author/contributor, please explicitly respond to t= his email > and indicate whether or not you are aware of any relevant undisclosed IPR= . > The Document won't progress without answers from all the Authors and > Contributors. > > If you're not a co-author/contributor, you need to respond only if you ar= e > aware of any relevant IPR not yet disclosed in conformance with IETF rule= s. > > Currently disclosed IPRs can be found here: > https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-r= ift-rift > . > > We are also polling for any existing implementation. > > Thanks! > Jeff and Jeffrey > > ------------------------------- > > From: RIFT On Behalf Of Tony Przygienda > Sent: Monday, September 9, 2019 3:06 AM > To: rift@ietf.org > Subject: [Rift] LC version -08 > > LC ready version -08 has been posted > > Last few small changes based on input of people playing with both > implementations in different scenarios > > * A new prefix tie type has been added > PositiveExternalDisaggregationPrefixTIEType since it is necessary to > distinguish between normal prefix and external prefix being disaggregated > to preserve priorities in complex redistribution scenarios. BTW, negative > prefixes are always least preferred and hence they don't need to > differentiate. > * Link pair carries now indication whether BFD is up 9on the link. This > allows at the top of the fabric not only see links that are secured and > outer keys but also whether link is BFD protected/BFD is up > * NodeCapabilities are required now and minor protocol version is carried > since there was no possiblity on adjacency building to check which minor > verswion the peer speaks (major is carried in the envelope). Major versio= n > compatibility allows to aways decode the model but minor could be used in > the future to understand minor schema variations > > thanks > > --- tony > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift > --0000000000008ef873059401b5d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+1

=C2=A0

not aw= are of any undisclosed IPR


Ilya


On Fri, 13 S= ep 2019 at 22:40, Jeffrey (Zhaohui) Zhang <zzhang=3D40juniper.net@dmarc.ietf.org> wrote:
=
Hi RIFTers,

This email starts WG Last Call, IPR and implementation polling=C2=A0 for ou= r base spec draft-ietf-rift-rift-08. It ends on 9/27.

Please thoroughly review the document and voice your support/objection.

If you=E2=80=99re a co-author/contributor, please explicitly respond to thi= s email and indicate whether or not you are aware of any relevant undisclos= ed IPR. The Document won't progress without answers from all the Author= s and Contributors.

If you're not a co-author/contributor, you need to respond only if you = are aware of any relevant IPR not yet disclosed in conformance with IETF ru= les.

Currently disclosed IPRs can be found here: https://datatracker.ietf.org/ipr/search/?submi= t=3Ddraft&id=3Ddraft-ietf-rift-rift.

We are also polling for any existing implementation.

Thanks!
Jeff and Jeffrey

-------------------------------

From: RIFT <r= ift-bounces@ietf.org> On Behalf Of Tony Przygienda
Sent: Monday, September 9, 2019 3:06 AM
To: rift@ietf.org Subject: [Rift] LC version -08

LC ready version -08 has been posted

Last few small changes based on input of people playing with both implement= ations in different scenarios

* A new prefix tie type has been added PositiveExternalDisaggregationPrefix= TIEType since it is necessary to distinguish between normal prefix and exte= rnal prefix being disaggregated to preserve priorities in complex redistrib= ution scenarios. BTW, negative prefixes are always least preferred and henc= e they don't need to differentiate.
* Link pair carries now indication whether BFD is up 9on the link. This all= ows at the top of the fabric not only see links that are secured and outer = keys but also whether link is BFD protected/BFD is up
* NodeCapabilities are required now and minor protocol version is carried s= ince there was no possiblity on adjacency building to check which minor ver= swion the peer speaks (major is carried in the envelope). Major version com= patibility allows to aways decode the model but minor could be used in the = future to understand minor schema variations

thanks

--- tony
_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
--0000000000008ef873059401b5d9-- From nobody Thu Oct 3 07:15: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 4F45212098D; Thu, 3 Oct 2019 07:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Tw_5Mny0e39O; Thu, 3 Oct 2019 07:15:42 -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 51098120979; Thu, 3 Oct 2019 07:15:42 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x93DV1a5018632; Thu, 3 Oct 2019 06:34:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=VWi3aM9Qv4QCIJWAnNy6u73BB2NL540RpDJ1LGxRybk=; b=yHfcUezGoXt9vNs7EMCM05phgsAsJ3xUe3EHY2v+p4/7PrC6b0vGrr/8H2/MqCOm8yaB q3Hg3/XPmALABbni7cJ/jfLelel7EyMRfJmxvFvdq2RvOfmYB9jo43MXlrMij0co1PTt 9bkFZnqKMuV//KueUgc1ccXh69AngxyWTycl4FuUeabWrPEZ+kWyT9FlbEKVEOVru9b+ F6Oa8Bunk4OHesZuykYxZeo66do0GsZSLlWgbN8CpWAZCzMZeFlZ3I26QCZbJgl4zba8 MdLGcFMQYK8wK4s33l+JcIiVHVlUoLq8lCTiXVKxZEX9ZrlSABbCTlaIJg1ZvhJ/VY+7 Pg== Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp2054.outbound.protection.outlook.com [104.47.33.54]) by mx0a-00273201.pphosted.com with ESMTP id 2vcyde1jvv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 03 Oct 2019 06:34:18 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NtmcWbU1MngVgf7PhphBTaowsVNQ6a6mKGZZpmTNirikDHRfHsDpc46zeejt3Tvfnn7ziGdhtobj6hMVBU0ThBrondox7jww2w+ZBPA5hwGggWi0UKuxnf4rEwjihGN4CUZqj5oYiD5PAg5cY0teyJg96ZQoXnFjFNcAyQlPwqa/KtguBHY2ECHGRbOrsmz3ab5mkiJ6yq8SS5oodxUSjg0jCIy9eCRidVIX27UVNvIhwr2CsUo9xQp262CDVRgrytTrKF6ouUFmrLqXdVf2fM8Pjep2Y/OJzl4weQYIixJfnwB7W8dUtCxnIAU6qgApnM0wuVlrUKb6MIXas0OJVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VWi3aM9Qv4QCIJWAnNy6u73BB2NL540RpDJ1LGxRybk=; b=jBHbOn38zEqNYmxl01XYSG9AckZYoweZjkx0WwSUer0HzohX/YvUEr+1bZzgaWUZH1OG0KUBK9Ec5ijmmrp6LjsJVIdD8j4heCUrQxwAukBY6E/alBhStb/FR2PStqnvIAe3NQxL3vB9uA4ir5tG579PVKTNWtOaVVUOmjfYo43VPnwNS+l1VaNd1/Bm7oS4BZC/8J7DJbdl8wIWIavcd2mQmc1QG/OTCvVklwjfS7ha+xNyD3Bf5Zit43fDX0nhSspvuSXD1zX4rTp3N18tSPOqvFPB8+Lk4tC0I6AVZLtCdTnjzz031p/it2Tbpzpca0EFb7V4acqdUM2FfwdecA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none Received: from CH2PR05MB7078.namprd05.prod.outlook.com (10.186.149.216) by CH2PR05MB7174.namprd05.prod.outlook.com (10.186.148.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Thu, 3 Oct 2019 13:34:15 +0000 Received: from CH2PR05MB7078.namprd05.prod.outlook.com ([fe80::ed28:e1cd:84b4:e48]) by CH2PR05MB7078.namprd05.prod.outlook.com ([fe80::ed28:e1cd:84b4:e48%3]) with mapi id 15.20.2327.017; Thu, 3 Oct 2019 13:34:15 +0000 From: John E Drake To: "Jeffrey (Zhaohui) Zhang" , Jeff Tantsura , "rift@ietf.org" , "rift-chairs@ietf.org" Thread-Topic: WGLC, IPR and Implementation polling for draft-ietf-rift-rift-08 Thread-Index: AdVqVcgVshB/jFDvRM+8c5HjmimYRwPmW1Aw Content-Class: Date: Thu, 3 Oct 2019 13:34:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=jdrake@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-10-03T13:34:13.8414940Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=0a671b48-8bbe-48c0-b862-3371bf7b7d47; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bbf3550f-e35f-4d55-9ff4-08d74806629b x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: CH2PR05MB7174: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(366004)(396003)(376002)(199004)(189003)(13464003)(2906002)(8936002)(53546011)(256004)(33656002)(6506007)(26005)(102836004)(186003)(6116002)(3846002)(5660300002)(110136005)(2501003)(99286004)(52536014)(66066001)(14454004)(74316002)(7736002)(7696005)(966005)(305945005)(76116006)(66446008)(66946007)(66556008)(66476007)(76176011)(478600001)(64756008)(6306002)(71190400001)(486006)(229853002)(55016002)(2201001)(8676002)(81156014)(81166006)(25786009)(476003)(71200400001)(11346002)(316002)(9686003)(6436002)(86362001)(446003)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR05MB7174; H:CH2PR05MB7078.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fCDa1xdrhUZWKMkdmNl6qtP7vxy3IsgP9lV1wyAQmXloH395uptrt0jkdR0V5E2hHMmE8rLeu7tE46i4W1UqYsf8YzdwFmi0fQp6NZb4xB/95wlH4KHmqXcFN7uvZ7YpgFFocuPDUytJEGhBtj32kRuPXYcfPiNkOf4+FYfybgswkUCiYcc2ircTfwW8hRVwBCT/JzX1PToR5Bw3Nnr1IJ2auXSORyEgHJHUgrR/KYHvmWeIkav46sXfqK4DtQ2zr8BGl91kVxFKlLtG3WVTHyu4hk6SqvSyRbZjF08pkgW1oSo7t0wXrtwxhO0t9leROo2+6idTp3O2UMsb6+m403SFHnsolXlr5sE7mlAhj34hKpro3Qld8H4TC096xA9W5OArDW3CdAQD10/E+0zXa7Mz+AfRFlynoiA0yn+c+4/Jfm/OizD9rULSvb/ZGV2I9IaDIX0MrI6NLdB+pCWHqw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: bbf3550f-e35f-4d55-9ff4-08d74806629b X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2019 13:34:15.5875 (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-CrossTenant-userprincipalname: S/QIUWEP8e5NrAz/b0iIbx0TvcsijIRTFSLywrXIukQLuzD6dOBlQrXkTie/nB2ODYzeuvgxIsjt0WZa2VB6Og== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR05MB7174 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-03_05:2019-10-03,2019-10-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 malwarescore=0 phishscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910030127 Archived-At: Subject: Re: [Rift] WGLC, IPR and Implementation polling for draft-ietf-rift-rift-08 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, 03 Oct 2019 14:15:56 -0000 SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSDQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2hu DQoNCg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFJJRlQgPHJpZnQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IEplZmZyZXkgKFpoYW9odWkpIFpoYW5nDQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDEzLCAy MDE5IDM6NDAgUE0NCj4gVG86IEplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29t PjsgcmlmdEBpZXRmLm9yZzsgcmlmdC1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW1JpZnRd IFdHTEMsIElQUiBhbmQgSW1wbGVtZW50YXRpb24gcG9sbGluZyBmb3IgZHJhZnQtaWV0Zi1yaWZ0 LXJpZnQtMDgNCj4gDQo+IEhpIFJJRlRlcnMsDQo+IA0KPiBUaGlzIGVtYWlsIHN0YXJ0cyBXRyBM YXN0IENhbGwsIElQUiBhbmQgaW1wbGVtZW50YXRpb24gcG9sbGluZyAgZm9yIG91ciBiYXNlIHNw ZWMNCj4gZHJhZnQtaWV0Zi1yaWZ0LXJpZnQtMDguIEl0IGVuZHMgb24gOS8yNy4NCj4gDQo+IFBs ZWFzZSB0aG9yb3VnaGx5IHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIHZvaWNlIHlvdXIgc3VwcG9y dC9vYmplY3Rpb24uDQo+IA0KPiBJZiB5b3XigJlyZSBhIGNvLWF1dGhvci9jb250cmlidXRvciwg cGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZA0KPiBpbmRpY2F0ZSB3 aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCB1bmRpc2Nsb3NlZCBJ UFIuIFRoZQ0KPiBEb2N1bWVudCB3b24ndCBwcm9ncmVzcyB3aXRob3V0IGFuc3dlcnMgZnJvbSBh bGwgdGhlIEF1dGhvcnMgYW5kDQo+IENvbnRyaWJ1dG9ycy4NCj4gDQo+IElmIHlvdSdyZSBub3Qg YSBjby1hdXRob3IvY29udHJpYnV0b3IsIHlvdSBuZWVkIHRvIHJlc3BvbmQgb25seSBpZiB5b3Ug YXJlIGF3YXJlDQo+IG9mIGFueSByZWxldmFudCBJUFIgbm90IHlldCBkaXNjbG9zZWQgaW4gY29u Zm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPiANCj4gQ3VycmVudGx5IGRpc2Nsb3NlZCBJUFJz IGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9zdWJtaXQ9ZA0KPiByYWZ0JmlkPWRy YWZ0LWlldGYtcmlmdC0NCj4gcmlmdF9fOyE4V29BNlJqQzgxYyFRUW5hNkZ5SEZSSV9jWWRDU0xf d0ZHVE1oaFlwYk1zODBxNllnSEJkUVlFOEYNCj4gaEhmcjVBRDlSUlRnU2ROZDRnJCAuDQo+IA0K PiBXZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBhbnkgZXhpc3RpbmcgaW1wbGVtZW50YXRpb24uDQo+ IA0KPiBUaGFua3MhDQo+IEplZmYgYW5kIEplZmZyZXkNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gDQo+IEZyb206IFJJRlQgPHJpZnQtYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIFRvbnkgUHJ6eWdpZW5kYQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciA5 LCAyMDE5IDM6MDYgQU0NCj4gVG86IHJpZnRAaWV0Zi5vcmcNCj4gU3ViamVjdDogW1JpZnRdIExD IHZlcnNpb24gLTA4DQo+IA0KPiBMQyByZWFkeSB2ZXJzaW9uIC0wOCBoYXMgYmVlbiBwb3N0ZWQN Cj4gDQo+IExhc3QgZmV3IHNtYWxsIGNoYW5nZXMgYmFzZWQgb24gaW5wdXQgb2YgcGVvcGxlIHBs YXlpbmcgd2l0aCBib3RoDQo+IGltcGxlbWVudGF0aW9ucyBpbiBkaWZmZXJlbnQgc2NlbmFyaW9z DQo+IA0KPiAqIEEgbmV3IHByZWZpeCB0aWUgdHlwZSBoYXMgYmVlbiBhZGRlZA0KPiBQb3NpdGl2 ZUV4dGVybmFsRGlzYWdncmVnYXRpb25QcmVmaXhUSUVUeXBlIHNpbmNlIGl0IGlzIG5lY2Vzc2Fy eSB0byBkaXN0aW5ndWlzaA0KPiBiZXR3ZWVuIG5vcm1hbCBwcmVmaXggYW5kIGV4dGVybmFsIHBy ZWZpeCBiZWluZyBkaXNhZ2dyZWdhdGVkIHRvIHByZXNlcnZlDQo+IHByaW9yaXRpZXMgaW4gY29t cGxleCByZWRpc3RyaWJ1dGlvbiBzY2VuYXJpb3MuIEJUVywgbmVnYXRpdmUgcHJlZml4ZXMgYXJl IGFsd2F5cw0KPiBsZWFzdCBwcmVmZXJyZWQgYW5kIGhlbmNlIHRoZXkgZG9uJ3QgbmVlZCB0byBk aWZmZXJlbnRpYXRlLg0KPiAqIExpbmsgcGFpciBjYXJyaWVzIG5vdyBpbmRpY2F0aW9uIHdoZXRo ZXIgQkZEIGlzIHVwIDlvbiB0aGUgbGluay4gVGhpcyBhbGxvd3MgYXQNCj4gdGhlIHRvcCBvZiB0 aGUgZmFicmljIG5vdCBvbmx5IHNlZSBsaW5rcyB0aGF0IGFyZSBzZWN1cmVkIGFuZCBvdXRlciBr ZXlzIGJ1dCBhbHNvDQo+IHdoZXRoZXIgbGluayBpcyBCRkQgcHJvdGVjdGVkL0JGRCBpcyB1cA0K PiAqIE5vZGVDYXBhYmlsaXRpZXMgYXJlIHJlcXVpcmVkIG5vdyBhbmQgbWlub3IgcHJvdG9jb2wg dmVyc2lvbiBpcyBjYXJyaWVkIHNpbmNlDQo+IHRoZXJlIHdhcyBubyBwb3NzaWJsaXR5IG9uIGFk amFjZW5jeSBidWlsZGluZyB0byBjaGVjayB3aGljaCBtaW5vciB2ZXJzd2lvbiB0aGUNCj4gcGVl ciBzcGVha3MgKG1ham9yIGlzIGNhcnJpZWQgaW4gdGhlIGVudmVsb3BlKS4gTWFqb3IgdmVyc2lv biBjb21wYXRpYmlsaXR5DQo+IGFsbG93cyB0byBhd2F5cyBkZWNvZGUgdGhlIG1vZGVsIGJ1dCBt aW5vciBjb3VsZCBiZSB1c2VkIGluIHRoZSBmdXR1cmUgdG8NCj4gdW5kZXJzdGFuZCBtaW5vciBz Y2hlbWEgdmFyaWF0aW9ucw0KPiANCj4gdGhhbmtzDQo+IA0KPiAtLS0gdG9ueQ0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSSUZUIG1haWxpbmcg bGlzdA0KPiBSSUZUQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JpZnRfXzshOFcNCj4gb0E2UmpDODFj IVFRbmE2RnlIRlJJX2NZZENTTF93RkdUTWhoWXBiTXM4MHE2WWdIQmRRWUU4RmhIZnI1QUQ5DQo+ IFJSVGRMSnp4MjQkDQo= From nobody Thu Oct 3 08:43: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 3DA0F1200C3; Thu, 3 Oct 2019 08:42:58 -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_HELO_NONE=0.001, 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 FR_Gv276VSCi; Thu, 3 Oct 2019 08:42:55 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 E161A1200B1; Thu, 3 Oct 2019 08:42:54 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id u8so6623070iom.5; Thu, 03 Oct 2019 08:42:54 -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=eDaAJtp6lvfm8PiTr2kxhsk/D/KK0FXQrOe81MyTX4I=; b=Q644YPEahbsrpOaUAch7upeaQqI6evJ/d8GPSnBg2meKebdJjhqX2y3fznn8wRy/R3 9MwMnwe4jAWZJqZjiJOjSggjAUPbXcN2GqR/ilGpsBbXhU1H3IhsxghONazZoGIUIsJF KK02KNn1XBFOf2NxIrPg4fMdmQGQbYhYgITeuTxEFI9kzSPjeSbkgJ/feYJj31KSPoe0 RLOuxvmjZDzevCebpbT2O9U6SAqe7GGLa3sLN3MzniGrPxCRJThMVyeWO1FE+fReUcMo jfWQHLrq2csY7u0/g1ThYiod98LDF4c5cvOO7+2sB3scfrXxbTYrGXphNJs0YsZ4phZ9 XJjQ== 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=eDaAJtp6lvfm8PiTr2kxhsk/D/KK0FXQrOe81MyTX4I=; b=FUjtBH9Hd1u08hfqG8AL7aQE4Nuc8W6EqbizPPN73pdSNQoPClvbNfdCj7F1V6EO1/ kGTW59rPQONJdb3NZ/9oO1Pa2O2Eeo6wNwk5xLTdufbAfauW5Kqn/dqj0aOb6ONbEY4h ZASmnshwXeb6SvcWCqwo4nOjs7pZa81KC9RL1x5+h2Hm+sYzjec74QETUEiYYiLCfOAN U4S3W0r67/0T96kFJpIOLvzJEoPLnE0XG2SAbI4A6xlQZmnj5wSitqYStcMbASa2oyj/ MY0vAxNHmwzMlLpkS2MK6agn45a0Qctj4t7MBLOWfKUw+6k8KFzOHIV0oeVCPmkRxqrX acNQ== X-Gm-Message-State: APjAAAUt3kiUpFnFxocxCO3R+66yd/OuVc7biMSWVCTJ//6Yc/uXUsgy EeT5K90lSX+1lynNwSsuiiPhzAD1b9QE+t2mdi0= X-Google-Smtp-Source: APXvYqxdM7AJ74FmRoQvJypzFRHM01zGkRUkdHeVC4N4Mz05xyvT3l+p5Yk7mW477JkubJRmDj9akcFqmMYqGVa/1cE= X-Received: by 2002:a92:c0d2:: with SMTP id t18mr2670721ilf.239.1570117374284; Thu, 03 Oct 2019 08:42:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tony Przygienda Date: Thu, 3 Oct 2019 08:42:17 -0700 Message-ID: To: "Jeffrey (Zhaohui) Zhang" Cc: Jeff Tantsura , "rift@ietf.org" , "rift-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000599b2a05940370c3" Archived-At: Subject: Re: [Rift] WGLC, IPR and Implementation polling for draft-ietf-rift-rift-08 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, 03 Oct 2019 15:42:59 -0000 --000000000000599b2a05940370c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable not aware of any undisclosed IPR On Fri, Sep 13, 2019 at 12:40 PM Jeffrey (Zhaohui) Zhang wrote: > Hi RIFTers, > > This email starts WG Last Call, IPR and implementation polling for our > base spec draft-ietf-rift-rift-08. It ends on 9/27. > > Please thoroughly review the document and voice your support/objection. > > If you=E2=80=99re a co-author/contributor, please explicitly respond to t= his email > and indicate whether or not you are aware of any relevant undisclosed IPR= . > The Document won't progress without answers from all the Authors and > Contributors. > > If you're not a co-author/contributor, you need to respond only if you ar= e > aware of any relevant IPR not yet disclosed in conformance with IETF rule= s. > > Currently disclosed IPRs can be found here: > https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-r= ift-rift > . > > We are also polling for any existing implementation. > > Thanks! > Jeff and Jeffrey > > ------------------------------- > > From: RIFT On Behalf Of Tony Przygienda > Sent: Monday, September 9, 2019 3:06 AM > To: rift@ietf.org > Subject: [Rift] LC version -08 > > LC ready version -08 has been posted > > Last few small changes based on input of people playing with both > implementations in different scenarios > > * A new prefix tie type has been added > PositiveExternalDisaggregationPrefixTIEType since it is necessary to > distinguish between normal prefix and external prefix being disaggregated > to preserve priorities in complex redistribution scenarios. BTW, negative > prefixes are always least preferred and hence they don't need to > differentiate. > * Link pair carries now indication whether BFD is up 9on the link. This > allows at the top of the fabric not only see links that are secured and > outer keys but also whether link is BFD protected/BFD is up > * NodeCapabilities are required now and minor protocol version is carried > since there was no possiblity on adjacency building to check which minor > verswion the peer speaks (major is carried in the envelope). Major versio= n > compatibility allows to aways decode the model but minor could be used in > the future to understand minor schema variations > > thanks > > --- tony > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift > --000000000000599b2a05940370c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
not aware of any undisclosed IPR

On Fri, Sep 13, 2019= at 12:40 PM Jeffrey (Zhaohui) Zhang <zzhang=3D40juniper.net@dmarc.ietf.org> wrote:
Hi RIFTers,

This email starts WG Last Call, IPR and implementation polling=C2=A0 for ou= r base spec draft-ietf-rift-rift-08. It ends on 9/27.

Please thoroughly review the document and voice your support/objection.

If you=E2=80=99re a co-author/contributor, please explicitly respond to thi= s email and indicate whether or not you are aware of any relevant undisclos= ed IPR. The Document won't progress without answers from all the Author= s and Contributors.

If you're not a co-author/contributor, you need to respond only if you = are aware of any relevant IPR not yet disclosed in conformance with IETF ru= les.

Currently disclosed IPRs can be found here: https://datatracker.ietf.org/ipr/search/?submi= t=3Ddraft&id=3Ddraft-ietf-rift-rift.

We are also polling for any existing implementation.

Thanks!
Jeff and Jeffrey

-------------------------------

From: RIFT <r= ift-bounces@ietf.org> On Behalf Of Tony Przygienda
Sent: Monday, September 9, 2019 3:06 AM
To: rift@ietf.org Subject: [Rift] LC version -08

LC ready version -08 has been posted

Last few small changes based on input of people playing with both implement= ations in different scenarios

* A new prefix tie type has been added PositiveExternalDisaggregationPrefix= TIEType since it is necessary to distinguish between normal prefix and exte= rnal prefix being disaggregated to preserve priorities in complex redistrib= ution scenarios. BTW, negative prefixes are always least preferred and henc= e they don't need to differentiate.
* Link pair carries now indication whether BFD is up 9on the link. This all= ows at the top of the fabric not only see links that are secured and outer = keys but also whether link is BFD protected/BFD is up
* NodeCapabilities are required now and minor protocol version is carried s= ince there was no possiblity on adjacency building to check which minor ver= swion the peer speaks (major is carried in the envelope). Major version com= patibility allows to aways decode the model but minor could be used in the = future to understand minor schema variations

thanks

--- tony
_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
--000000000000599b2a05940370c3-- From nobody Thu Oct 3 12:14:03 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 7AE50120180; Thu, 3 Oct 2019 12:14:01 -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_HELO_NONE=0.001, 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 b5h1WM5b9dLx; Thu, 3 Oct 2019 12:13:58 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 BF4221200FE; Thu, 3 Oct 2019 12:13:58 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id k9so3644008oib.7; Thu, 03 Oct 2019 12:13:58 -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=kl53NgDIZUwCVURW3c3jVWTiHjfgcn3pGB6SPRbt5g0=; b=b/PiwCTl9hnlotfFVkib80xrBB7CdAf17u/bH0B+EjXOrYlLSAOwKrtB0+V8QIOCb8 IUS1K9zyz4hy6PpQiWJrjZll97kioSFnfOnhEnTKJ7Irw6jinWU0H0WZ5vwsS/VYXlcL vEYWlMAAnRjhP45qNyz5UZrL70taCb44hG2C8XqEO4GuS/ggAOHEhtpYaIqKyG//zSXq ZbufXqUXkNAKLVeHQDvLtdUnmLsKw4XdFX0OAykJCYyHqN2fFN89eIkFSPmV9rf3vMQG Cwui0VTdXGIQAquXVRVFRu78Al9tepq/ncyzyOyo4AdW1diJMBrAvXrpSQfXQYNfso18 7hxw== 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=kl53NgDIZUwCVURW3c3jVWTiHjfgcn3pGB6SPRbt5g0=; b=qjrHi9eKBI4StvY+sKVY/zykfBRwGdPQfMo5R1cmqEst2kKMG6raJpzhfRPke2J7Pb uWslBSSuGJJh9g5wxeWy3M2/TWZ3Q4sKtQh4hOAsXMAgvNGR8kfD/Pr+y11JExD1Itsb kwVXkqEIEsxydMoIEQp/hQ5Uwg047naoKZ4oFza4ICRoyV11Cj/Bf6px5iHUvlhJljnr zBG0HYY8GfocIcY5T/8QbvGpNZR1DRbkcefD0vqaxswHJ97OEDYhbV6lMwAMjCAWb9KX ynoPfw8IA4tjJm1owRnHI8lFzwwiTTKk+xJtgdamlLYFkJ97lWACicDCarBrRksmGYmN 1Vsw== X-Gm-Message-State: APjAAAUIZp6ZBNLWDhzsD1SyVo471oVSwVrV5pjD6KmhG0fWxgGaL8Qk vLTKVETZo7rO6SiqbCkFb6J0Yd+P5Bit/QKad+I= X-Google-Smtp-Source: APXvYqxRGEY1G7Y9c9XTWngwjSOQOtwx8uSdZAWlfsnroSpKbWJ8HQxGB1p8A/tp8voH5HVCwaDdfUms7hqP+tOXiuw= X-Received: by 2002:aca:adc1:: with SMTP id w184mr3942288oie.80.1570130037792; Thu, 03 Oct 2019 12:13:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alia Atlas Date: Thu, 3 Oct 2019 15:13:46 -0400 Message-ID: To: Tony Przygienda Cc: "Jeffrey (Zhaohui) Zhang" , Jeff Tantsura , "rift-chairs@ietf.org" , "rift@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002767e805940663b5" Archived-At: Subject: Re: [Rift] WGLC, IPR and Implementation polling for draft-ietf-rift-rift-08 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, 03 Oct 2019 19:14:02 -0000 --0000000000002767e805940663b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not aware of any undisclosed IPR. On Thu, Oct 3, 2019 at 11:43 AM Tony Przygienda wrote= : > not aware of any undisclosed IPR > > On Fri, Sep 13, 2019 at 12:40 PM Jeffrey (Zhaohui) Zhang 40juniper.net@dmarc.ietf.org> wrote: > >> Hi RIFTers, >> >> This email starts WG Last Call, IPR and implementation polling for our >> base spec draft-ietf-rift-rift-08. It ends on 9/27. >> >> Please thoroughly review the document and voice your support/objection. >> >> If you=E2=80=99re a co-author/contributor, please explicitly respond to = this >> email and indicate whether or not you are aware of any relevant undisclo= sed >> IPR. The Document won't progress without answers from all the Authors an= d >> Contributors. >> >> If you're not a co-author/contributor, you need to respond only if you >> are aware of any relevant IPR not yet disclosed in conformance with IETF >> rules. >> >> Currently disclosed IPRs can be found here: >> https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-= rift-rift >> . >> >> We are also polling for any existing implementation. >> >> Thanks! >> Jeff and Jeffrey >> >> ------------------------------- >> >> From: RIFT On Behalf Of Tony Przygienda >> Sent: Monday, September 9, 2019 3:06 AM >> To: rift@ietf.org >> Subject: [Rift] LC version -08 >> >> LC ready version -08 has been posted >> >> Last few small changes based on input of people playing with both >> implementations in different scenarios >> >> * A new prefix tie type has been added >> PositiveExternalDisaggregationPrefixTIEType since it is necessary to >> distinguish between normal prefix and external prefix being disaggregate= d >> to preserve priorities in complex redistribution scenarios. BTW, negativ= e >> prefixes are always least preferred and hence they don't need to >> differentiate. >> * Link pair carries now indication whether BFD is up 9on the link. This >> allows at the top of the fabric not only see links that are secured and >> outer keys but also whether link is BFD protected/BFD is up >> * NodeCapabilities are required now and minor protocol version is carrie= d >> since there was no possiblity on adjacency building to check which minor >> verswion the peer speaks (major is carried in the envelope). Major versi= on >> compatibility allows to aways decode the model but minor could be used i= n >> the future to understand minor schema variations >> >> thanks >> >> --- tony >> _______________________________________________ >> RIFT mailing list >> RIFT@ietf.org >> https://www.ietf.org/mailman/listinfo/rift >> > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift > --0000000000002767e805940663b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any undisclosed IPR.

On Thu, Oct 3, 2019 = at 11:43 AM Tony Przygienda <tony= sietf@gmail.com> wrote:
not aware of any undisclosed IPR
<= br>
On Fri,= Sep 13, 2019 at 12:40 PM Jeffrey (Zhaohui) Zhang <zzhang=3D40juniper.net@dmarc.i= etf.org> wrote:
Hi RIFTers,

This email starts WG Last Call, IPR and implementation polling=C2=A0 for ou= r base spec draft-ietf-rift-rift-08. It ends on 9/27.

Please thoroughly review the document and voice your support/objection.

If you=E2=80=99re a co-author/contributor, please explicitly respond to thi= s email and indicate whether or not you are aware of any relevant undisclos= ed IPR. The Document won't progress without answers from all the Author= s and Contributors.

If you're not a co-author/contributor, you need to respond only if you = are aware of any relevant IPR not yet disclosed in conformance with IETF ru= les.

Currently disclosed IPRs can be found here: https://datatracker.ietf.org/ipr/search/?submi= t=3Ddraft&id=3Ddraft-ietf-rift-rift.

We are also polling for any existing implementation.

Thanks!
Jeff and Jeffrey

-------------------------------

From: RIFT <r= ift-bounces@ietf.org> On Behalf Of Tony Przygienda
Sent: Monday, September 9, 2019 3:06 AM
To: rift@ietf.org Subject: [Rift] LC version -08

LC ready version -08 has been posted

Last few small changes based on input of people playing with both implement= ations in different scenarios

* A new prefix tie type has been added PositiveExternalDisaggregationPrefix= TIEType since it is necessary to distinguish between normal prefix and exte= rnal prefix being disaggregated to preserve priorities in complex redistrib= ution scenarios. BTW, negative prefixes are always least preferred and henc= e they don't need to differentiate.
* Link pair carries now indication whether BFD is up 9on the link. This all= ows at the top of the fabric not only see links that are secured and outer = keys but also whether link is BFD protected/BFD is up
* NodeCapabilities are required now and minor protocol version is carried s= ince there was no possiblity on adjacency building to check which minor ver= swion the peer speaks (major is carried in the envelope). Major version com= patibility allows to aways decode the model but minor could be used in the = future to understand minor schema variations

thanks

--- tony
_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
--0000000000002767e805940663b5-- From nobody Tue Oct 8 09:49:55 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 6EBFE12004C for ; Tue, 8 Oct 2019 09:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex-team.ru 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 mBzOaBU-kkps for ; Tue, 8 Oct 2019 09:49:50 -0700 (PDT) Received: from forwardcorp1o.mail.yandex.net (forwardcorp1o.mail.yandex.net [95.108.205.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80065120018 for ; Tue, 8 Oct 2019 09:49:50 -0700 (PDT) Received: from mxbackcorp2j.mail.yandex.net (mxbackcorp2j.mail.yandex.net [IPv6:2a02:6b8:0:1619::119]) by forwardcorp1o.mail.yandex.net (Yandex) with ESMTP id D45B82E15C3 for ; Tue, 8 Oct 2019 19:49:47 +0300 (MSK) Received: from localhost (localhost [::1]) by mxbackcorp2j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Tm3lYhyQoU-nlNGJ2NY; Tue, 08 Oct 2019 19:49:47 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1570553387; bh=RD3IbY7YC3rEr59jhuZXEaXGQGxgniFQdez2Dfqnwvw=; h=Subject:In-Reply-To:Date:References:To:From:Message-Id; b=hR3z7PYhwJgXDTzns7lEqL7e/VX+SmecEYIXp/IPtv85OHnaymZH+Okq6s9hGyK6I fGW/v+poTFclwsxcH8CF3sFQQ4u34kmWFZTmhWyqZ8p5RnWAC/e10UOakq79FVRtGB t9QTFgw5Q33xAbXI+MQd4NzUxVisV5XF8x1hOR7k= Authentication-Results: mxbackcorp2j.mail.yandex.net; dkim=pass header.i=@yandex-team.ru X-Yandex-Sender-Uid: 1120000000014913 X-Yandex-Avir: 1 Received: from mxbackcorp2j.mail.yandex.net (localhost [::1]) by mxbackcorp2j.mail.yandex.net with LMTP id 9V2qJ0km16-fa79GSjW for ; Tue, 08 Oct 2019 19:49:12 +0300 Received: by sas1-fc7737ec834f.qloud-c.yandex.net with HTTP; Tue, 08 Oct 2019 19:49:12 +0300 From: Dmitry Afanasiev To: rift@ietf.org In-Reply-To: References: MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 08 Oct 2019 19:49:47 +0300 Message-Id: <1784751570553352@sas1-fc7737ec834f.qloud-c.yandex.net> Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=utf-8 Archived-At: Subject: Re: [Rift] WGLC, IPR and Implementation polling for draft-ietf-rift-rift-08 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: Tue, 08 Oct 2019 16:49:54 -0000
+ rift@
- all
 
 
I am not aware of any undisclosed IPR.
 
--
Dmitry
 
[skip]
From nobody Wed Oct 9 13:05: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 685E71200F7; Wed, 9 Oct 2019 13:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 NJjGFOo28tR3; Wed, 9 Oct 2019 13:05:41 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 3975212004F; Wed, 9 Oct 2019 13:05:41 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x99JtwQ2022085; Wed, 9 Oct 2019 13:05:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=QSsxBzB+gVZD/1nQLTasUi+s14fYHgXSN0BNA8bMnSs=; b=Smzy2xh3wMNYslLUQSQRGnsPqP/fnUY9/C5WGNe+JVYtn/Cvquv2RP9Hx3SB+msGbe7e hbdOhh3TGRARGQDQTgcwJVK59Cj8DVkPmeN0dkKONt9pNVbYxNK6j1jerkBl2RlVC47G RvSQ9XqhO6g1PU3UwvBAhMK7FMkG1n7Nk2AuGIudVVL4eBoUu8SBIqmVgJKZiAWDMqTT IXRa0+g9TZmpYPxpSrw/toKAXSmbSWn46iziYTjPkxuDOJPsbLYV8pQF8BgBURodIQzY KLhj8BrRkUCnGGr/hlALVgPGgzgLMh3IRh30IDtSwTzIturikVZc2uVT0r5atkQz4TlS uw== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2053.outbound.protection.outlook.com [104.47.36.53]) by mx0b-00273201.pphosted.com with ESMTP id 2vgdu93sqf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 13:05:38 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kmG2+gfbbRge99k6yC2emwd+CiVnAoO3zm66M878Cx9NZCdoD1xrr60shAU21K/Cg5zC21cyAuQfzIpxmX2XIUgsZNSHz4gpi7UMPZFQoWEVURdxWIFQxiXAY+n2USFBmJZSBxCgmHazAjHO4MLE2si3OKUSEREw6XcC3cgsCZMZlhzRobwV70pKAMiNPSJLyoY71Zs+E6YeCZxSynnIhNL8f2DWgIxphQXDXkoZSQWy6yRiLAQrM6aU3j8bvYlWE/hz/huKQT8V/9KKAYlWF2dKIH1vlhr8dir3y6wYdnjXYgLIq2oWHmoOQboUmGjXPKTicgILylh0Vj4hy89pMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QSsxBzB+gVZD/1nQLTasUi+s14fYHgXSN0BNA8bMnSs=; b=C6rf4B7AROnzsY7h9AtGrrQ4s3RdAin3fLFTzDpipT5u+rGqyeVDwaVbpTp44fE1yBG9hmjXU7XJwZZWvZs1ETLsZusmVxS0kD6ematXCdxTOFWuo57nq8hPwMcTbM6d/btYSKyDfIp3hWcykNmdeq6JDgqBkiFDc47zwTA6vZFymPpR0tWzZxvxcbHCYn+F36XJ6J0+Ka2cjkRuTBNQaBq+TNc9Byxzv+hIcZrmiHOpvBjQSIcHUyAfp/y2KIRtm1JL0ELPvijiHWFSnTZTV5T+uCigYbZxyvIkQ6DihsKbg3VibXihRmUIc2ezqzlp3aAp1greJNPcPa3jaS+Dgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none Received: from DM5PR05MB3548.namprd05.prod.outlook.com (10.174.242.153) by DM5PR05MB3609.namprd05.prod.outlook.com (10.174.242.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Wed, 9 Oct 2019 20:05:34 +0000 Received: from DM5PR05MB3548.namprd05.prod.outlook.com ([fe80::4949:bb34:ba48:1913]) by DM5PR05MB3548.namprd05.prod.outlook.com ([fe80::4949:bb34:ba48:1913%7]) with mapi id 15.20.2347.016; Wed, 9 Oct 2019 20:05:34 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Jeff Tantsura , "rift@ietf.org" , "rift-chairs@ietf.org" Thread-Topic: WGLC, IPR and Implementation polling for draft-ietf-rift-rift-08 Thread-Index: AdVqVcgVshB/jFDvRM+8c5HjmimYRwPc6lSA Date: Wed, 9 Oct 2019 20:05:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action x-originating-ip: [173.76.174.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0536b1b2-47e2-4a76-b846-08d74cf40baf x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: DM5PR05MB3609: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(346002)(366004)(376002)(199004)(189003)(13464003)(476003)(33656002)(110136005)(8936002)(55016002)(7696005)(6436002)(486006)(2201001)(305945005)(102836004)(5660300002)(6246003)(81156014)(81166006)(8676002)(6306002)(99286004)(9686003)(26005)(2501003)(2906002)(446003)(11346002)(25786009)(6506007)(256004)(186003)(66556008)(71200400001)(66476007)(478600001)(53546011)(74316002)(14454004)(52536014)(66066001)(71190400001)(86362001)(966005)(229853002)(316002)(66446008)(66946007)(3846002)(7736002)(76176011)(6116002)(64756008)(76116006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3609; H:DM5PR05MB3548.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nFtExzVXTsNbUZfySSk/wNRX5cMr5389nZNHzxsSu2yK2P7BBEG53VGYZOk9efriMKnaKt1+c8P4w2Bf+3AgzoML5yYWAyp9XpY48AwM+/NgYUBNJW0+V8knqyRqbqV/FOTIRjFLTlsnh6XeGznHY4CXNfMcX5bStlbBXu9nAug+AN32lbh68n8g4/EpUwbVK0f4Rf9uVxAIOeCiVRjL1qZyYcIycTEmF5jrkPg95AnIfmt/77rnSR6rPbPzcpNDRQnfJLEz8KcjtxPxDq8F5MUEHJEJAUchU31pGR0lzNKrMF3DRtAUfsAiGNWTt6I7A7oJYEhxGicKbJRJuOGI3zjoFaNwPqMYfETvmxcd4J+DshWVhWE4QgFMthLEwZ9AtXy9r/xITurqFhL1qUEQ8p9RNDtfZgCRLpEamCJmcvf6n8nQrtBWPMW54a4xUYnhsSAKqudEotedbiiLZjGBoA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 0536b1b2-47e2-4a76-b846-08d74cf40baf X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2019 20:05:34.5592 (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-CrossTenant-userprincipalname: 5O1/2m8dWrNjyjAtiDoPgBD4LroDBaYqOOO8eCWoMCV4VyIiY1PaoXhBJXBuTcaXfAAeIJKEUADyXXZwFkRh9w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3609 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-09_09:2019-10-08,2019-10-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 impostorscore=0 bulkscore=0 phishscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 clxscore=1011 lowpriorityscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910090158 Archived-At: Subject: Re: [Rift] WGLC, IPR and Implementation polling for draft-ietf-rift-rift-08 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, 09 Oct 2019 20:05:44 -0000 SGksDQoNClRob3VnaCB3aXRoIHNvbWUgZGVsYXkgaW4gZ2V0dGluZyBJUFIgc3RhdGVtZW50IGZy b20gYWxsIGNvLWF1dGhvcnMsIHRoZSBXR0xDIGZvciBkcmFmdC1pZXRmLXJpZnQtcmlmdC0wOCBo YXMgY29uY2x1ZGVkIHdpdGggbG90cyBvZiBzdXBwb3J0IGFuZCBubyBjb25jZXJucyByYWlzZWQu DQoNClRoZXJlIGFyZSB0d28gZXhpc3RpbmcgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMg YXMgZGVzY3JpYmVkIGluIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcmlm dC8wVnB2Rk9VUTNNNXAwSnZ0TTF4R2RDdnAwX2csIHBsdXMgYW5vdGhlciBvbmdvaW5nIGltcGxl bWVudGF0aW9uIHRoYXQgd2Uga25vdyBvZi4NCiANCldlIG5vdyBwcm9jZWVkIHRvIHRoZSBuZXh0 IHN0YWdlIGZvciB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KVGhhbmtzIQ0KSmVmZiAmIEplZmZyZXkN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEplZmZyZXkgKFpoYW9odWkpIFpo YW5nIA0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTkgMzo0MCBQTQ0KVG86IEplZmYg VGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsgcmlmdEBpZXRmLm9yZzsgcmlmdC1j aGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFdHTEMsIElQUiBhbmQgSW1wbGVtZW50YXRpb24gcG9s bGluZyBmb3IgZHJhZnQtaWV0Zi1yaWZ0LXJpZnQtMDgNCg0KSGkgUklGVGVycywNCg0KVGhpcyBl bWFpbCBzdGFydHMgV0cgTGFzdCBDYWxsLCBJUFIgYW5kIGltcGxlbWVudGF0aW9uIHBvbGxpbmcg IGZvciBvdXIgYmFzZSBzcGVjIGRyYWZ0LWlldGYtcmlmdC1yaWZ0LTA4LiBJdCBlbmRzIG9uIDkv MjcuDQoNClBsZWFzZSB0aG9yb3VnaGx5IHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIHZvaWNlIHlv dXIgc3VwcG9ydC9vYmplY3Rpb24uDQoNCklmIHlvdeKAmXJlIGEgY28tYXV0aG9yL2NvbnRyaWJ1 dG9yLCBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGljYXRl IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IHVuZGlzY2xvc2Vk IElQUi4gVGhlIERvY3VtZW50IHdvbid0IHByb2dyZXNzIHdpdGhvdXQgYW5zd2VycyBmcm9tIGFs bCB0aGUgQXV0aG9ycyBhbmQgQ29udHJpYnV0b3JzLg0KDQpJZiB5b3UncmUgbm90IGEgY28tYXV0 aG9yL2NvbnRyaWJ1dG9yLCB5b3UgbmVlZCB0byByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgcmVsZXZhbnQgSVBSIG5vdCB5ZXQgZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdp dGggSUVURiBydWxlcy4NCg0KQ3VycmVudGx5IGRpc2Nsb3NlZCBJUFJzIGNhbiBiZSBmb3VuZCBo ZXJlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP3N1Ym1pdD1kcmFm dCZpZD1kcmFmdC1pZXRmLXJpZnQtcmlmdC4NCg0KV2UgYXJlIGFsc28gcG9sbGluZyBmb3IgYW55 IGV4aXN0aW5nIGltcGxlbWVudGF0aW9uLg0KDQpUaGFua3MhDQpKZWZmIGFuZCBKZWZmcmV5DQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KRnJvbTogUklGVCA8cmlmdC1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgVG9ueSBQcnp5Z2llbmRhDQpTZW50OiBNb25kYXks IFNlcHRlbWJlciA5LCAyMDE5IDM6MDYgQU0NClRvOiByaWZ0QGlldGYub3JnDQpTdWJqZWN0OiBb UmlmdF0gTEMgdmVyc2lvbiAtMDgNCg0KTEMgcmVhZHkgdmVyc2lvbiAtMDggaGFzIGJlZW4gcG9z dGVkIA0KDQpMYXN0IGZldyBzbWFsbCBjaGFuZ2VzIGJhc2VkIG9uIGlucHV0IG9mIHBlb3BsZSBw bGF5aW5nIHdpdGggYm90aCBpbXBsZW1lbnRhdGlvbnMgaW4gZGlmZmVyZW50IHNjZW5hcmlvcw0K DQoqIEEgbmV3IHByZWZpeCB0aWUgdHlwZSBoYXMgYmVlbiBhZGRlZCBQb3NpdGl2ZUV4dGVybmFs RGlzYWdncmVnYXRpb25QcmVmaXhUSUVUeXBlIHNpbmNlIGl0IGlzIG5lY2Vzc2FyeSB0byBkaXN0 aW5ndWlzaCBiZXR3ZWVuIG5vcm1hbCBwcmVmaXggYW5kIGV4dGVybmFsIHByZWZpeCBiZWluZyBk aXNhZ2dyZWdhdGVkIHRvIHByZXNlcnZlIHByaW9yaXRpZXMgaW4gY29tcGxleCByZWRpc3RyaWJ1 dGlvbiBzY2VuYXJpb3MuIEJUVywgbmVnYXRpdmUgcHJlZml4ZXMgYXJlIGFsd2F5cyBsZWFzdCBw cmVmZXJyZWQgYW5kIGhlbmNlIHRoZXkgZG9uJ3QgbmVlZCB0byBkaWZmZXJlbnRpYXRlLiANCiog TGluayBwYWlyIGNhcnJpZXMgbm93IGluZGljYXRpb24gd2hldGhlciBCRkQgaXMgdXAgOW9uIHRo ZSBsaW5rLiBUaGlzIGFsbG93cyBhdCB0aGUgdG9wIG9mIHRoZSBmYWJyaWMgbm90IG9ubHkgc2Vl IGxpbmtzIHRoYXQgYXJlIHNlY3VyZWQgYW5kIG91dGVyIGtleXMgYnV0IGFsc28gd2hldGhlciBs aW5rIGlzIEJGRCBwcm90ZWN0ZWQvQkZEIGlzIHVwDQoqIE5vZGVDYXBhYmlsaXRpZXMgYXJlIHJl cXVpcmVkIG5vdyBhbmQgbWlub3IgcHJvdG9jb2wgdmVyc2lvbiBpcyBjYXJyaWVkIHNpbmNlIHRo ZXJlIHdhcyBubyBwb3NzaWJsaXR5IG9uIGFkamFjZW5jeSBidWlsZGluZyB0byBjaGVjayB3aGlj aCBtaW5vciB2ZXJzd2lvbiB0aGUgcGVlciBzcGVha3MgKG1ham9yIGlzIGNhcnJpZWQgaW4gdGhl IGVudmVsb3BlKS4gTWFqb3IgdmVyc2lvbiBjb21wYXRpYmlsaXR5IGFsbG93cyB0byBhd2F5cyBk ZWNvZGUgdGhlIG1vZGVsIGJ1dCBtaW5vciBjb3VsZCBiZSB1c2VkIGluIHRoZSBmdXR1cmUgdG8g dW5kZXJzdGFuZCBtaW5vciBzY2hlbWEgdmFyaWF0aW9ucw0KDQp0aGFua3MgDQoNCi0tLSB0b255 IA0K From nobody Thu Oct 24 01:52: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 8EB2112006B for ; Thu, 24 Oct 2019 01:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 N_hsalwRuB3H for ; Thu, 24 Oct 2019 01:52:52 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 8EB95120059 for ; Thu, 24 Oct 2019 01:52:52 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id A14C348082C748669D71; Thu, 24 Oct 2019 16:52:49 +0800 (CST) Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id x9O8qPbj090285; Thu, 24 Oct 2019 16:52:25 +0800 (GMT-8) (envelope-from xu.benchong@zte.com.cn) Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Thu, 24 Oct 2019 16:52:24 +0800 (CST) Date: Thu, 24 Oct 2019 16:52:24 +0800 (CST) X-Zmail-TransId: 2afb5db16648b4091389 X-Mailer: Zmail v1.0 Message-ID: <201910241652249011192@zte.com.cn> Mime-Version: 1.0 From: To: Cc: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn x9O8qPbj090285 Archived-At: Subject: [Rift] =?utf-8?q?Device_restart_problem?= 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, 24 Oct 2019 08:52:55 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIFRvbnkNCg0KDQpUaGVyZSBpcyBhIGRldmljZSByZXN0YXJ0IHByb2JsZW0NCg0KSW4gZHJh ZnQtaWV0Zi1yaWZ0LXJpZnQtMDggRmlndXJlIDIsIE4tVElFIG9mIExlYWYxMTEgZmxvb2RlZCB0 byBUb0YyMSB2aWEgU3BpbmUxMTEuIFNlcSBOUiBtYXkgYmUgbGFyZ2VyLg0KDQpMZWFmMTExIHJl c3RhcnRzIGFuZCByZWdlbmVyYXRlcyBOLVRJRS4gVGhlIHJhbmRvbSBzZXEgTlIgbWF5IGJlIHNt YWxsLCBzbyB0aGF0IHdoZW4gU3BpbmUxMTEgcmVjZWl2ZXMgaXQsIGl0IHdpbGwgY29tcGFyZSB0 aGUgc2VxIE5SIGFuZCBkaXNjYXJkIHRoZSBuZXcgbWVzc2FnZS4NCg0KQWNjb3JkaW5nIHRvIHRo ZSBiZWhhdmlvciBvZiBBcHBlbmRpeCBjLjMuNCBiLjMsIGl0IGlzIGhvcGVkIHRoYXQgU3BpbmUx MTEgc2VuZHMgREJUSUUgdG8gTGVhZjExMSB0byB1cGRhdGUgc2VxIE5SLg0KDQpIb3dldmVyLCBh Y2NvcmRpbmcgdG8gdGhlIGZsb29kaW5nIHJhbmdlIG9mIE4tVElFLCB0aGlzIG1lc3NhZ2UgY2Fu bm90IGJlIHNlbnQgb3V0Lg0KDQpJbiB0aGlzIHdheSwgdGhlcmUgd2lsbCBiZSBhIGxhcmdlIG51 bWJlciBvZiBpbnZhbGlkIE4tVElFcyBpbiB0aGUgbmV0d29yayBmb3IgYSBsb25nIHRpbWUgKHRo ZSBkZWZhdWx0IGV4cGlyZSB0aW1lIG9mIHRoZSBwcm90b2NvbCBpcyAxIHdlZWspDQoNCklzIHRo aXMgdW5kZXJzdGFuZGluZyBjb3JyZWN0PyBIb3cgZG9lcyByaWZ0IHNvbHZlIHRoaXMgcHJvYmxl bT8NCg0KDQoNCg0KVGhhbmsgeW91IQ0KDQpCZW5jaG9uZw== --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPkhpLCBUb255PGJyPjwvcD48cD5UaGVyZSBpcyBhIGRldmljZSByZXN0YXJ0 IHByb2JsZW08L3A+PHA+SW4gZHJhZnQtaWV0Zi1yaWZ0LXJpZnQtMDggRmlndXJlIDIsIE4tVElF IG9mIExlYWYxMTEgZmxvb2RlZCB0byBUb0YyMSB2aWEgU3BpbmUxMTEuIFNlcSBOUiBtYXkgYmUg bGFyZ2VyLjwvcD48cD5MZWFmMTExIHJlc3RhcnRzIGFuZCByZWdlbmVyYXRlcyBOLVRJRS4gVGhl IHJhbmRvbSBzZXEgTlIgbWF5IGJlIHNtYWxsLCBzbyB0aGF0IHdoZW4gU3BpbmUxMTEgcmVjZWl2 ZXMgaXQsIGl0IHdpbGwgY29tcGFyZSB0aGUgc2VxIE5SIGFuZCBkaXNjYXJkIHRoZSBuZXcgbWVz c2FnZS48L3A+PHA+QWNjb3JkaW5nIHRvIHRoZSBiZWhhdmlvciBvZiBBcHBlbmRpeCBjLjMuNCBi LjMsIGl0IGlzIGhvcGVkIHRoYXQgU3BpbmUxMTEgc2VuZHMgREJUSUUgdG8gTGVhZjExMSB0byB1 cGRhdGUgc2VxIE5SLjwvcD48cD5Ib3dldmVyLCBhY2NvcmRpbmcgdG8gdGhlIGZsb29kaW5nIHJh bmdlIG9mIE4tVElFLCB0aGlzIG1lc3NhZ2UgY2Fubm90IGJlIHNlbnQgb3V0LjwvcD48cD5JbiB0 aGlzIHdheSwgdGhlcmUgd2lsbCBiZSBhIGxhcmdlIG51bWJlciBvZiBpbnZhbGlkIE4tVElFcyBp biB0aGUgbmV0d29yayBmb3IgYSBsb25nIHRpbWUgKHRoZSBkZWZhdWx0IGV4cGlyZSB0aW1lIG9m IHRoZSBwcm90b2NvbCBpcyAxIHdlZWspPC9wPjxwPklzIHRoaXMgdW5kZXJzdGFuZGluZyBjb3Jy ZWN0PyBIb3cgZG9lcyByaWZ0IHNvbHZlIHRoaXMgcHJvYmxlbT88L3A+PHA+PGJyPjwvcD48cD5U aGFuayB5b3UhPC9wPjxwPkJlbmNob25nPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250 LWZhbWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFt aWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6 YXJpYWw7Ij48YnI+PC9wPjwvZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Thu Oct 24 08:59:22 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 1A7751200CC for ; Thu, 24 Oct 2019 08:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 jVoPwSU5_1Ta for ; Thu, 24 Oct 2019 08:59:18 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 940C5120052 for ; Thu, 24 Oct 2019 08:59:18 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id v2so22894099ilm.0 for ; Thu, 24 Oct 2019 08:59:18 -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=nfmyHjzjiVv2WvcIeHUks8vgMnGMqBziG5A6dEQafSI=; b=Ea2PUyfq5pWa3zf5eMqMrUwMDWdt58lz18UvJFngRGfVPGr1hn785dVKKOH7zP6r4x 3Z3DG4IqZeszLGOaygZ/3iWU7e9LbDp02eIsuOvzbI1IvYWX7G7CCqFY/SsI8kGdH3PD HdX7fkplOOZMUSV7CyPoeqf4G4IsrvVhkxZ2jRahv9aT0zdR03u/wRRg2hn0nvxDSTH8 EyFacmP+HNFO86zWt5YlZUDrW53aYpYDhsVs5PHwFaq8ZlOBF9jeDJA0qlMk87hBiwzL 1MDoiK29kXYfGxiZxxqqVBM9EWM1shxDpNId7+2iHuWFmH1zazI5v9AoUvpDgqrR3Dge T/qQ== 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=nfmyHjzjiVv2WvcIeHUks8vgMnGMqBziG5A6dEQafSI=; b=ilrY7Io8QtnO03ol/BMk0cxxpnf7hL2TGqvT+4fPnSfaEIzM53vznPGGmY4o2wxGrv WbOpxydQS1Pwj+KndobZPS60JYrDs9GJ+ogS4+BMrjorPClUlHcok9BfJTfwHZI1JJYJ I7FXlo21/VlXo6SFWIbLAYZeBHK2ck/jwvytTkETG/AeNM9X1bNP1gT/HVn61gro0O5A DutA/cQX3DZWsoh1B+5DdweNgtAfVKMlN/egUlxkrsJPEJf+pTlSevkIZczy13lCTpKv rf9UOg+24opcihgMhRTaUrFfnl4oopHI+b8cuqHPzF0kgailVA3BwY8xex4yikwczJ/u HWKg== X-Gm-Message-State: APjAAAX8VCaCbONPorZSV+gauGMFuswwB8tehrszjMURdxnvgMUT0Kxh dsF72L98Yo4X5Y6T/G/ZACXNaT0vMTkclAhlYUM5WJeY X-Google-Smtp-Source: APXvYqwKQka4CFARhF+DsS/0XhEmcXULPBwWF6uvmTgjD9/W0ck+DBvgoAGS+TNX7qWTUsB08I4jXvHi2TMFQl6MyP0= X-Received: by 2002:a92:dac1:: with SMTP id o1mr47194262ilq.132.1571932757726; Thu, 24 Oct 2019 08:59:17 -0700 (PDT) MIME-Version: 1.0 References: <201910241652249011192@zte.com.cn> In-Reply-To: <201910241652249011192@zte.com.cn> From: Tony Przygienda Date: Thu, 24 Oct 2019 08:58:35 -0700 Message-ID: To: xu.benchong@zte.com.cn Cc: rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000a29f740595aa1d16" Archived-At: Subject: Re: [Rift] Device restart problem 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, 24 Oct 2019 15:59:21 -0000 --000000000000a29f740595aa1d16 Content-Type: text/plain; charset="UTF-8" hey xu, I see deeper and deepr into implementation, you just found first layer of the onion here BTW ;-) The seqnr# handling is since times immemorial one of the trickier parts of IGP implementation (but not only, same problems exists in other places but there, the information is not persistent so problem is not as pressing). Multiple mechanisms kick in here a) the seqnr# is circular which is a very important piece of the puzzle. you cannot generate a "biggest" number no'one can override. math explained in appendix in lots detail. BTW, not my invention, smarter people than me worked stuff out long time ago but there was never a full, detailed, easy to implement writedown AFAIK. b) yes, the fact that we flood only northbound prevents via normal "flat flooding" Leaf111 "getting" its old TIE with a higher sequence number. Using flat flooding south would of course kill largely the scalability of the protocol and make it equivalent to OSPF or ISIS or any other "normal" link-state approach in terms of flooding complexity (well, flood reduction would still work ;-) c) However, observe that Table 3 holds the key to the solution. TIDE/South tells you what you need to do to describe your database to the neighbor south. The description from Spine111 includes the description of N-TIEs of Leaf111 and with that Leaf111 can realize that there is a stale N-TIE it originated before reboot and re-issue with a higher sequence number (that's where a] comes into play) When you keep on implementing and testing you'll find another very interesting, far more complex case that we solved but I will keep the suspension going ;-) The observation on the one week is also correct. Done very purposefully. Let's say RIFT runs on 0.5M devices (scale we aim at given multi-homed/overlay originating servers can run it as well). If you assume 5 TIEs per device that's 2.5M TIEs @ the top of the fabric (large but not a scary number compared to what we do with BGP and add/path on daily basis in world's most scalable implementations ;-). If we'd have something like 1hr reorigination we talk 2.5M/24 = 100K re-originations per hour. That gives you a flooding rate into ToFs of 30 TIEs/sec (assuming perfect flood reduction). All that disregarding things like server rebooting or container architectures which will possibly inject lots prefixes on moves/boots and so on. So refresh often is churn that is unnecessary. With 1 week lifetime we're talking 15K TIEs per hour refresh which is a manageable number given we're talking 0.5M devices. Observe however that you can issue with any lifetime you choose as a device and RIFT will work (and when emptying TIEs you are supposed to originate with 300secs only). So the 1 week is basically a protocol constant that can be knobbed. Let us know when you got first pieces inter'oped with Bruno's open source BTW. Things always become much more clear when implementations are bashed against each other ;-) --- tony On Thu, Oct 24, 2019 at 1:52 AM wrote: > Hi, Tony > > There is a device restart problem > > In draft-ietf-rift-rift-08 Figure 2, N-TIE of Leaf111 flooded to ToF21 via > Spine111. Seq NR may be larger. > > Leaf111 restarts and regenerates N-TIE. The random seq NR may be small, so > that when Spine111 receives it, it will compare the seq NR and discard the > new message. > > According to the behavior of Appendix c.3.4 b.3, it is hoped that Spine111 > sends DBTIE to Leaf111 to update seq NR. > > However, according to the flooding range of N-TIE, this message cannot be > sent out. > > In this way, there will be a large number of invalid N-TIEs in the network > for a long time (the default expire time of the protocol is 1 week) > > Is this understanding correct? How does rift solve this problem? > > > Thank you! > > Benchong > > > > > --000000000000a29f740595aa1d16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hey xu, I see deeper and deepr into implementation, y= ou just found first layer of the onion here BTW ;-)=C2=A0 The seqnr# handli= ng is since times immemorial one of the trickier parts of IGP implementatio= n (but not only, same problems exists in=C2=A0 other places but there, the = information is not persistent so problem is not as pressing).

Multiple mechanisms kick in here

= a) the seqnr# is circular which is a very important piece of the puzzle. yo= u cannot generate a "biggest" number no'one can override. mat= h explained in appendix in lots detail. BTW, not my invention, smarter peop= le than me worked stuff out long time ago but there was never a full, detai= led, easy to implement writedown AFAIK.
b) yes, the fact tha= t we flood only northbound prevents via normal "flat flooding"=C2= =A0 Leaf111 "getting" its old TIE with a higher sequence number. = Using flat flooding south would of course kill largely the scalability of t= he protocol and make it equivalent to OSPF or ISIS=C2=A0 or any other "= ;normal" link-state approach in terms of flooding complexity (well, fl= ood reduction would still work ;-)
c) However, observe that Tabl= e 3 holds the key to the solution. TIDE/South tells you what you need to do= to describe your database to the neighbor south. The description from Spin= e111 includes the description of N-TIEs of Leaf111 and with that Leaf111 ca= n realize that there is a stale N-TIE it originated before reboot and re-is= sue with a higher sequence number (that's where a] comes into play)

When you keep on implementing and testing you= 9;ll find another very interesting, far more complex case that we solved bu= t I will keep the suspension going ;-)

The obs= ervation on the one week is also correct. Done very purposefully. Let's= say RIFT runs on 0.5M devices (scale we aim at given multi-homed/overlay o= riginating servers can run it as well). If you assume 5 TIEs per device tha= t's 2.5M TIEs @ the top of the fabric (large but not a scary number com= pared to what we do with BGP and add/path on daily basis in world's mos= t scalable implementations ;-). If we'd have something like 1hr reorigi= nation we talk=C2=A0 2.5M/24 =3D 100K re-originations per hour. That gives = you a flooding rate into ToFs of 30 TIEs/sec (assuming perfect flood reduct= ion). All that disregarding things like server rebooting or container archi= tectures which will possibly inject lots prefixes on moves/boots and so on.= So refresh often is churn that is unnecessary. With 1 week lifetime we'= ;re talking 15K TIEs per hour refresh which is a manageable number given we= 're talking 0.5M devices.

Observe however= that you can issue with any lifetime you choose as a device and RIFT will = work (and when emptying TIEs you are supposed to originate with 300secs onl= y). So the 1 week is basically a protocol constant that can be knobbed.

Let us know when you got first pieces inter'= oped with Bruno's open source BTW. Things always become much more clear= when implementations are bashed against each other ;-)

<= /div>
--- tony



<= /div>
O= n Thu, Oct 24, 2019 at 1:52 AM <xu.benchong@zte.com.cn> wrote:

= Hi, Tony

There is a device restart problem

In draft-ietf-ri= ft-rift-08 Figure 2, N-TIE of Leaf111 flooded to ToF21 via Spine111. Seq NR= may be larger.

Leaf111 restarts and regenerates N-TIE. The random se= q NR may be small, so that when Spine111 receives it, it will compare the s= eq NR and discard the new message.

According to the behavior of Appen= dix c.3.4 b.3, it is hoped that Spine111 sends DBTIE to Leaf111 to update s= eq NR.

However, according to the flooding range of N-TIE, this messag= e cannot be sent out.

In this way, there will be a large number of in= valid N-TIEs in the network for a long time (the default expire time of the= protocol is 1 week)

Is this understanding correct? How does rift sol= ve this problem?


Thank you!

Benchong




=
--000000000000a29f740595aa1d16-- From nobody Fri Oct 25 00:44: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 412BA120110 for ; Fri, 25 Oct 2019 00:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4Wo0s8y_w1kM for ; Fri, 25 Oct 2019 00:44:43 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 1134B12004C for ; Fri, 25 Oct 2019 00:44:42 -0700 (PDT) Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 86AA9ABFE327E9963A40; Fri, 25 Oct 2019 15:44:39 +0800 (CST) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 6FEFC19D49E0A98A955A; Fri, 25 Oct 2019 15:44:39 +0800 (CST) Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id x9P7h7Bi064223; Fri, 25 Oct 2019 15:43:07 +0800 (GMT-8) (envelope-from xu.benchong@zte.com.cn) Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Fri, 25 Oct 2019 15:43:06 +0800 (CST) Date: Fri, 25 Oct 2019 15:43:06 +0800 (CST) X-Zmail-TransId: 2afb5db2a78a1a66e615 X-Mailer: Zmail v1.0 Message-ID: <201910251543067579596@zte.com.cn> In-Reply-To: References: 201910241652249011192@zte.com.cn, CA+wi2hNN9JrRft2_n0eHmWq4+p2KHdBH3dwQ6pat8Ri02FTrHQ@mail.gmail.com Mime-Version: 1.0 From: To: Cc: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn x9P7h7Bi064223 Archived-At: Subject: Re: [Rift] =?utf-8?q?Device_restart_problem?= 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, 25 Oct 2019 07:44:45 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksdG9ueQ0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQoNCldoZW4gTGVhZjExMSBhbmQgU3Bp bmUxMTEgKGFzc3VtaW5nIG5vIG90aGVyIHNwaW5lcykgYXJlIHJlc3RhcnRlZCBhdCB0aGUgc2Ft ZSB0aW1lLCBTcGluZTExMSBjYW7igJl0IGZsb29kIHRoZSByZWNlaXZlZCBUSURFIG9mIFRvRjIx IHRvIExlYWYxMTEsIGFuZCBTZXEgTlIgY2Fu4oCZdCBiZSB1cGRhdGVkIC0tIElzIHRoaXMgdGhl IHNlY29uZCBsYXllciBvZiBvbmlvbjstKQ0KDQpDYW4gd2UgdXBkYXRlIHRoZSBsaWZldGltZSBv ZiB0aGUgdGllIGJ5IHRpZGUgdG8gYXZvaWQgc2VuZGluZyB0aWUgcGVyaW9kPw0KDQpXZSBhcmUg ZGV2ZWxvcGluZyBhIHZlcmlmaWNhdGlvbiBpbXBsZW1lbnRhdGlvbiwgYW5kIGhhdmUgbm90IHll dCBjb25uZWN0IHdpdGggQnJ1bm8ncy4NCg0KDQoNCg0KDQoNCkJlbmNob25nDQoNCg0KDQoNCg0K DQoNCuWOn+Wni+mCruS7tg0KDQoNCg0K5Y+R5Lu25Lq677yaVG9ueVByenlnaWVuZGEgPHRvbnlz aWV0ZkBnbWFpbC5jb20+DQrmlLbku7bkurrvvJrlvpDmnKzltIcxMDA2NTA1MzsNCuaKhOmAgeS6 uu+8mnJpZnRAaWV0Zi5vcmcgPHJpZnRAaWV0Zi5vcmc+Ow0K5pelIOacnyDvvJoyMDE55bm0MTDm nIgyNOaXpSAyMzo1OQ0K5Li7IOmimCDvvJpSZTogRGV2aWNlIHJlc3RhcnQgcHJvYmxlbQ0KDQoN Cg0KaGV5IHh1LCBJIHNlZSBkZWVwZXIgYW5kIGRlZXByIGludG8gaW1wbGVtZW50YXRpb24sIHlv dSBqdXN0IGZvdW5kIGZpcnN0IGxheWVyIG9mIHRoZSBvbmlvbiBoZXJlIEJUVyA7LSkgIFRoZSBz ZXFuciMgaGFuZGxpbmcgaXMgc2luY2UgdGltZXMgaW1tZW1vcmlhbCBvbmUgb2YgdGhlIHRyaWNr aWVyIHBhcnRzIG9mIElHUCBpbXBsZW1lbnRhdGlvbiAoYnV0IG5vdCBvbmx5LCBzYW1lIHByb2Js ZW1zIGV4aXN0cyBpbiAgb3RoZXIgcGxhY2VzIGJ1dCB0aGVyZSwgdGhlIGluZm9ybWF0aW9uIGlz IG5vdCBwZXJzaXN0ZW50IHNvIHByb2JsZW0gaXMgbm90IGFzIHByZXNzaW5nKS4gDQoNCg0KTXVs dGlwbGUgbWVjaGFuaXNtcyBraWNrIGluIGhlcmUNCg0KYSkgdGhlIHNlcW5yIyBpcyBjaXJjdWxh ciB3aGljaCBpcyBhIHZlcnkgaW1wb3J0YW50IHBpZWNlIG9mIHRoZSBwdXp6bGUuIHlvdSBjYW5u b3QgZ2VuZXJhdGUgYSAiYmlnZ2VzdCIgbnVtYmVyIG5vJ29uZSBjYW4gb3ZlcnJpZGUuIG1hdGgg ZXhwbGFpbmVkIGluIGFwcGVuZGl4IGluIGxvdHMgZGV0YWlsLiBCVFcsIG5vdCBteSBpbnZlbnRp b24sIHNtYXJ0ZXIgcGVvcGxlIHRoYW4gbWUgd29ya2VkIHN0dWZmIG91dCBsb25nIHRpbWUgYWdv IGJ1dCB0aGVyZSB3YXMgbmV2ZXIgYSBmdWxsLCBkZXRhaWxlZCwgZWFzeSB0byBpbXBsZW1lbnQg d3JpdGVkb3duIEFGQUlLLiANCg0KYikgeWVzLCB0aGUgZmFjdCB0aGF0IHdlIGZsb29kIG9ubHkg bm9ydGhib3VuZCBwcmV2ZW50cyB2aWEgbm9ybWFsICJmbGF0IGZsb29kaW5nIiAgTGVhZjExMSAi Z2V0dGluZyIgaXRzIG9sZCBUSUUgd2l0aCBhIGhpZ2hlciBzZXF1ZW5jZSBudW1iZXIuIFVzaW5n IGZsYXQgZmxvb2Rpbmcgc291dGggd291bGQgb2YgY291cnNlIGtpbGwgbGFyZ2VseSB0aGUgc2Nh bGFiaWxpdHkgb2YgdGhlIHByb3RvY29sIGFuZCBtYWtlIGl0IGVxdWl2YWxlbnQgdG8gT1NQRiBv ciBJU0lTICBvciBhbnkgb3RoZXIgIm5vcm1hbCIgbGluay1zdGF0ZSBhcHByb2FjaCBpbiB0ZXJt cyBvZiBmbG9vZGluZyBjb21wbGV4aXR5ICh3ZWxsLCBmbG9vZCByZWR1Y3Rpb24gd291bGQgc3Rp bGwgd29yayA7LSkNCmMpIEhvd2V2ZXIsIG9ic2VydmUgdGhhdCBUYWJsZSAzIGhvbGRzIHRoZSBr ZXkgdG8gdGhlIHNvbHV0aW9uLiBUSURFL1NvdXRoIHRlbGxzIHlvdSB3aGF0IHlvdSBuZWVkIHRv IGRvIHRvIGRlc2NyaWJlIHlvdXIgZGF0YWJhc2UgdG8gdGhlIG5laWdoYm9yIHNvdXRoLiBUaGUg ZGVzY3JpcHRpb24gZnJvbSBTcGluZTExMSBpbmNsdWRlcyB0aGUgZGVzY3JpcHRpb24gb2YgTi1U SUVzIG9mIExlYWYxMTEgYW5kIHdpdGggdGhhdCBMZWFmMTExIGNhbiByZWFsaXplIHRoYXQgdGhl cmUgaXMgYSBzdGFsZSBOLVRJRSBpdCBvcmlnaW5hdGVkIGJlZm9yZSByZWJvb3QgYW5kIHJlLWlz c3VlIHdpdGggYSBoaWdoZXIgc2VxdWVuY2UgbnVtYmVyICh0aGF0J3Mgd2hlcmUgYV0gY29tZXMg aW50byBwbGF5KSANCg0KDQpXaGVuIHlvdSBrZWVwIG9uIGltcGxlbWVudGluZyBhbmQgdGVzdGlu ZyB5b3UnbGwgZmluZCBhbm90aGVyIHZlcnkgaW50ZXJlc3RpbmcsIGZhciBtb3JlIGNvbXBsZXgg Y2FzZSB0aGF0IHdlIHNvbHZlZCBidXQgSSB3aWxsIGtlZXAgdGhlIHN1c3BlbnNpb24gZ29pbmcg Oy0pDQoNCg0KVGhlIG9ic2VydmF0aW9uIG9uIHRoZSBvbmUgd2VlayBpcyBhbHNvIGNvcnJlY3Qu IERvbmUgdmVyeSBwdXJwb3NlZnVsbHkuIExldCdzIHNheSBSSUZUIHJ1bnMgb24gMC41TSBkZXZp Y2VzIChzY2FsZSB3ZSBhaW0gYXQgZ2l2ZW4gbXVsdGktaG9tZWQvb3ZlcmxheSBvcmlnaW5hdGlu ZyBzZXJ2ZXJzIGNhbiBydW4gaXQgYXMgd2VsbCkuIElmIHlvdSBhc3N1bWUgNSBUSUVzIHBlciBk ZXZpY2UgdGhhdCdzIDIuNU0gVElFcyBAIHRoZSB0b3Agb2YgdGhlIGZhYnJpYyAobGFyZ2UgYnV0 IG5vdCBhIHNjYXJ5IG51bWJlciBjb21wYXJlZCB0byB3aGF0IHdlIGRvIHdpdGggQkdQIGFuZCBh ZGQvcGF0aCBvbiBkYWlseSBiYXNpcyBpbiB3b3JsZCdzIG1vc3Qgc2NhbGFibGUgaW1wbGVtZW50 YXRpb25zIDstKS4gSWYgd2UnZCBoYXZlIHNvbWV0aGluZyBsaWtlIDFociByZW9yaWdpbmF0aW9u IHdlIHRhbGsgIDIuNU0vMjQgPSAxMDBLIHJlLW9yaWdpbmF0aW9ucyBwZXIgaG91ci4gVGhhdCBn aXZlcyB5b3UgYSBmbG9vZGluZyByYXRlIGludG8gVG9GcyBvZiAzMCBUSUVzL3NlYyAoYXNzdW1p bmcgcGVyZmVjdCBmbG9vZCByZWR1Y3Rpb24pLiBBbGwgdGhhdCBkaXNyZWdhcmRpbmcgdGhpbmdz IGxpa2Ugc2VydmVyIHJlYm9vdGluZyBvciBjb250YWluZXIgYXJjaGl0ZWN0dXJlcyB3aGljaCB3 aWxsIHBvc3NpYmx5IGluamVjdCBsb3RzIHByZWZpeGVzIG9uIG1vdmVzL2Jvb3RzIGFuZCBzbyBv bi4gU28gcmVmcmVzaCBvZnRlbiBpcyBjaHVybiB0aGF0IGlzIHVubmVjZXNzYXJ5LiBXaXRoIDEg d2VlayBsaWZldGltZSB3ZSdyZSB0YWxraW5nIDE1SyBUSUVzIHBlciBob3VyIHJlZnJlc2ggd2hp Y2ggaXMgYSBtYW5hZ2VhYmxlIG51bWJlciBnaXZlbiB3ZSdyZSB0YWxraW5nIDAuNU0gZGV2aWNl cy4gDQoNCg0KT2JzZXJ2ZSBob3dldmVyIHRoYXQgeW91IGNhbiBpc3N1ZSB3aXRoIGFueSBsaWZl dGltZSB5b3UgY2hvb3NlIGFzIGEgZGV2aWNlIGFuZCBSSUZUIHdpbGwgd29yayAoYW5kIHdoZW4g ZW1wdHlpbmcgVElFcyB5b3UgYXJlIHN1cHBvc2VkIHRvIG9yaWdpbmF0ZSB3aXRoIDMwMHNlY3Mg b25seSkuIFNvIHRoZSAxIHdlZWsgaXMgYmFzaWNhbGx5IGEgcHJvdG9jb2wgY29uc3RhbnQgdGhh dCBjYW4gYmUga25vYmJlZC4gDQoNCg0KTGV0IHVzIGtub3cgd2hlbiB5b3UgZ290IGZpcnN0IHBp ZWNlcyBpbnRlcidvcGVkIHdpdGggQnJ1bm8ncyBvcGVuIHNvdXJjZSBCVFcuIFRoaW5ncyBhbHdh eXMgYmVjb21lIG11Y2ggbW9yZSBjbGVhciB3aGVuIGltcGxlbWVudGF0aW9ucyBhcmUgYmFzaGVk IGFnYWluc3QgZWFjaCBvdGhlciA7LSkNCg0KDQotLS0gdG9ueSANCg0KDQoNCg0KDQoNCg0KDQpP biBUaHUsIE9jdCAyNCwgMjAxOSBhdCAxOjUyIEFNIDx4dS5iZW5jaG9uZ0B6dGUuY29tLmNuPiB3 cm90ZToNCg0KDQpIaSwgVG9ueQ0KDQoNClRoZXJlIGlzIGEgZGV2aWNlIHJlc3RhcnQgcHJvYmxl bQ0KDQpJbiBkcmFmdC1pZXRmLXJpZnQtcmlmdC0wOCBGaWd1cmUgMiwgTi1USUUgb2YgTGVhZjEx MSBmbG9vZGVkIHRvIFRvRjIxIHZpYSBTcGluZTExMS4gU2VxIE5SIG1heSBiZSBsYXJnZXIuDQoN CkxlYWYxMTEgcmVzdGFydHMgYW5kIHJlZ2VuZXJhdGVzIE4tVElFLiBUaGUgcmFuZG9tIHNlcSBO UiBtYXkgYmUgc21hbGwsIHNvIHRoYXQgd2hlbiBTcGluZTExMSByZWNlaXZlcyBpdCwgaXQgd2ls bCBjb21wYXJlIHRoZSBzZXEgTlIgYW5kIGRpc2NhcmQgdGhlIG5ldyBtZXNzYWdlLg0KDQpBY2Nv cmRpbmcgdG8gdGhlIGJlaGF2aW9yIG9mIEFwcGVuZGl4IGMuMy40IGIuMywgaXQgaXMgaG9wZWQg dGhhdCBTcGluZTExMSBzZW5kcyBEQlRJRSB0byBMZWFmMTExIHRvIHVwZGF0ZSBzZXEgTlIuDQoN Ckhvd2V2ZXIsIGFjY29yZGluZyB0byB0aGUgZmxvb2RpbmcgcmFuZ2Ugb2YgTi1USUUsIHRoaXMg bWVzc2FnZSBjYW5ub3QgYmUgc2VudCBvdXQuDQoNCkluIHRoaXMgd2F5LCB0aGVyZSB3aWxsIGJl IGEgbGFyZ2UgbnVtYmVyIG9mIGludmFsaWQgTi1USUVzIGluIHRoZSBuZXR3b3JrIGZvciBhIGxv bmcgdGltZSAodGhlIGRlZmF1bHQgZXhwaXJlIHRpbWUgb2YgdGhlIHByb3RvY29sIGlzIDEgd2Vl aykNCg0KSXMgdGhpcyB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/IEhvdyBkb2VzIHJpZnQgc29sdmUg dGhpcyBwcm9ibGVtPw0KDQoNCg0KDQpUaGFuayB5b3UhDQoNCkJlbmNob25n --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjxicj48L3A+PHA+SGksdG9ueTwvcD48cD5UaGFua3MgZm9yIHlvdXIgcmVw bHkuPC9wPjxwPldoZW4gTGVhZjExMSBhbmQgU3BpbmUxMTEgKGFzc3VtaW5nIG5vIG90aGVyIHNw aW5lcykgYXJlIHJlc3RhcnRlZCBhdCB0aGUgc2FtZSB0aW1lLCBTcGluZTExMSBjYW7igJl0IGZs b29kIHRoZSByZWNlaXZlZCBUSURFIG9mIFRvRjIxIHRvIExlYWYxMTEsIGFuZCBTZXEgTlIgY2Fu 4oCZdCBiZSB1cGRhdGVkIC0tIElzIHRoaXMgdGhlIHNlY29uZCBsYXllciBvZiBvbmlvbjstKTwv cD48cD5DYW4gd2UgdXBkYXRlIHRoZSBsaWZldGltZSBvZiB0aGUgdGllIGJ5IHRpZGUgdG8gYXZv aWQgc2VuZGluZyB0aWUgcGVyaW9kPzwvcD48cD5XZSBhcmUgZGV2ZWxvcGluZyBhIHZlcmlmaWNh dGlvbiBpbXBsZW1lbnRhdGlvbiwgYW5kIGhhdmUgbm90IHlldCBjb25uZWN0IHdpdGggQnJ1bm8n cy48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwv cD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48c3BhbiBzdHls ZT0ibGluZS1oZWlnaHQ6IDIxcHg7Ij5CZW5jaG9uZzwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQt c2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48ZGl2PjxkaXYgY2xhc3M9Inpo aXN0b3J5Um93IiBzdHlsZT0iZGlzcGxheTpibG9jayI+PGRpdiBjbGFzcz0iemhpc3RvcnlEZXMi IHN0eWxlPSJ3aWR0aDogMTAwJTsgaGVpZ2h0OiAyOHB4OyBsaW5lLWhlaWdodDogMjhweDsgYmFj a2dyb3VuZC1jb2xvcjogI0UwRTVFOTsgY29sb3I6ICMxMzg4RkY7IHRleHQtYWxpZ246IGNlbnRl cjsiIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlPcmdUeHQiPuWOn+Wni+mCruS7tjwvZGl2PjxkaXYg aWQ9Inp3cml0ZUhpc3RvcnlDb250YWluZXIiPjxkaXYgY2xhc3M9ImNvbnRyb2wtZ3JvdXAgemhp c3RvcnlQYW5lbCI+PGRpdiBjbGFzcz0iemhpc3RvcnlIZWFkZXIiIHN0eWxlPSJwYWRkaW5nOiA4 cHg7IGJhY2tncm91bmQtY29sb3I6ICNGNUY2Rjg7Ij48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0 YT0iSGlzdG9yeVNlbmRlclR4dCI+5Y+R5Lu25Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9Inpy ZWFkVXNlck5hbWUiPlRvbnlQcnp5Z2llbmRhICZsdDt0b255c2lldGZAZ21haWwuY29tJmd0Ozwv c3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVRPVHh0Ij7mlLbk u7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3Bs YXk6IGlubGluZTsiPuW+kOacrOW0hzEwMDY1MDUzOzwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcg bGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeUNDVHh0Ij7mioTpgIHkurrvvJo8L3N0cm9uZz48c3BhbiBj bGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPnJpZnRAaWV0Zi5v cmcgJmx0O3JpZnRAaWV0Zi5vcmcmZ3Q7Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3Vh Z2UtZGF0YT0iSGlzdG9yeURhdGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9 IiI+MjAxOeW5tDEw5pyIMjTml6UgMjM6NTk8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1 YWdlLWRhdGE9Ikhpc3RvcnlTdWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwvc3Ryb25nPjxzcGFuIGNs YXNzPSJ6cmVhZFRpdGxlIj48c3Ryb25nPlJlOiBEZXZpY2UgcmVzdGFydCBwcm9ibGVtPC9zdHJv bmc+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9InpoaXN0b3J5Q29udGVudCI+PGRpdj48 ZGl2IGRpcj0ibHRyIj48ZGl2PmhleSB4dSwgSSBzZWUgZGVlcGVyIGFuZCBkZWVwciBpbnRvIGlt cGxlbWVudGF0aW9uLCB5b3UganVzdCBmb3VuZCBmaXJzdCBsYXllciBvZiB0aGUgb25pb24gaGVy ZSBCVFcgOy0pJm5ic3A7IFRoZSBzZXFuciMgaGFuZGxpbmcgaXMgc2luY2UgdGltZXMgaW1tZW1v cmlhbCBvbmUgb2YgdGhlIHRyaWNraWVyIHBhcnRzIG9mIElHUCBpbXBsZW1lbnRhdGlvbiAoYnV0 IG5vdCBvbmx5LCBzYW1lIHByb2JsZW1zIGV4aXN0cyBpbiZuYnNwOyBvdGhlciBwbGFjZXMgYnV0 IHRoZXJlLCB0aGUgaW5mb3JtYXRpb24gaXMgbm90IHBlcnNpc3RlbnQgc28gcHJvYmxlbSBpcyBu b3QgYXMgcHJlc3NpbmcpLiA8YnI+PC9kaXY+PGJyPjxkaXY+TXVsdGlwbGUgbWVjaGFuaXNtcyBr aWNrIGluIGhlcmU8L2Rpdj48YnI+PGRpdj5hKSB0aGUgc2VxbnIjIGlzIGNpcmN1bGFyIHdoaWNo IGlzIGEgdmVyeSBpbXBvcnRhbnQgcGllY2Ugb2YgdGhlIHB1enpsZS4geW91IGNhbm5vdCBnZW5l cmF0ZSBhICJiaWdnZXN0IiBudW1iZXIgbm8nb25lIGNhbiBvdmVycmlkZS4gbWF0aCBleHBsYWlu ZWQgaW4gYXBwZW5kaXggaW4gbG90cyBkZXRhaWwuIEJUVywgbm90IG15IGludmVudGlvbiwgc21h cnRlciBwZW9wbGUgdGhhbiBtZSB3b3JrZWQgc3R1ZmYgb3V0IGxvbmcgdGltZSBhZ28gYnV0IHRo ZXJlIHdhcyBuZXZlciBhIGZ1bGwsIGRldGFpbGVkLCBlYXN5IHRvIGltcGxlbWVudCB3cml0ZWRv d24gQUZBSUsuIDxicj48L2Rpdj48ZGl2PmIpIHllcywgdGhlIGZhY3QgdGhhdCB3ZSBmbG9vZCBv bmx5IG5vcnRoYm91bmQgcHJldmVudHMgdmlhIG5vcm1hbCAiZmxhdCBmbG9vZGluZyImbmJzcDsg TGVhZjExMSAiZ2V0dGluZyIgaXRzIG9sZCBUSUUgd2l0aCBhIGhpZ2hlciBzZXF1ZW5jZSBudW1i ZXIuIFVzaW5nIGZsYXQgZmxvb2Rpbmcgc291dGggd291bGQgb2YgY291cnNlIGtpbGwgbGFyZ2Vs eSB0aGUgc2NhbGFiaWxpdHkgb2YgdGhlIHByb3RvY29sIGFuZCBtYWtlIGl0IGVxdWl2YWxlbnQg dG8gT1NQRiBvciBJU0lTJm5ic3A7IG9yIGFueSBvdGhlciAibm9ybWFsIiBsaW5rLXN0YXRlIGFw cHJvYWNoIGluIHRlcm1zIG9mIGZsb29kaW5nIGNvbXBsZXhpdHkgKHdlbGwsIGZsb29kIHJlZHVj dGlvbiB3b3VsZCBzdGlsbCB3b3JrIDstKTwvZGl2PjxkaXY+YykgSG93ZXZlciwgb2JzZXJ2ZSB0 aGF0IFRhYmxlIDMgaG9sZHMgdGhlIGtleSB0byB0aGUgc29sdXRpb24uIFRJREUvU291dGggdGVs bHMgeW91IHdoYXQgeW91IG5lZWQgdG8gZG8gdG8gZGVzY3JpYmUgeW91ciBkYXRhYmFzZSB0byB0 aGUgbmVpZ2hib3Igc291dGguIFRoZSBkZXNjcmlwdGlvbiBmcm9tIFNwaW5lMTExIGluY2x1ZGVz IHRoZSBkZXNjcmlwdGlvbiBvZiBOLVRJRXMgb2YgTGVhZjExMSBhbmQgd2l0aCB0aGF0IExlYWYx MTEgY2FuIHJlYWxpemUgdGhhdCB0aGVyZSBpcyBhIHN0YWxlIE4tVElFIGl0IG9yaWdpbmF0ZWQg YmVmb3JlIHJlYm9vdCBhbmQgcmUtaXNzdWUgd2l0aCBhIGhpZ2hlciBzZXF1ZW5jZSBudW1iZXIg KHRoYXQncyB3aGVyZSBhXSBjb21lcyBpbnRvIHBsYXkpIDxicj48L2Rpdj48YnI+PGRpdj5XaGVu IHlvdSBrZWVwIG9uIGltcGxlbWVudGluZyBhbmQgdGVzdGluZyB5b3UnbGwgZmluZCBhbm90aGVy IHZlcnkgaW50ZXJlc3RpbmcsIGZhciBtb3JlIGNvbXBsZXggY2FzZSB0aGF0IHdlIHNvbHZlZCBi dXQgSSB3aWxsIGtlZXAgdGhlIHN1c3BlbnNpb24gZ29pbmcgOy0pPGJyPjwvZGl2Pjxicj48ZGl2 PlRoZSBvYnNlcnZhdGlvbiBvbiB0aGUgb25lIHdlZWsgaXMgYWxzbyBjb3JyZWN0LiBEb25lIHZl cnkgcHVycG9zZWZ1bGx5LiBMZXQncyBzYXkgUklGVCBydW5zIG9uIDAuNU0gZGV2aWNlcyAoc2Nh bGUgd2UgYWltIGF0IGdpdmVuIG11bHRpLWhvbWVkL292ZXJsYXkgb3JpZ2luYXRpbmcgc2VydmVy cyBjYW4gcnVuIGl0IGFzIHdlbGwpLiBJZiB5b3UgYXNzdW1lIDUgVElFcyBwZXIgZGV2aWNlIHRo YXQncyAyLjVNIFRJRXMgQCB0aGUgdG9wIG9mIHRoZSBmYWJyaWMgKGxhcmdlIGJ1dCBub3QgYSBz Y2FyeSBudW1iZXIgY29tcGFyZWQgdG8gd2hhdCB3ZSBkbyB3aXRoIEJHUCBhbmQgYWRkL3BhdGgg b24gZGFpbHkgYmFzaXMgaW4gd29ybGQncyBtb3N0IHNjYWxhYmxlIGltcGxlbWVudGF0aW9ucyA7 LSkuIElmIHdlJ2QgaGF2ZSBzb21ldGhpbmcgbGlrZSAxaHIgcmVvcmlnaW5hdGlvbiB3ZSB0YWxr Jm5ic3A7IDIuNU0vMjQgPSAxMDBLIHJlLW9yaWdpbmF0aW9ucyBwZXIgaG91ci4gVGhhdCBnaXZl cyB5b3UgYSBmbG9vZGluZyByYXRlIGludG8gVG9GcyBvZiAzMCBUSUVzL3NlYyAoYXNzdW1pbmcg cGVyZmVjdCBmbG9vZCByZWR1Y3Rpb24pLiBBbGwgdGhhdCBkaXNyZWdhcmRpbmcgdGhpbmdzIGxp a2Ugc2VydmVyIHJlYm9vdGluZyBvciBjb250YWluZXIgYXJjaGl0ZWN0dXJlcyB3aGljaCB3aWxs IHBvc3NpYmx5IGluamVjdCBsb3RzIHByZWZpeGVzIG9uIG1vdmVzL2Jvb3RzIGFuZCBzbyBvbi4g U28gcmVmcmVzaCBvZnRlbiBpcyBjaHVybiB0aGF0IGlzIHVubmVjZXNzYXJ5LiBXaXRoIDEgd2Vl ayBsaWZldGltZSB3ZSdyZSB0YWxraW5nIDE1SyBUSUVzIHBlciBob3VyIHJlZnJlc2ggd2hpY2gg aXMgYSBtYW5hZ2VhYmxlIG51bWJlciBnaXZlbiB3ZSdyZSB0YWxraW5nIDAuNU0gZGV2aWNlcy4g PGJyPjwvZGl2Pjxicj48ZGl2Pk9ic2VydmUgaG93ZXZlciB0aGF0IHlvdSBjYW4gaXNzdWUgd2l0 aCBhbnkgbGlmZXRpbWUgeW91IGNob29zZSBhcyBhIGRldmljZSBhbmQgUklGVCB3aWxsIHdvcmsg KGFuZCB3aGVuIGVtcHR5aW5nIFRJRXMgeW91IGFyZSBzdXBwb3NlZCB0byBvcmlnaW5hdGUgd2l0 aCAzMDBzZWNzIG9ubHkpLiBTbyB0aGUgMSB3ZWVrIGlzIGJhc2ljYWxseSBhIHByb3RvY29sIGNv bnN0YW50IHRoYXQgY2FuIGJlIGtub2JiZWQuIDxicj48L2Rpdj48YnI+PGRpdj5MZXQgdXMga25v dyB3aGVuIHlvdSBnb3QgZmlyc3QgcGllY2VzIGludGVyJ29wZWQgd2l0aCBCcnVubydzIG9wZW4g c291cmNlIEJUVy4gVGhpbmdzIGFsd2F5cyBiZWNvbWUgbXVjaCBtb3JlIGNsZWFyIHdoZW4gaW1w bGVtZW50YXRpb25zIGFyZSBiYXNoZWQgYWdhaW5zdCBlYWNoIG90aGVyIDstKTxicj48L2Rpdj48 YnI+PGRpdj4tLS0gdG9ueSA8YnI+PC9kaXY+PGJyPjxicj48YnI+PC9kaXY+PGJyPjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVGh1 LCBPY3QgMjQsIDIwMTkgYXQgMTo1MiBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnh1LmJlbmNob25n QHp0ZS5jb20uY24iIHRhcmdldD0iX2JsYW5rIj54dS5iZW5jaG9uZ0B6dGUuY29tLmNuPC9hPiZn dDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwy MDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2PjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtm b250LWZhbWlseTphcmlhbCI+SGksIFRvbnk8YnI+PC9wPjxwPlRoZXJlIGlzIGEgZGV2aWNlIHJl c3RhcnQgcHJvYmxlbTwvcD48cD5JbiBkcmFmdC1pZXRmLXJpZnQtcmlmdC0wOCBGaWd1cmUgMiwg Ti1USUUgb2YgTGVhZjExMSBmbG9vZGVkIHRvIFRvRjIxIHZpYSBTcGluZTExMS4gU2VxIE5SIG1h eSBiZSBsYXJnZXIuPC9wPjxwPkxlYWYxMTEgcmVzdGFydHMgYW5kIHJlZ2VuZXJhdGVzIE4tVElF LiBUaGUgcmFuZG9tIHNlcSBOUiBtYXkgYmUgc21hbGwsIHNvIHRoYXQgd2hlbiBTcGluZTExMSBy ZWNlaXZlcyBpdCwgaXQgd2lsbCBjb21wYXJlIHRoZSBzZXEgTlIgYW5kIGRpc2NhcmQgdGhlIG5l dyBtZXNzYWdlLjwvcD48cD5BY2NvcmRpbmcgdG8gdGhlIGJlaGF2aW9yIG9mIEFwcGVuZGl4IGMu My40IGIuMywgaXQgaXMgaG9wZWQgdGhhdCBTcGluZTExMSBzZW5kcyBEQlRJRSB0byBMZWFmMTEx IHRvIHVwZGF0ZSBzZXEgTlIuPC9wPjxwPkhvd2V2ZXIsIGFjY29yZGluZyB0byB0aGUgZmxvb2Rp bmcgcmFuZ2Ugb2YgTi1USUUsIHRoaXMgbWVzc2FnZSBjYW5ub3QgYmUgc2VudCBvdXQuPC9wPjxw PkluIHRoaXMgd2F5LCB0aGVyZSB3aWxsIGJlIGEgbGFyZ2UgbnVtYmVyIG9mIGludmFsaWQgTi1U SUVzIGluIHRoZSBuZXR3b3JrIGZvciBhIGxvbmcgdGltZSAodGhlIGRlZmF1bHQgZXhwaXJlIHRp bWUgb2YgdGhlIHByb3RvY29sIGlzIDEgd2Vlayk8L3A+PHA+SXMgdGhpcyB1bmRlcnN0YW5kaW5n IGNvcnJlY3Q/IEhvdyBkb2VzIHJpZnQgc29sdmUgdGhpcyBwcm9ibGVtPzwvcD48cD48YnI+PC9w PjxwPlRoYW5rIHlvdSE8L3A+PHA+QmVuY2hvbmc8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4 O2ZvbnQtZmFtaWx5OmFyaWFsIj48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250 LWZhbWlseTphcmlhbCI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1p bHk6YXJpYWwiPjxicj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwPjxicj48L3A+PC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Fri Oct 25 14:14:44 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 98BB6120815; Fri, 25 Oct 2019 14:12:07 -0700 (PDT) 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.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203792762.2724.10406535494323316807.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:07 -0700 Archived-At: Subject: [Rift] rift - Requested session has been scheduled for IETF 106 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, 25 Oct 2019 21:12:13 -0000 Dear Jeff Tantsura, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rift Session 1 (1:30 requested) Thursday, 21 November 2019, Afternoon Session I 1330-1530 Room Name: Olivia size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/rift.ics Request Information: --------------------------------------------------------- Working Group Name: Routing In Fat Trees Area Name: Routing Area Session Requester: Jeff Tantsura Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: Chair Conflict: rtgwg Technology Overlap: lsr idr spring bier lsvr Key Participant Conflict: bess teas bfd mpls pce People who must be present: Alvaro Retana Zhaohui (Jeffrey) Zhang Jeff Tantsura Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 28 07:27:55 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 EAE42120897 for ; Mon, 28 Oct 2019 07:27:52 -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_HELO_NONE=0.001, 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 R2zh7akJpUcQ for ; Mon, 28 Oct 2019 07:27:50 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 137C912088E for ; Mon, 28 Oct 2019 07:27:50 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id c6so10850507ioo.13 for ; Mon, 28 Oct 2019 07:27: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=GOWj4u2FXpKdsOUqPXhBlq+p7T1QvL+yjtTuhx8N6dc=; b=hx6Sddm7XUta3xu0LFMD4gx3Qn8v/3kjdQMdZMo9fdMH9ZsNyMBTv6Nvqlz/Lm1V/V opZO0WBMrojcnU8xPziOQ35Xd/1miEh4srvFXmAnr9D/gU5XDXypkROMUYZYYlyYFlPf zEDwzllde0TL2E/jP0yOCBP+rXKLPl21BWZbw0Rx8Tmsx1BGgHzgpt07s1GvPXFMzrE/ w1jhLRyFJQbU36bX6LQX8n9TrBtAjtMgS7wsl7PH8Di9dejeon3S0f78Yb2xoO5v/FFt bMRR5TG14G1FlOCAm1Mgb1CWIt/D3ey8xo1+l/9WFQbCLzT8Q9////2Ixm7+5ZXKWd0Z L/mQ== 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=GOWj4u2FXpKdsOUqPXhBlq+p7T1QvL+yjtTuhx8N6dc=; b=KpT0hE1niECyNUJ4m6A6p1MWrf92MZ45+D+cnNdBjMp2+96ppdhgaXIuQ+BntXwWnN PwqhgcjXegNh0HuRT4HYycaX8iH9vFZAMR7jL6yaISNpioFiRI3FvuiuQBvT4filuJyJ XdWy1eXfUONESGSk5yHS/fUZZo7IYLFJRCQnGZ96KspqAsY5yjCJbkJB+czjIl5xYXZt hN9SYTMxfHLjHx/cLxowiLsWN1MTQjQRDJWkXTIBSIXgFeM/h4nNoAFnwdKQs4SkwlCA eLKo98tsZPP7Ob46m3AY37tYY/r0c1Kj4wQtFJtHHehz3dNZpw8RLh6qDBf2s2PKu+F3 ODYQ== X-Gm-Message-State: APjAAAVYJzlFhk66vh9xujCbdPrEVheRbHjKsWbU69a2VVI7hLJAH1Jz hyKMMRtHHnw5SOoYQcmael3CBWeflUBEDhVBc29MXVXyXoM= X-Google-Smtp-Source: APXvYqzCncHKKKGcPwlEPu6d42VZVFsBozqlQVe1zoTMi63LQaSNXQ/7cYlobxrR5eqi0kuWrjdgT+gLJcLXsdrOB20= X-Received: by 2002:a6b:fb0c:: with SMTP id h12mr10804108iog.239.1572272869021; Mon, 28 Oct 2019 07:27:49 -0700 (PDT) MIME-Version: 1.0 References: <201910251543067579596@zte.com.cn> In-Reply-To: <201910251543067579596@zte.com.cn> From: Tony Przygienda Date: Mon, 28 Oct 2019 07:27:03 -0700 Message-ID: To: xu.benchong@zte.com.cn Cc: rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000d929350595f94dfa" Archived-At: Subject: Re: [Rift] Device restart problem 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, 28 Oct 2019 14:27:53 -0000 --000000000000d929350595f94dfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable TIDEs are never flooded, each node constructs them independently from the database. Yes, what you say is related to the 2nd onion somewhat but only an aspect of it. When you implement flood procedures carefully and start to test it will become clear what C.3.2.2.6.I.i) is necessary for. Great you're getting there. Let us know when you want to hook up and any help though Bruno's descriptions are very detailed and well debugged given quite a lot of people were using the stuff already including, from what I heard, running it on couple of Linux NOSes. --- tony On Fri, Oct 25, 2019 at 12:44 AM wrote: > > Hi,tony > > Thanks for your reply. > > When Leaf111 and Spine111 (assuming no other spines) are restarted at the > same time, Spine111 can=E2=80=99t flood the received TIDE of ToF21 to Lea= f111, and > Seq NR can=E2=80=99t be updated -- Is this the second layer of onion;-) > > Can we update the lifetime of the tie by tide to avoid sending tie period= ? > > We are developing a verification implementation, and have not yet connect > with Bruno's. > > > Benchong > > > =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A*TonyPrzygienda > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A*=E5=BE=90=E6=9C=AC=E5=B4=8710065053= ; > *=E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9A*rift@ietf.org ; > *=E6=97=A5 =E6=9C=9F =EF=BC=9A*2019=E5=B9=B410=E6=9C=8824=E6=97=A5 23:59 > *=E4=B8=BB =E9=A2=98 =EF=BC=9A**Re: Device restart problem* > hey xu, I see deeper and deepr into implementation, you just found first > layer of the onion here BTW ;-) The seqnr# handling is since times > immemorial one of the trickier parts of IGP implementation (but not only, > same problems exists in other places but there, the information is not > persistent so problem is not as pressing). > > Multiple mechanisms kick in here > > a) the seqnr# is circular which is a very important piece of the puzzle. > you cannot generate a "biggest" number no'one can override. math explaine= d > in appendix in lots detail. BTW, not my invention, smarter people than me > worked stuff out long time ago but there was never a full, detailed, easy > to implement writedown AFAIK. > b) yes, the fact that we flood only northbound prevents via normal "flat > flooding" Leaf111 "getting" its old TIE with a higher sequence number. > Using flat flooding south would of course kill largely the scalability of > the protocol and make it equivalent to OSPF or ISIS or any other "normal= " > link-state approach in terms of flooding complexity (well, flood reductio= n > would still work ;-) > c) However, observe that Table 3 holds the key to the solution. TIDE/Sout= h > tells you what you need to do to describe your database to the neighbor > south. The description from Spine111 includes the description of N-TIEs o= f > Leaf111 and with that Leaf111 can realize that there is a stale N-TIE it > originated before reboot and re-issue with a higher sequence number (that= 's > where a] comes into play) > > When you keep on implementing and testing you'll find another very > interesting, far more complex case that we solved but I will keep the > suspension going ;-) > > The observation on the one week is also correct. Done very purposefully. > Let's say RIFT runs on 0.5M devices (scale we aim at given > multi-homed/overlay originating servers can run it as well). If you assum= e > 5 TIEs per device that's 2.5M TIEs @ the top of the fabric (large but not= a > scary number compared to what we do with BGP and add/path on daily basis = in > world's most scalable implementations ;-). If we'd have something like 1h= r > reorigination we talk 2.5M/24 =3D 100K re-originations per hour. That gi= ves > you a flooding rate into ToFs of 30 TIEs/sec (assuming perfect flood > reduction). All that disregarding things like server rebooting or contain= er > architectures which will possibly inject lots prefixes on moves/boots and > so on. So refresh often is churn that is unnecessary. With 1 week lifetim= e > we're talking 15K TIEs per hour refresh which is a manageable number give= n > we're talking 0.5M devices. > > Observe however that you can issue with any lifetime you choose as a > device and RIFT will work (and when emptying TIEs you are supposed to > originate with 300secs only). So the 1 week is basically a protocol > constant that can be knobbed. > > Let us know when you got first pieces inter'oped with Bruno's open source > BTW. Things always become much more clear when implementations are bashed > against each other ;-) > > --- tony > > > > > On Thu, Oct 24, 2019 at 1:52 AM wrote: > >> Hi, Tony >> >> There is a device restart problem >> >> In draft-ietf-rift-rift-08 Figure 2, N-TIE of Leaf111 flooded to ToF21 >> via Spine111. Seq NR may be larger. >> >> Leaf111 restarts and regenerates N-TIE. The random seq NR may be small, >> so that when Spine111 receives it, it will compare the seq NR and discar= d >> the new message. >> >> According to the behavior of Appendix c.3.4 b.3, it is hoped that >> Spine111 sends DBTIE to Leaf111 to update seq NR. >> >> However, according to the flooding range of N-TIE, this message cannot b= e >> sent out. >> >> In this way, there will be a large number of invalid N-TIEs in the >> network for a long time (the default expire time of the protocol is 1 we= ek) >> >> Is this understanding correct? How does rift solve this problem? >> >> >> Thank you! >> >> Benchong >> >> >> >> >> > --000000000000d929350595f94dfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TIDEs are never flooded, each node constructs them in= dependently from the database.

Yes, what you = say is related to the 2nd onion somewhat but only an aspect of it. When you= implement flood procedures carefully and start to test it will become clea= r what 
C.3.2.2.6.I.i)

is necessary for. 

=

Great you're getting there. Let us know when you want to hoo=
k up and any help though Bruno's descriptions are very detailed and wel=
l 
debugged given quite a lot of people were using the stuff already inc=
luding, from what I heard, running it on couple of Linux NOSes. 

--- tony


<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 25, 2019 at 12:44 AM <<= a href=3D"mailto:xu.benchong@zte.com.cn">xu.benchong@zte.com.cn> wro= te:


Hi,tony

Thanks for = your reply.

When Leaf111 and Spine111 (assuming no other spines) are = restarted at the same time, Spine111 can=E2=80=99t flood the received TIDE = of ToF21 to Leaf111, and Seq NR can=E2=80=99t be updated -- Is this the sec= ond layer of onion;-)

Can we update the lifetime of the tie by tide t= o avoid sending tie period?

We are developing a verification implemen= tation, and have not yet connect with Bruno's.


Benchong


=E5=8E=9F=E5=A7=8B=E9=82=AE= =E4=BB=B6
<= strong>=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ATonyPrzygienda &l= t;tonysietf@gmail.= com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A=E5=BE=90=E6=9C=AC=E5=B4=8710065053;<= /span>
=E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Arift@ietf.org <= rift@ietf.org>;
=E6=97=A5 =E6=9C=9F =EF=BC= =9A2019=E5=B9=B410=E6=9C=8824=E6=97=A5 23:59
=E4=B8=BB =E9=A2=98 =EF=BC=9ARe: Device re= start problem
he= y xu, I see deeper and deepr into implementation, you just found first laye= r of the onion here BTW ;-)=C2=A0 The seqnr# handling is since times immemo= rial one of the trickier parts of IGP implementation (but not only, same pr= oblems exists in=C2=A0 other places but there, the information is not persi= stent so problem is not as pressing).

Multiple mechanism= s kick in here

a) the seqnr# is circular which is a very impo= rtant piece of the puzzle. you cannot generate a "biggest" number= no'one can override. math explained in appendix in lots detail. BTW, n= ot my invention, smarter people than me worked stuff out long time ago but = there was never a full, detailed, easy to implement writedown AFAIK.
b) yes, the fact that we flood only northbound prevents via normal= "flat flooding"=C2=A0 Leaf111 "getting" its old TIE wi= th a higher sequence number. Using flat flooding south would of course kill= largely the scalability of the protocol and make it equivalent to OSPF or = ISIS=C2=A0 or any other "normal" link-state approach in terms of = flooding complexity (well, flood reduction would still work ;-)
c= ) However, observe that Table 3 holds the key to the solution. TIDE/South t= ells you what you need to do to describe your database to the neighbor sout= h. The description from Spine111 includes the description of N-TIEs of Leaf= 111 and with that Leaf111 can realize that there is a stale N-TIE it origin= ated before reboot and re-issue with a higher sequence number (that's w= here a] comes into play)

When you keep on implementing a= nd testing you'll find another very interesting, far more complex case = that we solved but I will keep the suspension going ;-)

T= he observation on the one week is also correct. Done very purposefully. Let= 's say RIFT runs on 0.5M devices (scale we aim at given multi-homed/ove= rlay originating servers can run it as well). If you assume 5 TIEs per devi= ce that's 2.5M TIEs @ the top of the fabric (large but not a scary numb= er compared to what we do with BGP and add/path on daily basis in world'= ;s most scalable implementations ;-). If we'd have something like 1hr r= eorigination we talk=C2=A0 2.5M/24 =3D 100K re-originations per hour. That = gives you a flooding rate into ToFs of 30 TIEs/sec (assuming perfect flood = reduction). All that disregarding things like server rebooting or container= architectures which will possibly inject lots prefixes on moves/boots and = so on. So refresh often is churn that is unnecessary. With 1 week lifetime = we're talking 15K TIEs per hour refresh which is a manageable number gi= ven we're talking 0.5M devices.

Observe however that= you can issue with any lifetime you choose as a device and RIFT will work = (and when emptying TIEs you are supposed to originate with 300secs only). S= o the 1 week is basically a protocol constant that can be knobbed.

Let us know when you got first pieces inter'oped with Bruno&= #39;s open source BTW. Things always become much more clear when implementa= tions are bashed against each other ;-)

--- tony




On Thu, Oct 24, 2019 at 1:52 AM <xu.benchong@zte.com.cn> wrote:<= br>

Hi, Tony

There is a device res= tart problem

In draft-ietf-rift-rift-08 Figure 2, N-TIE of Leaf111 fl= ooded to ToF21 via Spine111. Seq NR may be larger.

Leaf111 restarts a= nd regenerates N-TIE. The random seq NR may be small, so that when Spine111= receives it, it will compare the seq NR and discard the new message.

According to the behavior of Appendix c.3.4 b.3, it is hoped that Spine111= sends DBTIE to Leaf111 to update seq NR.

However, according to the f= looding range of N-TIE, this message cannot be sent out.

In this way,= there will be a large number of invalid N-TIEs in the network for a long t= ime (the default expire time of the protocol is 1 week)

Is this under= standing correct? How does rift solve this problem?


Thank = you!

Benchong





--000000000000d929350595f94dfa-- From nobody Mon Oct 28 11:59:25 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 04B1412094B; Mon, 28 Oct 2019 11:59:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-rift-rift.all@ietf.org, rift@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <157228915192.16080.15649375711620871809@ietfa.amsl.com> Date: Mon, 28 Oct 2019 11:59:12 -0700 Archived-At: Subject: [Rift] Genart early review of draft-ietf-rift-rift-08 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, 28 Oct 2019 18:59:20 -0000 Reviewer: Robert Sparks Review result: Not Ready Summary: Not ready for publication as a Proposed Standard I found this document very difficult to read. On my first past through, I was fairly certain it didn't specify the protocol well enough to actually implement it, until I got deep into the appendices. Even after a second pass, I am not comfortable that a implementation could be produced without having guess at some behavior, which will lead to interoperability problems. I strongly suggest restructuring the draft to pull the actual definition of the protocol from the appendix and into the early part of the document text. You may also want to use the new v3 format so that you can take advantage of its support for SVG to help convey your state diagrams. At the very least, the document needs a strong editorial scrub. There are many sentences that are missing important articles. There are many sentences that are very complex and would be better written as two or three sentences. There are many sections that too deeply assume the reader already understands the problem space. In the remainder of the review, I'm not going to call out each overly-complex sentence individually, but will attempt to point at a few that also had other issues. Some high-level points before going into a document-order set of comments: ** The IANA considerations section does not provide a clear set of instructions for IANA to follow. * The notion of a "three-way adjacency" is not made clear in the document. It really takes looking at a rendering of the dot for the state machines before this term becomes well-defined. * There are a few places where there are internal references in the document that are not clear. These center around the word "Paragraph". For instance, in Req4, there is a reference to "Paragraph 17". Does that mean "Req 17"? * K_LEAF suddently appears without support or definition in 5.1.2. That and the other K_ terms should be discussed in the terminology section. * It's unclear whether HH symbol means one or two RJ45 jacks. The diagrams appear to use the symbol inconsistently. === Issues in document order === In the introduction: "The incumbent protocols precondition normally extensive configuration or provisioning during bring up and re-dimensioning which is only viable for a set of organizations with according networking operations skills and budgets." did not parse for me until my second read-through, where I realized "precondition normally" was intended to mean "normally require". "bring up" and "re-dimensioning" are almost jargon in this context. In the Terminology section: It would be good to introduce S-TIE and N-TIE as top level terms in this section. The words for Adjacency are not really a definition, but taken as such they are circular. The definition for Metric is not useful. In the first paragraph of 5.1.1, The construction of 'never ... (we'll talk about exceptions later)' is awkward. It's also unclear where the the "later" is pointing. The last sentence is grammatically incorrect ("We omit ... out"), and talks of omimitting discussion "for the moment". Please make it clear where you return to the discussion. The third paragraph of 5.1.2 does not parse. I suspect there is a missing word somewhere in "the introduced Section 3.1". The nested numbered lists in section 5.2.3.9 are perhaps not the best tool for describing the algorithms you want to convey. On page 46, steps 4.3.3 and 4.4 are comments, not actions. Numbering them as you number actions is confusing. The last Step 7 in section 5.2.3.9 speaks of "sine flooding reduction". What is that? The reference in 5.2.7.2's first paragraph to [EUI64] looks like a normative reference to me. Something is wrong at the bottom of page 68. One branch of the sentence reduces to "we have to decide whether node Y is ... at the same level as Y". In 5.3.4.1 rule 1, you only consider nodes to which the reciever has a bi-directional adjacency. As opposed to what? Does this mean adjacencies in TwoWay or ThreeWay state? Or something else? There is a dangling reference to [PGP reference] at the end of 5.3.11. Section 7.3 is really not useful for the protocol specification. Consider removing it. In section 8.4 the sentence "The attack vector packet number present is relatively benign." does not parse. It's particularly unclear what you are trying to achive with the "DirectionMaxValue" registry entry defined in 9.2.11.1 Are you trying to say the registry is not allowed any more values? If so, just say that in the instructions to IANA. I don't see where the codepoint is used by the protocol, so I suggest it not be added to the registry. It's a leap to get from the description of Sequence Number Binary Arithmetic in Appendix A to the "rollover" mechanic the paragraphs that reference Appendix A are looking for. Please clarify. Also in Appendix A, I question the sentence "The >: relationship is symmetric but not transitive". Symmetric says "if A>:B then B>:A". === Nits === The document has many lines that exceed the maximum line width for txt formatted RFCs. The definition section uses terms before it defines them. For those that are acronyms (see the first use of PoD and ZTP for example) an expansion would help. The short-hand "E-W" isn't saving much over "East-West" and the latter would be much clearer in the terminology section. In section 3.2 at " We will use topology in Figure 2 (called commonly a fat tree/network in modern IP fabric considerations [VAHDAT08] as homonym to the original definition of the term [FATTREE]) in all further considerations.". This would better be conveyed as two seperate sentences. I don't think "homonym" (same spelling or pronunciation, but different meanings) is really the word you are looking for. On page 17, you have a block labelled "Following list represents non-requirements", followed by a single PEND requirement, and then "Finally, following are the non-requirements" before the NONREQs. The description of the first block is incorrect? The last sentence in the paragraph immediately following Figure 10 has no verb. The second paragraph after Figure 10 includes a sentence that begins "If proves convenient". I suspect it meant to be "It proves convenient" In section 5.2.2 the phrase "if a link has entered three way IPv4 and/or IPv6 with a neighbor on an adjacency" should be reconstructed. I _think_ you mean has an adjacency with a neighbor that is in the three-way state"? In section 5.2.3.5, the pronouns in "It should only set it" can become confused.Please rework the sentence to avoid the pronouns. There is a stray double-quote at the end of the first sentence in 5.2.7.2 At 5.2.8 "(with some finer distinctions not explained further)" adds no useful information to the document. Please remove it. At section 6.1, please explicitly point to figure 2 when mentioning the example topology. The term "ToRs" appears without definition or reference at section 7.1 From nobody Mon Oct 28 13:52:51 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 C407E120086; Mon, 28 Oct 2019 13:52:49 -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_HELO_NONE=0.001, 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 HhGuyvbfkqZR; Mon, 28 Oct 2019 13:52:46 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 E0B55120024; Mon, 28 Oct 2019 13:52:45 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id t5so9406345ilh.10; Mon, 28 Oct 2019 13:52:45 -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=eiN7bmnbXCNPgfqzVcmezdMiWtw5LXvbHedVneL6nnM=; b=QHZxOeGmkQGKnZMJGGiebv05kq2QlzD+zFs1WTzxQ65egi1X82LJoHORzLK9Tbu8t3 mJCVNEPhyoQWf2qC4tnVYwK1gPjYOjDH4miU4/zS28b0x4V4bpiKDipG4c0VUS+yZjQ+ nssYUeTtf8ZpBAxNN7G7KV3A0b7Mo38AwWFt87CtPisihThG0OOJxyRyAyJyAsxc4XJe nIWNsjU9G/l7yo5MoY6G4H+fyKSNOlKyWKkVda4A93FQkbbA+ehNn9T9p7gP6A0GLaCn 810QIAc7hHxN8tmtYneUoYdD1TZV4T1+/gwzwvIcsyzCObx/VrQdWTnN8II9XGAyMulK oDkA== 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=eiN7bmnbXCNPgfqzVcmezdMiWtw5LXvbHedVneL6nnM=; b=YUON63PbSzxJ7Dy5eRWHXCsWEh89B0GBBCpJiEUSg880/Cc7bfKzPNqkZhkB/bpIfp kpZAYqLkmoZe8eAsaveV9AvXfse7bHcUWrl3rZCLIV9Gj3jGdvUT08DKm7xyLxy6EnEn z05NTYNTsrRaX5+pACJwuw7aUFBDX6NU2w2vDvJwDL8FwOrXNcdUHrcAwpptib817BUP ZTkUFVPJEBV1zjDUIN7mdDpuQX8Yn04aCm49XCE97vjZy4sLkVk/VgQLkGtj4KIk9dC2 kSGy4RZt6aEElhtKR4GvsxUGwMDQ3JMqq+uhDf1CAItaCmBKqwf7bzKTLV4D43+y+Lpi cRiA== X-Gm-Message-State: APjAAAURoh1ZwWiwSFltfFGoHHYHQ1p+MK5U3viZfjLNd9VwNYt+bTcv PgxabP/G1gVioASBW0dK6PNFInHQJJkaZs66G7sCkXX/B5w= X-Google-Smtp-Source: APXvYqyc7MYeuIf1IN3UaIi9YaLUWj4bLURaaN3RH0YMddtw2kJH7ZWhKUQCX/EETOnOygIAiq28m8znPyzmJ+KqYAg= X-Received: by 2002:a92:1948:: with SMTP id e8mr2613643ilm.302.1572295964978; Mon, 28 Oct 2019 13:52:44 -0700 (PDT) MIME-Version: 1.0 References: <157228915192.16080.15649375711620871809@ietfa.amsl.com> In-Reply-To: <157228915192.16080.15649375711620871809@ietfa.amsl.com> From: Tony Przygienda Date: Mon, 28 Oct 2019 13:51:58 -0700 Message-ID: To: Robert Sparks Cc: gen-art@ietf.org, draft-ietf-rift-rift.all@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="0000000000007975600595feaeb3" Archived-At: Subject: Re: [Rift] Genart early review of draft-ietf-rift-rift-08 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, 28 Oct 2019 20:52:50 -0000 --0000000000007975600595feaeb3 Content-Type: text/plain; charset="UTF-8" Robert, reacting as editor here thanks for your detailed review, answers inline I'm raising couple questions myself in the answers, if you'd care to clarify those further I can try to make the draft cut-off for an updated version On Mon, Oct 28, 2019 at 12:00 PM Robert Sparks via Datatracker < noreply@ietf.org> wrote: > Reviewer: Robert Sparks > Review result: Not Ready > > Summary: Not ready for publication as a Proposed Standard > > I found this document very difficult to read. On my first past through, I > was > fairly certain it didn't specify the protocol well enough to actually > implement > it, until I got deep into the appendices. Even after a second pass, I am > not > comfortable that a implementation could be produced without having guess at > some behavior, which will lead to interoperability problems. > > I strongly suggest restructuring the draft to pull the actual definition > of the > protocol from the appendix and into the early part of the document text. > You > may also want to use the new v3 format so that you can take advantage of > its > support for SVG to help convey your state diagrams. > As first observation, we have two interoperable implementations since a bit, one completely open source which has been produced based on the spec. It was in fact open source work that helped to refine the document content to make sure we can have an implementation produced based on the text without further "guessing things". As example the LIE FSM has been implemented initially in open source without consulting authors of the spec and interoperat'ed without a single defect (but discovered a protocol underspecification in case of misconfiguration that was subsequently added). Please refer to IETF proceedings for the according presentations if necessary. We have a third implemenation progressing now where all questions the implementor asked so far could be answered by pointing directly @ the specification as written. This seems to answer to me the "suspicion of specification maybe not being good enough to implement" as an objective measuring stick as far I can imagine one. As second observation regarding your comments, the majority of readers seemed to prefer a format where the protocol is "described" in narrative and the tight procedure appendices are left to people implementing the protocol but I have no issue to pull the appendices directly into the document under the according sections. I would simply add something along the lines of "this section of interest to a reader implementing the spec". I will try the v3 format again but last time we tried couple months ago it wasn't workable. I see first RFC havs been just published using it (albeit I don't see it using any drawings). > > At the very least, the document needs a strong editorial scrub. There are > many > sentences that are missing important articles. There are many sentences > that > are very complex and would be better written as two or three sentences. > There > are many sections that too deeply assume the reader already understands the > problem space. > Point taken and a scrub will be performed along the lines you suggest. > > In the remainder of the review, I'm not going to call out each > overly-complex > sentence individually, but will attempt to point at a few that also had > other > issues. > yes, thank you. that should suffice for a scrub. > > Some high-level points before going into a document-order set of comments: > > ** The IANA considerations section does not provide a clear set of > instructions > for IANA to follow. > Ok, could you be a little bit more specific 9.1. Requested Multicast and Port Numbers seems to describe the allocation points and registries. 9.2. Requested Registries with Suggested Values requests new registries with pre-allocated entries, maybe it's not clear that each subsection is a new registry? I can point that out. > * The notion of a "three-way adjacency" is not made clear in the document. > It > really takes looking at a rendering of the dot for the state machines > before > this term becomes well-defined. > good catch, will be pulled up into "terminology" section and defined. > > * There are a few places where there are internal references in the > document > that are not clear. These center around the word "Paragraph". For > instance, in > Req4, there is a reference to "Paragraph 17". Does that mean "Req 17"? > anomaly of rfc2txt, when referencing a list no matter what the prefix it will always generate "paragraph" in the reference. I will see how I can fix that. > > * K_LEAF suddently appears without support or definition in 5.1.2. That and > the other K_ terms should be discussed in the terminology section. > the section 5.1.2. was written more as a narrative but no problem, I will add a special terminology section and define the variables. > > * It's unclear whether HH symbol means one or two RJ45 jacks. The diagrams > appear to use the symbol inconsistently. > The document says verbatim *"we have chosen to use the "HH" symbol as ASCII visualisation of a RJ45 jack." *I will add "single" to it. Figure 9 may cause confusing since a single H is used to visualize the jack. I also see possible inconsistency in Figure 13, will correct, probably replacing the "HH" with "X" > > > === Issues in document order === > > In the introduction: > > "The incumbent protocols precondition normally extensive configuration or > provisioning during bring up and re-dimensioning which is only viable for > a set > of organizations with according networking operations skills and budgets." > did > not parse for me until my second read-through, where I realized > "precondition > normally" was intended to mean "normally require". "bring up" and > "re-dimensioning" are almost jargon in this context. > will try to simplify language where it looks possible. > > In the Terminology section: > > It would be good to introduce S-TIE and N-TIE as top level terms in this > section. > terminology section already says: TIE: This is an acronym for a "Topology Information Element". TIEs are exchanged between RIFT nodes to describe parts of a network such as links and address prefixes, in a fashion similar to ISIS LSPs or OSPF LSAs. *We will talk about N-TIEs when talking about TIEs in the northbound representation and S-TIEs for the southbound equivalent.* but sure, I will break that out and define more explicitly > The words for Adjacency are not really a definition, but taken as such > they are > circular. > correct, we failed to root the defintions of interface/link/adjacency since in p2p link-state protocols they are pretty much equivalent (modulo tunnels). suggestions? I'll introduce 3-way as clear defintion and define adjacency as "3-way state on a link" > > The definition for Metric is not useful. > ok, will be removed > In the first paragraph of 5.1.1, The construction of 'never ... (we'll talk > about exceptions later)' is awkward. It's also unclear where the the > "later" is > pointing. The last sentence is grammatically incorrect ("We omit ... > out"), and > talks of omimitting discussion "for the moment". Please make it clear > where you > return to the discussion. > ok, I'll list the exceptions in detail here > The third paragraph of 5.1.2 does not parse. I suspect there is a missing > word > somewhere in "the introduced Section 3.1". > word missing > > The nested numbered lists in section 5.2.3.9 are perhaps not the best tool > for > describing the algorithms you want to convey. On page 46, steps 4.3.3 and > 4.4 > are comments, not actions. Numbering them as you number actions is > confusing. > any better suggestions? (I will move from numbering to number.latin.other and so on). This is an old technique in protocol specs to allow implementors to discuss very, very precise statement and their meaning (e.g. ISIS spec is all written like that). Otherwise people start to talk about "4th line in the algorithm X" which is far more confusing. rfc2txt does not have a mechanism to "skip numbering for this item" when genreeating lists unless I'm oblivious to it so I'm limited by the tools IETF provides to render documents. > > The last Step 7 in section 5.2.3.9 speaks of "sine flooding reduction". > What is > that? > some editorial slip on find/replace I assume, was "such" AFAIR, seems slipped -04 or -05. missed by good amount of readers ;-) > > The reference in 5.2.7.2's first paragraph to [EUI64] looks like a > normative > reference to me. > I wasn't sure since the EUI64 is kind of a "side implementation note in IEEE". Can move to normative. > > Something is wrong at the bottom of page 68. One branch of the sentence > reduces > to "we have to decide whether node Y is ... at the same level as Y". > correct, sentence is illogical. I will correct > > In 5.3.4.1 rule 1, you only consider nodes to which the reciever has a > bi-directional adjacency. As opposed to what? Does this mean adjacencies in > TwoWay or ThreeWay state? Or something else? > I will define "bi-directional adjacency", it cannot hurt. But the term is kind of well understood by anyone who implemented OSPF/ISIS or is intimately familiar with the specs normally. > > There is a dangling reference to [PGP reference] at the end of 5.3.11. > slipped. PGP has been folded out the main document and this got missed. I probably remove the reference since we cannot publish standard with reference to a draft while PGP work is going slowly. > > Section 7.3 is really not useful for the protocol specification. Consider > removing it. > This question/observation/doubt was coming up many, many times and that's why the document introduced this section. I prefer to retain it to prevent the question being asked over and over again on the reading of the spec. > In section 8.4 the sentence "The attack vector packet number present is > relatively benign." does not parse. > yes > > It's particularly unclear what you are trying to achive with the > "DirectionMaxValue" registry entry defined in 9.2.11.1 Are you trying to > say > the registry is not allowed any more values? If so, just say that in the > instructions to IANA. I don't see where the codepoint is used by the > protocol, > so I suggest it not be added to the registry. > implementation specific basically. Can be removed but allows in implementation to use the codepoint to scale arrays for example. If the registry takes DirectionMaxValue for e.g. version 3.0 schema this value could move. Alternately we could split a registry _per schema version_ but that seems a huge proliferation and replication. I'm agnostic either way and would like to hear an opinion here > > It's a leap to get from the description of Sequence Number Binary > Arithmetic in > Appendix A to the "rollover" mechanic the paragraphs that reference > Appendix A > are looking for. Please clarify. > ok, will explain rollover in relation to Appendix albeit it's a well-known technique since many years in link-state protocols (explained e.g. in depth in John Moy's book) though lacking a rigorous implementation description such as Appendix A provides. > > Also in Appendix A, I question the sentence "The >: relationship is > symmetric > but not transitive". Symmetric says "if A>:B then B>:A". > yes, symmetric means "if A>:B then B>:A" precisely what you say and the relation holds. non transitive means obviously that A>:B and B>:C does NOT imply A>:C Obvious example of the 3-bit arithmetic is 4 >: 2 & 2 >: 0 does NOT follow in 4 >: 0 That seems quite clear to me so I don't see easily what you question unless you care to explain more. > > === Nits === > > The document has many lines that exceed the maximum line width for txt > formatted RFCs. > ack, will correct > > The definition section uses terms before it defines them. For those that > are > acronyms (see the first use of PoD and ZTP for example) an expansion would > help. The short-hand "E-W" isn't saving much over "East-West" and the > latter > would be much clearer in the terminology section. > will correct > > In section 3.2 at " We will use topology in Figure 2 (called commonly a fat > tree/network in modern IP fabric considerations [VAHDAT08] as homonym to > the > original definition of the term [FATTREE]) in all further considerations.". > This would better be conveyed as two seperate sentences. I don't think > "homonym" (same spelling or pronunciation, but different meanings) is > really > the word you are looking for. > "homonym" is precisely what is meant hear, the term has been overloaded to mean two different things over time. Will split into shorter sentences. > > On page 17, you have a block labelled "Following list represents > non-requirements", followed by a single PEND requirement, and then > "Finally, > following are the non-requirements" before the NONREQs. The description of > the > first block is incorrect? > yes, sorry, slipped. we had pending? requirements which slid into non requirements or has been removed. this one is a left over. > The last sentence in the paragraph immediately following Figure 10 has no > verb. > correct, thanks > The second paragraph after Figure 10 includes a sentence that begins "If > proves > convenient". I suspect it meant to be "It proves convenient" > correct > In section 5.2.2 the phrase "if a link has entered three way IPv4 and/or > IPv6 > with a neighbor on an adjacency" should be reconstructed. I _think_ you > mean > has an adjacency with a neighbor that is in the three-way state"? > yes, should clarify via crisp definition of 3-way. > > In section 5.2.3.5, the pronouns in "It should only set it" can become > confused.Please rework the sentence to avoid the pronouns. > ack > > There is a stray double-quote at the end of the first sentence in 5.2.7.2 > ack > > At 5.2.8 "(with some finer distinctions not explained further)" adds no > useful > information to the document. Please remove it. > ack > > At section 6.1, please explicitly point to figure 2 when mentioning the > example > topology. > ack > > The term "ToRs" appears without definition or reference at section 7.1 > ack --0000000000007975600595feaeb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Robert, reacting as editor here
<= /div>

thanks for your detailed review, answers inline

I'm raising couple questions myself in the answe= rs, if you'd care to clarify those further I can try to make the
draft cut-off for an updated version

On Mon, Oct 28, 2019= at 12:00 PM Robert Sparks via Datatracker <noreply@ietf.org> wrote:
Reviewer: Robert Sparks
Review result: Not Ready

Summary: Not ready for publication as a Proposed Standard

I found this document very difficult to read. On my first past through, I w= as
fairly certain it didn't specify the protocol well enough to actually i= mplement
it, until I got deep into the appendices. Even after a second pass, I am no= t
comfortable that a implementation could be produced without having guess at=
some behavior, which will lead to interoperability problems.

I strongly suggest restructuring the draft to pull the actual definition of= the
protocol from the appendix and into the early part of the document text. Yo= u
may also want to use the new v3 format so that you can take advantage of it= s
support for SVG to help convey your state diagrams.
As first observation, we have two interoperable implementation= s since a bit, one completely open source which has been produced based on = the spec. It was in fact open source work that helped to refine the documen= t content to make sure we can have an implementation produced based on the = text without further "guessing things". As example the LIE FSM ha= s been implemented initially in open source without consulting authors of t= he spec and interoperat'ed without a single defect (but discovered a pr= otocol underspecification in case of misconfiguration that was subsequently= added). Please refer to IETF proceedings for the according presentations i= f necessary. We have a third implemenation progressing now where all questi= ons the implementor asked so far could be answered by pointing directly @= =C2=A0 the specification as written. This seems to answer to me the "s= uspicion of specification maybe not being good enough to implement" as= an objective measuring stick as far I can imagine one.

=
As second observation regarding your comments, the majority of r= eaders seemed to prefer a format where the protocol is "described"= ; in narrative and the tight procedure appendices are left to people implem= enting the protocol but I have no issue to pull the appendices directly int= o the document under the according sections. I would simply add something a= long the lines of "this section of interest to a reader implementing t= he spec".

I will try the v3 format again= but last time we tried couple months ago it wasn't workable. I see fir= st RFC havs been just published using it (albeit I don't see it using a= ny drawings).
=C2=A0

At the very least, the document needs a strong editorial scrub. There are m= any
sentences that are missing important articles. There are many sentences tha= t
are very complex and would be better written as two or three sentences. The= re
are many sections that too deeply assume the reader already understands the=
problem space.

Point taken and a scrub = will be performed along the lines you suggest.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
In the remainder of the review, I'm not going to call out each overly-c= omplex
sentence individually, but will attempt to point at a few that also had oth= er
issues.

yes, thank you. that should suf= fice for a scrub.
=C2=A0

Some high-level points before going into a document-order set of comments:<= br>
** The IANA considerations section does not provide a clear set of instruct= ions
for IANA to follow.

Ok, could you be a = little bit more specific

9.1.  Requested Multicast and Port Numbers  seems to describe t=
he allocation points and registries. 
9.2.  Requested Registries with Suggested Values reques=
ts new registries with pre-allocated entries, maybe it's not clear that=
 each subsection is a new registry? I can point that out.
=C2=A0


* The notion of a "three-way adjacency" is not made clear in the = document. It
really takes looking at a rendering of the dot for the state machines befor= e
this term becomes well-defined.

good ca= tch, will be pulled up into "terminology" section and defined.
=C2=A0

* There are a few places where there are internal references in the documen= t
that are not clear. These center around the word "Paragraph". For= instance, in
Req4, there is a reference to "Paragraph 17". Does that mean &quo= t;Req 17"?=C2=A0

anomaly of rfc2t= xt, when referencing a list no matter what the prefix it will always genera= te
"paragraph" in the reference. I will see how I = can fix that.
=C2=A0

* K_LEAF suddently appears without support or definition in 5.1.2. That and=
the other K_ terms should be discussed in the terminology section.

the section 5.1.2. was written more as a narrat= ive but no problem, I will add a special terminology section and define the= variables.
=C2=A0

* It's unclear whether HH symbol means one or two RJ45 jacks. The diagr= ams
appear to use the symbol inconsistently.

The document says ver= batim "we have chosen to use the "HH" symbol as ASCII vis= ualisation of a RJ45 jack."=C2=A0 I will add "single" to= it.

Figure 9 may cause confusing since a single H is used to visualize the = jack.=C2=A0 I also see possible inconsistency in Figure 13, will correct, p= robably replacing the "HH" with "X"

=C2=A0


=3D=3D=3D Issues in document order =3D=3D=3D

In the introduction:

"The incumbent protocols precondition normally extensive configuration= or
provisioning during bring up and re-dimensioning which is only viable for a= set
of organizations with according networking operations skills and budgets.&q= uot; did
not parse for me until my second read-through, where I realized "preco= ndition
normally" was intended to mean "normally require". "bri= ng up" and
"re-dimensioning" are almost jargon in this context.

will try to simplify language where it looks possib= le.
=C2=A0

In the Terminology section:

It would be good to introduce S-TIE and N-TIE as top level terms in this section.

terminology section already sa= ys:

TIE:  Thi=
s is an acronym for a "Topology Information Element".  TIEs
  =
 are exchanged between RIFT nodes to describe parts of a network
   such=
 as links and address prefixes, in a fashion similar to ISIS
   LSPs or =
OSPF LSAs.  We will talk about N-TIEs when talking about
   TIEs in t=
he northbound representation and S-TIEs for the
   southbound equivalent=
.
=C2=A0
but sure, I will break that out and = define more explicitly


The words for Adjacency are not really a definition, but taken as such they= are
circular.

correct, we failed to root th= e defintions of interface/link/adjacency since in p2p link-state
=
protocols they are pretty much equivalent (modulo tunnels). suggestion= s?=C2=A0 I'll introduce
3-way as clear defintion and define a= djacency as "3-way state on a link"
=C2=A0

The definition for Metric is not useful.

ok, will be removed


In the first paragraph of 5.1.1, The construction of 'never ... (we'= ;ll talk
about exceptions later)' is awkward. It's also unclear where the th= e "later" is
pointing. The last sentence is grammatically incorrect ("We omit ... o= ut"), and
talks of omimitting discussion "for the moment". Please make it c= lear where you
return to the discussion.

ok, I'll = list the exceptions in detail here


The third paragraph of 5.1.2 does not parse. I suspect there is a missing w= ord
somewhere in "the introduced Section 3.1".
<= br>
word missing
=C2=A0

The nested numbered lists in section 5.2.3.9 are perhaps not the best tool = for
describing the algorithms you want to convey. On page 46, steps 4.3.3 and 4= .4
are comments, not actions. Numbering them as you number actions is confusin= g.

any better suggestions? (I will move= from numbering to number.latin.other and so on). This is
an old = technique in protocol specs to allow implementors to discuss very, very pre= cise statement
and their meaning (e.g. ISIS spec is all written l= ike that). Otherwise people start to talk about
"4th li= ne in the algorithm X" which is far more confusing.
rfc2txt does not have a mechanism to "skip numbering for t= his item" when genreeating
lists unless I'm oblivio= us to it so I'm limited by the tools IETF provides to render documents.=
=C2=A0

The reference in 5.2.7.2's first paragraph to [EUI64] looks like a norm= ative
reference to me.

I wasn't sure sin= ce the EUI64 is kind of a "side implementation note in IEEE". Can= move to normative.
=C2=A0

Something is wrong at the bottom of page 68. One branch of the sentence red= uces
to "we have to decide whether node Y is ... at the same level as Y&quo= t;.

correct, sentence is illogical. I w= ill correct
=C2=A0

In 5.3.4.1 rule 1, you only consider nodes to which the reciever has a
bi-directional adjacency. As opposed to what? Does this mean adjacencies in=
TwoWay or ThreeWay state? Or something else?

I will define "bi-directional adjacency", it cannot hurt. <= br>
But the term is kind of well understood by anyone who
implemented OSPF/ISIS or is intimately familiar with the specs norm= ally.
=C2=A0

There is a dangling reference to [PGP reference] at the end of 5.3.11.
<= /blockquote>

slipped. PGP has been folded out the main d= ocument and this got missed. I probably remove the reference
sinc= e we cannot publish standard with reference to a draft while PGP work is go= ing slowly.
=C2=A0

Section 7.3 is really not useful for the protocol specification. Consider removing it.

This question/observation/= doubt was coming up many, many times and that's why the document
introduced this section. I prefer to retain it to prevent the ques= tion being asked over and over again
on the reading of the spec. =


In section 8.4 the sentence "The attack vector packet number present i= s
relatively benign." does not parse.

yes
=C2=A0

It's particularly unclear what you are trying to achive with the
"DirectionMaxValue" registry entry defined in 9.2.11.1 Are you tr= ying to say
the registry is not allowed any more values? If so, just say that in the instructions to IANA. I don't see where the codepoint is used by the pr= otocol,
so I suggest it not be added to the registry.

implementation specific basically. Can be removed but allows in impl= ementation to
use the codepoint to scale arrays for example.=

If the registry takes 
DirectionMaxV=
alue

for e.g=
. version 3.0 schema this value could move. Alternately we could split a re=
gistry 
_per schema version_ but that seems a huge proliferation and rep=
lication. 

I'm agnostic either way and would like to hear an opinion here
=C2=A0

It's a leap to get from the description of Sequence Number Binary Arith= metic in
Appendix A to the "rollover" mechanic the paragraphs that referen= ce Appendix A
are looking for. Please clarify.

ok, w= ill explain rollover in relation to Appendix albeit it's a well-known t= echnique
since many years in link-state protocols (explained= e.g. in depth in John Moy's book) though
lacking a rigorous = implementation description such as Appendix A provides.
=C2= =A0

Also in Appendix A, I question the sentence "The >: relationship is= symmetric
but not transitive". Symmetric says "if A>:B then=C2=A0 B>:= A".

yes, symmetric means "if A>:B then=C2=A0 B>= :A" precisely what you say and the
relation holds.

non transitive means obviously that

A>:B and B>:C d= oes NOT imply A>:C

Obvious example of the 3-bit arithmetic is

4 >: 2 & = 2 >: 0 does NOT follow in 4 >: 0

That seems quite clear to me so I don't see easily wha= t you question unless you
care to explain m= ore.
=C2=A0

=3D=3D=3D Nits =3D=3D=3D

The document has many lines that exceed the maximum line width for txt
formatted RFCs.

ack, will correct
=C2=A0

The definition section uses terms before it defines them. For those that ar= e
acronyms (see the first use of PoD and ZTP for example) an expansion would<= br> help. The short-hand "E-W" isn't saving much over "East-= West" and the latter
would be much clearer in the terminology section.

=
will correct
=C2=A0

In section 3.2 at " We will use topology in Figure 2 (called commonly = a fat
tree/network in modern IP fabric considerations [VAHDAT08] as homonym to th= e
original definition of the term [FATTREE]) in all further considerations.&q= uot;.
This would better be conveyed as two seperate sentences. I don't think<= br> "homonym" (same spelling or pronunciation, but different meanings= ) is really
the word you are looking for.

"hom= onym" is precisely what is meant hear, the term has been overloaded to=
mean two different things over time.

Will split into shorter sentences.
=C2=A0

On page 17, you have a block labelled "Following list represents
non-requirements", followed by a single PEND requirement, and then &qu= ot;Finally,
following are the non-requirements" before the NONREQs. The descriptio= n of the
first block is incorrect?

yes, sorry, s= lipped. we had pending? requirements which slid into non requirements or ha= s
been removed. this one is a left over.

=

The last sentence in the paragraph immediately following Figure 10 has no v= erb.

correct, thanks


The second paragraph after Figure 10 includes a sentence that begins "= If proves
convenient". I suspect it meant to be "It proves convenient"=

correct
=C2=A0
In section 5.2.2 the phrase "if a link has entered three way IPv4 and/= or IPv6
with a neighbor on an adjacency" should be reconstructed. I _think_ yo= u mean
has an adjacency with a neighbor that is in the three-way state"?
<= /blockquote>


yes, should clarify via cris= p definition of 3-way.
=C2=A0

In section 5.2.3.5, the pronouns in "It should only set it" can b= ecome
confused.Please rework the sentence to avoid the pronouns.

ack
=C2=A0

There is a stray double-quote at the end of the first sentence in 5.2.7.2

ack
=C2=A0

At 5.2.8 "(with some finer distinctions not explained further)" a= dds no useful
information to the document. Please remove it.

ack
=C2=A0

At section 6.1, please explicitly point to figure 2 when mentioning the exa= mple
topology.

ack
=C2=A0

The term "ToRs" appears without definition or reference at sectio= n 7.1

ack
--0000000000007975600595feaeb3-- From nobody Mon Oct 28 14:16:18 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 8C854120088; Mon, 28 Oct 2019 14:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 EHheXvzqvOWg; Mon, 28 Oct 2019 14:16:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 25E8F120072; Mon, 28 Oct 2019 14:16:12 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x9SLG77O028225 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 28 Oct 2019 16:16:08 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1572297369; bh=hUSrmTxLjK2QHDr8cyaqXYcRMFiKR+V1Ei7+vGzsix4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=mD0mSDoDVSiUzbnOxJqOQNhaVQJlKtx6IC+WKoZiGyjQj0iyc9s9LY2fBZRfeCBr0 skKd8+S7FJs9G1614dGVbIuW5q8VcLeE5GPXZCNOP1Eiw/sOYCzmat+7W3r5vykrt2 lw/SRcv5hUrikKO6atK+DGO2lOIUVwoK6o2vNV4s= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Tony Przygienda Cc: gen-art@ietf.org, draft-ietf-rift-rift.all@ietf.org, rift@ietf.org References: <157228915192.16080.15649375711620871809@ietfa.amsl.com> From: Robert Sparks Message-ID: <15b2c084-ec76-4b5b-016a-39333867d625@nostrum.com> Date: Mon, 28 Oct 2019 16:16:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------48B572D66093E714BDB5A63D" Content-Language: en-US Archived-At: Subject: Re: [Rift] Genart early review of draft-ietf-rift-rift-08 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, 28 Oct 2019 21:16:16 -0000 This is a multi-part message in MIME format. --------------48B572D66093E714BDB5A63D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/28/19 3:51 PM, Tony Przygienda wrote: > Robert, reacting as editor here > > thanks for your detailed review, answers inline > > I'm raising couple questions myself in the answers, if you'd care to > clarify those further I can try to make the > draft cut-off for an updated version > > On Mon, Oct 28, 2019 at 12:00 PM Robert Sparks via Datatracker > > wrote: > > Reviewer: Robert Sparks > Review result: Not Ready > > Summary: Not ready for publication as a Proposed Standard > > I found this document very difficult to read. On my first past > through, I was > fairly certain it didn't specify the protocol well enough to > actually implement > it, until I got deep into the appendices. Even after a second > pass, I am not > comfortable that a implementation could be produced without having > guess at > some behavior, which will lead to interoperability problems. > > I strongly suggest restructuring the draft to pull the actual > definition of the > protocol from the appendix and into the early part of the document > text. You > may also want to use the new v3 format so that you can take > advantage of its > support for SVG to help convey your state diagrams. > > > As first observation, we have two interoperable implementations since > a bit, one completely open source which has been produced based on the > spec. It was in fact open source work that helped to refine the > document content to make sure we can have an implementation produced > based on the text without further "guessing things". As example the > LIE FSM has been implemented initially in open source without > consulting authors of the spec and interoperat'ed without a single > defect (but discovered a protocol underspecification in case of > misconfiguration that was subsequently added). Please refer to IETF > proceedings for the according presentations if necessary. We have a > third implemenation progressing now where all questions the > implementor asked so far could be answered by pointing directly @  the > specification as written. This seems to answer to me the "suspicion of > specification maybe not being good enough to implement" as an > objective measuring stick as far I can imagine one. > > As second observation regarding your comments, the majority of readers > seemed to prefer a format where the protocol is "described" in > narrative and the tight procedure appendices are left to people > implementing the protocol but I have no issue to pull the appendices > directly into the document under the according sections. I would > simply add something along the lines of "this section of interest to a > reader implementing the spec". > > I will try the v3 format again but last time we tried couple months > ago it wasn't workable. I see first RFC havs been just published using > it (albeit I don't see it using any drawings). > > > At the very least, the document needs a strong editorial scrub. > There are many > sentences that are missing important articles. There are many > sentences that > are very complex and would be better written as two or three > sentences. There > are many sections that too deeply assume the reader already > understands the > problem space. > > > Point taken and a scrub will be performed along the lines you suggest. > > > In the remainder of the review, I'm not going to call out each > overly-complex > sentence individually, but will attempt to point at a few that > also had other > issues. > > > yes, thank you. that should suffice for a scrub. > > > Some high-level points before going into a document-order set of > comments: > > ** The IANA considerations section does not provide a clear set of > instructions > for IANA to follow. > > > Ok, could you be a little bit more specific You can get AD help here. See section 2.2 of https://datatracker.ietf.org/doc/rfc8126/. 9.2 is where I am concerned. Please add an explicit statement that you are asking IANA to create a new top-level registry named RIFT with the following subregistries under it. > > 9.1. Requested Multicast and Port Numbers seems to describe the allocation points and registries. > 9.2. Requested Registries with Suggested Values requests new registries with pre-allocated entries, maybe it's not clear that each subsection is a new registry? I can point that out. > > > * The notion of a "three-way adjacency" is not made clear in the > document. It > really takes looking at a rendering of the dot for the state > machines before > this term becomes well-defined. > > > good catch, will be pulled up into "terminology" section and defined. > > > * There are a few places where there are internal references in > the document > that are not clear. These center around the word "Paragraph". For > instance, in > Req4, there is a reference to "Paragraph 17". Does that mean "Req > 17"? > > > anomaly of rfc2txt, when referencing a list no matter what the prefix > it will always generate > "paragraph" in the reference. I will see how I can fix that. > > > * K_LEAF suddently appears without support or definition in 5.1.2. > That and > the other K_ terms should be discussed in the terminology section. > > > the section 5.1.2. was written more as a narrative but no problem, I > will add a special terminology section and define the variables. > > > * It's unclear whether HH symbol means one or two RJ45 jacks. The > diagrams > appear to use the symbol inconsistently. > > > The document says verbatim /"we have chosen to use the "HH" symbol as > ASCII visualisation of a RJ45 jack." /I will add "single" to it. > > Figure 9 may cause confusing since a single H is used to visualize the > jack.  I also see possible inconsistency in Figure 13, will correct, > probably replacing the "HH" with "X" > > > > === Issues in document order === > > In the introduction: > > "The incumbent protocols precondition normally extensive > configuration or > provisioning during bring up and re-dimensioning which is only > viable for a set > of organizations with according networking operations skills and > budgets." did > not parse for me until my second read-through, where I realized > "precondition > normally" was intended to mean "normally require". "bring up" and > "re-dimensioning" are almost jargon in this context. > > > will try to simplify language where it looks possible. > > > In the Terminology section: > > It would be good to introduce S-TIE and N-TIE as top level terms > in this > section. > > > terminology section already says: > > TIE: This is an acronym for a "Topology Information Element". TIEs > are exchanged between RIFT nodes to describe parts of a network > such as links and address prefixes, in a fashion similar to ISIS > LSPs or OSPF LSAs.*We will talk about N-TIEs when talking about TIEs in the northbound > representation and S-TIEs for the southbound equivalent.* > but sure, I will break that out and define more explicitly > > > The words for Adjacency are not really a definition, but taken as > such they are > circular. > > > correct, we failed to root the defintions of interface/link/adjacency > since in p2p link-state > protocols they are pretty much equivalent (modulo tunnels). > suggestions?  I'll introduce > 3-way as clear defintion and define adjacency as "3-way state on a link" > > > The definition for Metric is not useful. > > > ok, will be removed > > > In the first paragraph of 5.1.1, The construction of 'never ... > (we'll talk > about exceptions later)' is awkward. It's also unclear where the > the "later" is > pointing. The last sentence is grammatically incorrect ("We omit > ... out"), and > talks of omimitting discussion "for the moment". Please make it > clear where you > return to the discussion. > > > ok, I'll list the exceptions in detail here > > > The third paragraph of 5.1.2 does not parse. I suspect there is a > missing word > somewhere in "the introduced Section 3.1". > > > word missing > > > The nested numbered lists in section 5.2.3.9 are perhaps not the > best tool for > describing the algorithms you want to convey. On page 46, steps > 4.3.3 and 4.4 > are comments, not actions. Numbering them as you number actions is > confusing. > > > any better suggestions? (I will move from numbering to > number.latin.other and so on). This is > an old technique in protocol specs to allow implementors to discuss > very, very precise statement > and their meaning (e.g. ISIS spec is all written like that). Otherwise > people start to talk about > "4th line in the algorithm X" which is far more confusing. number.latin.other will help. > > rfc2txt does not have a mechanism to "skip numbering for this item" > when genreeating > lists unless I'm oblivious to it so I'm limited by the tools IETF > provides to render documents. Do you mean xml2rfc when you say rfc2txt? > > > The last Step 7 in section 5.2.3.9 speaks of "sine flooding > reduction". What is > that? > > > some editorial slip on find/replace I assume, was "such" AFAIR, seems > slipped -04 or -05. missed by > good amount of readers ;-) > > > The reference in 5.2.7.2's first paragraph to [EUI64] looks like a > normative > reference to me. > > > I wasn't sure since the EUI64 is kind of a "side implementation note > in IEEE". Can move to normative. > > > Something is wrong at the bottom of page 68. One branch of the > sentence reduces > to "we have to decide whether node Y is ... at the same level as Y". > > > correct, sentence is illogical. I will correct > > > In 5.3.4.1 rule 1, you only consider nodes to which the reciever has a > bi-directional adjacency. As opposed to what? Does this mean > adjacencies in > TwoWay or ThreeWay state? Or something else? > > > I will define "bi-directional adjacency", it cannot hurt. > But the term is kind of well understood by anyone who > implemented OSPF/ISIS or is intimately familiar with the specs normally. > > > There is a dangling reference to [PGP reference] at the end of 5.3.11. > > > slipped. PGP has been folded out the main document and this got > missed. I probably remove the reference > since we cannot publish standard with reference to a draft while PGP > work is going slowly. > > > Section 7.3 is really not useful for the protocol specification. > Consider > removing it. > > > This question/observation/doubt was coming up many, many times and > that's why the document > introduced this section. I prefer to retain it to prevent the question > being asked over and over again > on the reading of the spec. > > > In section 8.4 the sentence "The attack vector packet number > present is > relatively benign." does not parse. > > > yes > > > It's particularly unclear what you are trying to achive with the > "DirectionMaxValue" registry entry defined in 9.2.11.1 Are you > trying to say > the registry is not allowed any more values? If so, just say that > in the > instructions to IANA. I don't see where the codepoint is used by > the protocol, > so I suggest it not be added to the registry. > > > implementation specific basically. Can be removed but allows in > implementation to > use the codepoint to scale arrays for example. > > If the registry takes > DirectionMaxValue > > for e.g. version 3.0 schema this value could move. Alternately we > could split a registry _per schema version_ but that seems a huge > proliferation and replication. > I'm agnostic either way and would like to hear an opinion here I'll punt this to the group/AD. > > > It's a leap to get from the description of Sequence Number Binary > Arithmetic in > Appendix A to the "rollover" mechanic the paragraphs that > reference Appendix A > are looking for. Please clarify. > > > ok, will explain rollover in relation to Appendix albeit it's a > well-known technique > since many years in link-state protocols (explained e.g. in depth in > John Moy's book) though > lacking a rigorous implementation description such as Appendix A > provides. > > > Also in Appendix A, I question the sentence "The >: relationship > is symmetric > but not transitive". Symmetric says "if A>:B then B>:A". > > > yes, symmetric means "if A>:B then B>:A" precisely what you say and the > relation holds. > > non transitive means obviously that > > A>:B and B>:C does NOT imply A>:C > > Obvious example of the 3-bit arithmetic is > > 4 >: 2 & 2 >: 0 does NOT follow in 4 >: 0 I will reread. 4 >: 2 and 2 >: 4 surprises me. > > That seems quite clear to me so I don't see easily what you question > unless you > care to explain more. > > > === Nits === > > The document has many lines that exceed the maximum line width for txt > formatted RFCs. > > > ack, will correct > > > The definition section uses terms before it defines them. For > those that are > acronyms (see the first use of PoD and ZTP for example) an > expansion would > help. The short-hand "E-W" isn't saving much over "East-West" and > the latter > would be much clearer in the terminology section. > > > will correct > > > In section 3.2 at " We will use topology in Figure 2 (called > commonly a fat > tree/network in modern IP fabric considerations [VAHDAT08] as > homonym to the > original definition of the term [FATTREE]) in all further > considerations.". > This would better be conveyed as two seperate sentences. I don't think > "homonym" (same spelling or pronunciation, but different meanings) > is really > the word you are looking for. > > > "homonym" is precisely what is meant hear, the term has been > overloaded to > mean two different things over time. > > Will split into shorter sentences. > > > On page 17, you have a block labelled "Following list represents > non-requirements", followed by a single PEND requirement, and then > "Finally, > following are the non-requirements" before the NONREQs. The > description of the > first block is incorrect? > > > yes, sorry, slipped. we had pending? requirements which slid into non > requirements or has > been removed. this one is a left over. > > > The last sentence in the paragraph immediately following Figure 10 > has no verb. > > > correct, thanks > > > The second paragraph after Figure 10 includes a sentence that > begins "If proves > convenient". I suspect it meant to be "It proves convenient" > > > correct > > In section 5.2.2 the phrase "if a link has entered three way IPv4 > and/or IPv6 > with a neighbor on an adjacency" should be reconstructed. I > _think_ you mean > has an adjacency with a neighbor that is in the three-way state"? > > > > yes, should clarify via crisp definition of 3-way. > > > In section 5.2.3.5, the pronouns in "It should only set it" can become > confused.Please rework the sentence to avoid the pronouns. > > > ack > > > There is a stray double-quote at the end of the first sentence in > 5.2.7.2 > > > ack > > > At 5.2.8 "(with some finer distinctions not explained further)" > adds no useful > information to the document. Please remove it. > > > ack > > > At section 6.1, please explicitly point to figure 2 when > mentioning the example > topology. > > > ack > > > The term "ToRs" appears without definition or reference at section 7.1 > > > ack --------------48B572D66093E714BDB5A63D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 10/28/19 3:51 PM, Tony Przygienda wrote:
Robert, reacting as editor here

thanks for your detailed review, answers inline

I'm raising couple questions myself in the answers, if you'd care to clarify those further I can try to make the
draft cut-off for an updated version

On Mon, Oct 28, 2019 at 12:00 PM Robert Sparks via Datatracker <noreply@ietf.org> wrote:
Reviewer: Robert Sparks
Review result: Not Ready

Summary: Not ready for publication as a Proposed Standard

I found this document very difficult to read. On my first past through, I was
fairly certain it didn't specify the protocol well enough to actually implement
it, until I got deep into the appendices. Even after a second pass, I am not
comfortable that a implementation could be produced without having guess at
some behavior, which will lead to interoperability problems.

I strongly suggest restructuring the draft to pull the actual definition of the
protocol from the appendix and into the early part of the document text. You
may also want to use the new v3 format so that you can take advantage of its
support for SVG to help convey your state diagrams.

As first observation, we have two interoperable implementations since a bit, one completely open source which has been produced based on the spec. It was in fact open source work that helped to refine the document content to make sure we can have an implementation produced based on the text without further "guessing things". As example the LIE FSM has been implemented initially in open source without consulting authors of the spec and interoperat'ed without a single defect (but discovered a protocol underspecification in case of misconfiguration that was subsequently added). Please refer to IETF proceedings for the according presentations if necessary. We have a third implemenation progressing now where all questions the implementor asked so far could be answered by pointing directly @  the specification as written. This seems to answer to me the "suspicion of specification maybe not being good enough to implement" as an objective measuring stick as far I can imagine one.

As second observation regarding your comments, the majority of readers seemed to prefer a format where the protocol is "described" in narrative and the tight procedure appendices are left to people implementing the protocol but I have no issue to pull the appendices directly into the document under the according sections. I would simply add something along the lines of "this section of interest to a reader implementing the spec".

I will try the v3 format again but last time we tried couple months ago it wasn't workable. I see first RFC havs been just published using it (albeit I don't see it using any drawings).
 

At the very least, the document needs a strong editorial scrub. There are many
sentences that are missing important articles. There are many sentences that
are very complex and would be better written as two or three sentences. There
are many sections that too deeply assume the reader already understands the
problem space.

Point taken and a scrub will be performed along the lines you suggest.
 

In the remainder of the review, I'm not going to call out each overly-complex
sentence individually, but will attempt to point at a few that also had other
issues.

yes, thank you. that should suffice for a scrub.
 

Some high-level points before going into a document-order set of comments:

** The IANA considerations section does not provide a clear set of instructions
for IANA to follow.

Ok, could you be a little bit more specific

You can get AD help here. See section 2.2 of https://datatracker.ietf.org/doc/rfc8126/.

9.2 is where I am concerned.

Please add an explicit statement that you are asking IANA to create a new top-level registry named RIFT with the following subregistries under it.


9.1.  Requested Multicast and Port Numbers  seems to describe the allocation points and registries. 

9.2.  Requested Registries with Suggested Values requests new registries with pre-allocated entries, maybe it's not clear that each subsection is a new registry? I can point that out.
 


* The notion of a "three-way adjacency" is not made clear in the document. It
really takes looking at a rendering of the dot for the state machines before
this term becomes well-defined.

good catch, will be pulled up into "terminology" section and defined.
 

* There are a few places where there are internal references in the document
that are not clear. These center around the word "Paragraph". For instance, in
Req4, there is a reference to "Paragraph 17". Does that mean "Req 17"? 

anomaly of rfc2txt, when referencing a list no matter what the prefix it will always generate
"paragraph" in the reference. I will see how I can fix that.
 

* K_LEAF suddently appears without support or definition in 5.1.2. That and
the other K_ terms should be discussed in the terminology section.

the section 5.1.2. was written more as a narrative but no problem, I will add a special terminology section and define the variables.
 

* It's unclear whether HH symbol means one or two RJ45 jacks. The diagrams
appear to use the symbol inconsistently.

The document says verbatim "we have chosen to use the "HH" symbol as ASCII visualisation of a RJ45 jack."  I will add "single" to it.

Figure 9 may cause confusing since a single H is used to visualize the jack.  I also see possible inconsistency in Figure 13, will correct, probably replacing the "HH" with "X"

 


=== Issues in document order ===

In the introduction:

"The incumbent protocols precondition normally extensive configuration or
provisioning during bring up and re-dimensioning which is only viable for a set
of organizations with according networking operations skills and budgets." did
not parse for me until my second read-through, where I realized "precondition
normally" was intended to mean "normally require". "bring up" and
"re-dimensioning" are almost jargon in this context.

will try to simplify language where it looks possible.
 

In the Terminology section:

It would be good to introduce S-TIE and N-TIE as top level terms in this
section.

terminology section already says:

TIE:  This is an acronym for a "Topology Information Element".  TIEs
   are exchanged between RIFT nodes to describe parts of a network
   such as links and address prefixes, in a fashion similar to ISIS
   LSPs or OSPF LSAs.  We will talk about N-TIEs when talking about
   TIEs in the northbound representation and S-TIEs for the
   southbound equivalent.
 
but sure, I will break that out and define more explicitly


The words for Adjacency are not really a definition, but taken as such they are
circular.

correct, we failed to root the defintions of interface/link/adjacency since in p2p link-state
protocols they are pretty much equivalent (modulo tunnels). suggestions?  I'll introduce
3-way as clear defintion and define adjacency as "3-way state on a link"
 

The definition for Metric is not useful.

ok, will be removed


In the first paragraph of 5.1.1, The construction of 'never ... (we'll talk
about exceptions later)' is awkward. It's also unclear where the the "later" is
pointing. The last sentence is grammatically incorrect ("We omit ... out"), and
talks of omimitting discussion "for the moment". Please make it clear where you
return to the discussion.

ok, I'll list the exceptions in detail here


The third paragraph of 5.1.2 does not parse. I suspect there is a missing word
somewhere in "the introduced Section 3.1".

word missing
 

The nested numbered lists in section 5.2.3.9 are perhaps not the best tool for
describing the algorithms you want to convey. On page 46, steps 4.3.3 and 4.4
are comments, not actions. Numbering them as you number actions is confusing.

any better suggestions? (I will move from numbering to number.latin.other and so on). This is
an old technique in protocol specs to allow implementors to discuss very, very precise statement
and their meaning (e.g. ISIS spec is all written like that). Otherwise people start to talk about
"4th line in the algorithm X" which is far more confusing.
number.latin.other will help.

rfc2txt does not have a mechanism to "skip numbering for this item" when genreeating
lists unless I'm oblivious to it so I'm limited by the tools IETF provides to render documents.
Do you mean xml2rfc when you say rfc2txt?
 

The last Step 7 in section 5.2.3.9 speaks of "sine flooding reduction". What is
that?

some editorial slip on find/replace I assume, was "such" AFAIR, seems slipped -04 or -05. missed by
good amount of readers ;-)
 

The reference in 5.2.7.2's first paragraph to [EUI64] looks like a normative
reference to me.

I wasn't sure since the EUI64 is kind of a "side implementation note in IEEE". Can move to normative.
 

Something is wrong at the bottom of page 68. One branch of the sentence reduces
to "we have to decide whether node Y is ... at the same level as Y".

correct, sentence is illogical. I will correct
 

In 5.3.4.1 rule 1, you only consider nodes to which the reciever has a
bi-directional adjacency. As opposed to what? Does this mean adjacencies in
TwoWay or ThreeWay state? Or something else?

I will define "bi-directional adjacency", it cannot hurt.
But the term is kind of well understood by anyone who
implemented OSPF/ISIS or is intimately familiar with the specs normally.
 

There is a dangling reference to [PGP reference] at the end of 5.3.11.

slipped. PGP has been folded out the main document and this got missed. I probably remove the reference
since we cannot publish standard with reference to a draft while PGP work is going slowly.
 

Section 7.3 is really not useful for the protocol specification. Consider
removing it.

This question/observation/doubt was coming up many, many times and that's why the document
introduced this section. I prefer to retain it to prevent the question being asked over and over again
on the reading of the spec.


In section 8.4 the sentence "The attack vector packet number present is
relatively benign." does not parse.

yes
 

It's particularly unclear what you are trying to achive with the
"DirectionMaxValue" registry entry defined in 9.2.11.1 Are you trying to say
the registry is not allowed any more values? If so, just say that in the
instructions to IANA. I don't see where the codepoint is used by the protocol,
so I suggest it not be added to the registry.

implementation specific basically. Can be removed but allows in implementation to
use the codepoint to scale arrays for example.

If the registry takes 
DirectionMaxValue


for e.g. version 3.0 schema this value could move. Alternately we could split a registry 
_per schema version_ but that seems a huge proliferation and replication. 


I'm agnostic either way and would like to hear an opinion here
I'll punt this to the group/AD.
 

It's a leap to get from the description of Sequence Number Binary Arithmetic in
Appendix A to the "rollover" mechanic the paragraphs that reference Appendix A
are looking for. Please clarify.

ok, will explain rollover in relation to Appendix albeit it's a well-known technique
since many years in link-state protocols (explained e.g. in depth in John Moy's book) though
lacking a rigorous implementation description such as Appendix A provides.
 

Also in Appendix A, I question the sentence "The >: relationship is symmetric
but not transitive". Symmetric says "if A>:B then  B>:A".

yes, symmetric means "if A>:B then  B>:A" precisely what you say and the
relation holds.

non transitive means obviously that

A>:B and B>:C does NOT imply A>:C

Obvious example of the 3-bit arithmetic is

4 >: 2 & 2 >: 0 does NOT follow in 4 >: 0
I will reread. 4 >: 2 and 2 >: 4 surprises me.

That seems quite clear to me so I don't see easily what you question unless you
care to explain more.
 

=== Nits ===

The document has many lines that exceed the maximum line width for txt
formatted RFCs.

ack, will correct
 

The definition section uses terms before it defines them. For those that are
acronyms (see the first use of PoD and ZTP for example) an expansion would
help. The short-hand "E-W" isn't saving much over "East-West" and the latter
would be much clearer in the terminology section.

will correct
 

In section 3.2 at " We will use topology in Figure 2 (called commonly a fat
tree/network in modern IP fabric considerations [VAHDAT08] as homonym to the
original definition of the term [FATTREE]) in all further considerations.".
This would better be conveyed as two seperate sentences. I don't think
"homonym" (same spelling or pronunciation, but different meanings) is really
the word you are looking for.

"homonym" is precisely what is meant hear, the term has been overloaded to
mean two different things over time.

Will split into shorter sentences.
 

On page 17, you have a block labelled "Following list represents
non-requirements", followed by a single PEND requirement, and then "Finally,
following are the non-requirements" before the NONREQs. The description of the
first block is incorrect?

yes, sorry, slipped. we had pending? requirements which slid into non requirements or has
been removed. this one is a left over.


The last sentence in the paragraph immediately following Figure 10 has no verb.

correct, thanks


The second paragraph after Figure 10 includes a sentence that begins "If proves
convenient". I suspect it meant to be "It proves convenient"

correct
 
In section 5.2.2 the phrase "if a link has entered three way IPv4 and/or IPv6
with a neighbor on an adjacency" should be reconstructed. I _think_ you mean
has an adjacency with a neighbor that is in the three-way state"?


yes, should clarify via crisp definition of 3-way.
 

In section 5.2.3.5, the pronouns in "It should only set it" can become
confused.Please rework the sentence to avoid the pronouns.

ack
 

There is a stray double-quote at the end of the first sentence in 5.2.7.2

ack
 

At 5.2.8 "(with some finer distinctions not explained further)" adds no useful
information to the document. Please remove it.

ack
 

At section 6.1, please explicitly point to figure 2 when mentioning the example
topology.

ack
 

The term "ToRs" appears without definition or reference at section 7.1

ack
--------------48B572D66093E714BDB5A63D-- From nobody Mon Oct 28 17:55: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 0107E1200C3; Mon, 28 Oct 2019 17:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 A24s4PRtbh50; Mon, 28 Oct 2019 17:55:21 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 28748120047; Mon, 28 Oct 2019 17:55:21 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id k1so3892853iom.9; Mon, 28 Oct 2019 17:55: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=lEI3WzSTdxOOUK6bgSoLZl5hgbW82rDRSqVlgESAo20=; b=lCCzrPb3UNe821SeupeqXzn8V96jtmMjKBQBaYRdPHo2Y9AhXahTrgMu/y1Wqs7JO8 TWjukgwb+P48gkIKD6oCW48qkXAJXo2VaOTEP0aKeCejoGeK4AZXFJKg5omI/hy2T/ht SHmDFP8VyrwOLbajB2nzkCH/yniohxTPUt7NHxDcbMc1/ib4lyuT2AN+0ByPEla4Nq5N 5Pq9e8sov5M4ZvwgRIVIwS03/ZvLzq9HjZCqFzT+/JUj80SL4hJiax54QjnVlPoPCR4v IfL4D4WRcGXC/EJZAgg+GkdNnntRWlMgroez82x7jLkH7NzXg5XsCFUGm+3THZdQkWM/ zAoQ== 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=lEI3WzSTdxOOUK6bgSoLZl5hgbW82rDRSqVlgESAo20=; b=iX57dxDBJq9AADjhwlwcGkBQ7F+IA5KzTx+LxalH49tWe10iMD0T+LrN0hChESvhN9 JxiUPb87WAr+no2v7TPTknkEEBX57DiSuy3NinbibmtFtrlnuFJD8BTXhULZpgMsILSc NHiQ7iJUHxPp/sztb9KPVhAVTNdvuhjlKDc06zxXwHljAmqFwPu5wPGwsGLiFaFCled/ DRGHYaldPhjN4kVQlFBkSs1MaIzPRPfkO7dkJ7X8o5hMHowiOaXt679PzVWULzz1hCm8 vkMI/EYJwwi17e5fAgTt9g2hWeLs4a6AR/UFAlJ7TZTp3d/dVvBb/0Xc5ZUEixfh6xy6 p7TQ== X-Gm-Message-State: APjAAAVRX/HtQutFKmb5H7EeNSUSbkOwsv8MmVj4/EyRpWol3pb46oUO 5ZSPXiok80jneTcWtdKInIzhGnIK+B+edn/XWNI= X-Google-Smtp-Source: APXvYqxxzEOvcf9VZy5XVxULL2vndORJRb4L5MkOKfuDbr0ri7s9YullNn5SSNDGAANx+5rw9WzJUbK5dNdoiJhKKUc= X-Received: by 2002:a6b:b54a:: with SMTP id e71mr918289iof.132.1572310520468; Mon, 28 Oct 2019 17:55:20 -0700 (PDT) MIME-Version: 1.0 References: <157228915192.16080.15649375711620871809@ietfa.amsl.com> <15b2c084-ec76-4b5b-016a-39333867d625@nostrum.com> In-Reply-To: <15b2c084-ec76-4b5b-016a-39333867d625@nostrum.com> From: Tony Przygienda Date: Mon, 28 Oct 2019 17:54:33 -0700 Message-ID: To: Robert Sparks Cc: gen-art@ietf.org, draft-ietf-rift-rift.all@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="0000000000000c9b0905960212ee" Archived-At: Subject: Re: [Rift] Genart early review of draft-ietf-rift-rift-08 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: Tue, 29 Oct 2019 00:55:24 -0000 --0000000000000c9b0905960212ee Content-Type: text/plain; charset="UTF-8" On Mon, Oct 28, 2019 at 2:16 PM Robert Sparks wrote: > > > > >> >> Some high-level points before going into a document-order set of comments: >> >> ** The IANA considerations section does not provide a clear set of >> instructions >> for IANA to follow. >> > > Ok, could you be a little bit more specific > > You can get AD help here. See section 2.2 of > https://datatracker.ietf.org/doc/rfc8126/. > > 9.2 is where I am concerned. > > Please add an explicit statement that you are asking IANA to create a new > top-level registry named RIFT with the following subregistries under it. > yes, no problem. > > > >> >> The nested numbered lists in section 5.2.3.9 are perhaps not the best >> tool for >> describing the algorithms you want to convey. On page 46, steps 4.3.3 and >> 4.4 >> are comments, not actions. Numbering them as you number actions is >> confusing. >> > > any better suggestions? (I will move from numbering to number.latin.other > and so on). This is > an old technique in protocol specs to allow implementors to discuss very, > very precise statement > and their meaning (e.g. ISIS spec is all written like that). Otherwise > people start to talk about > "4th line in the algorithm X" which is far more confusing. > > number.latin.other will help. > ok, thanks > > rfc2txt does not have a mechanism to "skip numbering for this item" when > genreeating > lists unless I'm oblivious to it so I'm limited by the tools IETF provides > to render documents. > > Do you mean xml2rfc when you say rfc2txt? > yes, correct. sorry. > > > >> >> It's particularly unclear what you are trying to achive with the >> "DirectionMaxValue" registry entry defined in 9.2.11.1 Are you trying to >> say >> the registry is not allowed any more values? If so, just say that in the >> instructions to IANA. I don't see where the codepoint is used by the >> protocol, >> so I suggest it not be added to the registry. >> > > implementation specific basically. Can be removed but allows in > implementation to > use the codepoint to scale arrays for example. > > If the registry takes > > DirectionMaxValue > > > for e.g. version 3.0 schema this value could move. Alternately we could split a registry > _per schema version_ but that seems a huge proliferation and replication. > > > I'm agnostic either way and would like to hear an opinion here > > I'll punt this to the group/AD. > ack > > > >> >> Also in Appendix A, I question the sentence "The >: relationship is >> symmetric >> but not transitive". Symmetric says "if A>:B then B>:A". >> > > yes, symmetric means "if A>:B then B>:A" precisely what you say and the > relation holds. > > non transitive means obviously that > > A>:B and B>:C does NOT imply A>:C > > Obvious example of the 3-bit arithmetic is > > 4 >: 2 & 2 >: 0 does NOT follow in 4 >: 0 > > I will reread. 4 >: 2 and 2 >: 4 surprises me. > oh, sorry, that's the objection, I thought you objected to transitive and focused on that. yes, you're correct, it's not symmetric, I was blind and implied 4 >: 2 <=> 2 <: 4 which is not symmetry of course. I will correct. > --0000000000000c9b0905960212ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 28, 2019 at 2:16 PM Rober= t Sparks <rjsparks@nostrum.com> wrote:
=20 =20 =20

yes, no problem.
=C2=A0


=C2=A0

The nested numbered lists in section 5.2.3.9 are perhaps not the best tool for
describing the algorithms you want to convey. On page 46, steps 4.3.3 and 4.4
are comments, not actions. Numbering them as you number actions is confusing.

any better suggestions? (I will move from numbering to number.latin.other and so on). This is
an old technique in protocol specs to allow implementors to discuss very, very precise statement
and their meaning (e.g. ISIS spec is all written like that). Otherwise people start to talk about
"4th line in the algorithm X" which is far more confusing.
number.latin.other will help.

ok, thanks=C2=A0

rfc2txt does not have a mechanism to "skip numbering fo= r this item" when genreeating
lists unless I'm oblivious to it so I'm limited by t= he tools IETF provides to render documents.
Do you mean xml2rfc when you say rfc2txt?
yes, correct. sorry.
=C2=A0
=C2=A0
=C2=A0

It's particularly unclear what you are trying to achive wit= h the
"DirectionMaxValue" registry entry defined in 9.2.11.= 1 Are you trying to say
the registry is not allowed any more values? If so, just say that in the
instructions to IANA. I don't see where the codepoint is used by the protocol,
so I suggest it not be added to the registry.

implementation specific basically. Can be removed but allows in implementation to
use the codepoint to scale arrays for example.

If the registry takes 
DirectionMaxValue


for e.g. vers=
ion 3.0 schema this value could move. Alternately we could split a registry=
=20
_per schema version_ but that seems a huge proliferation and replication.=
=20


I'm agnos=
tic either way and would like to hear an opinion here=20
I'll punt this to the group/AD.

ack
=C2=A0
=C2=A0
=C2=A0

Also in Appendix A, I question the sentence "The >: relationship is symmetric
but not transitive". Symmetric says "if A>:B then= =C2=A0 B>:A".

yes, symmetric means "if A>:B th= en=C2=A0 B>:A" precisely what you say and the
relation holds.

non transitive means obviously that

A>:B and B>:C does NOT imply A>:C

Obvious example of the 3-bit arithmetic is

4 >: 2 & 2 >: 0 does NOT follow in 4 >: 0
I will reread. 4 >: 2 and 2 >: 4 surprises me.

oh, sorry, that's the objection, I thought you = objected to transitive and focused on that. yes, you're correct, it'= ;s not symmetric, I was blind and implied

4 &= gt;: 2=C2=A0 <=3D>=C2=A0 2 <: 4

whic= h is not symmetry of course. I will correct.


--0000000000000c9b0905960212ee-- From nobody Thu Oct 31 10:55:55 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 B5EC312082E for ; Thu, 31 Oct 2019 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 JMnIa9M0t2g1 for ; Thu, 31 Oct 2019 10:49:49 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 AB7A912012E for ; Thu, 31 Oct 2019 10:49:49 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9VHl5bk002797; Thu, 31 Oct 2019 10:49:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=D7c94RaAA0VFscIqOCfLMaNjtw0rtnuj7L87PY0efpc=; b=HqvGE6R4y21wWFF+n3OcNJjgu+/7OuK1Dv1YNEaLiFH1RlZ+RlvRmaf6XiHANBv+jLQ8 aayKYOebOuP4w6yJ1deIiJ1N1mIVySK23AS/ANlMONcgE+tbsCvYpujCNJjr/38LeYt/ MFJXN9av0Sb5xjmv2IG71pFvKdNKhYj5UahRRAyyOY3Ir3RB2IX2vY4lwInExcbWuhzj 5MWdcAD8rorUA+BIyRT16rxY94+KlVH4boPmhsWaKh24zkS2DVQ5/8LagEIAXXp+MqV6 4XwITTm14uBFjY+Xymn0TTtlxF7Mw3v5qd76z9kwykqSdAoDoWf+DYw3ciiANIVo1wHI 3A== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2058.outbound.protection.outlook.com [104.47.45.58]) by mx0b-00273201.pphosted.com with ESMTP id 2vydkdj7s4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 10:49:41 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=chKenpV7o/arz1vSXkGzfIh/FufVkrurVUZQ50k/7gbnNokUykgWyM7Wy1UB1SSPKrTbsx5t58YuuSk6+28KGASHiGCrkXkiLc33qWUzX7vsy5WQisRdXQ5iu4teVsp9X/ud51iY8Ymrd1WZW45ZsLXmWc33kBcR3xk77UkciWiXtrg8jcIvaTQeONhY3qca98SPTgiOcBgrpFrr7h4NsPgt75IL2T2DlK2d5IV8SZzf1nMX8M0yJpfXvaJQWg+8qlMnlBsQnMTKmIm8wh9pS4VkKuIHJF3x62o02rE+LeVk58j55O1j2g1TM4mlTIKHI2Mmoy1kNlIYqpsDc/xo9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D7c94RaAA0VFscIqOCfLMaNjtw0rtnuj7L87PY0efpc=; b=kEoKWcziKTxLHffTTzA1DG5AQBI7OZUAXkbAWxWVB+E6pQYwumPfy0F4hS/Q3jqDacH0rRSjPofJwzXA/LSfspyhmavtEQYM7QfPuOY0DPL+cDxLlkU4QRcycqV8dpGNMbl4zPDJWbLEL4cHJdR1O0CK071J040J85OIMQgtZBg1Ck8z4KutR+GK8zM9vFKmHiHzYm/DN6NBlJB16oQpP5tac8wjMYvnCYpLWZPWJj4lppOlNgv/ckzpfY4/Nv5/9E6zR0UFYToBfpWCWI/4gpCkkCBW1sxVtmR7ExN17nYi+Mv4VYG4MpYXL2WUkYtLHEWYRdy0RPzG4qu/CSWxLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none Received: from DM5PR05MB3548.namprd05.prod.outlook.com (10.174.242.153) by DM5PR05MB3529.namprd05.prod.outlook.com (10.174.242.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.10; Thu, 31 Oct 2019 17:49:36 +0000 Received: from DM5PR05MB3548.namprd05.prod.outlook.com ([fe80::5de9:4ee0:9174:fc4f]) by DM5PR05MB3548.namprd05.prod.outlook.com ([fe80::5de9:4ee0:9174:fc4f%6]) with mapi id 15.20.2408.016; Thu, 31 Oct 2019 17:49:36 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "rift@ietf.org" CC: "Acee Lindem (acee)" , "gregimirsky@gmail.com" , Suneesh Babu , "Peter Psenak (ppsenak)" , Fabian Prou , John E Drake , "wei.yuehua@zte.com.cn" , Salih K A , "melchior@aelmans.eu" , Rafal Szmidt , "Dailongfei (Larry, IP Research)" , "Phil Boulo (pboulo)" , "Mankamana Mishra (mankamis)" Thread-Topic: Monthly RIFT Virtual Interim Meeting Thread-Index: AdUP/S2eCsjvvkBUSe+nGxToszKCUyAFl97Q Importance: high X-Priority: 1 Date: Thu, 31 Oct 2019 17:49:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAfjCwfA1oym2w/VAQAAAAAAAAAAEAAAADyxEptNyS9HjM7Y6RDwzeo= x-originating-ip: [96.237.64.80] x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 400e288a-46d1-421b-6ea4-08d75e2ab1d8 x-ms-traffictypediagnostic: DM5PR05MB3529:MeetingMessage x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:294; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(396003)(136003)(346002)(189003)(199004)(478600001)(316002)(99286004)(86362001)(2501003)(81686011)(5640700003)(486006)(558084003)(6506007)(66556008)(55016002)(7696005)(2351001)(54896002)(7736002)(9686003)(6306002)(6916009)(102836004)(3846002)(2906002)(790700001)(14454004)(4326008)(76116006)(476003)(64756008)(66946007)(66446008)(66476007)(6116002)(81156014)(6436002)(33656002)(186003)(26005)(25786009)(81166006)(54906003)(71190400001)(71200400001)(66066001)(8936002)(8676002)(74316002)(52536014)(1730700003)(5660300002)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3529; H:DM5PR05MB3548.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: BCL:0; x-microsoft-antispam-message-info: nAYJV2tLeMF9Z2l0IIjZUsXXqVsRNFvkcGJX2gwEubQ2tUb5QjZoPDNGtapBVSJXsMs9ramRQkaOoepS2u8z7plxEzBtSpkZ63yFW/FTGbNc+pS9wbKmgz1Cd4sNNejGgNR048IXiyJfINVkQqgan9gDhTd0Lk3QXNV+CH1cVT8rCa/PPxLlpvKjK7ivGcHN7NNG2KVd/e04x4C/7bsOfNh/JX4a1NDfOfp8u1rMY1IE84Em5U3q1mOVs4KoyooNidxx/q/utZNY9f3C4dkGcLKe55H0954zAEPXKZikLkyUy/WiQPCpWvWEgONP2iip7wzQU8Q8RnMoxtYkOgvO3XWxOl4pE3I2xdA+jkiJ3U0Ff1LEflgNSp+faRZn5C4nm2U0y7Z3zurqn6i5nTexRjXW/uLhlD/OXHatbpia1TtnL6isJbAP7Wxoed3ipPIf Content-Type: multipart/alternative; boundary="_000_DM5PR05MB35488205E107E49240E73FBCD4630DM5PR05MB3548namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 400e288a-46d1-421b-6ea4-08d75e2ab1d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 17:49:36.1053 (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-CrossTenant-userprincipalname: Q9cv681lJIMP5EItQ2beHCjZVn9yyDHREYflq28NmSONw3IGA3BrcxuImmpzvfeBUuaiB6/YyF6rE6dlSyQLNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3529 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-31_07:2019-10-30,2019-10-31 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 bulkscore=0 suspectscore=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 clxscore=1011 impostorscore=0 malwarescore=0 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910310175 Archived-At: X-Mailman-Approved-At: Thu, 31 Oct 2019 10:55:54 -0700 Subject: [Rift] Canceled: Monthly RIFT Virtual Interim Meeting 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, 31 Oct 2019 17:49:52 -0000 --_000_DM5PR05MB35488205E107E49240E73FBCD4630DM5PR05MB3548namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We'll cancel this month's meeting - draft cut-off time, people busy & we're= under review, other drafts are progressing independently --_000_DM5PR05MB35488205E107E49240E73FBCD4630DM5PR05MB3548namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ll cancel this month’s meeting –= ; draft cut-off time, people busy & we’re under review, other dra= fts are progressing independently

--_000_DM5PR05MB35488205E107E49240E73FBCD4630DM5PR05MB3548namp_ Content-Type: text/calendar; charset="utf-8"; method=CANCEL Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6Q0FOQ0VMDQpQUk9ESUQ6TWljcm9zb2Z0IEV4Y2hhbmdl IFNlcnZlciAyMDEwDQpWRVJTSU9OOjIuMA0KQkVHSU46VlRJTUVaT05FDQpUWklEOkVhc3Rlcm4g U3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDIwMDAwDQpU Wk9GRlNFVEZST006LTA0MDANClRaT0ZGU0VUVE86LTA1MDANClJSVUxFOkZSRVE9WUVBUkxZO0lO VEVSVkFMPTE7QllEQVk9MVNVO0JZTU9OVEg9MTENCkVORDpTVEFOREFSRA0KQkVHSU46REFZTElH SFQNCkRUU1RBUlQ6MTYwMTAxMDFUMDIwMDAwDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VU VE86LTA0MDANClJSVUxFOkZSRVE9WUVBUkxZO0lOVEVSVkFMPTE7QllEQVk9MlNVO0JZTU9OVEg9 Mw0KRU5EOkRBWUxJR0hUDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCk9SR0FOSVpFUjtD Tj1KZWZmcmV5IChaaGFvaHVpKSBaaGFuZzpNQUlMVE86enpoYW5nQGp1bmlwZXIubmV0DQpBVFRF TkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVF O0NOPXJpZnRAaWV0Zi4NCiBvcmc6TUFJTFRPOnJpZnRAaWV0Zi5vcmcNCkFUVEVOREVFO1JPTEU9 T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049QWNlZSBM aW5kZQ0KIG0gKGFjZWUpOk1BSUxUTzphY2VlQGNpc2NvLmNvbQ0KQVRURU5ERUU7Uk9MRT1PUFQt UEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1ncmVnaW1pcnNr DQogeUBnbWFpbC5jb206TUFJTFRPOmdyZWdpbWlyc2t5QGdtYWlsLmNvbQ0KQVRURU5ERUU7Uk9M RT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1TdW5l ZXNoIEJhDQogYnU6TUFJTFRPOnN1bmVlc2hAanVuaXBlci5uZXQNCkFUVEVOREVFO1JPTEU9T1BU LVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049UGV0ZXIgUHNl bg0KIGFrIChwcHNlbmFrKTpNQUlMVE86cHBzZW5ha0BjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9 T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049RmFiaWFu IFBybw0KIHU6TUFJTFRPOmZwcm91QGp1bmlwZXIubmV0DQpBVFRFTkRFRTtST0xFPU9QVC1QQVJU SUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPUpvaG4gRSBEcmENCiBr ZTpNQUlMVE86amRyYWtlQGp1bmlwZXIubmV0DQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFO VDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPXdlaS55dWVodWENCiBAenRlLmNv bS5jbjpNQUlMVE86d2VpLnl1ZWh1YUB6dGUuY29tLmNuDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJU SUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPVNhbGloIEsgQToNCiBN QUlMVE86c2FsaWhAanVuaXBlci5uZXQNCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BB UlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049bWVsY2hpb3JAYQ0KIGVsbWFucy5ldTpN QUlMVE86bWVsY2hpb3JAYWVsbWFucy5ldQ0KQVRURU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBBTlQ7 UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1SYWZhbCBTem1pDQogZHQ6TUFJTFRP OnJzem1pZHRAanVuaXBlci5uZXQNCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRT VEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049IkRhaWxvbmdmZWkNCiAgKExhcnJ5LCBJUCBS ZXNlYXJjaCkiOk1BSUxUTzpsYXJyeS5kYWlAaHVhd2VpLmNvbQ0KQVRURU5ERUU7Uk9MRT1PUFQt UEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1QaGlsIEJvdWxv DQogIChwYm91bG8pOk1BSUxUTzpwYm91bG9AY2lzY28uY29tDQpBVFRFTkRFRTtST0xFPU9QVC1Q QVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPU1hbmthbWFuYSAN CiBNaXNocmEgKG1hbmthbWlzKTpNQUlMVE86bWFua2FtaXNAY2lzY28uY29tDQpERVNDUklQVElP TjtMQU5HVUFHRT1lbi1VUzpXZeKAmWxsIGNhbmNlbCB0aGlzIG1vbnRo4oCZcyBtZWV0aW5nIOKA kyBkcmFmdCANCiBjdXQtb2ZmIHRpbWVcLCBwZW9wbGUgYnVzeSAmIHdl4oCZcmUgdW5kZXIgcmV2 aWV3XCwgb3RoZXIgZHJhZnRzIGFyZSBwcm9ncg0KIGVzc2luZyBpbmRlcGVuZGVudGx5XG4NClVJ RDowNDAwMDAwMDgyMDBFMDAwNzRDNUI3MTAxQTgyRTAwODAwMDAwMDAwQzBENjhDQTZEQjBGRDUw MTAwMDAwMDAwMDAwMDAwMA0KIDAxMDAwMDAwMDNDQjExMjlCNERDOTJGNDc4Q0NFRDhFOTEwRjBD REVBDQpSRUNVUlJFTkNFLUlEO1RaSUQ9RWFzdGVybiBTdGFuZGFyZCBUaW1lOjIwMTkxMTA3VDEx MDAwMA0KU1VNTUFSWTtMQU5HVUFHRT1lbi1VUzpDYW5jZWxlZDogTW9udGhseSBSSUZUIFZpcnR1 YWwgSW50ZXJpbSBNZWV0aW5nDQpEVFNUQVJUO1RaSUQ9RWFzdGVybiBTdGFuZGFyZCBUaW1lOjIw MTkxMTA3VDExMDAwMA0KRFRFTkQ7VFpJRD1FYXN0ZXJuIFN0YW5kYXJkIFRpbWU6MjAxOTExMDdU MTIwMDAwDQpDTEFTUzpQVUJMSUMNClBSSU9SSVRZOjENCkRUU1RBTVA6MjAxOTEwMzFUMTc0OTMz Wg0KVFJBTlNQOlRSQU5TUEFSRU5UDQpTVEFUVVM6Q0FOQ0VMTEVEDQpTRVFVRU5DRToxMA0KTE9D QVRJT047TEFOR1VBR0U9ZW4tVVM6DQpYLU1JQ1JPU09GVC1DRE8tQVBQVC1TRVFVRU5DRToxMA0K WC1NSUNST1NPRlQtQ0RPLU9XTkVSQVBQVElEOi0xNTUwNDkzNzI1DQpYLU1JQ1JPU09GVC1DRE8t QlVTWVNUQVRVUzpGUkVFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURTVEFUVVM6RlJFRQ0KWC1N SUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JPU09GVC1DRE8tSU1QT1JUQU5D RToyDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6Mw0KWC1NSUNST1NPRlQtRE9OT1RGT1JXQVJE TUVFVElORzpGQUxTRQ0KWC1NSUNST1NPRlQtRElTQUxMT1ctQ09VTlRFUjpGQUxTRQ0KRU5EOlZF VkVOVA0KRU5EOlZDQUxFTkRBUg0K --_000_DM5PR05MB35488205E107E49240E73FBCD4630DM5PR05MB3548namp_-- From nobody Thu Oct 31 11:01: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 2C6F4120073; Thu, 31 Oct 2019 11:01:51 -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, 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 (1024-bit key) header.d=metaswitch.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 JiqvGUa1QBcu; Thu, 31 Oct 2019 11:01:47 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820098.outbound.protection.outlook.com [40.107.82.98]) (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 9D0B1120071; Thu, 31 Oct 2019 11:01:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M0cWYrUeQmkjuDtUEJ9a1PvAk8Vrh7e2Q/1acSkrDzj2SBm6K/UiHY/vgUgkQHwBTCHHTWgPBha01kwx06d3y7DDBVR58Ese66yuUtwkySpaB/tP4Fj25WGHGxmfbz7aC4h2P81GnrEOlbsbpNwfFZEyYp9ICmcLz4/zObLtU8M3ssgrBtw3NHbmC23fQK0GRTuBg++VLETxEfE9JDyv68djpMkRYlg1hg6swksAr0AwIhPPGWqVF/CqN6cZbHQ8ZdSzhPwb+I01YBX34nZQz1n2ZjsGYm6CqEajkPyMmQqJp9oOdpejUMxddyWpe6VonBcZLsXShmh6PJ2n8w/TBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vTlc54b02kAqkDVW8X4G46pwBlGtQbRvY7qhqt/5kKs=; b=hFkNEYwwhCg9oT/xtWFeJ8VtnsBxGyCCRoSu7uMldRIEdDi/yajiknZqk0jgEPCd5flDzXW1Eweb5MMUlWDyMDgqbxJp4oSaSxJ1RRQY1w800IdXl7rFAFof5qsbUeMubVAQVkpzlURl1o8HCIZhFAkwlrRazXBjqpgy7TWst12JUCLez8xfi8QsdVWx381ecsSqw57hNIYHwW0ydVGk9zr/KMLVPBUvP1tKISImgtf4m08TcR4kCH3fnK8S4oE2/tU6jOKUt00k5AGGDNzwWsnzuhT5ZjtadmOENYr5ZKdJ4WeOC14IifJqMULd/qy83Domd8RIKZw2QCCj53nJEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=metaswitch.com; dmarc=pass action=none header.from=metaswitch.com; dkim=pass header.d=metaswitch.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vTlc54b02kAqkDVW8X4G46pwBlGtQbRvY7qhqt/5kKs=; b=cDPF8C6fpB7ToSj55LoitIX5fD01dofvQXIXTzyZHDZEIG/0stXS1O7v+pO7luf+VQ0skQ2wc8XXHP5w3A6SX0wW51xXBRb0yu5BwasJMB5D4GTjVm77G0asTd0BdK8zgQ1/SUCiv1NqGt6Zk5jvPgytIX9bWIUnsFiEmQ8dKfA= Received: from BL0PR02MB4868.namprd02.prod.outlook.com (20.177.144.87) by BL0PR02MB3858.namprd02.prod.outlook.com (52.132.27.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.22; Thu, 31 Oct 2019 18:01:43 +0000 Received: from BL0PR02MB4868.namprd02.prod.outlook.com ([fe80::d967:8fc7:e08c:410c]) by BL0PR02MB4868.namprd02.prod.outlook.com ([fe80::d967:8fc7:e08c:410c%5]) with mapi id 15.20.2408.018; Thu, 31 Oct 2019 18:01:43 +0000 From: Jonathan Hardwick To: "rift-wg-chairs@ietf.org" , "draft-ietf-rift-rift.all@ietf.org" CC: "rtg-dir@ietf.org" , "rift@ietf.org" , =?utf-8?B?THVjIEFuZHLDqSBCdXJkZXQ=?= , Min Ye Thread-Topic: Routing directorate early review of draft-ietf-rift-rift Thread-Index: AdWQFFZ+nLkvsrpgQ+mvM9YJ2lkc7w== Date: Thu, 31 Oct 2019 18:01:43 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 73fb94ce-28bc-4077-894d-ddd1c8e3120c.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.137.6.53] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82600669-32f4-459d-a668-08d75e2c6378 x-ms-traffictypediagnostic: BL0PR02MB3858: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(39850400004)(136003)(396003)(376002)(366004)(199004)(189003)(54094003)(51444003)(74316002)(316002)(8676002)(256004)(66066001)(81156014)(86362001)(2501003)(2906002)(81166006)(5660300002)(6116002)(110136005)(14444005)(3846002)(33656002)(66556008)(76116006)(66946007)(606006)(66446008)(64756008)(66476007)(790700001)(52536014)(7736002)(6436002)(186003)(54896002)(486006)(25786009)(7696005)(966005)(55016002)(8936002)(6306002)(14454004)(99286004)(26005)(54906003)(6506007)(4326008)(476003)(236005)(71190400001)(478600001)(9326002)(102836004)(9686003)(71200400001)(60764002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR02MB3858; H:BL0PR02MB4868.namprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vaSm5WYkHuCiJV4qipIsTzVZ/A1NAdjhV5HDPgVdo9pFuBuRbKTAZFVKAm7AM5vECqTmmal8Vv3uioKxQRWQFP+aTHmbfwhSggvjRlXDTYCU9S0hg72miMbppmvlrxt/dIfse62rnPof+8F1m8pdhzlrjHcjhv+/LxJjZXt0izbmeHqVLnHcArhLEb4b056n/4c2lAb27FbqKnpe6iJ2PBV94+AI80gy45vvpm51TZa9BaUIb3Teq58u5+usqmdGNNsdaFmlcpnDQyWArTi3JDbKbH3KgiMQp8KAo6g3Q1O3XkYFHdFpmYeNa2yt1wHTxCDiaEVTL8/D9WNcIhowbuPQSEu8ug5PuZSpT4Usvci/p9JZjDba4z+7y2jNxTckXj+iC/bjyKkh9yzXqeo4v0F37moTwI/+Qpw9PrVZREmaNXpiGAtfLf/yXehhlv6GM+XpJmIqDH/B+gGSBZ64YyOioKu0RW2AZ1khWm/3Nt0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR02MB48689FA2D6B7C255DF11045D84630BL0PR02MB4868namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82600669-32f4-459d-a668-08d75e2c6378 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 18:01:43.5558 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ND1oEyQ938M0wRAPNsx9E8ZY6e2pcPY+rajJatCnEvt8MXWPReZlSw9Zj5cI0g//a3gF08gqbayL1k8tivasbQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB3858 Archived-At: Subject: [Rift] Routing directorate early review of draft-ietf-rift-rift 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, 31 Oct 2019 18:01:51 -0000 --_000_BL0PR02MB48689FA2D6B7C255DF11045D84630BL0PR02MB4868namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8NCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgdG8gZG8gYSBSb3V0aW5nIERpcmVjdG9yYXRl IOKAnGVhcmx5IHJldmlld+KAnSBvZiB0aGlzIGRyYWZ0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yaWZ0LXJpZnQvDQoNClRoZSByb3V0aW5nIGRpcmVjdG9y YXRlIHdpbGwsIG9uIHJlcXVlc3QgZnJvbSB0aGUgd29ya2luZyBncm91cCBjaGFpciwgcGVyZm9y bSBhbiDigJxlYXJseeKAnSByZXZpZXcgb2YgYSBkcmFmdCBiZWZvcmUgaXQgaXMgc3VibWl0dGVk IGZvciBwdWJsaWNhdGlvbiB0byB0aGUgSUVTRy4gVGhlIGVhcmx5IHJldmlldyBjYW4gYmUgcGVy Zm9ybWVkIGF0IGFueSB0aW1lIGR1cmluZyB0aGUgZHJhZnTigJlzIGxpZmV0aW1lIGFzIGEgd29y a2luZyBncm91cCBkb2N1bWVudC4gVGhlIHB1cnBvc2Ugb2YgdGhlIGVhcmx5IHJldmlldyBkZXBl bmRzIG9uIHRoZSBzdGFnZSB0aGF0IHRoZSBkb2N1bWVudCBoYXMgcmVhY2hlZC4gIEFzIHRoaXMg ZG9jdW1lbnQgaGFzIGFkdmFuY2VkIHRvIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLCBteSBmb2N1 cyBmb3IgdGhlIHJldmlldyB3YXMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlz IHJlYWR5IHRvIGJlIHB1Ymxpc2hlZC4gUGxlYXNlIGNvbnNpZGVyIG15IGNvbW1lbnRzIGFsb25n IHdpdGggdGhlIG90aGVyIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpGb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNl ZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGly DQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLXJpZnQtcmlmdA0KUmV2aWV3ZXI6IEpvbiBIYXJkd2lj aw0KUmV2aWV3IERhdGU6IDMxIE9jdCAyMDE5DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBU cmFjaw0KDQpTdW1tYXJ5DQpUaGFua3MgZm9yIHdyaXRpbmcgdGhpcyBkb2N1bWVudC4gIEl0IGlz IGEgdmVyeSBpbnRlcmVzdGluZyBhcHByb2FjaCBhbmQgSSByZWFsbHkgZW5qb3llZCBnZXR0aW5n IHRvIGdyaXBzIHdpdGggdGhlIGlkZWFzIHByZXNlbnRlZCBpbiB0aGUgZHJhZnQhDQpVbmZvcnR1 bmF0ZWx5LCBJIGhhdmUgc29tZSBjb25jZXJucyBhYm91dCB0aGUgZG9jdW1lbnQgYW5kIHRoaW5r IGl0IG5lZWRzIG1vcmUgd29yayBiZWZvcmUgYmVpbmcgc3VibWl0dGVkIHRvIHRoZSBJRVNHLiAg VGhlIHByb2JsZW0gaXMgdGhhdCBJIGZvdW5kIHRoZSBkb2N1bWVudCBoYXJkIHRvIHJlYWQsIGZv ciBzZXZlcmFsIHJlYXNvbnMuDQoNCiAgKiAgIEl0IGlzIHZlcnkgbGlnaHQgaW4gaXRzIHVzZSBv ZiBub3JtYXRpdmUgUkZDLTIxMTkgc3R5bGUgbGFuZ3VhZ2UuICBBbiBpbXBsZW1lbnRlciB3b3Vs ZCBoYXZlIHRvIGZpbGwgaW4gcXVpdGUgYSBmZXcgZ2FwcyBhbmQvb3IgbWFrZSBhc3N1bXB0aW9u cyBhYm91dCB2YXJpb3VzIHBhc3NhZ2VzLg0KICAqICAgVGhlIGRlZmluaXRpb24gb2YgdGhlIHBy b3RvY29sIGFuZCBzb21lIG9mIHRoZSBub3JtYXRpdmUgYmVoYXZpb3VyIGlzIGRlZmVycmVkIHRv IHRoZSBhcHBlbmRpY2VzLCB3aGVyZWFzIEkgd291bGQgZXhwZWN0IHRvIGVuY291bnRlciBpdCBl YXJseSBvbiBpbiB0aGUgdGV4dCwgd2l0aCBhbiBpbi1saW5lIGRpc2N1c3Npb24gb2YgdGhlIHB1 cnBvc2VzIG9mIHRoZSBtZXNzYWdlcyBhbmQgZmllbGRzLg0KICAqICAgSXQgc29tZXRpbWVzIHJl ZmVycyB0byBjb25jZXB0cyBvciB0ZXJtcyB0aGF0IGFyZSBlaXRoZXIgbm90IGRlZmluZWQgb3Ig aGF2ZSBub3QgeWV0IGJlZW4gaW50cm9kdWNlZCB0byB0aGUgcmVhZGVyLCBzdWdnZXN0aW5nIGFu IG9yZGVyaW5nIGlzc3VlIHdpdGhpbiB0aGUgdGV4dC4NCg0KSSB0aGluayB0aGF0IHRoZSBkb2N1 bWVudCBuZWVkcyB0byBiZSByZWZhY3RvcmVkIHNvbWV3aGF0IHRvIHNvbHZlIHRoZSBvcmRlcmlu ZyBpc3N1ZXMsIHVzZSBtb3JlIG5vcm1hdGl2ZSBsYW5ndWFnZSwgZWxpbWluYXRlIGFueSB0ZXh0 IHRoYXQgaXMgbm90IGFjdHVhbGx5IHJlbGV2YW50IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQg ZGVwbG95bWVudCBvZiB0aGUgcHJvdG9jb2wsIGFuZCBwdWxsIHRvZ2V0aGVyIHRoZSBub3JtYXRp dmUgZGVmaW5pdGlvbiBvZiB0aGUgcHJvdG9jb2wgaW50byBhIGNvbnRpZ3VvdXMgYmxvY2sgZWFy bHkgb24gaW4gdGhlIGRvY3VtZW50Lg0KDQpUaGUgb3RoZXIgaXNzdWUgaXMgdGhhdCwgYmVjYXVz ZSB0aGUgZG9jdW1lbnQgaXMgbGFyZ2UgYW5kIEkgZm91bmQgaXQgcmF0aGVyIGhhcmQgZ29pbmcs IEkgZGlkIG5vdCBoYXZlIHRpbWUgZG8gYSB0aG9yb3VnaCByZXZpZXcgYmV5b25kIHNlY3Rpb24g NS4zLiAgSeKAmWQgdGhlcmVmb3JlIGhhdmUgdG8gcmVjb21tZW5kIGFub3RoZXIgZGlyZWN0b3Jh dGUgcmV2aWV3IG9uY2Ugd2UgaGF2ZSBjb25jbHVkZWQgb24gdGhlIGlzc3VlcyBJ4oCZbSByYWlz aW5nIGJlbG93Lg0KDQpEZXRhaWxzDQpIZXJlIGFyZSBjb21tZW50cyBvbiB0aGUgc2VjdGlvbnMg dGhhdCBJIHdhcyBhYmxlIHRvIHJldmlldyBpbiBkZXRhaWwgYmVmb3JlIEkgcmFuIG91dCBvZiB0 aW1lLg0KDQpBYnN0cmFjdA0KSXMgaXQgcG9zc2libGUgdG8gcmVmb3JtYXQgdGhpcyBhcyBhIGxp c3Qgb2YgaXRlbXMgb24gbXVsdGlwbGUgbGluZXM/IEl0IHdvdWxkIHJlYWQgbW9yZSBjbGVhcmx5 Lg0KDQpTZWN0aW9uIDINCiJhbiBvcHRpbWFsIGFwcHJvYWNoIGRvZXMgbm90IHNlZW0gaG93ZXZl ciI6IHRoaXMgYXBwZWFycyB0byBiZSBhIHZhbHVlIGp1ZGdtZW50IHJhdGhlciB0aGFuIGNvbnNl bnN1cyBvcGluaW9uLCBhcHBlYXJpbmcgYXMgaXQgZG9lcyB3aXRob3V0IGNpdGF0aW9uLCBhbmQg bWF5IGJlIHBlcmNlaXZlZCBhcyB0cmVhZGluZyBvbiB0aGUgdG9lcyBvZiBvdGhlciBzdGFuZGFy ZGl6YXRpb24gZWZmb3J0cyBjdXJyZW50bHkgaW4gcHJvZ3Jlc3MgYXQgdGhlIElFVEYuIEkgc3Vn Z2VzdCB5b3Ugc2ltcGx5IHN0YXRlIHRoZSBmYWN0czogIlJJRlQgYXBwcm9hY2hlcyB0aGlzIHBy b2JsZW0gdXNpbmcgYSBtaXh0dXJlIG9mLi4uIg0KDQpTZWN0aW9uIDIuMQ0KVGhlIGZvcm0gb2Yg d29yZHMgaW4gdGhlIFJlcXVpcmVtZW50cyBMYW5ndWFnZSBib2lsZXJwbGF0ZSBoYXMgY2hhbmdl ZCByZWNlbnRseSAtIHNlZSBSRkMgODE3NC4NCg0KU2VjdGlvbiAzLjENClpUUCAtIGV4cGFuZCBh Y3JvbnltIG9uIGZpcnN0IHVzZS4NClRoZXJlIGlzIHBvdGVudGlhbCBmb3IgY29uZnVzaW9uIGJl dHdlZW4gTi1USUUgYW5kIE5vZGUgVElFISBJJ2QgcHJlZmVyICJOb3J0aCBUSUUiIGZvciB0aGUg Zm9ybWVyLg0KQW4gZXhhbXBsZSBvZiBjb25mdXNpb246IGlzIHRoZSAiU291dGggTm9kZSBUSUUi IHJlZmVycmVkIHRvIGluIHRoZSBkZWZpbml0aW9uIG9mICJTb3V0aCBSZWZsZWN0aW9uIiB0aGUg c2FtZSBhcyB0aGUgUy1USUUgcmVmZXJyZWQgdG8gaW4gdGhlIGRlZmluaXRpb24gb2YgIlRJRSI/ DQoiVGhlIGRvY3VtZW50IHNvbWV0aW1lcyBjYWxscyB0aGVtIGZsb29kIGxlYWRlcnMgYXMgd2Vs bC4iIEJ1dCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgeW91IGp1c3QgdXNlZCBvbmUgdGVybS4NCg0K U2VjdGlvbiA0DQpQZXJzb25hbGx5IEkgY291bGQgbGl2ZSB3aXRob3V0IHRoaXMgc2VjdGlvbg0K TWVyZ2UgUEVORDEgd2l0aCBOT05SRVF4IChvciBleHBsYWluIHRoZSBkaXN0aW5jdGlvbikNCg0K U2VjdGlvbiA1LjEuMyAtIDUuMS41DQpUaGlzIGRpc2N1c3Npb24gaXMgbm90IHBvc3NpYmxlIHRv IGZvbGxvdyBwcm9wZXJseSB1bnRpbCB5b3UgaGF2ZSBiZWVuIGludHJvZHVjZWQgdG8gcG9zaXRp dmUgJiBuZWdhdGl2ZSBkaXNhZ2dyZWdhdGlvbiBhbmQgc291dGhlcm4gcmVmbGVjdGlvbi4gIEFz IHN1Y2ggSSB3b25kZXIgaWYgaXQgcmVhbGx5IGJlbG9uZ3MgaW4gYSBzZWN0aW9uIGNhbGxlZCAi b3ZlcnZpZXciLg0KDQpTZWN0aW9uIDUuMi4yDQoNCiAgIEEgbm9kZSBjb25maWd1cmVkIHdpdGgg InVuZGVmaW5lZCIgUG9EIG1lbWJlcnNoaXAgTVVTVCwgYWZ0ZXINCiAgIGJ1aWxkaW5nIGZpcnN0 IG5vcnRoYm91bmQgdGhyZWUgd2F5IGFkamFjZW5jaWVzIHRvIGEgbm9kZSBiZWluZyBpbiBhDQog ICBkZWZpbmVkIFBvRCwgYWR2ZXJ0aXNlIHRoYXQgUG9EIGFzIHBhcnQgb2YgaXRzIExJRXMuICBJ biBjYXNlIHRoYXQNCiAgIGFkamFjZW5jeSBpcyBsb3N0LCBmcm9tIGFsbCBhdmFpbGFibGUgbm9y dGhib3VuZCB0aHJlZSB3YXkNCiAgIGFkamFjZW5jaWVzIHRoZSBub2RlIHdpdGggdGhlIGhpZ2hl c3QgU3lzdGVtIElEIGFuZCBkZWZpbmVkIFBvRCBpcw0KICAgY2hvc2VuLg0KDQpJdCBzZWVtcyBv ZGQgdGhhdCB0aGUgY2hvaWNlIG9mIGFkdmVydGlzZWQgcG9kIGlzIGF0IGZpcnN0IG5vbi1kZXRl cm1pbmlzdGljIChyYWNlIHRvIHRoZSBmaXJzdCBhZGphY2VuY3kpIGFuZCB0aGVuLCBvbmx5IGlm IHRoaXMgaW5pdGlhbCBhZGphY2VuY3kgaXMgbG9zdCwgdGhlIGNob2ljZSBvZiBwb2QgYmVjb21l cyBkZXRlcm1pbmlzdGljLiBXaHkgbm90IG1ha2UgaXQgZGV0ZXJtaW5pc3RpYyB0aGUgd2hvbGUg dGltZT8NCg0KU2VjdGlvbiA1LjIuMy4yDQoNCkluIHRoZSBleGFtcGxlIFRJRXMsICJTcGluZTIx IiBzaG91bGQgYmUgIlRvRiAyMSIgdG8gYWdyZWUgd2l0aCB0aGUgbm9tZW5jbGF0dXJlIG9mIGZp Z3VyZSAyLiAgRGl0dG8gaW4gdGFibGUgNCAoc2VjdGlvbiA1LjIuMy40KQ0KSW4gU3BpbmUgMTEx J3MgTm9kZS1TLVRJRSwgSSBhbSBub3Qgc3VyZSB0aGF0IHRoZSBsaW5rcyguLi4pIHNob3VsZCBi ZSBnaXZlbiBmb3IgZWFjaCBuZWlnaGJvci4NCg0KU2VjdGlvbiA1LjIuMy41DQoiSXQgc2hvdWxk IG9ubHkgc2V0IGl0IGluIHRoZSBzb3V0aGJvdW5kIGRpcmVjdGlvbi4iICAtIFNIT1VMRD8NCg0K U2VjdGlvbiA1LjIuMy44DQpEZWZpbmUgTi1TUEYgb24gZmlyc3QgdXNlDQoNClNlY3Rpb24gNS4y LjQNCiJBIG5vZGUgaGFzIHRocmVlIHNvdXJjZXMiIC0gSSBzZWUgb25seSB0d28gbGlzdGVkLg0K IldlIHVzZSBzaW1wbGUsIGZhbWlsaWFyIFNQRiBhbGdvcml0aG1zIGhlcmUuLi4iIC0gaXMgdGhl IHVzZSBvZiB0aG9zZSBhbGdvcml0aG1zIHN1cHBvc2VkIHRvIGJlIG5vcm1hdGl2ZT8gT3IgYXJl IHlvdSBqdXN0IGdpdmluZyBhbiBleGFtcGxlIGFuZCBsZWF2aW5nIG1lIHRvIGNob29zZSBteSBv d24gYWxnb3JpdGhtPyAgSWYgU1BGIGlzIG5vcm1hdGl2ZSB0aGVuIHlvdSBuZWVkIHRvIHNwZWNp ZnkgaXQgdXNpbmcgbm9ybWF0aXZlIGxhbmd1YWdlIG9yIGluY2x1ZGUgYSBub3JtYXRpdmUgcmVm ZXJlbmNlIHRvIGl0Lg0KDQpTZWN0aW9uIDUuMi40LjENClBsZWFzZSBkZWZpbmUgdGhlIHRlcm1z ICJzb3V0aCBwcmVmaXgiIGFuZCAibm9ydGggcHJlZml4Ig0KIlN1cGVyc3VtaW5nIiBpcyBub3Qg YSB3b3JkIEkgcmVjb2duaXNlLiAgVXNlICJvciBhIG5vbi1kZWZhdWx0IHByZWZpeCB3aGljaCBj b250YWlucyB0aGlzIHNvdXRoIHByZWZpeCINCiJ0aGUgbm9kZSBkb2VzIG5vdC4uLiIgLT4gInRo ZSBjb21wdXRpbmcgbm9kZSBkb2VzIG5vdC4uLiINCg0KU2VjdGlvbiA1LjIuNC4yDQoiUy1TUEYg dXNlcyBub3J0aGJvdW5kIGFkamFjZW5jaWVzIGluIG5vZGUgTi1USUVzIHRvIHZlcmlmeSBiYWNr bGluayBjb25uZWN0aXZpdHkiIC0gdGhpcyBzdGF0ZW1lbnQgbmVlZHMgdG8gYmUgcmVjYXN0IGlu dG8gbm9ybWF0aXZlIGxhbmd1YWdlIHVzaW5nIFJGQyAyMTE5IHRlcm1zLiAgIkEgbm9kZSBNVVNU IHZlcmlmeSBiYWNrbGluayBjb25uZWN0aXZpdHkgLi4uIEVsc2UgaXQgTVVTVCBOT1QgaW5jbHVk ZSB0aGUgbGluay4uLi4gRXRjLiINClNhbWUgY29tbWVudCBhcHBsaWVzIGluIG1hbnkgcGxhY2Vz IHRocm91Z2hvdXQgdGhlIGRvY3VtZW50Lg0KDQpTZWN0aW9uIDUuMi40LjMNCldoYXQgaXMgYSBg InJpbmcgcHJvdGVjdGlvbiIgc2NoZW1lYD8NCkFyZSBFLVcgbGlua3MgcGVybWl0dGVkIGJldHdl ZW4gcGxhbmVzPw0KTm90IHN1cmUgd2hhdCB0aGlzIGlzIHRlbGxpbmcgbWU6ICJVc2luZyBzb3V0 aCBwcmVmaXhlcyBvdmVyIGhvcml6b250YWwgbGlua3MgaXMgb3B0aW9uYWwuLi4iIC0gaXMgdGhh dCBPUFRJT05BTCBhcyBpbiBSRkMgMjExOT8gIERvIHlvdSBtZWFuIHRoYXQgbXkgaW1wbGVtZW50 YXRpb24gY2FuIGlnbm9yZSB0aGVtPyBPciBub3QgYWR2ZXJ0aXNlIHRoZW0/IE9yIHRoYXQgdGhl IG5ldHdvcmsgb3BlcmF0b3IgZG9lcyBub3QgaGF2ZSB0byBjYWJsZSB0aGVtPw0KDQpTZWN0aW9u IDUuMi40LjQNCiJFdmVuIHRob3VnaCBhIFRvRiBub2RlIGNvdWxkDQogICBiZSB0ZW1wdGVkIHRv IHVzZSB0aG9zZSBsaW5rcyBkdXJpbmcgc291dGhib3VuZCBTUEYgdGhpcyBNVVNUIE5PVCBiZQ0K ICAgYXR0ZW1wdGVkIHNpbmNlIGl0IG1heSBsZWFkIGluLCBlLmcuIGFueWNhc3QgY2FzZXMgdG8g cm91dGluZyBsb29wcy4iDQoNClRoaXMgaXMgdG9vIHZlcmJvc2UgYW5kIG9idHVzZS4gIEkgY2Fu bm90IHNlZSBob3cgYW55Y2FzdCBjYXNlcyBsZWFkIHRvIHJvdXRpbmcgbG9vcHMgYW5kIEkgZG9u J3Qga25vdyBpZiBJIG5lZWQgdG8gdW5kZXJzdGFuZCB3aHkgb3Igbm90LiAgU3VnZ2VzdDoNCg0K IkEgVG9GIG5vZGUgTVVTVCBOT1QgaW5jbHVkZSBlYXN0LXdlc3QgbGlua3MgaW4gaXRzIHNvdXRo LVNQRiBjYWxjdWxhdGlvbi4iDQoNClRoaXMgc2VjdGlvbiBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0 aGF0IEUtVyBsaW5rcyBhdCB0aGUgVG9GIHdpbGwgbmV2ZXIgYmUgdXNlZCBmb3IgZm9yd2FyZGlu ZyBkYXRhIC0gaXMgdGhhdCB0cnVlPyAgVGhleSBhcmUgdXNlZCBmb3IgY29udHJvbCBwbGFuZSBv bmx5Pw0KDQoiQW4gaW1wbGVtZW50YXRpb24gY291bGQgdHJ5IC4uLiBidXQgdGhlIGRldGFpbHMg YXJlIG91dHNpZGUgdGhpcyBzcGVjaWZpY2F0aW9uIiAtIHNvIHdoeSBtZW50aW9uIGl0Pw0KDQpT ZWN0aW9uIDUuMi41LjENCiJBIERBRyBjb21wdXRhdGlvbiIgLSBleHBhbmQgREFHLg0KDQoiTmVp dGhlcg0KICAgICAgIGlzIGl0IG5lY2Vzc2FyeSBmb3IgdGhlIHJlY2VpdmluZyBub2RlIHRvIHJl ZmxlY3QgdGhlDQogICAgICAgZGlzYWdncmVnYXRlZCBwcmVmaXhlcyBiYWNrIG92ZXIgaXRzIGFk amFjZW5jaWVzIHRvIG5vZGVzIGF0IHRoZQ0KICAgICAgIGxldmVsIGZyb20gd2hpY2ggaXQgd2Fz IHJlY2VpdmVkLiINCg0KUGxlYXNlIHJlc3RhdGUgdGhpcyB1c2luZyBSRkMgMjExOSBsYW5ndWFn ZS4NCg0KSG93IGNhbiB3ZSBndWFyYW50ZWUgdGhhdCBhIHNhbWUtbGV2ZWwgbm9kZSBkb2VzIG5v dCBoYXZlIGEgbmV4dCBob3AgdG8gYSBnaXZlbiBwcmVmaXggdGhhdCBpcyB1bmtub3duIHRvIHRo ZSBub2RlIGRvaW5nIHRoZSBjb21wdXRhdGlvbj8gIElmIFggcmVhY2hlcyBQIHZpYSBOMSBhbmQg TjIsIFkgKGF0IHRoZSBzYW1lIGxldmVsIGFzIFgpIGNhbiByZWFjaCBQIHZpYSBOMyBidXQgWCBk b2VzIG5vdCBrbm93IHRoaXMgYW5kIGFzc3VtZXMgWSBjYW5ub3QgcmVhY2ggUCBiZWNhdXNlIFkg aXMgbm90IGFkamFjZW50IHRvIE4xIGFuZCBOMiwgdGhlbiBYIHVubmVjZXNzYXJpbHkgZGlzYWdn cmVnYXRlcyBQIHBvc2l0aXZlbHkuICBGb3IgaW5zdGFuY2UgaWYgWCdzIGxpbmsgdG8gTjMgaGFz IGZhaWxlZCBhbmQgWSdzIGxpbmtzIHRvIE4xIGFuZCBOMiBoYXZlIGZhaWxlZC4NCg0KIkVhY2gg ZW50cnkgaXMgYSBsaXN0IG9mIHNvdXRoIG5laWdoYm9yIG9mIFggYW5kIGEgbGlzdCBvZiBub2Rl cw0KICAgICAgIG9mIFgubGV2ZWwgdGhhdCBjYW4ndCByZWFjaCB0aGF0IG5laWdoYm9yIg0KDQpU aGluayB0aGlzIHNob3VsZCBzYXkNCg0KIkVhY2ggZW50cnkgaW4gdGhlIHNldCBpcyBhIHNvdXRo IG5laWdoYm9yIG9mIFggYW5kIGEgbGlzdCBvZiBub2Rlcw0KICAgICAgIG9mIFgubGV2ZWwgdGhh dCBjYW4ndCByZWFjaCB0aGF0IG5laWdoYm9yIg0KDQoiWCBkb2VzIG5vdCB0byBkaXNhZ2dyZWdh dGUgYW55IHByZWZpeGVzIiAtPiAiIlggZG9lcyBub3QgZGlzYWdncmVnYXRlIGFueSBwcmVmaXhl cy4iIg0KDQoiVGhlIFBvRCBjb250YWluaW5nIHRoZSBwcmVmaXggd2lsbCBwcmVmZXIgc291dGhi b3VuZCBhbnl3YXkuIiAtIEkgZGlkbid0IHVuZGVyc3RhbmQgdGhlIHBvaW50LiBJcyBpdCBuZWNl c3NhcnkgZm9yIG1lIHRvIHVuZGVyc3RhbmQgaXQ/IFBsZWFzZSBleHBhbmQgb3IgZGVsZXRlIHRo ZSBzZW50ZW5jZSBpZiBpdCdzIG5vdCBuZWNlc3NhcnkuDQoNClNlY3Rpb24gNS4yLjYNCiJzdWNo IGFzIG1vYmlsaXR5IHBlciBzZWN0aW9uIDUuMy4zIG5lY2Vzc2FyeSIgLSBkZWxldGUgIm5lY2Vz c2FyeSIuDQoidGllcyBhcmUgYnJva2VuIGJhc2VkIHVwb24gdHlwZSBmaXJzdCBhbmQgdGhlbiBk aXN0YW5jZSBhbmQgZnVydGhlciBhdHRyaWJ1dGVzIiAtIEkgZG9uJ3Qgc2VlIG1lbnRpb24gb2Yg ZnVydGhlciBhdHRyaWJ1dGVzIGluIHRoZSBwcm9wb3NlZCBhbGdvcml0aG0uDQoNCiJUaGUgbmV4 dGhvcA0KICAgYWRqYWNlbmNpZXMgZm9yIGEgbmVnYXRpdmUgcHJlZml4IGFyZSBpbmhlcml0ZWQg ZnJvbSB0aGUgbG9uZ2VzdA0KICAgcHJlZml4IHRoYXQgYWdncmVnYXRlcyBpdCIgLSBzdWdnZXN0 IGNoYW5naW5nIHRvICJsb25nZXN0IHBvc2l0aXZlIHByZWZpeCINCg0KImFsbCBlbnRyaWVzIG9m IHRoZSBmYXRoZXIiIC0+ICJhbGwgZW50cmllcyBvZiB0aGUgcGFyZW50Ig0KDQpTZWN0aW9uIDUu Mi43LjMNCiJ3ZSBoYXZlIHRvIGRlY2lkZSB3aGV0aGVyIG5vZGUgWSBpcyBhdCB0aGUgc2FtZSBs ZXZlbCBhcyBJLCBKIG9yIGF0DQogICB0aGUgc2FtZSBsZXZlbCBhcyBZIGFuZCBjb25zZXF1ZW50 bHksIFggaXMgc291dGggb2YgaXQuIg0KDQpJIGNvdWxkIG5vdCBwYXJzZSB0aGlzLiAgSSB0aGlu ayB5b3UgbWlnaHQgbWVhbiB0aGlzOg0KDQoid2UgaGF2ZSB0byBkZWNpZGUgd2hldGhlciBub2Rl IFkgaXMgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgSSwgSg0KICAoYW5kIGNvbnNlcXVlbnRseSBYIGlz IHNvdXRoIG9mIGl0KSBvciBhdCB0aGUgc2FtZSBsZXZlbCBhcyBYLiINCg0KU2VjdGlvbiA1LjIu Ny40DQpIb3cgZG9lcyBhIFRvRiBub2RlIGtub3cgd2hhdCB2YWx1ZSB0byBhZHZlcnRpc2UgaW4g aXRzIExFVkVMX1ZBTFVFPw0K --_000_BL0PR02MB48689FA2D6B7C255DF11045D84630BL0PR02MB4868namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjUyNjM5MzU3 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODM1OTQx MjQgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SGVsbG88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIHRvIGRvIGEgUm91dGluZyBEaXJlY3Rv cmF0ZSDigJxlYXJseSByZXZpZXfigJ0gb2YgdGhpcyBkcmFmdDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yaWZ0LXJpZnQvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJpZnQtcmlmdC88L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIj5UaGUgcm91dGluZyBkaXJlY3RvcmF0ZSB3aWxsLCBvbiByZXF1ZXN0 IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXIsIHBlcmZvcm0gYW4g4oCcZWFybHnigJ0gcmV2 aWV3IG9mIGEgZHJhZnQgYmVmb3JlIGl0IGlzIHN1Ym1pdHRlZCBmb3IgcHVibGljYXRpb24gdG8g dGhlIElFU0cuIFRoZSBlYXJseSByZXZpZXcgY2FuIGJlIHBlcmZvcm1lZCBhdCBhbnkgdGltZSBk dXJpbmcgdGhlDQogZHJhZnTigJlzIGxpZmV0aW1lIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVu dC4gVGhlIHB1cnBvc2Ugb2YgdGhlIGVhcmx5IHJldmlldyBkZXBlbmRzIG9uIHRoZSBzdGFnZSB0 aGF0IHRoZSBkb2N1bWVudCBoYXMgcmVhY2hlZC4mbmJzcDsgQXMgdGhpcyBkb2N1bWVudCBoYXMg YWR2YW5jZWQgdG8gd29ya2luZyBncm91cCBsYXN0IGNhbGwsIG15IGZvY3VzIGZvciB0aGUgcmV2 aWV3IHdhcyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgcmVhZHkNCiB0byBi ZSBwdWJsaXNoZWQuIFBsZWFzZSBjb25zaWRlciBteSBjb21tZW50cyBhbG9uZyB3aXRoIHRoZSBv dGhlciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PkZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVh c2Ugc2VlIOKAizxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3Ry YWMvd2lraS9SdGdEaXIiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMv d2lraS9SdGdEaXI8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5Eb2N1bWVudDogZHJhZnQtaWV0Zi1y aWZ0LXJpZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+UmV2aWV3ZXI6IEpvbiBIYXJkd2ljazxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5SZXZpZXcgRGF0ZTog MzEgT2N0IDIwMTk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+SW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2s8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tR0IiPlN1bW1hcnk8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoYW5rcyBmb3Igd3JpdGluZyB0aGlz IGRvY3VtZW50LiZuYnNwOyBJdCBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgYXBwcm9hY2ggYW5kIEkg cmVhbGx5IGVuam95ZWQgZ2V0dGluZyB0byBncmlwcyB3aXRoIHRoZSBpZGVhcyBwcmVzZW50ZWQg aW4gdGhlIGRyYWZ0ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj5VbmZvcnR1bmF0ZWx5LCBJIGhhdmUgc29tZSBjb25jZXJucyBh Ym91dCB0aGUgZG9jdW1lbnQgYW5kIHRoaW5rIGl0IG5lZWRzIG1vcmUgd29yayBiZWZvcmUgYmVp bmcgc3VibWl0dGVkIHRvIHRoZSBJRVNHLiZuYnNwOyBUaGUgcHJvYmxlbSBpcyB0aGF0IEkgZm91 bmQgdGhlIGRvY3VtZW50IGhhcmQgdG8gcmVhZCwgZm9yIHNldmVyYWwgcmVhc29ucy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gbGFuZz0iRU4tR0IiPkl0IGlzIHZlcnkgbGlnaHQg aW4gaXRzIHVzZSBvZiBub3JtYXRpdmUgUkZDLTIxMTkgc3R5bGUgbGFuZ3VhZ2UuJm5ic3A7IEFu IGltcGxlbWVudGVyIHdvdWxkIGhhdmUgdG8gZmlsbCBpbiBxdWl0ZSBhIGZldyBnYXBzIGFuZC9v ciBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHZhcmlvdXMgcGFzc2FnZXMuPG86cD48L286cD48L3Nw YW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow Y207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgZGVmaW5p dGlvbiBvZiB0aGUgcHJvdG9jb2wgYW5kIHNvbWUgb2YgdGhlIG5vcm1hdGl2ZSBiZWhhdmlvdXIg aXMgZGVmZXJyZWQgdG8gdGhlIGFwcGVuZGljZXMsIHdoZXJlYXMgSSB3b3VsZCBleHBlY3QgdG8g ZW5jb3VudGVyIGl0IGVhcmx5IG9uIGluIHRoZSB0ZXh0LCB3aXRoDQogYW4gaW4tbGluZSBkaXNj dXNzaW9uIG9mIHRoZSBwdXJwb3NlcyBvZiB0aGUgbWVzc2FnZXMgYW5kIGZpZWxkcy48bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gbGFuZz0iRU4tR0IiPkl0 IHNvbWV0aW1lcyByZWZlcnMgdG8gY29uY2VwdHMgb3IgdGVybXMgdGhhdCBhcmUgZWl0aGVyIG5v dCBkZWZpbmVkIG9yIGhhdmUgbm90IHlldCBiZWVuIGludHJvZHVjZWQgdG8gdGhlIHJlYWRlciwg c3VnZ2VzdGluZyBhbiBvcmRlcmluZyBpc3N1ZSB3aXRoaW4gdGhlIHRleHQuPG86cD48L286cD48 L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj5JIHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IG5lZWRzIHRvIGJlIHJlZmFj dG9yZWQgc29tZXdoYXQgdG8gc29sdmUgdGhlIG9yZGVyaW5nIGlzc3VlcywgdXNlIG1vcmUgbm9y bWF0aXZlIGxhbmd1YWdlLCBlbGltaW5hdGUgYW55IHRleHQgdGhhdCBpcyBub3QgYWN0dWFsbHkg cmVsZXZhbnQgdG8gdGhlIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50IG9mIHRoZSBwcm90 b2NvbCwNCiBhbmQgcHVsbCB0b2dldGhlciB0aGUgbm9ybWF0aXZlIGRlZmluaXRpb24gb2YgdGhl IHByb3RvY29sIGludG8gYSBjb250aWd1b3VzIGJsb2NrIGVhcmx5IG9uIGluIHRoZSBkb2N1bWVu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoZSBvdGhlciBpc3N1ZSBpcyB0aGF0LCBiZWNhdXNlIHRo ZSBkb2N1bWVudCBpcyBsYXJnZSBhbmQgSSBmb3VuZCBpdCByYXRoZXIgaGFyZCBnb2luZywgSSBk aWQgbm90IGhhdmUgdGltZSBkbyBhIHRob3JvdWdoIHJldmlldyBiZXlvbmQgc2VjdGlvbiA1LjMu Jm5ic3A7IEnigJlkIHRoZXJlZm9yZSBoYXZlIHRvIHJlY29tbWVuZCBhbm90aGVyIGRpcmVjdG9y YXRlIHJldmlldyBvbmNlIHdlDQogaGF2ZSBjb25jbHVkZWQgb24gdGhlIGlzc3VlcyBJ4oCZbSBy YWlzaW5nIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiI+RGV0YWlsczxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SGVy ZSBhcmUgY29tbWVudHMgb24gdGhlIHNlY3Rpb25zIHRoYXQgSSB3YXMgYWJsZSB0byByZXZpZXcg aW4gZGV0YWlsIGJlZm9yZSBJIHJhbiBvdXQgb2YgdGltZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkFi c3RyYWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPklzIGl0IHBvc3NpYmxlIHRvIHJlZm9ybWF0IHRoaXMgYXMgYSBsaXN0IG9m IGl0ZW1zIG9uIG11bHRpcGxlIGxpbmVzPyBJdCB3b3VsZCByZWFkIG1vcmUgY2xlYXJseS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPlNlY3Rpb24gMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mcXVvdDthbiBvcHRpbWFsIGFwcHJvYWNo IGRvZXMgbm90IHNlZW0gaG93ZXZlciZxdW90OzogdGhpcyBhcHBlYXJzIHRvIGJlIGEgdmFsdWUg anVkZ21lbnQgcmF0aGVyIHRoYW4gY29uc2Vuc3VzIG9waW5pb24sIGFwcGVhcmluZyBhcyBpdCBk b2VzIHdpdGhvdXQgY2l0YXRpb24sIGFuZCBtYXkgYmUgcGVyY2VpdmVkIGFzIHRyZWFkaW5nIG9u IHRoZSB0b2VzIG9mIG90aGVyIHN0YW5kYXJkaXphdGlvbg0KIGVmZm9ydHMgY3VycmVudGx5IGlu IHByb2dyZXNzIGF0IHRoZSBJRVRGLiBJIHN1Z2dlc3QgeW91IHNpbXBseSBzdGF0ZSB0aGUgZmFj dHM6ICZxdW90O1JJRlQgYXBwcm9hY2hlcyB0aGlzIHByb2JsZW0gdXNpbmcgYSBtaXh0dXJlIG9m Li4uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TZWN0aW9uIDIuMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgZm9ybSBv ZiB3b3JkcyBpbiB0aGUgUmVxdWlyZW1lbnRzIExhbmd1YWdlIGJvaWxlcnBsYXRlIGhhcyBjaGFu Z2VkIHJlY2VudGx5IC0gc2VlIFJGQyA4MTc0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+U2VjdGlvbiAz LjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+WlRQIC0gZXhwYW5kIGFjcm9ueW0gb24gZmlyc3QgdXNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGVyZSBp cyBwb3RlbnRpYWwgZm9yIGNvbmZ1c2lvbiBiZXR3ZWVuIE4tVElFIGFuZCBOb2RlIFRJRSEgSSdk IHByZWZlciAmcXVvdDtOb3J0aCBUSUUmcXVvdDsgZm9yIHRoZSBmb3JtZXIuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkFuIGV4 YW1wbGUgb2YgY29uZnVzaW9uOiBpcyB0aGUgJnF1b3Q7U291dGggTm9kZSBUSUUmcXVvdDsgcmVm ZXJyZWQgdG8gaW4gdGhlIGRlZmluaXRpb24gb2YgJnF1b3Q7U291dGggUmVmbGVjdGlvbiZxdW90 OyB0aGUgc2FtZSBhcyB0aGUgUy1USUUgcmVmZXJyZWQgdG8gaW4gdGhlIGRlZmluaXRpb24gb2Yg JnF1b3Q7VElFJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mcXVvdDtUaGUgZG9jdW1lbnQgc29tZXRpbWVzIGNhbGxz IHRoZW0gZmxvb2QgbGVhZGVycyBhcyB3ZWxsLiZxdW90OyBCdXQgaXQgd291bGQgYmUgYmV0dGVy IGlmIHlvdSBqdXN0IHVzZWQgb25lIHRlcm0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TZWN0aW9uIDQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+UGVyc29uYWxseSBJIGNvdWxkIGxpdmUgd2l0aG91dCB0aGlzIHNlY3Rpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ TWVyZ2UgUEVORDEgd2l0aCBOT05SRVF4IChvciBleHBsYWluIHRoZSBkaXN0aW5jdGlvbik8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPlNlY3Rpb24gNS4xLjMgLSA1LjEuNTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGlzIGRpc2N1c3Np b24gaXMgbm90IHBvc3NpYmxlIHRvIGZvbGxvdyBwcm9wZXJseSB1bnRpbCB5b3UgaGF2ZSBiZWVu IGludHJvZHVjZWQgdG8gcG9zaXRpdmUgJmFtcDsgbmVnYXRpdmUgZGlzYWdncmVnYXRpb24gYW5k IHNvdXRoZXJuIHJlZmxlY3Rpb24uJm5ic3A7IEFzIHN1Y2ggSSB3b25kZXIgaWYgaXQgcmVhbGx5 IGJlbG9uZ3MgaW4gYSBzZWN0aW9uIGNhbGxlZCAmcXVvdDtvdmVydmlldyZxdW90Oy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPlNlY3Rpb24gNS4yLjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNw OyBBIG5vZGUgY29uZmlndXJlZCB3aXRoICZxdW90O3VuZGVmaW5lZCZxdW90OyBQb0QgbWVtYmVy c2hpcCBNVVNULCBhZnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgYnVpbGRpbmcgZmlyc3Qgbm9ydGhi b3VuZCB0aHJlZSB3YXkgYWRqYWNlbmNpZXMgdG8gYSBub2RlIGJlaW5nIGluIGE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7Jm5ic3A7IGRlZmluZWQgUG9ELCBhZHZlcnRpc2UgdGhhdCBQb0QgYXMgcGFydCBvZiBpdHMg TElFcy4mbmJzcDsgSW4gY2FzZSB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBhZGphY2VuY3kgaXMg bG9zdCwgZnJvbSBhbGwgYXZhaWxhYmxlIG5vcnRoYm91bmQgdGhyZWUgd2F5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNw OyZuYnNwOyBhZGphY2VuY2llcyB0aGUgbm9kZSB3aXRoIHRoZSBoaWdoZXN0IFN5c3RlbSBJRCBh bmQgZGVmaW5lZCBQb0QgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IGNob3Nlbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPkl0IHNlZW1zIG9kZCB0aGF0IHRoZSBjaG9pY2Ugb2YgYWR2ZXJ0aXNlZCBwb2QgaXMg YXQgZmlyc3Qgbm9uLWRldGVybWluaXN0aWMgKHJhY2UgdG8gdGhlIGZpcnN0IGFkamFjZW5jeSkg YW5kIHRoZW4sIG9ubHkgaWYgdGhpcyBpbml0aWFsIGFkamFjZW5jeSBpcyBsb3N0LCB0aGUgY2hv aWNlIG9mIHBvZCBiZWNvbWVzIGRldGVybWluaXN0aWMuIFdoeSBub3QgbWFrZSBpdCBkZXRlcm1p bmlzdGljDQogdGhlIHdob2xlIHRpbWU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TZWN0aW9uIDUuMi4z LjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPkluIHRoZSBleGFtcGxlIFRJRXMsICZxdW90O1NwaW5lMjEm cXVvdDsgc2hvdWxkIGJlICZxdW90O1RvRiAyMSZxdW90OyB0byBhZ3JlZSB3aXRoIHRoZSBub21l bmNsYXR1cmUgb2YgZmlndXJlIDIuJm5ic3A7IERpdHRvIGluIHRhYmxlIDQgKHNlY3Rpb24gNS4y LjMuNCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+SW4gU3BpbmUgMTExJ3MgTm9kZS1TLVRJRSwgSSBhbSBub3Qgc3VyZSB0aGF0 IHRoZSBsaW5rcyguLi4pIHNob3VsZCBiZSBnaXZlbiBmb3IgZWFjaCBuZWlnaGJvci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPlNlY3Rpb24gNS4yLjMuNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mcXVvdDtJdCBzaG91bGQgb25seSBz ZXQgaXQgaW4gdGhlIHNvdXRoYm91bmQgZGlyZWN0aW9uLiZxdW90OyZuYnNwOyAtIFNIT1VMRD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPlNlY3Rpb24gNS4yLjMuODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5EZWZpbmUgTi1TUEYgb24g Zmlyc3QgdXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TZWN0aW9uIDUuMi40PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZxdW90O0Eg bm9kZSBoYXMgdGhyZWUgc291cmNlcyZxdW90OyAtIEkgc2VlIG9ubHkgdHdvIGxpc3RlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+JnF1b3Q7V2UgdXNlIHNpbXBsZSwgZmFtaWxpYXIgU1BGIGFsZ29yaXRobXMgaGVyZS4uLiZx dW90OyAtIGlzIHRoZSB1c2Ugb2YgdGhvc2UgYWxnb3JpdGhtcyBzdXBwb3NlZCB0byBiZSBub3Jt YXRpdmU/IE9yIGFyZSB5b3UganVzdCBnaXZpbmcgYW4gZXhhbXBsZSBhbmQgbGVhdmluZyBtZSB0 byBjaG9vc2UgbXkgb3duIGFsZ29yaXRobT8mbmJzcDsgSWYgU1BGIGlzIG5vcm1hdGl2ZSB0aGVu IHlvdSBuZWVkDQogdG8gc3BlY2lmeSBpdCB1c2luZyBub3JtYXRpdmUgbGFuZ3VhZ2Ugb3IgaW5j bHVkZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TZWN0 aW9uIDUuMi40LjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+UGxlYXNlIGRlZmluZSB0aGUgdGVybXMgJnF1b3Q7c291dGggcHJl Zml4JnF1b3Q7IGFuZCAmcXVvdDtub3J0aCBwcmVmaXgmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+JnF1b3Q7U3VwZXJz dW1pbmcmcXVvdDsgaXMgbm90IGEgd29yZCBJIHJlY29nbmlzZS4mbmJzcDsgVXNlICZxdW90O29y IGEgbm9uLWRlZmF1bHQgcHJlZml4IHdoaWNoIGNvbnRhaW5zIHRoaXMgc291dGggcHJlZml4JnF1 b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPiZxdW90O3RoZSBub2RlIGRvZXMgbm90Li4uJnF1b3Q7IC0mZ3Q7ICZxdW90O3Ro ZSBjb21wdXRpbmcgbm9kZSBkb2VzIG5vdC4uLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+U2Vj dGlvbiA1LjIuNC4yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPiZxdW90O1MtU1BGIHVzZXMgbm9ydGhib3VuZCBhZGphY2VuY2ll cyBpbiBub2RlIE4tVElFcyB0byB2ZXJpZnkgYmFja2xpbmsgY29ubmVjdGl2aXR5JnF1b3Q7IC0g dGhpcyBzdGF0ZW1lbnQgbmVlZHMgdG8gYmUgcmVjYXN0IGludG8gbm9ybWF0aXZlIGxhbmd1YWdl IHVzaW5nIFJGQyAyMTE5IHRlcm1zLiZuYnNwOyAmcXVvdDtBIG5vZGUgTVVTVCB2ZXJpZnkgYmFj a2xpbmsgY29ubmVjdGl2aXR5IC4uLiBFbHNlDQogaXQgTVVTVCBOT1QgaW5jbHVkZSB0aGUgbGlu ay4uLi4gRXRjLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TYW1lIGNvbW1lbnQgYXBwbGllcyBpbiBtYW55IHBsYWNl cyB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlY3Rpb24gNS4y LjQuMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj5XaGF0IGlzIGEgYCZxdW90O3JpbmcgcHJvdGVjdGlvbiZxdW90OyBzY2hlbWVg PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj5BcmUgRS1XIGxpbmtzIHBlcm1pdHRlZCBiZXR3ZWVuIHBsYW5lcz88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Tm90 IHN1cmUgd2hhdCB0aGlzIGlzIHRlbGxpbmcgbWU6ICZxdW90O1VzaW5nIHNvdXRoIHByZWZpeGVz IG92ZXIgaG9yaXpvbnRhbCBsaW5rcyBpcyBvcHRpb25hbC4uLiZxdW90OyAtIGlzIHRoYXQgT1BU SU9OQUwgYXMgaW4gUkZDIDIxMTk/Jm5ic3A7IERvIHlvdSBtZWFuIHRoYXQgbXkgaW1wbGVtZW50 YXRpb24gY2FuIGlnbm9yZSB0aGVtPyBPciBub3QgYWR2ZXJ0aXNlIHRoZW0/IE9yIHRoYXQgdGhl DQogbmV0d29yayBvcGVyYXRvciBkb2VzIG5vdCBoYXZlIHRvIGNhYmxlIHRoZW0/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj5TZWN0aW9uIDUuMi40LjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+JnF1b3Q7RXZlbiB0aG91Z2ggYSBUb0Yg bm9kZSBjb3VsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgYmUgdGVtcHRlZCB0byB1c2UgdGhvc2UgbGlu a3MgZHVyaW5nIHNvdXRoYm91bmQgU1BGIHRoaXMgTVVTVCBOT1QgYmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5i c3A7IGF0dGVtcHRlZCBzaW5jZSBpdCBtYXkgbGVhZCBpbiwgZS5nLiBhbnljYXN0IGNhc2VzIHRv IHJvdXRpbmcgbG9vcHMuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGlzIGlzIHRvbyB2ZXJi b3NlIGFuZCBvYnR1c2UuJm5ic3A7IEkgY2Fubm90IHNlZSBob3cgYW55Y2FzdCBjYXNlcyBsZWFk IHRvIHJvdXRpbmcgbG9vcHMgYW5kIEkgZG9uJ3Qga25vdyBpZiBJIG5lZWQgdG8gdW5kZXJzdGFu ZCB3aHkgb3Igbm90LiZuYnNwOyBTdWdnZXN0Ojxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mcXVvdDtBIFRv RiBub2RlIE1VU1QgTk9UIGluY2x1ZGUgZWFzdC13ZXN0IGxpbmtzIGluIGl0cyBzb3V0aC1TUEYg Y2FsY3VsYXRpb24uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGlzIHNlY3Rpb24gZ2l2ZXMg dGhlIGltcHJlc3Npb24gdGhhdCBFLVcgbGlua3MgYXQgdGhlIFRvRiB3aWxsIG5ldmVyIGJlIHVz ZWQgZm9yIGZvcndhcmRpbmcgZGF0YSAtIGlzIHRoYXQgdHJ1ZT8mbmJzcDsgVGhleSBhcmUgdXNl ZCBmb3IgY29udHJvbCBwbGFuZSBvbmx5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+JnF1b3Q7QW4gaW1w bGVtZW50YXRpb24gY291bGQgdHJ5IC4uLiBidXQgdGhlIGRldGFpbHMgYXJlIG91dHNpZGUgdGhp cyBzcGVjaWZpY2F0aW9uJnF1b3Q7IC0gc28gd2h5IG1lbnRpb24gaXQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj5TZWN0aW9uIDUuMi41LjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+JnF1b3Q7QSBEQUcgY29tcHV0YXRpb24mcXVvdDsg LSBleHBhbmQgREFHLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+JnF1b3Q7TmVpdGhlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgaXQgbmVjZXNzYXJ5IGZvciB0aGUg cmVjZWl2aW5nIG5vZGUgdG8gcmVmbGVjdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGRpc2FnZ3JlZ2F0ZWQgcHJlZml4ZXMgYmFjayBvdmVyIGl0cyBhZGph Y2VuY2llcyB0byBub2RlcyBhdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGxldmVsIGZyb20gd2hpY2ggaXQgd2FzIHJlY2VpdmVkLiZxdW90OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+UGxlYXNlIHJlc3RhdGUgdGhpcyB1c2luZyBSRkMgMjExOSBsYW5ndWFnZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPkhvdyBjYW4gd2UgZ3VhcmFudGVlIHRoYXQgYSBzYW1lLWxldmVs IG5vZGUgZG9lcyBub3QgaGF2ZSBhIG5leHQgaG9wIHRvIGEgZ2l2ZW4gcHJlZml4IHRoYXQgaXMg dW5rbm93biB0byB0aGUgbm9kZSBkb2luZyB0aGUgY29tcHV0YXRpb24/Jm5ic3A7IElmIFggcmVh Y2hlcyBQIHZpYSBOMSBhbmQgTjIsIFkgKGF0IHRoZSBzYW1lIGxldmVsIGFzIFgpIGNhbiByZWFj aCBQIHZpYSBOMyBidXQNCiBYIGRvZXMgbm90IGtub3cgdGhpcyBhbmQgYXNzdW1lcyBZIGNhbm5v dCByZWFjaCBQIGJlY2F1c2UgWSBpcyBub3QgYWRqYWNlbnQgdG8gTjEgYW5kIE4yLCB0aGVuIFgg dW5uZWNlc3NhcmlseSBkaXNhZ2dyZWdhdGVzIFAgcG9zaXRpdmVseS4mbmJzcDsgRm9yIGluc3Rh bmNlIGlmIFgncyBsaW5rIHRvIE4zIGhhcyBmYWlsZWQgYW5kIFkncyBsaW5rcyB0byBOMSBhbmQg TjIgaGF2ZSBmYWlsZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mcXVvdDtFYWNoIGVudHJ5IGlzIGEg bGlzdCBvZiBzb3V0aCBuZWlnaGJvciBvZiBYIGFuZCBhIGxpc3Qgb2Ygbm9kZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIFgubGV2ZWwgdGhhdCBjYW4ndCBy ZWFjaCB0aGF0IG5laWdoYm9yJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGluayB0aGlzIHNo b3VsZCBzYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZxdW90O0VhY2ggZW50cnkgaW4gdGhlIHNldCBp cyBhIHNvdXRoIG5laWdoYm9yIG9mIFggYW5kIGEgbGlzdCBvZiBub2RlczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgWC5sZXZlbCB0aGF0IGNhbid0IHJlYWNo IHRoYXQgbmVpZ2hib3ImcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZxdW90O1ggZG9lcyBub3Qg dG8gZGlzYWdncmVnYXRlIGFueSBwcmVmaXhlcyZxdW90OyAtJmd0OyAmcXVvdDsmcXVvdDtYIGRv ZXMgbm90IGRpc2FnZ3JlZ2F0ZSBhbnkgcHJlZml4ZXMuJnF1b3Q7JnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj4mcXVvdDtUaGUgUG9EIGNvbnRhaW5pbmcgdGhlIHByZWZpeCB3aWxsIHByZWZlciBz b3V0aGJvdW5kIGFueXdheS4mcXVvdDsgLSBJIGRpZG4ndCB1bmRlcnN0YW5kIHRoZSBwb2ludC4g SXMgaXQgbmVjZXNzYXJ5IGZvciBtZSB0byB1bmRlcnN0YW5kIGl0PyBQbGVhc2UgZXhwYW5kIG9y IGRlbGV0ZSB0aGUgc2VudGVuY2UgaWYgaXQncyBub3QgbmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+U2VjdGlvbiA1LjIuNiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+JnF1b3Q7c3VjaCBhcyBtb2JpbGl0eSBwZXIgc2Vj dGlvbiA1LjMuMyBuZWNlc3NhcnkmcXVvdDsgLSBkZWxldGUgJnF1b3Q7bmVjZXNzYXJ5JnF1b3Q7 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj4mcXVvdDt0aWVzIGFyZSBicm9rZW4gYmFzZWQgdXBvbiB0eXBlIGZpcnN0IGFuZCB0 aGVuIGRpc3RhbmNlIGFuZCBmdXJ0aGVyIGF0dHJpYnV0ZXMmcXVvdDsgLSBJIGRvbid0IHNlZSBt ZW50aW9uIG9mIGZ1cnRoZXIgYXR0cmlidXRlcyBpbiB0aGUgcHJvcG9zZWQgYWxnb3JpdGhtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+JnF1b3Q7VGhlIG5leHRob3A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IGFk amFjZW5jaWVzIGZvciBhIG5lZ2F0aXZlIHByZWZpeCBhcmUgaW5oZXJpdGVkIGZyb20gdGhlIGxv bmdlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IHByZWZpeCB0aGF0IGFnZ3JlZ2F0ZXMgaXQmcXVvdDsg LSBzdWdnZXN0IGNoYW5naW5nIHRvICZxdW90O2xvbmdlc3QgcG9zaXRpdmUgcHJlZml4JnF1b3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj4mcXVvdDthbGwgZW50cmllcyBvZiB0aGUgZmF0aGVyJnF1b3Q7 IC0mZ3Q7ICZxdW90O2FsbCBlbnRyaWVzIG9mIHRoZSBwYXJlbnQmcXVvdDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPlNlY3Rpb24gNS4yLjcuMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mcXVvdDt3ZSBoYXZlIHRvIGRlY2lkZSB3aGV0 aGVyIG5vZGUgWSBpcyBhdCB0aGUgc2FtZSBsZXZlbCBhcyBJLCBKIG9yIGF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNw OyZuYnNwOyB0aGUgc2FtZSBsZXZlbCBhcyBZIGFuZCBjb25zZXF1ZW50bHksIFggaXMgc291dGgg b2YgaXQuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGNvdWxkIG5vdCBwYXJzZSB0aGlzLiZu YnNwOyBJIHRoaW5rIHlvdSBtaWdodCBtZWFuIHRoaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mcXVv dDt3ZSBoYXZlIHRvIGRlY2lkZSB3aGV0aGVyIG5vZGUgWSBpcyBhdCB0aGUgc2FtZSBsZXZlbCBh cyBJLCBKDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7KGFuZCBjb25zZXF1ZW50bHkgWCBpcyBzb3V0aCBv ZiBpdCkgb3IgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgWC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PlNlY3Rpb24gNS4yLjcuNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5Ib3cgZG9lcyBhIFRvRiBub2RlIGtub3cgd2hhdCB2YWx1 ZSB0byBhZHZlcnRpc2UgaW4gaXRzIExFVkVMX1ZBTFVFPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL0PR02MB48689FA2D6B7C255DF11045D84630BL0PR02MB4868namp_-- From nobody Thu Oct 31 19:09:18 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 738A712081B; Thu, 31 Oct 2019 19:09:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Nagendra Kumar via Datatracker To: Cc: draft-ietf-rift-rift.all@ietf.org, rift@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Nagendra Kumar Message-ID: <157257415137.30463.17526140657219162235@ietfa.amsl.com> Date: Thu, 31 Oct 2019 19:09:11 -0700 Archived-At: Subject: [Rift] Opsdir early review of draft-ietf-rift-rift-08 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 Nov 2019 02:09:12 -0000 Reviewer: Nagendra Kumar Review result: Has Issues Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts per guidelines in RFC5706. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Overall Summary: This draft is a standard track proposing a very new protocol and not an extension of any existing protocol. As such, there are no backward compatibility issues expected. Overall this is a well written document. Some ambiguity that needs attention are listed below. I chose "Has Issues" primarily to address the issue that may cause behavior inconsistency or traffic blakc holes. More details below: --> LIE with TTL more than 1 is clearly defined to be discarded. I couldn't find a similar clarification when TIE is received with TTL more than 1?. If i didn't miss it, I think it is better to be clarified for consistent behavior. 5.3.7. Label Binding A node MAY advertise on its TIEs a locally significant, downstream assigned label for the according interface. One use of such label is a hop-by-hop encapsulation allowing to easily distinguish forwarding planes served by a multiplicity of RIFT instances. --> Read this more than a couple of times and not sure if "for the accordingly interface" means assigning a locally unique label for each interface/adjacency or just one label for the node and advertise the same label over all adjacency. --> Since it is mentioned that the use of this label is for HbH encapsulation, a node at Level n should install (or ignore) the label from node at Level (n-1) in its Incoming Label Mapping (ILM) table?. --> On the same line, a node at Level n should install (or ignore) the label from node at Level (n-2)?. --> I think some clarity is better to avoid traffic black holing due to inconsistent behavior. 5.3.8.1. Global Segment Identifiers Assignment Global segment identifiers are normally assumed to be provided by some kind of a centralized "controller" instance and distributed to other entities. This can be performed in RIFT by attaching a controller to the Top-of-Fabric nodes at the top of the fabric where the whole topology is always visible, assign such identifiers and then distribute those via the KV mechanism towards all nodes so they can perform things like probing the fabric for failures using a stack of segments. --> According to RFC 8402, Global Segment is a generic term that refers to a segment from SR Global Block with instruction or forwarding semantic defined at the domain level. But it does not have a default instruction associated with it. I think the above should be more specific as Prefix SID or something related to RIFT. Few observations below: Clos/Fat Tree: This document uses the terms Clos and Fat Tree interchangeably whereas it always refers to a folded spine-and- leaf topology with possibly multiple PoDs and one or multiple ToF --> ToF and PoD were not expanded in the first occurrence. ToF was explained later. --> While Southbound representation is explained in the terminology section, northbound representation is not. I think it is better to define the same for consistency. Multiple adjacencies can be formed to a neighbor via parallel interfaces but such adjacencies are NOT sharing a neighbor structure. Saying "neighbor" is thus equivalent to saying "a three way adjacency". --> The above says "Multiple adjacencies can be formed to a neighbor.." where the "neighbor" here is implicitly defining the remote node and then the sentence further continues stating "Saying "neighbor" is thus equivalent to saying "a three way adjacency"". May be the first "neighbor" can be changed to "remote node"? mobility defined in Paragraph 17 --> I assume that you are referring to REQ#17?. I think it is better to refer it as REQ#17. But I will leave that to the authors to decide. The solution should allow for access to link states of the whole topology to enable efficient support for modern control architectures like SPRING [RFC7855] or PCE [RFC4655]. --> RFC 7855 is an information RFC that outlines the problem statement and use case. I think you should refer RFC 8402 here for the SR architecture. "Future versions of this document may describe support for such tunneling in RIFT." --> Section 5.3.3.4 talks about Overlay encapsulation and leave it a bit ambiguous with the above statement. I think, it should be removed. already to HAT nodes with level different than the adjacent --> HAT was first expanded in page 66 while the abbreviation is used in/from Page 34. In Section 5.2.3.2, I hope the first node is "ToF21 S-TIEs" instead of "Spine21 S-TIEs"?. Similar references are throughout the example with Spine21 and Spine22. "scope of this document and may be covered in a separate document about policy guided prefixes [PGP reference]." --> There is no PGP reference. This may need to be fixed or removed.