From nobody Tue Jan 2 09:29:14 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620E1128C0A; Tue, 2 Jan 2018 09:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RE5nJXmzBZrE; Tue, 2 Jan 2018 09:29:10 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73425124E15; Tue, 2 Jan 2018 09:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7257; q=dns/txt; s=iport; t=1514914150; x=1516123750; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0yg8GD1xJi2/HEQ5PRrc/BYBMvynh3KQMjpocBOvZ7A=; b=SfE+xgVUQGNmi5E+y+5jf6ZlSuIU5AnhSaxvoZyxcplVnehrU+pTy/nE alnI8AuAj6Ky/PdZAdCB79CKE028w1O7n20vkFxv6PPFt4Dh+fMKEzUnl tBXdARRKFIrYNqduFpeOlK+DX1CgRfjM3IhIMCZeIckpyXRi7zIIRGbIR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAgD0v0ta/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdIFaJweEAJk+ggGJCIhRh2YKhTsCGoQWQhUBAQEBAQEBAQF?= =?us-ascii?q?rKIUjAQEBAQMjVhACAQgOAwMBAg0bAwICAh8RFAkIAQEEAQ0FiUpMAxWyB4Inh?= =?us-ascii?q?zkNgnABAQEBAQEBAQEBAQEBAQEBAQEBAQEdhAyCEoZtgmtFgg6Cd4JlBZlhiS4?= =?us-ascii?q?9ApA1hH6CF4YWi1CNYoh0AhEZAYE7ATUjgU9vFT2CKYRXeId8gRYBAQE?= X-IronPort-AV: E=Sophos;i="5.45,498,1508803200"; d="scan'208,217";a="338436139" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jan 2018 17:29:09 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w02HT8Fu013281 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Jan 2018 17:29:09 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 2 Jan 2018 12:29:08 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 2 Jan 2018 12:29:08 -0500 From: "Acee Lindem (acee)" To: Alvaro Retana , Xuxiaohu , "dcrouting@ietf.org" CC: "lsvr@ietf.org" Thread-Topic: [Dcrouting] A comment on draft-keyupate-idr-bgp-spf Thread-Index: AdN6/qalrWTMjyrZR1yUr/rOo79ZxwAW0IKAAiVQMgA= Date: Tue, 2 Jan 2018 17:29:08 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7141@NKGEML515-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: multipart/alternative; boundary="_000_D6712B2DE8033aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dcrouting] A comment on draft-keyupate-idr-bgp-spf X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 17:29:12 -0000 --_000_D6712B2DE8033aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXNlZCBhcyBhbiB1bmRlcmxheSwgQkdQIFNQRiBqdXN0IHdvcmtzLiBXaGF0IG5lZWRzIHRvIGJl IGRlZmluZWQgYXJlIHRoZSBydWxlcyB3aGVuIHRoZSBzYW1lIHByZWZpeCBpcyBhZHZlcnRpc2Vk IGluIGJvdGggYWRkcmVzcyBmYW1pbGllcy4NClRoYW5rcywNCkFjZWUNCg0KRnJvbTogRGNyb3V0 aW5nIDxkY3JvdXRpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGNyb3V0aW5nLWJvdW5jZXNA aWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWls LmNvbTxtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXksIERlY2Vt YmVyIDIyLCAyMDE3IGF0IDk6MjAgQU0NClRvOiBYaWFvaHUgWHUgPHh1eGlhb2h1QGh1YXdlaS5j b208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiwgImRjcm91dGluZ0BpZXRmLm9yZzxtYWls dG86ZGNyb3V0aW5nQGlldGYub3JnPiIgPGRjcm91dGluZ0BpZXRmLm9yZzxtYWlsdG86ZGNyb3V0 aW5nQGlldGYub3JnPj4NCkNjOiAibHN2ckBpZXRmLm9yZzxtYWlsdG86bHN2ckBpZXRmLm9yZz4i IDxsc3ZyQGlldGYub3JnPG1haWx0bzpsc3ZyQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbRGNy b3V0aW5nXSBBIGNvbW1lbnQgb24gZHJhZnQta2V5dXBhdGUtaWRyLWJncC1zcGYNCg0KT24gRGVj ZW1iZXIgMjIsIDIwMTcgYXQgMzoyNzoyNCBBTSwgWHV4aWFvaHUgKHh1eGlhb2h1QGh1YXdlaS5j b208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+KSB3cm90ZToNCg0KWGlhb2h1Og0KDQpIaSEN Cg0KSSB3b25kZXIgd2hldGhlciBpdCdzIHdvcnRod2hpbGUgdG8gY29uc2lkZXIgdGhlIGNvZXhp c3RlbmNlIG9mIHRoZSB0cmFkaXRpb25hbCBCR1AtRFYgcHJvdG9jb2wgYW5kIHRoZSBCR1AtU1BG IHByb3RvY29sIG9uIGEgZ2l2ZW4gbm9kZS4gSWYgc28uLi4NCg0KWWVzLCBJIHRoaW5rIHNvLg0K DQpUaGF0IChjb2V4aXN0ZW5jZSB3aXRoL3NlcGFyYXRpb24gZnJvbSB0cmFkaXRpb25hbCBCR1Ap IGlzIG9uZSBvZiB0aGUgcGllY2VzIHRoYXQgSSBleHBlY3QgdG8gc2VlIGluIGEgZm9ydGhjb21p bmcgcHJvcG9zZWQgY2hhcnRlciBmb3IgbHN2ciDigJQgcGxlYXNlIHN1YnNjcmliZSB0byB0aGF0 IGxpc3QgKGNj4oCZZCBoZXJlKSBhbmQgY29udHJpYnV0ZSB5b3VyIGNvbW1lbnRzIGFuZCBpZGVh cyB0aGVyZS4gOi0pDQoNClRoYW5rcyEhDQoNCkFsdmFyby4NCg== --_000_D6712B2DE8033aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Vc2VkIGFzIGFu IHVuZGVybGF5LCBCR1AgU1BGIGp1c3Qgd29ya3MuIFdoYXQgbmVlZHMgdG8gYmUgZGVmaW5lZCBh cmUgdGhlIHJ1bGVzIHdoZW4gdGhlIHNhbWUgcHJlZml4IGlzIGFkdmVydGlzZWQgaW4gYm90aCBh ZGRyZXNzIGZhbWlsaWVzLiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFj ZWUmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEx cHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu b25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJ TkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0 IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+RGNyb3V0aW5nICZsdDs8 YSBocmVmPSJtYWlsdG86ZGNyb3V0aW5nLWJvdW5jZXNAaWV0Zi5vcmciPmRjcm91dGluZy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEFsdmFybyBSZXRhbmEgJmx0OzxhIGhy ZWY9Im1haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tIj5hcmV0YW5hLmlldGZAZ21haWwuY29t PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFu PkZyaWRheSwgRGVjZW1iZXIgMjIsIDIwMTcgYXQgOToyMCBBTTxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPlhpYW9odSBYdSAmbHQ7PGEgaHJlZj0ibWFpbHRv Onh1eGlhb2h1QGh1YXdlaS5jb20iPnh1eGlhb2h1QGh1YXdlaS5jb208L2E+Jmd0OywgJnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmRjcm91dGluZ0BpZXRmLm9yZyI+ZGNyb3V0aW5nQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRjcm91dGluZ0BpZXRmLm9yZyI+ZGNyb3V0aW5n QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6 IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bHN2ckBpZXRmLm9yZyI+bHN2ckBpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsc3ZyQGlldGYub3JnIj5sc3ZyQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDog PC9zcGFuPlJlOiBbRGNyb3V0aW5nXSBBIGNvbW1lbnQgb24gZHJhZnQta2V5dXBhdGUtaWRyLWJn cC1zcGY8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVj NGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+PHN0 eWxlPmJvZHl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4fTwvc3R5 bGU+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGlkPSJibG9vcF9j dXN0b21mb250IiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTttYXJnaW46MHB4Ij48Zm9udCBmYWNl PSJIZWx2ZXRpY2EiPk9uIERlY2VtYmVyIDIyLCAyMDE3IGF0IDM6Mjc6MjQgQU0sIFh1eGlhb2h1 ICg8YSBocmVmPSJtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbSI+eHV4aWFvaHVAaHVhd2VpLmNv bTwvYT4pIHdyb3RlOjwvZm9udD48L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiIHN0 eWxlPSJjb2xvcjpyZ2IoMCwwLDApO21hcmdpbjowcHgiPjxmb250IGZhY2U9IkhlbHZldGljYSI+ PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCIgc3R5bGU9ImNv bG9yOnJnYigwLDAsMCk7bWFyZ2luOjBweCI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIj5YaWFvaHU6 PC9mb250PjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCIgc3R5bGU9ImNvbG9yOnJn YigwLDAsMCk7bWFyZ2luOjBweCI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIj48YnI+DQo8L2ZvbnQ+ PC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250IiBzdHlsZT0iY29sb3I6cmdiKDAsMCww KTttYXJnaW46MHB4Ij48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiPkhpITwvZm9udD48L2Rpdj4NCjxk aXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO21hcmdpbjow cHgiPjxmb250IGZhY2U9IkhlbHZldGljYSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSJjbGVhbl9icSIgc3R5bGU9ImZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0 LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1z cGFjaW5nOjBweCI+DQo8c3Bhbj4NCjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5v cm1hbDt3b3JkLXNwYWNpbmc6MHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KTtm bG9hdDpub25lO2Rpc3BsYXk6aW5saW5lIWltcG9ydGFudCI+PGZvbnQgZmFjZT0iSGVsdmV0aWNh Ij5JDQogd29uZGVyIHdoZXRoZXIgaXQncyB3b3J0aHdoaWxlIHRvIGNvbnNpZGVyIHRoZSBjb2V4 aXN0ZW5jZSBvZiB0aGUgdHJhZGl0aW9uYWwgQkdQLURWIHByb3RvY29sIGFuZCB0aGUgQkdQLVNQ RiBwcm90b2NvbCBvbiBhIGdpdmVuIG5vZGUuIElmIHNvLi4uPC9mb250Pjwvc3Bhbj48L2Rpdj4N Cjwvc3Bhbj48L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwPjxmb250IGZhY2U9IkhlbHZldGljYSI+ WWVzLCBJIHRoaW5rIHNvLjwvZm9udD48L3A+DQo8cD48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiPlRo YXQgKGNvZXhpc3RlbmNlIHdpdGgvc2VwYXJhdGlvbiBmcm9tIHRyYWRpdGlvbmFsIEJHUCkgaXMg b25lIG9mIHRoZSBwaWVjZXMgdGhhdCBJIGV4cGVjdCB0byBzZWUgaW4gYSBmb3J0aGNvbWluZyBw cm9wb3NlZCBjaGFydGVyIGZvciBsc3ZyIOKAlCBwbGVhc2Ugc3Vic2NyaWJlIHRvIHRoYXQgbGlz dCAoY2PigJlkIGhlcmUpIGFuZCBjb250cmlidXRlIHlvdXIgY29tbWVudHMgYW5kIGlkZWFzIHRo ZXJlLg0KIDotKTwvZm9udD48L3A+DQo8cD48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiPlRoYW5rcyEh PC9mb250PjwvcD4NCjxwPjxmb250IGZhY2U9IkhlbHZldGljYSI+QWx2YXJvLjwvZm9udD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_D6712B2DE8033aceeciscocom_-- From nobody Tue Jan 2 09:49:14 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA7E124E15; Tue, 2 Jan 2018 09:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 kHl4g3MrSIkM; Tue, 2 Jan 2018 09:49:10 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0080.outbound.protection.outlook.com [104.47.41.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E42124B17; Tue, 2 Jan 2018 09:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=d+D0hNhb5GAInNnYEcO2Ywx/hbt0q7VyXmZhId3EfiY=; b=hY49DbEfyvWvCA3K2Debp/KPr9dfybp3USxnnvrJVP8FPPQxkQkxkzJEB32szKB2d5K8qNFJt06JHT+OjP4ZtjX46LYKZ36UyZMG1CNdAQcDU6u09NY8GP/D7yDjrChuMiV7OEf9zvKJbP8DS45LZ3Vq6sa0rgiuKsFSRus9AXY= Received: from CY4PR18MB1127.namprd18.prod.outlook.com (10.173.184.14) by CY4PR18MB1127.namprd18.prod.outlook.com (10.173.184.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.8; Tue, 2 Jan 2018 17:49:07 +0000 Received: from CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) by CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) with mapi id 15.20.0366.007; Tue, 2 Jan 2018 17:49:07 +0000 From: Keyur Patel To: "Acee Lindem (acee)" , Alvaro Retana , Xuxiaohu , "dcrouting@ietf.org" CC: "lsvr@ietf.org" Thread-Topic: [Lsvr] [Dcrouting] A comment on draft-keyupate-idr-bgp-spf Thread-Index: AQHTg/H8Y7k3PUiZ40+n21S43R09BQ== Date: Tue, 2 Jan 2018 17:49:07 +0000 Message-ID: <0DB89F21-8E32-46A7-A2B7-B79977948455@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [75.8.210.205] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR18MB1127; 6:N2n89Yig7AQ4s21ulX5YeseXJgeMaULnFvCM+7Nc0bNyvIvFcWS6xi86GNzDnH+ZwNflj4XnGkrjHUl2BAAEGk1hzLJ27Ipo485atPYyb7Fev7Oh/vh3UgOXi8CVsk9L/eo6xC+zcyYHzf+Q0g/cJOH9JbAR9mX0iB8oCVtmgZxVuDb948WWdVyvzdRt8aUsuz+Wz+unVCIhXPEC6zehwUmuRPKuWD1R2g5eNz6++anB0SJ70d+7IOx3iwy5neFL8fJe97enxTShYIexugAPIIgoeyIgLPtfPkYNQJti1CgkkhcdZkZb8cF5scw7VOtEBvlYLRRqc+6fDldBkHW/YxbTqI1LXXJEbN3vfJ8BDdBaOBRR5AQmkNF+YMY/ZqTt; 5:zz6Qmnniay3k5rgAic8iCatVIfumoZfXCihW6lDF7mXQsY8eqnjjMSgyXw2qac3HXoIooSdVS9AE4D2KgTPuAx/kFlXbqAQU7vKO6jfuQp5uTKe2E2v1/AeQ8McahsT0OkRCu4PLK9Kab5tr4FsXH+gWzzCqBCrKCzSIMMw3JG8=; 24:ykMpVjJ/RfP/x5mzlCPdJ0qJoBDimysL1CDRdgUYEmUBogvciWjEz8qtDlgcqlG+1PnM+ZBcM4om/QFWKjSLsjoV6MasWSwW502akm62Ddo=; 7:Ycy+GfE2p0oHHNz4cDIt8LFzkspusou07++gu1DJcinm1Buv7+ItBMX9aOoSGvAf+tnLPLyqTcvSIOvnqj7IJDnVTmwhORUOvNCBXhQyCWCPKBGHUf/7kFiMD65A2E5MHv4/WPmJnmDTBt/Hu8mNOAARAKWDUH39dIVU/357RjK3RtmpVK+zHMlk+xaBF0lkuA7C2N1eYkPPsr2UcxmU8fL28JKke7I2+ark7V/BqXIhVxwmt5ENfFHuRxiC6qpf x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: dfd2ecff-b857-4f58-eb2c-08d552091f53 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:CY4PR18MB1127; x-ms-traffictypediagnostic: CY4PR18MB1127: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231023)(944501075)(6041268)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:CY4PR18MB1127; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR18MB1127; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39830400003)(396003)(376002)(39380400002)(189003)(199004)(24454002)(106356001)(86362001)(105586002)(33656002)(8936002)(5660300001)(81156014)(36756003)(83716003)(230783001)(2906002)(8676002)(81166006)(7736002)(82746002)(6116002)(14454004)(68736007)(3846002)(97736004)(99286004)(6512007)(6306002)(54896002)(236005)(4326008)(39060400002)(6246003)(102836004)(77096006)(6486002)(25786009)(316002)(53936002)(6436002)(53546011)(6506007)(229853002)(3280700002)(2900100001)(478600001)(2501003)(110136005)(66066001)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR18MB1127; H:CY4PR18MB1127.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: btViPaO42myFMQsgQ1APReP8OV4kXAjykdbn8B46xlzpAKKXzoby7Dj5Ox7bxZci6HucjbE3pNEiqUDS7OSGAg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0DB89F218E3246A7A2B7B79977948455arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfd2ecff-b857-4f58-eb2c-08d552091f53 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 17:49:07.4694 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR18MB1127 Archived-At: Subject: Re: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 17:49:13 -0000 --_000_0DB89F218E3246A7A2B7B79977948455arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gd2hhdCBBY2VlIHNhaWQuDQoNCkZ1cnRoZXJtb3JlLCB3ZSBjb3VsZCBjaG9zZSB0byBj b25zaWRlciBzdWNoIGFuIGludGVyYWN0aW9uIGFzIGEgbWF0dGVyIG9mIGxvY2FsIHBvbGljeSAo aW1wbGVtZW50YXRpb24gc3BlY2lmaWMpLg0KDQpSZWdhcmRzLA0KS2V5dXINCg0KDQpGcm9tOiBM c3ZyIDxsc3ZyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiQWNlZSBMaW5kZW0gKGFj ZWUpIiA8YWNlZUBjaXNjby5jb20+DQpEYXRlOiBUdWVzZGF5LCBKYW51YXJ5IDIsIDIwMTggYXQg OToyOSBBTQ0KVG86IEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+LCBYdXhp YW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4sICJkY3JvdXRpbmdAaWV0Zi5vcmciIDxkY3JvdXRp bmdAaWV0Zi5vcmc+DQpDYzogImxzdnJAaWV0Zi5vcmciIDxsc3ZyQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtMc3ZyXSBbRGNyb3V0aW5nXSBBIGNvbW1lbnQgb24gZHJhZnQta2V5dXBhdGUtaWRy LWJncC1zcGYNCg0KVXNlZCBhcyBhbiB1bmRlcmxheSwgQkdQIFNQRiBqdXN0IHdvcmtzLiBXaGF0 IG5lZWRzIHRvIGJlIGRlZmluZWQgYXJlIHRoZSBydWxlcyB3aGVuIHRoZSBzYW1lIHByZWZpeCBp cyBhZHZlcnRpc2VkIGluIGJvdGggYWRkcmVzcyBmYW1pbGllcy4NClRoYW5rcywNCkFjZWUNCg0K RnJvbTogRGNyb3V0aW5nIDxkY3JvdXRpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGNyb3V0 aW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQWx2YXJvIFJldGFuYSA8YXJldGFu YS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4+DQpEYXRlOiBG cmlkYXksIERlY2VtYmVyIDIyLCAyMDE3IGF0IDk6MjAgQU0NClRvOiBYaWFvaHUgWHUgPHh1eGlh b2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiwgImRjcm91dGluZ0Bp ZXRmLm9yZzxtYWlsdG86ZGNyb3V0aW5nQGlldGYub3JnPiIgPGRjcm91dGluZ0BpZXRmLm9yZzxt YWlsdG86ZGNyb3V0aW5nQGlldGYub3JnPj4NCkNjOiAibHN2ckBpZXRmLm9yZzxtYWlsdG86bHN2 ckBpZXRmLm9yZz4iIDxsc3ZyQGlldGYub3JnPG1haWx0bzpsc3ZyQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbRGNyb3V0aW5nXSBBIGNvbW1lbnQgb24gZHJhZnQta2V5dXBhdGUtaWRyLWJncC1z cGYNCg0KT24gRGVjZW1iZXIgMjIsIDIwMTcgYXQgMzoyNzoyNCBBTSwgWHV4aWFvaHUgKHh1eGlh b2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+KSB3cm90ZToNCg0KWGlh b2h1Og0KDQpIaSENCg0KSSB3b25kZXIgd2hldGhlciBpdCdzIHdvcnRod2hpbGUgdG8gY29uc2lk ZXIgdGhlIGNvZXhpc3RlbmNlIG9mIHRoZSB0cmFkaXRpb25hbCBCR1AtRFYgcHJvdG9jb2wgYW5k IHRoZSBCR1AtU1BGIHByb3RvY29sIG9uIGEgZ2l2ZW4gbm9kZS4gSWYgc28uLi4NCg0KWWVzLCBJ IHRoaW5rIHNvLg0KDQpUaGF0IChjb2V4aXN0ZW5jZSB3aXRoL3NlcGFyYXRpb24gZnJvbSB0cmFk aXRpb25hbCBCR1ApIGlzIG9uZSBvZiB0aGUgcGllY2VzIHRoYXQgSSBleHBlY3QgdG8gc2VlIGlu IGEgZm9ydGhjb21pbmcgcHJvcG9zZWQgY2hhcnRlciBmb3IgbHN2ciDigJQgcGxlYXNlIHN1YnNj cmliZSB0byB0aGF0IGxpc3QgKGNj4oCZZCBoZXJlKSBhbmQgY29udHJpYnV0ZSB5b3VyIGNvbW1l bnRzIGFuZCBpZGVhcyB0aGVyZS4gOi0pDQoNClRoYW5rcyEhDQoNCkFsdmFyby4NCg== --_000_0DB89F218E3246A7A2B7B79977948455arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1z b0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+JiM0MzsxIHRvIHdoYXQgQWNlZSBzYWlkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPkZ1cnRoZXJtb3JlLCB3ZSBjb3VsZCBjaG9zZSB0byBjb25zaWRlciBzdWNo IGFuIGludGVyYWN0aW9uIGFzIGEgbWF0dGVyIG9mIGxvY2FsIHBvbGljeSAoaW1wbGVtZW50YXRp b24gc3BlY2lmaWMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+S2V5dXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Mc3ZyICZsdDtsc3ZyLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtBY2VlIExpbmRlbSAoYWNlZSkmcXVvdDsgJmx0O2FjZWVA Y2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDIsIDIwMTgg YXQgOToyOSBBTTxicj4NCjxiPlRvOiA8L2I+QWx2YXJvIFJldGFuYSAmbHQ7YXJldGFuYS5pZXRm QGdtYWlsLmNvbSZndDssIFh1eGlhb2h1ICZsdDt4dXhpYW9odUBodWF3ZWkuY29tJmd0OywgJnF1 b3Q7ZGNyb3V0aW5nQGlldGYub3JnJnF1b3Q7ICZsdDtkY3JvdXRpbmdAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj4mcXVvdDtsc3ZyQGlldGYub3JnJnF1b3Q7ICZsdDtsc3ZyQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0xzdnJdIFtEY3JvdXRpbmddIEEgY29tbWVu dCBvbiBkcmFmdC1rZXl1cGF0ZS1pZHItYmdwLXNwZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXNlZCBhcyBhbiB1bmRlcmxheSwg QkdQIFNQRiBqdXN0IHdvcmtzLiBXaGF0IG5lZWRzIHRvIGJlIGRlZmluZWQgYXJlIHRoZSBydWxl cyB3aGVuIHRoZSBzYW1lIHByZWZpeCBpcyBhZHZlcnRpc2VkIGluIGJvdGggYWRkcmVzcyBmYW1p bGllcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFjZWUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj5EY3JvdXRpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpkY3JvdXRpbmctYm91 bmNlc0BpZXRmLm9yZyI+ZGNyb3V0aW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhh bGYgb2YgQWx2YXJvIFJldGFuYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmEuaWV0ZkBnbWFp bC5jb20iPmFyZXRhbmEuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5G cmlkYXksIERlY2VtYmVyIDIyLCAyMDE3IGF0IDk6MjAgQU08YnI+DQo8Yj5UbzogPC9iPlhpYW9o dSBYdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20iPnh1eGlhb2h1QGh1 YXdlaS5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRjcm91dGluZ0BpZXRmLm9y ZyI+ZGNyb3V0aW5nQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRjcm91 dGluZ0BpZXRmLm9yZyI+ZGNyb3V0aW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9i PiZxdW90OzxhIGhyZWY9Im1haWx0bzpsc3ZyQGlldGYub3JnIj5sc3ZyQGlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxzdnJAaWV0Zi5vcmciPmxzdnJAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0Rjcm91dGluZ10gQSBjb21tZW50IG9uIGRy YWZ0LWtleXVwYXRlLWlkci1iZ3Atc3BmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERG IDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdp bi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj5PbiBE ZWNlbWJlciAyMiwgMjAxNyBhdCAzOjI3OjI0IEFNLCBYdXhpYW9odSAoPGEgaHJlZj0ibWFpbHRv Onh1eGlhb2h1QGh1YXdlaS5jb20iPnh1eGlhb2h1QGh1YXdlaS5jb208L2E+KSB3cm90ZTo8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+WGlhb2h1Ojwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj5IaSE8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+SSB3b25kZXIgd2hl dGhlciBpdCdzIHdvcnRod2hpbGUgdG8gY29uc2lkZXIgdGhlIGNvZXhpc3RlbmNlIG9mIHRoZSB0 cmFkaXRpb25hbCBCR1AtRFYgcHJvdG9jb2wgYW5kIHRoZSBCR1AtU1BGIHByb3RvY29sIG9uIGEg Z2l2ZW4gbm9kZS4gSWYgc28uLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+ WWVzLCBJIHRoaW5rIHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpIZWx2ZXRpY2EiPlRoYXQgKGNvZXhpc3RlbmNlIHdpdGgvc2VwYXJhdGlvbiBm cm9tIHRyYWRpdGlvbmFsIEJHUCkgaXMgb25lIG9mIHRoZSBwaWVjZXMgdGhhdCBJIGV4cGVjdCB0 byBzZWUgaW4gYSBmb3J0aGNvbWluZyBwcm9wb3NlZCBjaGFydGVyIGZvciBsc3ZyIOKAlCBwbGVh c2Ugc3Vic2NyaWJlIHRvIHRoYXQgbGlzdCAoY2PigJlkIGhlcmUpIGFuZCBjb250cmlidXRlIHlv dXIgY29tbWVudHMgYW5kDQogaWRlYXMgdGhlcmUuIDotKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoYW5rcyEhPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+QWx2 YXJvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0DB89F218E3246A7A2B7B79977948455arrcuscom_-- From nobody Tue Jan 2 19:21:28 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A0E1276AF; Tue, 2 Jan 2018 19:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 v8MsPhO5c8AQ; Tue, 2 Jan 2018 19:21:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 D287212426E; Tue, 2 Jan 2018 19:21:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eWZcF-00074w-7W; Wed, 03 Jan 2018 03:21:19 +0000 Date: Wed, 03 Jan 2018 12:21:16 +0900 Message-ID: From: Randy Bush To: Keyur Patel Cc: "Acee Lindem (acee)" , Alvaro Retana , Xuxiaohu , "dcrouting@ietf.org" , "lsvr@ietf.org" In-Reply-To: <0DB89F21-8E32-46A7-A2B7-B79977948455@arrcus.com> References: <0DB89F21-8E32-46A7-A2B7-B79977948455@arrcus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 03:21:26 -0000 > Furthermore, we could chose to consider such an interaction as a > matter of local policy (implementation specific). pedantry: s/implementation/configuration/. i.e. op chooses, not vendor. randy From nobody Wed Jan 3 04:40:58 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51355126FDC; Wed, 3 Jan 2018 04:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Y5CICoeiEf_h; Wed, 3 Jan 2018 04:40:56 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E1F126579; Wed, 3 Jan 2018 04:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=478; q=dns/txt; s=iport; t=1514983255; x=1516192855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TFwR7lyg8luPAdfaKYX+gNiTlHJi4bg+em4Xp3EzNAg=; b=iF4mXvvLgzzVlItNVkg1KgY7NLNRBIADheZp/itrQsLll99GckMoJMIm jVMLqo5qxeiPHovLbzkda611DVZpOQmE36wkVy+Yci3uqFloBtNDS6hRp K6T2Oq0aOK9/ZWIZ1NdHYxXQkTPzTZIlr/bBDbIsKxKbPvLp0KZpp3gL/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgBXzkxa/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+gVonB4QAmT6CAZk/CoU7AhqEFkIVAQEBAQEBAQEBayiFJAE?= =?us-ascii?q?EASMRRRACAQgaAiYCAgIwFRACBAENBYomCLFAgieKOQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2BD4MEghKGbYMwhQWCZQEEo1EClTSBfgGSApZZAhEZAYE7ATUjgU9?= =?us-ascii?q?vFYJmhFd4iCaBFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,501,1508803200"; d="scan'208";a="51223707" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2018 12:40:54 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w03Ces8a010772 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jan 2018 12:40:54 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 3 Jan 2018 07:40:53 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 3 Jan 2018 07:40:53 -0500 From: "Acee Lindem (acee)" To: Randy Bush , Keyur Patel CC: Alvaro Retana , Xuxiaohu , "dcrouting@ietf.org" , "lsvr@ietf.org" Thread-Topic: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf Thread-Index: AQHThEHv+i0Opd4R8Eu6OAvJJu6vT6NiF5+A Date: Wed, 3 Jan 2018 12:40:53 +0000 Message-ID: References: <0DB89F21-8E32-46A7-A2B7-B79977948455@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 12:40:57 -0000 QWdyZWVkLiBUaGFua3MgUmFuZHkhDQoNClBsYW4gdG8gcmVmcmVzaCB0aGUgZHJhZnQgdGhpcyB3 ZWVrLg0KDQpBY2VlIA0KDQpPbiAxLzIvMTgsIDEwOjIxIFBNLCAiUmFuZHkgQnVzaCIgPHJhbmR5 QHBzZy5jb20+IHdyb3RlOg0KDQo+PiBGdXJ0aGVybW9yZSwgd2UgY291bGQgY2hvc2UgdG8gY29u c2lkZXIgc3VjaCBhbiBpbnRlcmFjdGlvbiBhcyBhDQo+PiBtYXR0ZXIgb2YgbG9jYWwgcG9saWN5 IChpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYykuDQo+DQo+cGVkYW50cnk6IHMvaW1wbGVtZW50YXRp b24vY29uZmlndXJhdGlvbi8uICBpLmUuIG9wIGNob29zZXMsIG5vdCB2ZW5kb3IuDQo+DQo+cmFu ZHkNCg0K From nobody Wed Jan 3 07:07:29 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42411267BB; Wed, 3 Jan 2018 07:07:27 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 ok-TeSqApjzF; Wed, 3 Jan 2018 07:07:25 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 A07D81205D3; Wed, 3 Jan 2018 07:07:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 79A4C8E14EF; Wed, 3 Jan 2018 07:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1514992045; bh=B7QCj46zTIUr2D6Xz5rQjBEap1wz1GUGD9ABRcoSR88=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Mcn6k+2qMR5BKoc8+P4jo0CHuptWeU8c7ZYIwBFUyNLb719GDSeYz8GjMNcSB9+gD 1xbRXr/5wB/CkYU5ayBP2boW0AhrkCMOXPkRQ0JaReyXF6opqS6wbLrQ3rLI5vjqrY BFBDSv1JW4ygRPStE2sIxfvhiHDeCVfZ+Lj/dhDU= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4008B8E12E6; Wed, 3 Jan 2018 07:07:23 -0800 (PST) To: "Acee Lindem (acee)" , Randy Bush , Keyur Patel Cc: Xuxiaohu , "dcrouting@ietf.org" , "lsvr@ietf.org" , Alvaro Retana References: <0DB89F21-8E32-46A7-A2B7-B79977948455@arrcus.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 3 Jan 2018 10:07:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 15:07:28 -0000 It seems to me that having two different BGP decision processes available is going to have significant impact on achieving consistency so taht routing actually converges. I suspect it willnot take much to define what choices are stable and effective. Leaving out any comments on how to make this (coexistence) work seems a mistake. Yours, Joel On 1/3/18 7:40 AM, Acee Lindem (acee) wrote: > Agreed. Thanks Randy! > > Plan to refresh the draft this week. > > Acee > > On 1/2/18, 10:21 PM, "Randy Bush" wrote: > >>> Furthermore, we could chose to consider such an interaction as a >>> matter of local policy (implementation specific). >> >> pedantry: s/implementation/configuration/. i.e. op chooses, not vendor. >> >> randy > > _______________________________________________ > Dcrouting mailing list > Dcrouting@ietf.org > https://www.ietf.org/mailman/listinfo/dcrouting > From nobody Wed Jan 3 09:23:28 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5308112D0C3 for ; Wed, 3 Jan 2018 09:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wDxIlM088u8U for ; Wed, 3 Jan 2018 09:23:23 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (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 6869512D7E3 for ; Wed, 3 Jan 2018 09:23:18 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-11v.sys.comcast.net with ESMTP id Wml4eFHXjP3F3Wml4eJhoq; Wed, 03 Jan 2018 17:23:18 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-06v.sys.comcast.net with SMTP id WmiuekJqCWQ7ZWmixe3OAY; Wed, 03 Jan 2018 17:21:16 +0000 From: tony.li@tony.li Content-Type: multipart/alternative; boundary="Apple-Mail=_F863C3B1-C4BB-403A-BDCA-1A004F556085" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <83281488-E942-4A8F-8C87-B4076734D3D1@tony.li> References: <151499984931.30939.8391883445576375968.idtracker@ietfa.amsl.com> To: dcrouting@ietf.org, isis-wg@ietf.org, ospf@ietf.org Date: Wed, 3 Jan 2018 09:21:04 -0800 X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfDslTiYr/r+A4b7MnTkwaABFqYU6+YSKbohpFKPNwV9sfsCg00fQPoAPnunvRk3hVCm7mLbYLAH+qYmiJGtFPIGdTM9/wb/ZLhT/3bOvijM+MfWWHuf8 P2cZ6Nn4Pv5L/clSDvTdw3b67wH23atdMd3/RHPk9iRGt2q0emS4Ie9DM0yyr1k8i58ZlH2E+v9MZWSYJwaGTRFdgRdFt4TFuPw= Archived-At: Subject: [Dcrouting] Fwd: New Version Notification for draft-li-dynamic-flooding-00.txt X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 17:23:26 -0000 --Apple-Mail=_F863C3B1-C4BB-403A-BDCA-1A004F556085 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI... > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-li-dynamic-flooding-00.txt > Date: January 3, 2018 at 9:17:29 AM PST > To: "Tony Li" >=20 >=20 > A new version of I-D, draft-li-dynamic-flooding-00.txt > has been successfully submitted by Tony Li and posted to the > IETF repository. >=20 > Name: draft-li-dynamic-flooding > Revision: 00 > Title: An Architecture for Dynamic Flooding on Dense = Graphs > Document date: 2018-01-02 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-li-dynamic-flooding-00.txt > Status: = https://datatracker.ietf.org/doc/draft-li-dynamic-flooding/ > Htmlized: = https://tools.ietf.org/html/draft-li-dynamic-flooding-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-li-dynamic-flooding-00 >=20 >=20 > Abstract: > Routing with link state protocols in dense network topologies can > result in suboptimal convergence times due to the overhead = associated > with flooding. This can be addressed by decreasing the flooding > topology so that it is less dense. >=20 > This document discusses the problem in some depth and an > architectural solution. Specific protocol changes are not described > in this document. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_F863C3B1-C4BB-403A-BDCA-1A004F556085 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

FYI...

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-li-dynamic-flooding-00.txt
Date: = January 3, 2018 at 9:17:29 AM = PST
To: = "Tony Li" <tony.li@tony.li>

A new version of I-D, draft-li-dynamic-flooding-00.txt
has been successfully submitted by Tony Li and posted to = the
IETF repository.

Name: = draft-li-dynamic-flooding
Revision: 00
Title:= = An Architecture for Dynamic Flooding on Dense Graphs
Document date: 2018-01-02
Group:= = Individual Submission
Pages: 8
URL: =            https://www.ietf.org/internet-drafts/draft-li-dynamic-flooding-= 00.txt
Status: =         https://datatracker.ietf.org/doc/draft-li-dynamic-flooding/=
Htmlized:       https://tools.ietf.org/html/draft-li-dynamic-flooding-00Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-dynamic-flooding= -00


Abstract:
  Routing with link state protocols in dense = network topologies can
  result in suboptimal = convergence times due to the overhead associated
=   with flooding.  This can be addressed by decreasing the = flooding
  topology so that it is less = dense.

  This document discusses = the problem in some depth and an
=   architectural solution.  Specific protocol changes are = not described
  in this document.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_F863C3B1-C4BB-403A-BDCA-1A004F556085-- From nobody Wed Jan 3 09:59:37 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972AC129C6C; Wed, 3 Jan 2018 09:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=netorgft1331857.onmicrosoft.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 8mhilv3t8nPB; Wed, 3 Jan 2018 09:59:33 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0081.outbound.protection.outlook.com [104.47.38.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B101C127873; Wed, 3 Jan 2018 09:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ONPLoALF/sISAw9rRV3njKd2h/97/rysMny+aA1VtjQ=; b=gtC/DBX8tFd2q9p9GuOPypfcF8TVMio19XWHQ1b8Ckf+J9/kWTy9e3Hb3Kn9JGFO0VOUkan7geJUYW4XZvTK7bHO9sIXXepXy908/T8IYPvHJh7pAuZLSIlG3oc/zEPo7mIWmH/SZLQVIqS5Bm5UBgmXbArCVDexR4L5FHHrxsw= Received: from BN6PR18MB1123.namprd18.prod.outlook.com (10.173.154.137) by BN6PR18MB1121.namprd18.prod.outlook.com (10.173.154.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.8; Wed, 3 Jan 2018 17:59:29 +0000 Received: from BN6PR18MB1123.namprd18.prod.outlook.com ([10.173.154.137]) by BN6PR18MB1123.namprd18.prod.outlook.com ([10.173.154.137]) with mapi id 15.20.0366.007; Wed, 3 Jan 2018 17:59:28 +0000 From: Keyur Patel To: Randy Bush CC: "Acee Lindem (acee)" , Alvaro Retana , Xuxiaohu , "dcrouting@ietf.org" , "lsvr@ietf.org" Thread-Topic: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf Thread-Index: AQHThEHv931sU5lHOUOXjaWIzyFocKNh6pOA Date: Wed, 3 Jan 2018 17:59:28 +0000 Message-ID: References: <0DB89F21-8E32-46A7-A2B7-B79977948455@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [75.8.210.205] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR18MB1121; 7:DHLzVpwotoeMVDjOA41SAsJKwma7AkYEz/r1XfRJ8Y5ZK2sxRomWQdvYQp8aodafMSuUTRjKZc4XOIYeeAUhGevTYx5AY1f6+vzGo+etjs8OxEZKWSR19soc6ytAagcQcD7saZ7y+a68MSSBwquFJNhYUUJ4feH7nh39OP8Uhm/w6IOaQ1NrGc6XVJSyPOjxGPNW4y7qZ4bf0DAq/RjUxooVEe3At5CKxZdNZDHdjwN/lXnOjFHxfFtCJb0ewswx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 852e827d-5111-4b63-5a22-08d552d3bc16 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:BN6PR18MB1121; x-ms-traffictypediagnostic: BN6PR18MB1121: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(944501075)(93006095)(93001095)(3002001)(10201501046)(6041268)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(2016111802025)(20161123564045)(6043046)(6072148)(201708071742011); SRVR:BN6PR18MB1121; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR18MB1121; x-forefront-prvs: 0541031FF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39830400003)(39380400002)(396003)(24454002)(189003)(199004)(76176011)(6506007)(66066001)(53546011)(83716003)(229853002)(6486002)(77096006)(230783001)(2900100001)(6512007)(6436002)(102836004)(86362001)(54906003)(82746002)(99286004)(558084003)(2906002)(8936002)(8676002)(33656002)(7736002)(68736007)(3280700002)(316002)(53936002)(36756003)(305945005)(3846002)(81156014)(14454004)(6916009)(4326008)(478600001)(3660700001)(97736004)(39060400002)(6246003)(5660300001)(6116002)(81166006)(25786009)(105586002)(2950100002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR18MB1121; H:BN6PR18MB1123.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: B+72lFkra5aAJ3iHssx6VODUHsZ9mk7i1PjmRsTL/hmIKu7gFBmUkcYYoucUEl/xYV0IVjvIv48BnuxHOh4w+g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <76C7D80D7684C84CB3725E78CABEB119@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 852e827d-5111-4b63-5a22-08d552d3bc16 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2018 17:59:28.7920 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR18MB1121 Archived-At: Subject: Re: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 17:59:36 -0000 WWVwLiBBZ3JlZWQuDQoNCk9uIDEvMi8xOCwgNzoyMSBQTSwgIlJhbmR5IEJ1c2giIDxyYW5keUBw c2cuY29tPiB3cm90ZToNCg0KICAgID4gRnVydGhlcm1vcmUsIHdlIGNvdWxkIGNob3NlIHRvIGNv bnNpZGVyIHN1Y2ggYW4gaW50ZXJhY3Rpb24gYXMgYQ0KICAgID4gbWF0dGVyIG9mIGxvY2FsIHBv bGljeSAoaW1wbGVtZW50YXRpb24gc3BlY2lmaWMpLg0KICAgIA0KICAgIHBlZGFudHJ5OiBzL2lt cGxlbWVudGF0aW9uL2NvbmZpZ3VyYXRpb24vLiAgaS5lLiBvcCBjaG9vc2VzLCBub3QgdmVuZG9y Lg0KICAgIA0KICAgIHJhbmR5DQogICAgDQoNCg== From nobody Thu Jan 4 14:01:34 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A46112741D for ; Thu, 4 Jan 2018 14:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhjGFcaJgP-o for ; Thu, 4 Jan 2018 14:01:30 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 5B34C126E3A for ; Thu, 4 Jan 2018 14:01:30 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id w107so2775082wrb.9 for ; Thu, 04 Jan 2018 14:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=mUw14SUTwtAj7HZA+997K7JwCSk10ne7HEQ4h1EtKWc=; b=JZr6qcT4COnAjfX5SG0YcA6JrlrAXVUNT5C0bbmhp283vv/Q9Pfl1e0Q2yOPX3SHn2 JCGchDry4f2ZGmXbzW4K+w/gk9HKG5tBx6kTRH/vHCPuWtpSXrFLtlBUHEPtTs4UcPIp m/INhtFqqFZOKmmZuy/fVuLaGgtVF7CetNumWymMdflZqePVy62don/HQnAwRZuEnNW5 tlSIyXlihJo7pQ9brXoJ0nN8aex/1HV3A3Md+wiUmO1zZZ5BCLG/ivGZfr0g7QainRAQ rNioVUsVyHaG+HQekTcuMkH+ZZvDCTC1QFXPnwyEOrFGIM288XuxPx+tJMi0OmGE/42p dWaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=mUw14SUTwtAj7HZA+997K7JwCSk10ne7HEQ4h1EtKWc=; b=E1rsinwAC4U6vfPVn9+/E81bfdhTLyHo+n6soOQ8bLExtEAUQnYbL6Db4LIIdA4vhR 4Uj08o3TbXbJ2BPSFBPr9jN66sKrVyDsbXMq0nnRN/wBOZgfvDkMCdixh1M64QdoOSHc 5BpNnxRR62uUoTNLboFLflpK9CZeRv6yyHTRDR1MlqqY7DJ1dWf9vWkI8rZPr08jjYqs RP5ktbvY1ROWhyyjoLsH7OHmKG9mGCXxVlagvwayfK1qOm6gQ+czD3qKxISL4RbhkKsJ j/dvSPWJZSEe0pfk23EzC8xLqh0ljkRoB+USAFQ2m8021SIf/0UD51yCsnJAgAcacimW RWyg== X-Gm-Message-State: AKGB3mLPu+KL14fQVzsGW//ztpUS8kjA82pWNt1MC+DLttgM+5u8GuwD MjQKXdn+YN+4pdKfCKrT29o1nygpU8wS+bUcmopVSA== X-Google-Smtp-Source: ACJfBotCcDMEcruyJW3Aq5OvTK2Y9HhAoLxKEWVQIk/ekdx0bCC8e6xa+qUDRqiyDTneaAxgTCuUslZmYqwz/1XYSdc= X-Received: by 10.223.134.125 with SMTP id 58mr874268wrw.224.1515103288578; Thu, 04 Jan 2018 14:01:28 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Thu, 4 Jan 2018 14:01:27 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Thu, 4 Jan 2018 23:01:27 +0100 X-Google-Sender-Auth: 8xxkGDYFQRNtZr-c9I6jYJwxfk4 Message-ID: To: dcrouting@ietf.org Content-Type: multipart/alternative; boundary="001a1146d1385058e90561fa790d" Archived-At: Subject: [Dcrouting] Fwd: [Rift] kicking off the charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 22:01:33 -0000 --001a1146d1385058e90561fa790d Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message ---------- From: Robert Raszuk Date: Thu, Jan 4, 2018 at 10:48 PM Subject: Re: [Rift] kicking off the charter discussion To: Alia Atlas Cc: rift@ietf.org Hi Alia, Do we really need yet one more new routing protocol vs relatively minor extension of existing link state protocols ? In the light of recent proposal of dynamic flooding I am completely not convinced there is need to discuss rift charter. REF: https://tools.ietf.org/html/draft-li-dynamic-flooding-00 Cheers, Robert On Thu, Jan 4, 2018 at 8:03 PM, Alia Atlas wrote: > Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG > charters with Alvaro. Here is what we have so far. Comments and > improvements would be most welcome. > > ================ > Routing in Fat Trees (RIFT) > > Clos and Fat-Tree topologies have gained prominence in data center > networks as a result of a trend towards centralized data center network > architectures that may deliver computation and storage services. > > The Routing in Fat Trees (RIFT) protocol addresses the demands of routing > in Clos and Fat-Tree networks via a mixture of both link-state and > distance-vector techniques colloquially described as 'link-state towards > the spine and distance vector towards the leafs'. RIFT uses this hybrid > approach to focus on networks with regular topologies with a high degree of > connectivity, a defined directionality, and large scale. > > The RIFT Working Group will work on a standards track specification of a > specialized, dynamic routing protocol for Clos and fat-tree network > topologies. The protocol will: > > - deal with automatic construction of fat-tree topologies based on > detection of links, > - minimize the amount of routing state held at each topology level, > - automatically prune topology distribution exchanges to a > sufficient subset of links, > - support automatic disaggregation of prefixes on link and node failures > to prevent black-holing and suboptimal routing, > - allow traffic steering and re-routing policies, > - and provide mechanisms to synchronize a limited key-value data-store > that can be used after protocol convergence. > > It is important that nodes participating in the protocol should need only > very light configuration and should be able to join a network as leaf nodes > simply by connecting to the network using default configuration. > > The protocol must support IPv6 and should also support IPv4. > > The Working Group may establish additional requirements to constrain and > inform their work. > > The RIFT Working Group is chartered for the following list of items: > > - A Standards Track specification based on draft-przygienda-rift. The > document will include: > > - an Implementation Status section as described in RFC 7942 > - an Operational Considerations section to explain how the protocol is > configured, deployed, and diagnosed > - Security and Privacy Considerations, although this material may refer > to a separate Threat Analysis document (q.v.). > - A YANG module focused on configuration of protocol instances > - An Applicability Statement that describes how to deploy and configure > the protocol in networks with different topologies > - A Security Threat Analysis document that describes the attack vectors > and mitigations that shall be sent for publication at the same time as the > protocol specification. > > Milestones > > Feb 2018 Adopt a protocol specification document > Feb 2019 Submit protocol specification to IESG for publication > Feb 2019 Submit Threat Analysis to IESG for publication > Apr 2019 Submit YANG module to IESG for publication > Apr 2019 Submit Applicability Statement to IESG for publication > > ============ > > Thanks, > > Alia > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > > --001a1146d1385058e90561fa790d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

--= -------- Forwarded message ----------
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, Jan 4, 2018 at 10:48 PM<= br>Subject: Re: [Rift] kicking off the charter discussion
To: Alia Atlas= <akatlas@gmail.com>
Cc: = rift@ietf.org


H= i Alia,

Do we really need yet one more new routing protocol vs relativ= ely minor extension of existing link state protocols ?=C2=A0

In the li= ght of recent proposal of dynamic flooding I am completely not convinced th= ere is need to discuss rift charter.=C2=A0


Cheers,
Robert



=
On Thu, Jan 4, 2018 at 8:03 PM, Alia Atlas <akatlas= @gmail.com> wrote:
Tony, Jeffrey Zhang, I, and oth= ers have been discussing possible RIFT WG charters with Alvaro.=C2=A0 Here = is what we have so far.=C2=A0 Comments and improvements would be most welco= me.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Routing in Fat Trees (RIFT)

Clos and Fat-Tree topologies have= gained prominence in data center networks as a result of a trend towards c= entralized data center network architectures that may deliver computation a= nd storage services.
=C2=A0
The Routing in Fat Trees (RIFT) protocol = addresses the demands of routing in Clos and Fat-Tree networks via a mixtur= e of both link-state and distance-vector techniques colloquially described = as 'link-state towards the spine and distance vector towards the leafs&= #39;.=C2=A0 RIFT uses this hybrid approach to focus on networks with regula= r topologies with a high degree of connectivity, a defined directionality, = and large scale.

The RIFT Working Group will work on a standards tra= ck specification of a specialized, dynamic routing protocol for Clos and fa= t-tree network topologies. The protocol will:

- deal with automatic = construction of fat-tree topologies based on detection of links,
- minim= ize the amount of routing state held at each topology level,
- automatic= ally prune topology distribution exchanges to a sufficient=C2=A0subset of l= inks,
- support automatic disaggregation of prefixes on link and node fa= ilures to prevent black-holing and suboptimal routing,
- allow traffic s= teering and re-routing policies,
- and provide mechanisms to synchronize= a limited key-value data-store that=C2=A0can be used after protocol conver= gence.

It is important that nodes participating in the protocol shou= ld need only very light configuration and should be able to join a network = as leaf nodes simply by connecting to the network using default configurati= on.

The protocol must support IPv6 and should also support IPv4.
=
The Working Group may establish additional requirements to constrain an= d inform their work.

The RIFT Working Group is chartered for the fol= lowing list of items:

- A Standards Track specification based on dra= ft-przygienda-rift. The document will include:

=C2=A0 - an Implement= ation Status section as described in RFC 7942
=C2=A0 - an Operational Co= nsiderations section to explain how the protocol is configured, deployed, a= nd diagnosed
=C2=A0 - Security and Privacy Considerations, although this= material may refer to a separate Threat Analysis document (q.v.).
=C2= =A0 - A YANG module focused on configuration of protocol instances
=C2= =A0 - An Applicability Statement that describes how to deploy and configure= the protocol in networks with different topologies
=C2=A0 - A Security = Threat Analysis document that describes the attack vectors and mitigations = that shall be sent for publication at the same time as the protocol specifi= cation.

Milestones

=C2=A0 Feb 2018 Adopt a protocol specifica= tion document
=C2=A0 Feb 2019 Submit protocol specification to IESG for = publication
=C2=A0 Feb 2019 Submit Threat Analysis to IESG for publicati= on
=C2=A0 Apr 2019 Submit YANG module to IESG for publication
=C2=A0 = Apr 2019 Submit Applicability Statement to IESG for publication

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Thanks,

Alia


_____________________________________= __________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift



--001a1146d1385058e90561fa790d-- From nobody Thu Jan 4 15:02:46 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9C1126BF7; Thu, 4 Jan 2018 15:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 L5uNiMSXIB4a; Thu, 4 Jan 2018 15:02:42 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 DA06B126B6E; Thu, 4 Jan 2018 15:02:41 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 97so36270otj.13; Thu, 04 Jan 2018 15:02:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=/vharC6XqmhTbYQsojGFS3lPraWqh5fOutlWSGfXu90=; b=VhU+RU12PhnIrcFgBXB6i1fcAkAspPiCizdh2pZWTGCIbf+4ELbSMwTqnQC1Vj2hJN Iczz/xkk19qers1qylNEXaxTjZtjY2/yLoviOy/j5TX/7Yv5KygegvucprRfNYTDgc6c 2vSbdtxNFZHHJdSjrz5idVv8XxJpxVP/l7p4U2LklqmfXLRMv/wTX8EDWkR0St3qls31 PYkdVJ3yFhzeTHuNxCo5HFrWZ7XInxNSxQBQM1Hnftech7ob8hmC+Xxgx8zM6xKcgnC9 wZGynDFU1+Uua89KttprfCZ7hlmYiO3YUvUZrmZIUZBPEpAvPD1g1scXZ8mBs5+Jdfnw Em3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=/vharC6XqmhTbYQsojGFS3lPraWqh5fOutlWSGfXu90=; b=Ry/MGoQc1/rGKdOoM8xxXBPC/usP29tDa6B08RCX85sdozGfgU7OsxgoCc3KM+YFbS Xegf59WSNFg12pAF563stS1MYbUG25X/73N3MqORsWUglNPmJr7uzYIjzkUHNVhSNXKV iOaCYeqSz5cMZAM2XQFerrHBEz6avwRH6alPANrBNfFhhpHIm2hHVvMAGn+/aU0SC0ID 3jkN16gk1LHlxaSq2IcEJpax68rKIG5TTEjVv6lJA1OGCScL3h7MsbaSUcP2PnVMcAs/ YhcoBePzdzgvblIqzBMqgJQ5OWNKBg5kkVWgdvEKAYJgoHT2wuVyGJk3S8Nx0Fdo44TO L8Kg== X-Gm-Message-State: AKwxyteAm3hgXsTT4A7M9Ph3RXDexY56v4+mIkudQCff4A1tQwmyucP/ PfG9FXFfy3ElakuI9q2J5dgBZgO9fuKlaijAtmE= X-Google-Smtp-Source: ACJfBosGobI0+2nrcxLrPc2op9uNqoxPxrbinSB0vMMfyF1Ag61N0OXQf7QZJW6u+ZONVTAzzTbS+a2ub+LnQJzKRvM= X-Received: by 10.157.89.137 with SMTP id u9mr702509oth.164.1515106961235; Thu, 04 Jan 2018 15:02:41 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 4 Jan 2018 15:02:40 -0800 From: Alvaro Retana In-Reply-To: References: X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 4 Jan 2018 15:02:40 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, lsvr@ietf.org, "dcrouting@ietf.org" Content-Type: multipart/alternative; boundary="f40304353f6438a2010561fb5471" Archived-At: Subject: Re: [Dcrouting] [Rift] kicking off the charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:02:45 -0000 --f40304353f6438a2010561fb5471 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote: Robert: Hi! Happy New Year! Do we really need yet one more new routing protocol vs relatively minor extension of existing link state protocols ? That was pretty much the question asked during the dcrouting BOF in Singapore. Starting from the assumption that one size doesn=E2=80=99t fit = all, the room showed interest in working on solutions beyond the current work in isis/ospf (which was also quickly reviewed there). To be clear, the intent of chartering rift doesn=E2=80=99t mean that work i= n other WGs (including new proposals) should stop. Quite the contrary, if there is sustained interest in this effort, then we will go on with it =E2=80=94 if = there isn=E2=80=99t (for whatever reason), then it will be clear as well. Note t= hat I asked the proponents to constrain the proposed charter to work items that should be able to be delivered within a short timeframe (around a year) =E2= =80=94 so that we can reassess the interest, and re-charter if appropriate. The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2=80= =99m cc=E2=80=99ing that list here to avoid repeating the discussion there. Als= o, I noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80=99= ing that list as well. Thanks! Alvaro. --f40304353f6438a2010561fb5471 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On January 5, = 2018 at 5:48:23 AM, Robert Raszuk (rob= ert@raszuk.net) wrote:

=
Robert:

Hi!=C2=A0 Happy New Year!

<= /font>
Do we really need yet one more new routing= protocol vs relatively minor extension of existing link state protocols ?= =C2=A0

That was pretty much the question asked durin= g the dcrouting BOF in Singapore.=C2=A0 Starting from the assumption that o= ne size doesn=E2=80=99t fit all, the room showed interest in working on sol= utions beyond the current work in isis/ospf (which was also quickly reviewe= d there).

To be clear, the intent of chartering rift doesn=E2=80=99t mean that wor= k in other WGs (including new proposals) should stop.=C2=A0 Quite the contr= ary, if there is sustained interest in this effort, then we will go on with= it =E2=80=94 if there isn=E2=80=99t (for whatever reason), then it will be= clear as well.=C2=A0 Note that I asked the proponents to constrain the pro= posed charter to work items that should be able to be delivered within a sh= ort timeframe (around a year) =E2=80=94 so that we can reassess the interes= t, and re-charter if appropriate.

The above obviously applies to the lsvr (aka BGP= -SPF) proposal, so I=E2=80=99m cc=E2=80=99ing that list here to avoid repea= ting the discussion there.=C2=A0 Also, I noticed you forwarded your message= to dcrouting, so I=E2=80=99m cc=E2=80=99ing that list as well.

Thanks!

Alvaro.
--f40304353f6438a2010561fb5471-- From nobody Thu Jan 4 15:13:39 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE18126B71; Thu, 4 Jan 2018 15:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1QXHrMx-l9KQ; Thu, 4 Jan 2018 15:13:35 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 30F3312420B; Thu, 4 Jan 2018 15:13:35 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id b141so6301299wme.1; Thu, 04 Jan 2018 15:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TIMiJJbEceqbsi0eZInm8W7y2HyIhMaKM98cY+BhLcU=; b=kRf5dq60K+tBNbTQawUatyzXWSXgqMrdWoycmTQTL3U3J61B7rRuDCM3/21XPJgCri e/pjMKvyLfnLV9niM6rsj2+4BEiRFX36hpf+8dezh/SX5A1WSud8J1qOMgLGsMiGgej3 2LQdj2TTJCb62hX8D5fj8lRmRnf8RETmKqk2mpzTsv6bj8tDk+P0UR1IAA66sZyVoX8q POOQ57NQpPbFIc9fXNOFCyDWla712N0ADYuv2rOAu9KUGH+QDWrmCnSbpf1D4mKHbeHT jUzp3HxUQ2eTWAP+3NqoBSL37eK32OWNR3YiTncfje2NOnZHZukdZmakAj7QweFzLgs9 LfSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TIMiJJbEceqbsi0eZInm8W7y2HyIhMaKM98cY+BhLcU=; b=l2MUOvEvUV/N6V1W9z4u/qG8IvjQ/jDtSsR4ArcHV5O+o3BKoeCPC66XNmmigPlOly TAO0tjVPWp7phbbmIsZFFu3dKqvipc3a92Fm1HwhaQx/tfxxRLDeF6UuoQQX19gu/bAN jHwe1vCwB/zMN/3KgB+R5IswNLQkV5byNEARygFXx3TfUudm0snj0ZDocBeoDbCpFl5m blOMKMSnk2Bkm4/e3mhOQIyB2oc7yTvB6tlv06RmBjUThtrOvdzJWHiM5UOt62ZD6sQi sAH2tXCX53GSfMBjkVlmAIJiEo33S+vR1+h3muQJo9rvW7bwVSOS6p4taWgBFnZMUuLG TVYQ== X-Gm-Message-State: AKGB3mKwipnRxQ4rP1d5hn7w+EEy2gG0FyutAjhNlPxAZKdAxpYdasw6 rrzFKg19uvYwsXDtrB05v8vp1R1QqLG1e6hyDUQ= X-Google-Smtp-Source: ACJfBovw7K5lG+jBVjkzMaMIvWgYmFlDsceEPM9YEp8uCLvUFPCqtchb4xsdsQCfk8X8zoaTXwVUVsd7DhWqsF2nv7k= X-Received: by 10.28.232.148 with SMTP id f20mr731933wmi.147.1515107613520; Thu, 04 Jan 2018 15:13:33 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Thu, 4 Jan 2018 15:13:32 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Fri, 5 Jan 2018 00:13:32 +0100 X-Google-Sender-Auth: eNsIvzejQXL_7-qh-nHpEo9bl-0 Message-ID: To: Alvaro Retana Cc: rift@ietf.org, lsvr@ietf.org, "dcrouting@ietf.org" Content-Type: multipart/alternative; boundary="001a1147c49e19b7380561fb7bfa" Archived-At: Subject: Re: [Dcrouting] [Rift] kicking off the charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:13:38 -0000 --001a1147c49e19b7380561fb7bfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Happy New Year !!! > That was pretty much the question asked during the dcrouting BOF in Singapore. Well .. in Singapore and during most of list discussions dynamic flooding proposal was not on the table. Now it is. To me this is game changer and any conclusions reached previously IMHO should now be revisited. As far as outcome of the BOF - I am not sure how the conclusion was derived that we need new protocols - especially only those presented. In real practical cases a lot of DC clusters are build with at most few hundreds of L3 nodes which in all flavors of current link state implementations will work just fine as is. For MSDCs use of either eBGP or Open/R is deployed. Now dynamic flooding can extend link state to scale much larger. Personally IMHO this case is solved. Maybe time to move on to other areas ? :) Best, R. On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana wrote: > On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote= : > > Robert: > > Hi! Happy New Year! > > Do we really need yet one more new routing protocol vs relatively minor > extension of existing link state protocols ? > > > That was pretty much the question asked during the dcrouting BOF in > Singapore. Starting from the assumption that one size doesn=E2=80=99t fi= t all, the > room showed interest in working on solutions beyond the current work in > isis/ospf (which was also quickly reviewed there). > > To be clear, the intent of chartering rift doesn=E2=80=99t mean that work= in other > WGs (including new proposals) should stop. Quite the contrary, if there = is > sustained interest in this effort, then we will go on with it =E2=80=94 i= f there > isn=E2=80=99t (for whatever reason), then it will be clear as well. Note= that I > asked the proponents to constrain the proposed charter to work items that > should be able to be delivered within a short timeframe (around a year) = =E2=80=94 > so that we can reassess the interest, and re-charter if appropriate. > > The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m > cc=E2=80=99ing that list here to avoid repeating the discussion there. A= lso, I > noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as > well. > > Thanks! > > Alvaro. > --001a1147c49e19b7380561fb7bfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

=
Happy New Year !!!

> That was pretty much the question asked during the dcrouting = BOF in Singapore.=C2=A0

Well= .. in Singapore and during most of list discussions dynamic flooding propo= sal was not on the table. Now it is.=C2=A0
<= span style=3D"font-family:arial,sans-serif;font-size:12.8px">
To me this is game changer and any conclusions reached previously IMHO sho= uld now be revisited.=C2=A0

As far as ou= tcome of the BOF - I am not sure how the conclusion was derived that we nee= d new protocols - especially only those presented. In real practical cases = a lot of DC clusters are build with at most few hundreds of L3 nodes which = in all flavors=C2=A0of current link state implementations will work just fi= ne as is.=C2=A0

For MSDCs use of e= ither eBGP or Open/R is deployed.

Now dyna= mic flooding can extend link state to scale much larger.=C2=A0
=
Personally=C2=A0IMHO this case is solved. Maybe time to move o= n to other areas ? :)
<= span style=3D"font-size:12.8px">
Best,
R.


<= br>
On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retan= a <aretana.ietf@gmail.com> wrote:
On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:

Robert:

Hi!= =C2=A0 Happy New Year!

D= o we really need yet one more new routing protocol vs relatively minor exte= nsion of existing link state protocols ?=C2=A0

That was pretty much t= he question asked during the dcrouting BOF in Singapore.=C2=A0 Starting fro= m the assumption that one size doesn=E2=80=99t fit all, the room showed int= erest in working on solutions beyond the current work in isis/ospf (which w= as also quickly reviewed there).

To be clear, the intent of chartering = rift doesn=E2=80=99t mean that work in other WGs (including new proposals) = should stop.=C2=A0 Quite the contrary, if there is sustained interest in th= is effort, then we will go on with it =E2=80=94 if there isn=E2=80=99t (for= whatever reason), then it will be clear as well.=C2=A0 Note that I asked t= he proponents to constrain the proposed charter to work items that should b= e able to be delivered within a short timeframe (around a year) =E2=80=94 s= o that we can reassess the interest, and re-charter if appropriate.

The a= bove obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2=80=99m c= c=E2=80=99ing that list here to avoid repeating the discussion there.=C2=A0= Also, I noticed you forwarded your message to dcrouting, so I=E2=80=99m cc= =E2=80=99ing that list as well.

Thanks!

Alvaro.

--001a1147c49e19b7380561fb7bfa-- From nobody Thu Jan 4 15:36:50 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E491127876; Thu, 4 Jan 2018 15:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 h5t0_F0rhCvt; Thu, 4 Jan 2018 15:36:39 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 91049127863; Thu, 4 Jan 2018 15:36:39 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id g59so2670093otg.11; Thu, 04 Jan 2018 15:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=VZyLhPQl9OMvHpsHmLbAogRpZEf6QtwXAYRe3BXYLvI=; b=KMTx4Zhj2V1HzM+z8zkOqPf02JN3ZhyemDTfQF2AokmSJ3D6rtgv0jDcmtd7ND3AQX ccU3IzQnK9kghRmaD+l246/mgzxtsJn2mTmL0wTY1YwkJnRVEYp26DBQLxG8YYILqmQU n07hY1oaZJ2lMTfoUdwKN6ti5jh8aXRvjLuuAgjSiEFY9lK2Zlg7B1s+vRoSUWfDTYsz 4bff/dh8MuIkTgILPPSDckgf6mObmUf8ZcMMJFtf1FOC4hi1GvospSYdwWDjlKiPaGJ7 F03Cb95m0qcCy27ubpB+mCcIDwLiN9OzVMFBPCf9wkREYWKgBOITIkQsVtQYQ7BlqhvI c2WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=VZyLhPQl9OMvHpsHmLbAogRpZEf6QtwXAYRe3BXYLvI=; b=dwzUhTCWW/Ue83n2dwgUVgrx2LoiyeVnmk3oFOoa1x+1oy/XUrjWH43W0bNpMhyFgd GAEUezK2z46FdRJx+kevAtlZAYcR/9fzKwj+h5dbEzW0b9WCJ5R9gFr2SZwQ/jDsA0Za ElfqfrX8mm5WSTcZD3hGhL+b1aBPgWzgszliGZ98MiSe8d5uk5n59n3Mhf1KQnJWpqRT UBS/sszQAE2M7DXbr8hW9h4gPpvlVjeqx1kWKb5MB53UvN4/qXIlVmd/DG6zPnzmKZBv Re2d6ZFc4r9U0dVTyKRdwTJWmWerT/i1/BndyGorAfhSENaZZ1+PWCFATmN2T5YObPDO CtDQ== X-Gm-Message-State: AKwxytdj/2MWtCCWiPkiJy3fTyNMxgPIQB0QkIhB+PCZNSrnMWfLvYxG 99o+jum2cQtT0+k72SEWLoRF5EvIgsbLvUirnQA= X-Google-Smtp-Source: ACJfBosT0rDxF7qpoheOgLy/B7Ib8gYYO0GNOD7UNTe1FNc4SXUUB8ehK74ndfwQ7rfQxcEL2ducUqf5ziBeiuLweIw= X-Received: by 10.157.63.136 with SMTP id r8mr855921otc.187.1515108998974; Thu, 04 Jan 2018 15:36:38 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 4 Jan 2018 15:36:38 -0800 From: Alvaro Retana In-Reply-To: References: X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 4 Jan 2018 15:36:38 -0800 Message-ID: To: Robert Raszuk Cc: "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="001a11c02924ae14570561fbcd63" Archived-At: Subject: Re: [Dcrouting] [Rift] kicking off the charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:36:42 -0000 --001a11c02924ae14570561fbcd63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert: As I said: if there=E2=80=99s no interest in a specific proposal it will th= en be clear from the list discussion and we=E2=80=99ll do the right thing. I really don=E2=80=99t want to make this a beauty contest =E2=80=94 there a= re multiple feasible solutions, some may be better than others. We can probably all argue in favor of our favorite solution/protocol/idea, but that won=E2=80= =99t move any of them forward. IOW, please focus on advancing what you think is worth advancing=E2=80=A6 Thanks! Alvaro. On January 5, 2018 at 7:13:34 AM, Robert Raszuk (robert@raszuk.net) wrote: Hi Alvaro, Happy New Year !!! > That was pretty much the question asked during the dcrouting BOF in Singapore. Well .. in Singapore and during most of list discussions dynamic flooding proposal was not on the table. Now it is. To me this is game changer and any conclusions reached previously IMHO should now be revisited. As far as outcome of the BOF - I am not sure how the conclusion was derived that we need new protocols - especially only those presented. In real practical cases a lot of DC clusters are build with at most few hundreds of L3 nodes which in all flavors of current link state implementations will work just fine as is. For MSDCs use of either eBGP or Open/R is deployed. Now dynamic flooding can extend link state to scale much larger. Personally IMHO this case is solved. Maybe time to move on to other areas ? :) Best, R. On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana wrote: > On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote= : > > Robert: > > Hi! Happy New Year! > > Do we really need yet one more new routing protocol vs relatively minor > extension of existing link state protocols ? > > > That was pretty much the question asked during the dcrouting BOF in > Singapore. Starting from the assumption that one size doesn=E2=80=99t fi= t all, the > room showed interest in working on solutions beyond the current work in > isis/ospf (which was also quickly reviewed there). > > To be clear, the intent of chartering rift doesn=E2=80=99t mean that work= in other > WGs (including new proposals) should stop. Quite the contrary, if there = is > sustained interest in this effort, then we will go on with it =E2=80=94 i= f there > isn=E2=80=99t (for whatever reason), then it will be clear as well. Note= that I > asked the proponents to constrain the proposed charter to work items that > should be able to be delivered within a short timeframe (around a year) = =E2=80=94 > so that we can reassess the interest, and re-charter if appropriate. > > The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m > cc=E2=80=99ing that list here to avoid repeating the discussion there. A= lso, I > noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as > well. > > Thanks! > > Alvaro. > --001a11c02924ae14570561fbcd63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Robert:

As I said: if there=E2=80=99s no interest in a specific prop= osal it will then be clear from the list discussion and we=E2=80=99ll do th= e right thing.
I real= ly don=E2=80=99t want to make this a beauty contest =E2=80=94 there are mul= tiple feasible solutions, some may be better than others.=C2=A0 We can prob= ably all argue in favor of our favorite solution/protocol/idea, but that wo= n=E2=80=99t move any of them forward.=C2=A0 IOW, please focus on advancing = what you think is worth advancing=E2=80=A6

Thanks!

Alvaro.

On January 5, 2018 at 7= :13:34 AM, Robert Raszuk (robert@raszu= k.net) wrote:

Hi Alvaro,

Happy New Year !!!

> That was pretty much the question asked during the dcrouting BOF in Singapore.=C2=A0
Well .. in Singapore and during most of list discussions dynamic flooding proposal was not on the table. Now it is.=C2=A0
To= me this is game changer and any conclusions reached previously IMHO should now be revisited.=C2=A0
As= far as outcome of the BOF - I am not sure how the conclusion was derived that we need new protocols - especially only those presented. In real practical cases a lot of DC clusters are build with at most few hundreds of L3 nodes which in all flavors=C2=A0of current link state implementations will work just fine as is.=C2=A0
For MSDCs use of either eBGP or Open/R is deployed.
No= w dynamic flooding can extend link state to scale much larger.=C2=A0
Pe= rsonally=C2=A0IMHO this case is solved. Maybe time to move on to other areas ? :)
Be= st,
R.=


On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote:
On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:

Robert:

Hi!=C2=A0 Happy New Year!
Do we really need yet one more new routing protocol vs relatively minor extension of existing link state protocols ?=C2=A0

That was pretty much the question asked during the dcrouting BOF in Singapore.=C2=A0 Starting from the assumption that one size doesn=E2=80=99t fit all, the room showed interest in working on solutions beyond the current work in isis/ospf (which was also quickly reviewed there).

To be clear, the intent of chartering rift doesn=E2=80=99t mean that work in other WGs (including new proposals) should stop.=C2=A0 Quite the contrary, if there is sustained interest in this effort, then we will go on with it =E2=80=94 if there isn=E2=80=99t (for whatever reason), then it will be clear as well.=C2=A0 Note that I asked the proponents to constrain the proposed charter to work items that should be able to be delivered within a short timeframe (around a year) =E2=80=94 so that we can reassess the interest, and re-charter if appropriate.

The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2=80=99m cc=E2=80=99ing that list= here to avoid repeating the discussion there.=C2=A0 Also, I noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80=99ing that lis= t as well.

Thanks!

Alvaro.

--001a11c02924ae14570561fbcd63-- From nobody Thu Jan 4 15:44:04 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F094128C0A for ; Thu, 4 Jan 2018 15:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9Aal8pnbMge for ; Thu, 4 Jan 2018 15:43:53 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 556261275F4 for ; Thu, 4 Jan 2018 15:43:49 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id h2so2682178oti.5 for ; Thu, 04 Jan 2018 15:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5uZqkmbAKtcxYzgCp7CqHjUEe+skkAFWcTPAUF8IsrU=; b=QHKjEJ7M1VtODJGMR1vf6iRi9YZFZYfxUt94dFoDDpu6tu7XH78u/GB+L/a69hXFpf ngFjbs8MUaQ+MdgtgNywxFQdByo67BY+KqzTAHbe1QXJ4HK8okGb92IAw4bb50pj4ZDi WKKNGu8ZSFMoM5U1sVa2+aMdjm9rgcMaHEn7fRWfjOYamjcx/xx/r09axevWHUZeg0Fv dx5GF4Ntmi0bm3lN4bFVt+iixIVotZnZQYaGsC5BwEqjSkXYcYdpQ2qPjI3x3yz906ir ca0A3I+HYengs+RASc+k3MUXJfy/Gj1+ilvtcFzdNNImLWFHmerhVj5OH87hiTKREdWt TJDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5uZqkmbAKtcxYzgCp7CqHjUEe+skkAFWcTPAUF8IsrU=; b=oNUwqARJzvnnuho6oaw2lzFX1/gEx+++6w8oJLeu586kTxPE7VjP1rqWwivcbPuTI+ 6h/Wfst2PIWk67GPIC0bFvLOp0pAc/HjuKLPKinoTk13kxL/gGTgjTNr9PAGLtJOC1F4 hWkkdM6heGN1Mvw4WVavCyiVs1g3kSGmhZ568AB7W5pxUjlnIebFt0yUfydHgcavkBmd N9/iVrNi/uDBJ+iM8JSxJIK9urXplwLkJ5voSFsMIrR0tyAucOg+v1DAVc+MnqM1GoIE QsBDdWS/wE6m9lsxI2tIwxZ1qAbDbzyRzcsaeBWwd4hu6YNG77cqMaKzMtSEGpAgADWc 5Rgw== X-Gm-Message-State: AKwxytdS44iAS2FCtjTLBlvMXJUTcLmydX+iOnSqiNKUKqPb5PpnkLGY nlXTcRNHMhHfrGOH0pWkEezuf4of1HCkUbCpaWModQ== X-Google-Smtp-Source: ACJfBos1Wc93420yZW2AQpRXu89Eukcj8oc6m26nhLywjWNG5CRrIPNdg8hLN8KcwXn5ItTz6Jh0VXkCi0pptLzj0no= X-Received: by 10.157.4.162 with SMTP id 31mr735044otm.98.1515109428393; Thu, 04 Jan 2018 15:43:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.60.173 with HTTP; Thu, 4 Jan 2018 15:43:47 -0800 (PST) In-Reply-To: References: From: Victor Kuarsingh Date: Thu, 4 Jan 2018 18:43:47 -0500 Message-ID: To: Robert Raszuk Cc: Alvaro Retana , "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c09c31e468c780561fbe7e7" Archived-At: Subject: Re: [Dcrouting] [Lsvr] [Rift] kicking off the charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:43:55 -0000 --94eb2c09c31e468c780561fbe7e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert, On Thu, Jan 4, 2018 at 6:13 PM, Robert Raszuk wrote: > Hi Alvaro, > > > As far as outcome of the BOF - I am not sure how the conclusion was derived > that we need new protocols - especially only those presented. In real > practical cases a lot of DC clusters are build with at most few hundreds of > L3 nodes which in all flavors of current link state implementations will > work just fine as is. We attempted to structure the BoF to help understand a few things. This included audience input on whether there are new/augmented requirements within the DC and if there was agreement if that may drive us to new protocol work. Based on questions to the audience and feedback (show of of hands), it indicated that there was room for new protocol work (Notes/Minutes here - https://datatracker.ietf.org/doc/minutes-100-dcrouting/) As for BGPSPF (LSVR based solution) and RIFT, audience feedback also supported the notion that there are folks willing to work on such protocols= . > > For MSDCs use of either eBGP or Open/R is deployed. This may be generally true, and based largely on availability of options and protocols. If new options were available, it's hard to say this would still be the case. > > Now dynamic flooding can extend link state to scale much larger. > > Personally IMHO this case is solved. Maybe time to move on to other areas ? > :) I am not sure anything is ever finally solved. Continue refinement of designs and deployments are a norm in our industry as things change. We often make due with what we have and drive changes if possible and/or when needed. I would not want this to limit innovation. Recent example of a place where a new protocol is useful would be Babel. Once can argue that we should have solved similar cases with existing protocols, but that did not mean targeting the new uses cases with a new protocol did not make sense. Requirements continue to change, and we know things today we did not know years ago when we originally built OSPF, IS-IS, BGP etc. I think using empirical knowledge from real deployments to focus new work makes a lot of sense to me. There is likely room to continue iteration of existing protocols, and that may be just fine for many use cases. However, that should not limit us from developing new protocols which can solve new and emerging problems. regards, Victor K > > Best, > R. > > > > On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana > wrote: >> >> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote: >> >> Robert: >> >> Hi! Happy New Year! >> >> Do we really need yet one more new routing protocol vs relatively minor >> extension of existing link state protocols ? >> >> >> That was pretty much the question asked during the dcrouting BOF in >> Singapore. Starting from the assumption that one size doesn=E2=80=99t f= it all, the >> room showed interest in working on solutions beyond the current work in >> isis/ospf (which was also quickly reviewed there). >> >> To be clear, the intent of chartering rift doesn=E2=80=99t mean that wor= k in other >> WGs (including new proposals) should stop. Quite the contrary, if there is >> sustained interest in this effort, then we will go on with it =E2=80=94 = if there >> isn=E2=80=99t (for whatever reason), then it will be clear as well. Not= e that I >> asked the proponents to constrain the proposed charter to work items tha= t >> should be able to be delivered within a short timeframe (around a year) =E2=80=94 so >> that we can reassess the interest, and re-charter if appropriate. >> >> The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m >> cc=E2=80=99ing that list here to avoid repeating the discussion there. = Also, I >> noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as >> well. >> >> Thanks! >> >> Alvaro. > > > > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr > --94eb2c09c31e468c780561fbe7e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Robert,

On Thu, Jan 4, 2018 at 6:13 PM, Robert Rasz= uk <robert@raszuk.net> wrote= :
> Hi Alvaro,
>
>
> As far as outcome of the BOF -= I am not sure how the conclusion was derived
> that we need new prot= ocols - especially only those presented. In real
> practical cases a = lot of DC clusters are build with at most few hundreds of
> L3 nodes = which in all flavors of current link state implementations will
> wor= k just fine as is.

We attempted to structure the BoF to help unders= tand a few things.=C2=A0 This included audience input on whether there are = new/augmented requirements within the DC and if there was agreement if that= may drive us to new protocol work.=C2=A0 Based on questions to the audienc= e and feedback (show of of hands), it indicated that there was room for new= protocol work (Notes/Minutes here - https://datatracker.ietf.org/doc/minutes-100-= dcrouting/)=C2=A0

As for BGPSPF (LSVR base= d solution) and RIFT, audience feedback also supported the notion that ther= e are folks willing to work on such protocols.

>
> For MSDC= s use of either eBGP or Open/R is deployed.

This m= ay be generally true, and based largely on availability of options and prot= ocols.=C2=A0 If new options were available, it's hard to say this would= still be the case.

>
> Now dynamic flooding can ext= end link state to scale much larger.
>
> Personally IMHO this c= ase is solved. Maybe time to move on to other areas ?
> :)
=
I am not sure anything is ever finally solved. Continue refi= nement of designs and deployments are a norm in our industry as things chan= ge.=C2=A0 We often make due with what we have and drive changes if possible= and/or when needed. I would not want this to limit innovation.=C2=A0 Recen= t example of a place where a new protocol is useful would be Babel.=C2=A0 O= nce can argue that we should have solved similar cases with existing protoc= ols, but that did not mean targeting the new uses cases with a new protocol= did not make sense.=C2=A0

Requirements continue t= o change, and we know things today we did not know years ago when we origin= ally built OSPF, IS-IS, BGP etc.=C2=A0 I think using empirical knowledge fr= om real deployments to focus new work makes a lot of sense to me.=C2=A0 The= re is likely room to continue iteration of existing protocols, and that may= be just fine for many use cases.=C2=A0 However, that should not limit us f= rom developing new protocols which can solve new and emerging problems.=C2= =A0

regards,

Victor K

>
> Best,
> R.
>
>
>
> On= Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <aretana.ietf@gmail.com>
> wrote:
>>>> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:
>>
>>= Robert:
>>
>> Hi!=C2=A0 Happy New Year!
>>
&= gt;> Do we really need yet one more new routing protocol vs relatively m= inor
>> extension of existing link state protocols ?
>>>>
>> That was pretty much the question asked during the d= crouting BOF in
>> Singapore.=C2=A0 Starting from the assumption t= hat one size doesn=E2=80=99t fit all, the
>> room showed interest = in working on solutions beyond the current work in
>> isis/ospf (w= hich was also quickly reviewed there).
>>
>> To be clear,= the intent of chartering rift doesn=E2=80=99t mean that work in other
&= gt;> WGs (including new proposals) should stop.=C2=A0 Quite the contrary= , if there is
>> sustained interest in this effort, then we will g= o on with it =E2=80=94 if there
>> isn=E2=80=99t (for whatever rea= son), then it will be clear as well.=C2=A0 Note that I
>> asked th= e proponents to constrain the proposed charter to work items that
>&g= t; should be able to be delivered within a short timeframe (around a year) = =E2=80=94 so
>> that we can reassess the interest, and re-charter = if appropriate.
>>
>> The above obviously applies to the = lsvr (aka BGP-SPF) proposal, so I=E2=80=99m
>> cc=E2=80=99ing that= list here to avoid repeating the discussion there.=C2=A0 Also, I
>&g= t; noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as
>> well.
>>
>> Thanks!
&g= t;>
>> Alvaro.
>
>
>
> ________________= _______________________________
> Lsvr mailing list
> Lsvr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsvr<= /a>
>
--94eb2c09c31e468c780561fbe7e7-- From nobody Thu Jan 4 15:59:29 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC07B12741D; Thu, 4 Jan 2018 15:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xMPN4eD2aapr; Thu, 4 Jan 2018 15:59:26 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 E5EFF126CF9; Thu, 4 Jan 2018 15:59:25 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id t8so6372585wmc.3; Thu, 04 Jan 2018 15:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2RxeVdpq1Mpcl9/pHeL7AJFTqSpIw56qWobL6i3Vy0g=; b=Ca8Bs05L5XRi8ijbGHMhPHbVn2wb3OVYiyXa0arK+6mgadO1AKCkCKz7sjVAZL+5/V e+DfTeQLEx6IMSinsVkOWcGTQoSQhShI95JGM1Hqx/V1o/Cmk5yDR012iCE0kIqkjBxC UMpbrVUpQAk5iNxmMOdO89rY77l7AHRWNkWFG0/+7JSyzOOuKQIqpasr4HwShMi7mG71 eBQ2kWO4uAK927X5CCnFDxogrPJUTIOiY5XC3lYqImEMR2AKhXBByvngXJBQrEBGsLrH cKGlLQUOEJyeied1y4AsIoTgWT9OSH2c50q3Bwm8ckfmHJQCzI9oiz1RKL6+kMoyNv79 IYfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2RxeVdpq1Mpcl9/pHeL7AJFTqSpIw56qWobL6i3Vy0g=; b=VLguUpw1kW4uN3Z0UMnLgsJOZhUaH246AkKB/o1qxJV/rbxiYRmjFbCakRcxTSNicu Xa+Z7qwhTE2TOr4COjrwJkvOEFf/xNpGG9zh23wJ8LgOf2j4LJ5Gr+7WucvSKvU50/CU BAyzgl+aDt85rF21lGACFv8PZFlOoqsshHjVKR+jCMGwjiu0Kklq003uaXzhCCJoRGtI pH3QAcfOoo8Tox61Ou4F9gbvKURKXcaM1PLrDtndVCvarlBWP9P3D756oIKVhtisOzsR X63I/7G+G37CF7fslVogXmQ0Nvfc+zCGG8iXg57ccGdwQpcm4UZslkGNIytEruEt1fbu 4GgQ== X-Gm-Message-State: AKGB3mKoTBkPxoRp5Qvh/8bSyP1Rg0ZYMr/mgmZuHQQPOaEgQz3W+bJ6 93Q5PHj8AGIqYhYv38AYd3brvQUJWHWSN5xr2FQ= X-Google-Smtp-Source: ACJfBos0Y9zLAMN57BQ42U15PZUA8JkRvw9Sn8tqZ326Jth0e8t9pXLEb71LPNE1F4oUau5vCpouNsuL6Sgbp2n7iYY= X-Received: by 10.28.232.148 with SMTP id f20mr787488wmi.147.1515110364219; Thu, 04 Jan 2018 15:59:24 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Thu, 4 Jan 2018 15:59:23 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Fri, 5 Jan 2018 00:59:23 +0100 X-Google-Sender-Auth: PGues8NnjwmILipBvOv1dvuuoV4 Message-ID: To: Victor Kuarsingh Cc: Alvaro Retana , "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="001a1147c49e0e0d430561fc1f61" Archived-At: Subject: Re: [Dcrouting] [Lsvr] [Rift] kicking off the charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:59:28 -0000 --001a1147c49e0e0d430561fc1f61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Victor, =E2=80=8BWriting new draft is easy ... getting via IETF journey =E2=80=8Bwi= th it is a bit harder, but doable. And all of this is free of real cost. However to have multiple vendors putting development resources into multiple proposals, having army of ops folks to learn it, test it across vendors and to be able to deploy it is a huge industry cost. Sure we should and will continue to innovate - this is beyond any doubt. But the crux is to choose areas where we spend community time on. Rightly structured BOF should start with discussing the problems .. what is technically wrong with existing solutions ? - Is it redundant flooding in case of link state ? - Is it lack of auto-config in case of BGP ? Both have protocol solutions in the pipe. See when you allow multiple proposals to progress, each will be supported by given vendor. So likely you will get N solutions moving to IESG. Then what ? We will then have multiple new protocols for inter-domain routing ? And not so long ago folks complained that having two OSPF and ISIS is a bad thing ..... Best, R. On Fri, Jan 5, 2018 at 12:43 AM, Victor Kuarsingh wrote= : > Robert, > > On Thu, Jan 4, 2018 at 6:13 PM, Robert Raszuk wrote: > > Hi Alvaro, > > > > > > As far as outcome of the BOF - I am not sure how the conclusion was > derived > > that we need new protocols - especially only those presented. In real > > practical cases a lot of DC clusters are build with at most few hundred= s > of > > L3 nodes which in all flavors of current link state implementations wil= l > > work just fine as is. > > We attempted to structure the BoF to help understand a few things. This > included audience input on whether there are new/augmented requirements > within the DC and if there was agreement if that may drive us to new > protocol work. Based on questions to the audience and feedback (show of = of > hands), it indicated that there was room for new protocol work > (Notes/Minutes here - https://datatracker.ietf.org/ > doc/minutes-100-dcrouting/) > > As for BGPSPF (LSVR based solution) and RIFT, audience feedback also > supported the notion that there are folks willing to work on such protoco= ls. > > > > > For MSDCs use of either eBGP or Open/R is deployed. > > This may be generally true, and based largely on availability of options > and protocols. If new options were available, it's hard to say this woul= d > still be the case. > > > > > Now dynamic flooding can extend link state to scale much larger. > > > > Personally IMHO this case is solved. Maybe time to move on to other > areas ? > > :) > > I am not sure anything is ever finally solved. Continue refinement of > designs and deployments are a norm in our industry as things change. We > often make due with what we have and drive changes if possible and/or whe= n > needed. I would not want this to limit innovation. Recent example of a > place where a new protocol is useful would be Babel. Once can argue that > we should have solved similar cases with existing protocols, but that did > not mean targeting the new uses cases with a new protocol did not make > sense. > > Requirements continue to change, and we know things today we did not know > years ago when we originally built OSPF, IS-IS, BGP etc. I think using > empirical knowledge from real deployments to focus new work makes a lot o= f > sense to me. There is likely room to continue iteration of existing > protocols, and that may be just fine for many use cases. However, that > should not limit us from developing new protocols which can solve new and > emerging problems. > > regards, > > Victor K > > > > > Best, > > R. > > > > > > > > On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana > > wrote: > >> > >> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) > wrote: > >> > >> Robert: > >> > >> Hi! Happy New Year! > >> > >> Do we really need yet one more new routing protocol vs relatively mino= r > >> extension of existing link state protocols ? > >> > >> > >> That was pretty much the question asked during the dcrouting BOF in > >> Singapore. Starting from the assumption that one size doesn=E2=80=99t= fit all, > the > >> room showed interest in working on solutions beyond the current work i= n > >> isis/ospf (which was also quickly reviewed there). > >> > >> To be clear, the intent of chartering rift doesn=E2=80=99t mean that w= ork in > other > >> WGs (including new proposals) should stop. Quite the contrary, if > there is > >> sustained interest in this effort, then we will go on with it =E2=80= =94 if there > >> isn=E2=80=99t (for whatever reason), then it will be clear as well. N= ote that I > >> asked the proponents to constrain the proposed charter to work items > that > >> should be able to be delivered within a short timeframe (around a year= ) > =E2=80=94 so > >> that we can reassess the interest, and re-charter if appropriate. > >> > >> The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I= =E2=80=99m > >> cc=E2=80=99ing that list here to avoid repeating the discussion there.= Also, I > >> noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2= =80=99ing that > list as > >> well. > >> > >> Thanks! > >> > >> Alvaro. > > > > > > > > _______________________________________________ > > Lsvr mailing list > > Lsvr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsvr > > > --001a1147c49e0e0d430561fc1f61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Victor,

=E2=80=8BWr= iting new draft is easy ... getting via IETF journey =E2=80=8Bwith it is a = bit harder, but doable. And all of this is free of real cost.=C2=A0

However to have multiple vend= ors putting development resources into multiple proposals, having army of o= ps folks to learn it, test it across vendors and to be able to deploy it is= a huge industry cost.=C2=A0

Sure we should and will continue to innovate - this is beyond any = doubt. But the crux is to choose areas where we spend community time on.=C2= =A0

Rightly structured= BOF should start with discussing the problems .. what is technically wrong= with existing solutions ?=C2=A0

- Is it redundant flooding in case of link state ?=C2=A0

- Is it lack of auto-config i= n case of BGP ?=C2=A0

= Both have protocol solutions in the pipe.=C2=A0

See when you allow multiple proposals to prog= ress, each will be supported by given vendor. So likely you will get N solu= tions moving to IESG. Then what ? We will then have multiple new protocols = for inter-domain routing ?=C2=A0

And not so long ago folks complained that having two OSPF and IS= IS is a bad thing .....=C2=A0

Best,
R.

<= /div>











On Fri, Jan 5, 2018 at = 12:43 AM, Victor Kuarsingh <victor@jvknet.com> wrote:
Robert,

On Thu, Jan 4, = 2018 at 6:13 PM, Robert Raszuk <robert@raszuk.net> wrote:
> Hi Alvaro,
>
>
> As far as outcome of the BOF - I am not su= re how the conclusion was derived
> that we need new protocols - espe= cially only those presented. In real
> practical cases a lot of DC cl= usters are build with at most few hundreds of
> L3 nodes which in all= flavors of current link state implementations will
> work just fine = as is.

We attempted to structure the BoF to help understand = a few things.=C2=A0 This included audience input on whether there are new/a= ugmented requirements within the DC and if there was agreement if that may = drive us to new protocol work.=C2=A0 Based on questions to the audience and= feedback (show of of hands), it indicated that there was room for new prot= ocol work (Notes/Minutes here - https://datatracker.ietf.org/doc/minutes-100-dcrouting/)=C2=A0

As for= BGPSPF (LSVR based solution) and RIFT, audience feedback also supported th= e notion that there are folks willing to work on such protocols.

>
> For MSDCs use of either eBGP or Open/R is deploy= ed.

This may be generally true, and based l= argely on availability of options and protocols.=C2=A0 If new options were = available, it's hard to say this would still be the case.

>
> Now dynamic flooding can extend link state t= o scale much larger.
>
> Personally IMHO this case is solved. M= aybe time to move on to other areas ?
> :)

I am not sure anything is ever finally solved. Continue refinement of= designs and deployments are a norm in our industry as things change.=C2=A0= We often make due with what we have and drive changes if possible and/or w= hen needed. I would not want this to limit innovation.=C2=A0 Recent example= of a place where a new protocol is useful would be Babel.=C2=A0 Once can a= rgue that we should have solved similar cases with existing protocols, but = that did not mean targeting the new uses cases with a new protocol did not = make sense.=C2=A0

Requirements continue to change,= and we know things today we did not know years ago when we originally buil= t OSPF, IS-IS, BGP etc.=C2=A0 I think using empirical knowledge from real d= eployments to focus new work makes a lot of sense to me.=C2=A0 There is lik= ely room to continue iteration of existing protocols, and that may be just = fine for many use cases.=C2=A0 However, that should not limit us from devel= oping new protocols which can solve new and emerging problems.=C2=A0
<= div>
regards,

Victor K

>
> Best,
> R.
>
>
&g= t;
> On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <aretana.ietf@gmail.com&g= t;
> wrote:
>>
>> On January 5, 2018 at 5:48:23 AM,= Robert Raszuk (robe= rt@raszuk.net) wrote:
>>
>> Robert:
>>
&g= t;> Hi!=C2=A0 Happy New Year!
>>
>> Do we really need = yet one more new routing protocol vs relatively minor
>> extension= of existing link state protocols ?
>>
>>
>> Tha= t was pretty much the question asked during the dcrouting BOF in
>>= ; Singapore.=C2=A0 Starting from the assumption that one size doesn=E2=80= =99t fit all, the
>> room showed interest in working on solutions = beyond the current work in
>> isis/ospf (which was also quickly re= viewed there).
>>
>> To be clear, the intent of charterin= g rift doesn=E2=80=99t mean that work in other
>> WGs (including n= ew proposals) should stop.=C2=A0 Quite the contrary, if there is
>>= ; sustained interest in this effort, then we will go on with it =E2=80=94 i= f there
>> isn=E2=80=99t (for whatever reason), then it will be cl= ear as well.=C2=A0 Note that I
>> asked the proponents to constrai= n the proposed charter to work items that
>> should be able to be = delivered within a short timeframe (around a year) =E2=80=94 so
>>= that we can reassess the interest, and re-charter if appropriate.
>&= gt;
>> The above obviously applies to the lsvr (aka BGP-SPF) propo= sal, so I=E2=80=99m
>> cc=E2=80=99ing that list here to avoid repe= ating the discussion there.=C2=A0 Also, I
>> noticed you forwarded= your message to dcrouting, so I=E2=80=99m cc=E2=80=99ing that list as
&= gt;> well.
>>
>> Thanks!
>>
>> Alvar= o.
>
>
>
> ____________________________= ___________________
> Lsvr mailing list
> Lsvr@ietf.org
> https://www.ietf= .org/mailman/listinfo/lsvr
>

--001a1147c49e0e0d430561fc1f61-- From nobody Fri Jan 5 09:39:34 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2926A12708C; Fri, 5 Jan 2018 09:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 7yKif4XRnOsu; Fri, 5 Jan 2018 09:39:27 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F76126BFD; Fri, 5 Jan 2018 09:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1988; q=dns/txt; s=iport; t=1515173967; x=1516383567; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gmuzNwp84igLTQhU/+ITevnFKeR6255ZkV/RqtLimnY=; b=A8R5J5lOAJVlibR2N1e3VKtlF6Z63g5NMUaqEVjpEnrBeQZ4+Z6W7laE u9pqStQp8+/mtnY+rMvWVdsT57abcsYCDMa2DLoAb1PQinCy5TE84rJJL 8tvVz/a6q0Le/RezgDqBUaKgSO07K1KSLM3w1CsZeuNZGKM8J09djrzFU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAwCIt09a/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4QAmQ6CApk/ChgLhElPAhqEF0MUAQEBAQEBAQEBayi?= =?us-ascii?q?FJAEBAQMBASEROgsQAgEIGAICJgICAiULFRACBAENBYovELAugieKPwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgQ+DBYIVgz+DLoMvAYFugxeCZQWjXAKVOpQGlmY?= =?us-ascii?q?CERkBgTsBNiKBUG8VPYIqhFd4iESBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,319,1511827200"; d="scan'208";a="52791289" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2018 17:39:26 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w05HdPr6018341 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Jan 2018 17:39:25 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 5 Jan 2018 12:39:24 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Fri, 5 Jan 2018 12:39:24 -0500 From: "Acee Lindem (acee)" To: "Joel M. Halpern" , Randy Bush , "Keyur Patel" CC: Xuxiaohu , "dcrouting@ietf.org" , "lsvr@ietf.org" , Alvaro Retana Thread-Topic: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf Thread-Index: AQHThKSXqqGIEB8ETEyTAt2rCKVfFqNljuKA Date: Fri, 5 Jan 2018 17:39:24 +0000 Message-ID: References: <0DB89F21-8E32-46A7-A2B7-B79977948455@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="utf-8" Content-ID: <04B134D51A26024F95A5B9A7412D6018@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 17:39:29 -0000 SGkgSm9lbCwgDQoNClllcyAtIHRoaXMgaXMgb25lIG9mIHRoZSBhcmVhcyBvZiBjb21wbGV4aXR5 IHdoZW4gaW1wbGVtZW50aW5nIEJHUCBTUEYuIEl0DQppcyB0aGUgcmVhc29uIHdoeSB3ZSBhbGxv Y2F0ZSBhIHNlcGFyYXRlIFNBRkkgZnJvbSBub3JtYWwgQkdQLUxTIHN0YXRlDQpkaXN0cmlidXRp b24uIA0KDQpUaGFua3MsDQpBY2VlIA0KDQpPbiAxLzMvMTgsIDEwOjA3IEFNLCAiRGNyb3V0aW5n IG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4iDQo8ZGNyb3V0aW5nLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KDQo+SXQgc2VlbXMg dG8gbWUgdGhhdCBoYXZpbmcgdHdvIGRpZmZlcmVudCBCR1AgZGVjaXNpb24gcHJvY2Vzc2VzDQo+ YXZhaWxhYmxlIGlzIGdvaW5nIHRvIGhhdmUgc2lnbmlmaWNhbnQgaW1wYWN0IG9uIGFjaGlldmlu ZyBjb25zaXN0ZW5jeQ0KPnNvIHRhaHQgcm91dGluZyBhY3R1YWxseSBjb252ZXJnZXMuIEkgc3Vz cGVjdCBpdCB3aWxsbm90IHRha2UgbXVjaCB0bw0KPmRlZmluZSB3aGF0IGNob2ljZXMgYXJlIHN0 YWJsZSBhbmQgZWZmZWN0aXZlLg0KPg0KPkxlYXZpbmcgb3V0IGFueSBjb21tZW50cyBvbiBob3cg dG8gbWFrZSB0aGlzIChjb2V4aXN0ZW5jZSkgd29yayBzZWVtcyBhDQo+bWlzdGFrZS4NCj4NCj5Z b3VycywNCj5Kb2VsDQo+DQo+T24gMS8zLzE4IDc6NDAgQU0sIEFjZWUgTGluZGVtIChhY2VlKSB3 cm90ZToNCj4+IEFncmVlZC4gVGhhbmtzIFJhbmR5IQ0KPj4gDQo+PiBQbGFuIHRvIHJlZnJlc2gg dGhlIGRyYWZ0IHRoaXMgd2Vlay4NCj4+IA0KPj4gQWNlZQ0KPj4gDQo+PiBPbiAxLzIvMTgsIDEw OjIxIFBNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBzZy5jb20+IHdyb3RlOg0KPj4gDQo+Pj4+IEZ1 cnRoZXJtb3JlLCB3ZSBjb3VsZCBjaG9zZSB0byBjb25zaWRlciBzdWNoIGFuIGludGVyYWN0aW9u IGFzIGENCj4+Pj4gbWF0dGVyIG9mIGxvY2FsIHBvbGljeSAoaW1wbGVtZW50YXRpb24gc3BlY2lm aWMpLg0KPj4+DQo+Pj4gcGVkYW50cnk6IHMvaW1wbGVtZW50YXRpb24vY29uZmlndXJhdGlvbi8u ICBpLmUuIG9wIGNob29zZXMsIG5vdA0KPj4+dmVuZG9yLg0KPj4+DQo+Pj4gcmFuZHkNCj4+IA0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IERj cm91dGluZyBtYWlsaW5nIGxpc3QNCj4+IERjcm91dGluZ0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kY3JvdXRpbmcNCj4+IA0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+RGNyb3V0aW5nIG1haWxp bmcgbGlzdA0KPkRjcm91dGluZ0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGNyb3V0aW5nDQoNCg== From nobody Fri Jan 5 12:09:36 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33A612D87A; Fri, 5 Jan 2018 12:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 D5yQd8fApCDj; Fri, 5 Jan 2018 12:09:33 -0800 (PST) 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 60DE012D876; Fri, 5 Jan 2018 12:09:33 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w05K85MG005931; Fri, 5 Jan 2018 12:09:24 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=hh4gYR6pMWhADadZiuIYGAFue3blol9GMIpAVdJP3vY=; b=DdNPYkLB5MAg2a3YvEt81l1AErYnRvaDjFuRmXNLCVQLjxrGfkUuZYJQ0lUGizP8aRR2 UacRRj3wra/1nbrlBpbbsThghSOU9+REIFrRFRgXBlbECs5PManKwGlhmKVL7gihWia6 wUR9f2N2YKDA85Mk5dUdt67xBUz0PlslPsnJO8xiww9LLkxBIYu74XiE+IlJAJHhW7e/ 9yhnhPSq3iFnYP6miZHHs9GoweceTT12E0BR75/KOgmCaGW4L1tjNlzCHTOxC+jjlOH6 nIKnC8E3han49OnbUe1S708me9q5qog1T6bV9sJGvezX390CUwuFyFdLaHcpBiVAXZBf sQ== Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0179.outbound.protection.outlook.com [216.32.180.179]) by mx0a-00273201.pphosted.com with ESMTP id 2fag4pg04m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Jan 2018 12:09:24 -0800 Received: from CY1PR0501MB1340.namprd05.prod.outlook.com (10.160.226.145) by CY1PR0501MB1386.namprd05.prod.outlook.com (10.160.148.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.4; Fri, 5 Jan 2018 20:09:21 +0000 Received: from CY1PR0501MB1340.namprd05.prod.outlook.com ([10.160.226.145]) by CY1PR0501MB1340.namprd05.prod.outlook.com ([10.160.226.145]) with mapi id 15.20.0386.005; Fri, 5 Jan 2018 20:09:20 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Acee Lindem (acee)" , "Joel M. Halpern" , EXT - randy , Keyur Patel CC: Xuxiaohu , "dcrouting@ietf.org" , "lsvr@ietf.org" , Alvaro Retana Thread-Topic: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf Thread-Index: AQHThl/S6ak8LQOE3kSxJEshAf0r/6NltHqQ Date: Fri, 5 Jan 2018 20:09:20 +0000 Message-ID: References: <0DB89F21-8E32-46A7-A2B7-B79977948455@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1386; 7:b76Qey4gzX3aF84B8wt6qgllAgc4p5hVf+8OD6X2hRSDn65SsjHhPBBPoOHuSv9/lmLkbWPBSt3jlZDqZbTQnNH05slbEed0WLW9gKvCkwCANNMmjiLiYF74w6ftPw7p1N3RRY2uLwNQFvCOl8wj5VuDQ0UXnq3OrVT9nvfQe82vSMsb8nupi/uzJPfYRzT6yW5A93OkGtqek9W2khX5YqetKRLTaBCNjYdCa/06Zo8q7jH2ZJlGExUCt1vFYisk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 35f9e0e0-2352-41a5-5b25-08d55478352d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:CY1PR0501MB1386; x-ms-traffictypediagnostic: CY1PR0501MB1386: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(50582790962513)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:CY1PR0501MB1386; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR0501MB1386; x-forefront-prvs: 05437568AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(366004)(39860400002)(346002)(376002)(189003)(199004)(24454002)(13464003)(106356001)(6436002)(105586002)(316002)(97736004)(33656002)(110136005)(39060400002)(230783001)(25786009)(229853002)(55016002)(6116002)(2906002)(93886005)(77096006)(9686003)(8676002)(86362001)(66066001)(5660300001)(4326008)(7696005)(6506007)(305945005)(6306002)(575784001)(54906003)(53546011)(2950100002)(7736002)(76176011)(81156014)(53936002)(74316002)(99286004)(6246003)(2900100001)(3280700002)(966005)(3846002)(3660700001)(8936002)(81166006)(14454004)(478600001)(102836004)(68736007)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1386; H:CY1PR0501MB1340.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: nu4m5aPD1zMFEODxT8nh7fVVrNkemB+QFIf/KnCiPdM5EFEsJUI+JdJgG9b/VrZlc6lQpRneyjwd4FfwqjJUSw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 35f9e0e0-2352-41a5-5b25-08d55478352d X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2018 20:09:20.7156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1386 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801050278 Archived-At: Subject: Re: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 20:09:35 -0000 VG9kYXkgdGhlcmUgYXJlIHdlbGwgZGVmaW5lZCAocGVyaGFwcyB2ZW5kb3Itc3BlY2lmaWMpIHBy b2NlZHVyZXMgdG8gY2hvb3NlIGlmIGFuIE9TUEYgcm91dGUgb3IgYSBCR1Agcm91dGUgaXMgdXNl ZCBmb3IgYSBwYXJ0aWN1bGFyIHByZWZpeC4gSSBhc3N1bWUgaWYgd2UgdHJlYXQgQkdQLVNQRiBh cyBhIGFub3RoZXIgcHJvdG9jb2wsIHRoZW4gdGhlIHByb2JsZW1zIGlzIHNvbHZlZCBhbHJlYWR5 Pw0KDQpKZWZmcmV5DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWNl ZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86YWNlZUBjaXNjby5jb21dDQo+IFNlbnQ6IEZyaWRheSwg SmFudWFyeSA1LCAyMDE4IDEyOjM5IFBNDQo+IFRvOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2Vs aGFscGVybi5jb20+OyBFWFQgLSByYW5keSA8cmFuZHlAcHNnLmNvbT47DQo+IEtleXVyIFBhdGVs IDxrZXl1ckBhcnJjdXMuY29tPg0KPiBDYzogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+ OyBkY3JvdXRpbmdAaWV0Zi5vcmc7IGxzdnJAaWV0Zi5vcmc7DQo+IEFsdmFybyBSZXRhbmEgPGFy ZXRhbmEuaWV0ZkBnbWFpbC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbRGNyb3V0aW5nXSBbTHN2cl0g QSBjb21tZW50IG9uIGRyYWZ0LWtleXVwYXRlLWlkci1iZ3Atc3BmDQo+IA0KPiBIaSBKb2VsLA0K PiANCj4gDQo+IA0KPiBZZXMgLSB0aGlzIGlzIG9uZSBvZiB0aGUgYXJlYXMgb2YgY29tcGxleGl0 eSB3aGVuIGltcGxlbWVudGluZyBCR1AgU1BGLiBJdA0KPiANCj4gaXMgdGhlIHJlYXNvbiB3aHkg d2UgYWxsb2NhdGUgYSBzZXBhcmF0ZSBTQUZJIGZyb20gbm9ybWFsIEJHUC1MUyBzdGF0ZQ0KPiAN Cj4gZGlzdHJpYnV0aW9uLg0KPiANCj4gDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBBY2VlDQo+IA0K PiANCj4gDQo+IE9uIDEvMy8xOCwgMTA6MDcgQU0sICJEY3JvdXRpbmcgb24gYmVoYWxmIG9mIEpv ZWwgTS4gSGFscGVybiINCj4gDQo+IDxkY3JvdXRpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2Ygam1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gDQo+ID5JdCBzZWVt cyB0byBtZSB0aGF0IGhhdmluZyB0d28gZGlmZmVyZW50IEJHUCBkZWNpc2lvbiBwcm9jZXNzZXMN Cj4gDQo+ID5hdmFpbGFibGUgaXMgZ29pbmcgdG8gaGF2ZSBzaWduaWZpY2FudCBpbXBhY3Qgb24g YWNoaWV2aW5nIGNvbnNpc3RlbmN5DQo+IA0KPiA+c28gdGFodCByb3V0aW5nIGFjdHVhbGx5IGNv bnZlcmdlcy4gSSBzdXNwZWN0IGl0IHdpbGxub3QgdGFrZSBtdWNoIHRvDQo+IA0KPiA+ZGVmaW5l IHdoYXQgY2hvaWNlcyBhcmUgc3RhYmxlIGFuZCBlZmZlY3RpdmUuDQo+IA0KPiA+DQo+IA0KPiA+ TGVhdmluZyBvdXQgYW55IGNvbW1lbnRzIG9uIGhvdyB0byBtYWtlIHRoaXMgKGNvZXhpc3RlbmNl KSB3b3JrIHNlZW1zIGENCj4gDQo+ID5taXN0YWtlLg0KPiANCj4gPg0KPiANCj4gPllvdXJzLA0K PiANCj4gPkpvZWwNCj4gDQo+ID4NCj4gDQo+ID5PbiAxLzMvMTggNzo0MCBBTSwgQWNlZSBMaW5k ZW0gKGFjZWUpIHdyb3RlOg0KPiANCj4gPj4gQWdyZWVkLiBUaGFua3MgUmFuZHkhDQo+IA0KPiA+ Pg0KPiANCj4gPj4gUGxhbiB0byByZWZyZXNoIHRoZSBkcmFmdCB0aGlzIHdlZWsuDQo+IA0KPiA+ Pg0KPiANCj4gPj4gQWNlZQ0KPiANCj4gPj4NCj4gDQo+ID4+IE9uIDEvMi8xOCwgMTA6MjEgUE0s ICJSYW5keSBCdXNoIiA8cmFuZHlAcHNnLmNvbT4gd3JvdGU6DQo+IA0KPiA+Pg0KPiANCj4gPj4+ PiBGdXJ0aGVybW9yZSwgd2UgY291bGQgY2hvc2UgdG8gY29uc2lkZXIgc3VjaCBhbiBpbnRlcmFj dGlvbiBhcyBhDQo+IA0KPiA+Pj4+IG1hdHRlciBvZiBsb2NhbCBwb2xpY3kgKGltcGxlbWVudGF0 aW9uIHNwZWNpZmljKS4NCj4gDQo+ID4+Pg0KPiANCj4gPj4+IHBlZGFudHJ5OiBzL2ltcGxlbWVu dGF0aW9uL2NvbmZpZ3VyYXRpb24vLiAgaS5lLiBvcCBjaG9vc2VzLCBub3QNCj4gDQo+ID4+PnZl bmRvci4NCj4gDQo+ID4+Pg0KPiANCj4gPj4+IHJhbmR5DQo+IA0KPiA+Pg0KPiANCj4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+ID4+IERj cm91dGluZyBtYWlsaW5nIGxpc3QNCj4gDQo+ID4+IERjcm91dGluZ0BpZXRmLm9yZw0KPiANCj4g Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAz QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fZGNyb3V0aW5nJmQ9RHdJR2FRJmM9SEFr WXVoNjNyc3VoDQo+IHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRYY1d6b0NJJnI9Zjd3c0xH Y2Z6QVdETlM2WE5UQlp3al9PTEFPc1pacWRyUjJJREF6ZVpxRSYNCj4gbT1NY0lCbGNMaU5SMV92 OVhwN2o3OHF5MTI3aUg3UjJsaWdwSVJxWTkwT0lVJnM9XzE3eEpZbkpCV0ZfUnprNHNjWg0KPiAy cF8zSnNKaVk1bWtuSC1vWE9zRFZmbjQmZT0NCj4gDQo+ID4+DQo+IA0KPiA+DQo+IA0KPiA+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+ID5EY3Jv dXRpbmcgbWFpbGluZyBsaXN0DQo+IA0KPiA+RGNyb3V0aW5nQGlldGYub3JnDQo+IA0KPiA+aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fZGNyb3V0aW5nJmQ9RHdJR2FRJmM9SEFrWXVoNjNy c3VoDQo+IHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRYY1d6b0NJJnI9Zjd3c0xHY2Z6QVdE TlM2WE5UQlp3al9PTEFPc1pacWRyUjJJREF6ZVpxRSYNCj4gbT1NY0lCbGNMaU5SMV92OVhwN2o3 OHF5MTI3aUg3UjJsaWdwSVJxWTkwT0lVJnM9XzE3eEpZbkpCV0ZfUnprNHNjWg0KPiAycF8zSnNK aVk1bWtuSC1vWE9zRFZmbjQmZT0NCj4gDQo+IA0KDQo= From nobody Fri Jan 5 14:12:27 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E87112D88D; Fri, 5 Jan 2018 14:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 jU2YlULg9Asi; Fri, 5 Jan 2018 14:12:19 -0800 (PST) Received: from bifrost.xalto.net (bifrost.xalto.net [IPv6:2001:41d0:52:100::ce9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2801200B9; Fri, 5 Jan 2018 14:12:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bifrost.xalto.net (Postfix) with ESMTP id A5767CE641C; Fri, 5 Jan 2018 23:12:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at xalto.net Received: from bifrost.xalto.net ([127.0.0.1]) by localhost (bifrost.xalto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFkR7h6zGW8S; Fri, 5 Jan 2018 23:12:15 +0100 (CET) Received: from webmail.xalto.net (localhost [IPv6:::1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bifrost.xalto.net (Postfix) with ESMTPSA id CA084CE641A; Fri, 5 Jan 2018 23:12:15 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 05 Jan 2018 23:12:15 +0100 From: Michael Hallgren To: "Jeffrey (Zhaohui) Zhang" Cc: "Acee Lindem (acee)" , "Joel M. Halpern" , EXT - randy , Keyur Patel , Xuxiaohu , dcrouting@ietf.org, lsvr@ietf.org, Alvaro Retana Organization: Xalto.net SARL In-Reply-To: References: <0DB89F21-8E32-46A7-A2B7-B79977948455@arrcus.com> Message-ID: <6f89c9a88b078d37e71b7ec14c633230@webmail.xalto.net> X-Sender: mh@xalto.net User-Agent: Roundcube Webmail/1.0.5 Archived-At: Subject: Re: [Dcrouting] [Lsvr] A comment on draft-keyupate-idr-bgp-spf X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 22:12:22 -0000 Hi guys, Yes, normally. Now, I guess the question that we have on our table is: what fundamental problem has been identified to trigger the proposed solution? No? Cheers, mh Le 2018-01-05 21:09, Jeffrey (Zhaohui) Zhang a écrit : > Today there are well defined (perhaps vendor-specific) procedures to > choose if an OSPF route or a BGP route is used for a particular > prefix. I assume if we treat BGP-SPF as a another protocol, then the > problems is solved already? > > Jeffrey > >> -----Original Message----- >> From: Acee Lindem (acee) [mailto:acee@cisco.com] >> Sent: Friday, January 5, 2018 12:39 PM >> To: Joel M. Halpern ; EXT - randy >> ; >> Keyur Patel >> Cc: Xuxiaohu ; dcrouting@ietf.org; lsvr@ietf.org; >> Alvaro Retana >> Subject: Re: [Dcrouting] [Lsvr] A comment on >> draft-keyupate-idr-bgp-spf >> >> Hi Joel, >> >> >> >> Yes - this is one of the areas of complexity when implementing BGP >> SPF. It >> >> is the reason why we allocate a separate SAFI from normal BGP-LS state >> >> distribution. >> >> >> >> Thanks, >> >> Acee >> >> >> >> On 1/3/18, 10:07 AM, "Dcrouting on behalf of Joel M. Halpern" >> >> wrote: >> >> >> >> >It seems to me that having two different BGP decision processes >> >> >available is going to have significant impact on achieving consistency >> >> >so taht routing actually converges. I suspect it willnot take much to >> >> >define what choices are stable and effective. >> >> > >> >> >Leaving out any comments on how to make this (coexistence) work seems a >> >> >mistake. >> >> > >> >> >Yours, >> >> >Joel >> >> > >> >> >On 1/3/18 7:40 AM, Acee Lindem (acee) wrote: >> >> >> Agreed. Thanks Randy! >> >> >> >> >> >> Plan to refresh the draft this week. >> >> >> >> >> >> Acee >> >> >> >> >> >> On 1/2/18, 10:21 PM, "Randy Bush" wrote: >> >> >> >> >> >>>> Furthermore, we could chose to consider such an interaction as a >> >> >>>> matter of local policy (implementation specific). >> >> >>> >> >> >>> pedantry: s/implementation/configuration/. i.e. op chooses, not >> >> >>>vendor. >> >> >>> >> >> >>> randy >> >> >> >> >> >> _______________________________________________ >> >> >> Dcrouting mailing list >> >> >> Dcrouting@ietf.org >> >> >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_dcrouting&d=DwIGaQ&c=HAkYuh63rsuh >> r6Scbfh0UjBXeMK- >> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE& >> m=McIBlcLiNR1_v9Xp7j78qy127iH7R2ligpIRqY90OIU&s=_17xJYnJBWF_Rzk4scZ >> 2p_3JsJiY5mknH-oXOsDVfn4&e= >> >> >> >> >> > >> >> >_______________________________________________ >> >> >Dcrouting mailing list >> >> >Dcrouting@ietf.org >> >> >https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_dcrouting&d=DwIGaQ&c=HAkYuh63rsuh >> r6Scbfh0UjBXeMK- >> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE& >> m=McIBlcLiNR1_v9Xp7j78qy127iH7R2ligpIRqY90OIU&s=_17xJYnJBWF_Rzk4scZ >> 2p_3JsJiY5mknH-oXOsDVfn4&e= >> >> > > _______________________________________________ > Dcrouting mailing list > Dcrouting@ietf.org > https://www.ietf.org/mailman/listinfo/dcrouting From nobody Sat Jan 6 13:35:55 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D7312D574; Sat, 6 Jan 2018 13:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 NpG5EHTVq9xd; Sat, 6 Jan 2018 13:35:51 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 4C8231201F2; Sat, 6 Jan 2018 13:35:51 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id m8so2421507lfc.6; Sat, 06 Jan 2018 13:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2NxtdpZBcGT6Xn6YYVE8gdQC13GgBaWJzEDAgsCmciw=; b=Ud/aErFP4S+z50hfFe6olc3SktwoeKc4pvoMfRlISaV45JtWfBlOaqPvO7/loLPWsJ jTrh6vZgxXa5SvA+2hPlj2kogtxuw9xhuxus3368eNHw6792rRC4Kl/rOM4C27tkmegT YPTKSgk9azaVcqZ5qcjeHIhuz5ALnyGPMjBFd8eFwHnQXxfw+5bjQ3VOqugKKDne7reT k9s2JTCvzcwfuszzw1VSJGl0OuVYwnpkJBrJ5YPZY4767nL9rITmESmD1dwTTWjpFWNh Wra0LqfQPzms5A5dTimekQmiF8Zv6XIlIqy5i+jmbgU4VFksEZfpiN0uo8jQeSG1CmfD SOxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2NxtdpZBcGT6Xn6YYVE8gdQC13GgBaWJzEDAgsCmciw=; b=JJPyUFW/kRcvfR49lGUAAvnoSkuTK1TwqhZOa2wRFYd0BOEICshVtMqq7+1nGsxt2P 9j/dbRAeZW7mfMb0usfEdTcYTBmKMBLwyrZbsI+zgogWZaCeSWnVrTk9P4aJut+/iQzz fM6+x20AFw2FeNOWoHTt4BsI42zx6pUJu2LHaF/eM3GFjPOXwTvf78YEpsZraSnppioo Js+NpzgNjtUn4iKKeAxZ6jg4xcsHLuHtnQmZpRjTtCD2NjCjyadY+GhgQo2pGYD3DIyS w31SdADXvdsn+Fhtpm3pnfBJdNbmIndAscglYr0F6TLFyVt0lrKXHZl3Iw1QBlvuThPC qOJw== X-Gm-Message-State: AKGB3mLvnQtdeP04SG+Y+L/6ZRT+lq1lVXkvh2iaMn/k2FtezrrdlBPg V4ndfyePC3F+d+chk4O+/3Y/SKobTFo4Z0vTTHU= X-Google-Smtp-Source: ACJfBovIU3xIVB4KiXKEJaj737KQwY6gTLG+66iDY64GiKOMjm1DXEfHM/9pjbD9AmAzmKx7OFxQLCbzXfokFKGGKJY= X-Received: by 10.46.87.12 with SMTP id l12mr3794356ljb.16.1515274549202; Sat, 06 Jan 2018 13:35:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.32.136 with HTTP; Sat, 6 Jan 2018 13:35:48 -0800 (PST) In-Reply-To: References: From: Greg Mirsky Date: Sat, 6 Jan 2018 13:35:48 -0800 Message-ID: To: Robert Raszuk , Petr Lapukhov Cc: Alvaro Retana , "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="f403045f8c563e153005622259d6" Archived-At: Subject: Re: [Dcrouting] [Rift] kicking off the charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 21:35:54 -0000 --f403045f8c563e153005622259d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Robert, I recall presentation by Petr Lapukhov on Open/R and Terragraph where the principle of optimized flooding was used. Of course, algorithms and mechanics of the Open/R in Terragraph may be different from those proposed in the draft An Architecture for Dynamic Flooding on Dense Graphs. I believe it will be very interesting and helpful to look at the proposed dynamic flooding from the point of experience of the Open/R and Terragraph. Regards, Greg On Thu, Jan 4, 2018 at 3:13 PM, Robert Raszuk wrote: > Hi Alvaro, > > Happy New Year !!! > > > That was pretty much the question asked during the dcrouting BOF in > Singapore. > > Well .. in Singapore and during most of list discussions dynamic flooding > proposal was not on the table. Now it is. > > To me this is game changer and any conclusions reached previously IMHO > should now be revisited. > > As far as outcome of the BOF - I am not sure how the conclusion was > derived that we need new protocols - especially only those presented. In > real practical cases a lot of DC clusters are build with at most few > hundreds of L3 nodes which in all flavors of current link state > implementations will work just fine as is. > > For MSDCs use of either eBGP or Open/R is deployed. > > Now dynamic flooding can extend link state to scale much larger. > > Personally IMHO this case is solved. Maybe time to move on to other areas > ? :) > > Best, > R. > > > > On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana > wrote: > >> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) >> wrote: >> >> Robert: >> >> Hi! Happy New Year! >> >> Do we really need yet one more new routing protocol vs relatively minor >> extension of existing link state protocols ? >> >> >> That was pretty much the question asked during the dcrouting BOF in >> Singapore. Starting from the assumption that one size doesn=E2=80=99t f= it all, the >> room showed interest in working on solutions beyond the current work in >> isis/ospf (which was also quickly reviewed there). >> >> To be clear, the intent of chartering rift doesn=E2=80=99t mean that wor= k in >> other WGs (including new proposals) should stop. Quite the contrary, if >> there is sustained interest in this effort, then we will go on with it = =E2=80=94 if >> there isn=E2=80=99t (for whatever reason), then it will be clear as well= . Note >> that I asked the proponents to constrain the proposed charter to work it= ems >> that should be able to be delivered within a short timeframe (around a >> year) =E2=80=94 so that we can reassess the interest, and re-charter if = appropriate. >> >> The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m >> cc=E2=80=99ing that list here to avoid repeating the discussion there. = Also, I >> noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as >> well. >> >> Thanks! >> >> Alvaro. >> > > > _______________________________________________ > Dcrouting mailing list > Dcrouting@ietf.org > https://www.ietf.org/mailman/listinfo/dcrouting > > --f403045f8c563e153005622259d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert,
I recall presentation by Petr Lapukhov on O= pen/R and Terragraph where the principle of optimized flooding was used. Of= course, algorithms and mechanics of the Open/R in Terragraph may be differ= ent from those proposed in the= =C2=A0draft An Architecture for Dynamic Flooding on Dense Graphs. I believe= it will be very interesting and helpful to look at the proposed dynamic fl= ooding from the point of experience of the Open/R and Terragraph.

<= font face=3D"arial, helvetica, sans-serif">Regards,
Greg

On Thu, Jan 4, 2018 at 3:13 PM,= Robert Raszuk <robert@raszuk.net> wrote:
Hi Alvaro,

Happy New Year !!!

> That was pretty much the que= stion asked during the dcrouting BOF in Singapore.=C2=A0

Well .. in Singapore and during most of l= ist discussions dynamic flooding proposal was not on the table. Now it is.= =C2=A0

To me this is game changer and any conclusions= reached previously IMHO should now be revisited.=C2=A0
<= br>
As far as outcome of the BOF - I am not sure how the conclusion was deri= ved that we need new protocols - especially only those presented. In real p= ractical cases a lot of DC clusters are build with at most few hundreds of = L3 nodes which in all flavors=C2=A0of current link state implementations wi= ll work just fine as is.=C2=A0

F= or MSDCs use of either eBGP or Open/R is deployed.

=
= Now dynamic flooding can extend link state to scale much larger.=C2=A0

<= /span>
P= ersonally=C2=A0IMHO this case is solved. Maybe time to move on to other are= as ? :)

Best,
R.



On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <aretana.= ietf@gmail.com> wrote:
On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:<= /font>

=
Rob= ert:

Hi!=C2=A0 Happy New Year!

Do we really need yet one more new routi= ng protocol vs relatively minor extension of existing link state protocols = ?=C2=A0

That was = pretty much the question asked during the dcrouting BOF in Singapore.=C2=A0= Starting from the assumption that one size doesn=E2=80=99t fit all, the ro= om showed interest in working on solutions beyond the current work in isis/= ospf (which was also quickly reviewed there).

To be clear, the = intent of chartering rift doesn=E2=80=99t mean that work in other WGs (incl= uding new proposals) should stop.=C2=A0 Quite the contrary, if there is sus= tained interest in this effort, then we will go on with it =E2=80=94 if the= re isn=E2=80=99t (for whatever reason), then it will be clear as well.=C2= =A0 Note that I asked the proponents to constrain the proposed charter to w= ork items that should be able to be delivered within a short timeframe (aro= und a year) =E2=80=94 so that we can reassess the interest, and re-charter = if appropriate.

The above obviously applies to the lsvr (aka BGP= -SPF) proposal, so I=E2=80=99m cc=E2=80=99ing that list here to avoid repea= ting the discussion there.=C2=A0 Also, I noticed you forwarded your message= to dcrouting, so I=E2=80=99m cc=E2=80=99ing that list as well.

= Thanks!

Alvaro.


_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>


--f403045f8c563e153005622259d6-- From nobody Sat Jan 6 14:29:49 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7F3129C6D; Sat, 6 Jan 2018 14:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skGzbyfPe8VH; Sat, 6 Jan 2018 14:29:26 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 83461124BE8; Sat, 6 Jan 2018 14:29:25 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id w107so7336148wrb.9; Sat, 06 Jan 2018 14:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PeqwTLrXTtDdECnVY0MWKsEX7BLM7Y9VVc4WXbhGPcE=; b=KYKmgP8usk1yIkMcPxmUgmhHSSiC0VjKjMcKrVV/A+OlkOdAm6Hl1agzFhcpVUdYpY okSFnK+raGkooQ4dZR+ZTL6bUaWINNQ7y9jEuphyjCRpviEgFUAZ1rUpEw/4lkbqvFec 3NByEQjpvlqgZxJnarGmWSjQ/waCf5uC2Gxrl1gbSQ1gjeOE/RcfMuv2MNqvGlvjqQPL fslwnH27RCT/F0lJFfemJ9TeLL1ZVLLuCR56HSHzJSMLCRXM9IObSdc5As2dMerEjyOF Zi7XAQfkisxO2oR8fNcspTEgvMGjhP85RgHBaVRk5KCw/RlLevVRJERmYPfuoIX/uS5b ayqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PeqwTLrXTtDdECnVY0MWKsEX7BLM7Y9VVc4WXbhGPcE=; b=a9HlnhMq519f+KTMJEPrKsvyiNxxuQBPQqzzjcB5GtKIZtqC252Vd4s+m1vDrQRPT+ sqtUsfGYpOj+j6fNg6r1WCbpjl0iz5vUXKcRH+idrzNlm8dfPXTiYFxZPm+JendgScE3 6uMRhL77OhGhTtw/VKuseLWolbViufOP2dle+uCV+annxrTgRyR+5uybX6yuvAkqqU1J eSoHzNQVeX/xZeBBCK8/bP4Fk2sTKmulZdJ/PsP9UzOxBgxwEAz3+tREv8GEF03ZYDPs JumPKvRaLepxI6QbNv2r38+8d3WDQqjPGssl9KHPjj6CzgciLyCCZ/NOslJf0zV2Fq0q gJVQ== X-Gm-Message-State: AKGB3mKzdiuJ1jTMke6ozKDZWKfkgCAz53PM/tx34ct6qmIV0S2nWgV2 P4p55uAxkHxCASH4opJ8NSGBDrKT1xOMIJsJoBU= X-Google-Smtp-Source: ACJfBoss27ZAQdDWX75/qZ+h15LW8g0HWo9pbsOfKHYEuqMXRSs/TD7rcSpiI/SsxfLFs4D4WtfXVAIvWR9f+Q6B1TQ= X-Received: by 10.223.151.142 with SMTP id s14mr6035506wrb.256.1515277763660; Sat, 06 Jan 2018 14:29:23 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Sat, 6 Jan 2018 14:29:22 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Sat, 6 Jan 2018 23:29:22 +0100 X-Google-Sender-Auth: -DMn0K1U4vKtKrHfa4eYDTYFM_o Message-ID: To: Greg Mirsky Cc: Petr Lapukhov , Alvaro Retana , "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1b5622d6cfd405622318a7" Archived-At: Subject: Re: [Dcrouting] [Rift] kicking off the charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 22:29:29 -0000 --94eb2c1b5622d6cfd405622318a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, > I believe it will be very interesting and helpful to look at the proposed dynamic flooding from the point of experience of the Open/R and Terragraph. Honestly I don't think so. The reason is that what Tony Li proposed is an update to classic link state flooding. In fact he is reusing existing DR/DIS in his proposal. Open/R is using message bus for control plane transport which is a completely different paradigm. I am not making any judgement here which is better or worse scale or convergence wise. But at least to me there are apples and oranges and comparing or drawing any conclusion from the behavior of one to the other seems quite bizarre. Personally I like a lot Open/R real pub-sub model. We have been using BGP to propagate p2p messages within p2mp protocol for way too long now. That nonsense has to stop. RTC has been proposed for other reasons and is not the right way to filter BGP information to stretch it as p2p database distribution protocol. It would be very interesting to see proposals for BGP intra-domain transport using message bus. But for robust topology discovery, computing SPF, local protection with no constrains on network topology I guess I will still value link state for a while :). And as already stated for 95% of DCs where cluster size is up to 100 racks I think there is no issue to use currently shipping OSPF or ISIS. When you go beyond that (if you as an enterprise ever do) there is for more optimizations. But from my personal experience building huge flat DC clusters is only applicable to very few customers. Very frankly even issuing RFC describing use of BGP for DC fabric confused number of folks with 5-10 racks and made them to insist that only BGP will work and ISIS or OSPF is a very bad idea. Others for the very same reasons use BGP only deployments in campus networks. Let's be very careful what we consider as good IETF work items and what we define here as standard tracks documents as even if not intended they do have a ricochet effect. Best, Robert. On Sat, Jan 6, 2018 at 10:35 PM, Greg Mirsky wrote: > Hi Robert, > I recall presentation by Petr Lapukhov on Open/R and Terragraph where the > principle of optimized flooding was used. Of course, algorithms and > mechanics of the Open/R in Terragraph may be different from those propose= d > in the draft An Architecture for Dynamic Flooding on Dense Graphs. I > believe it will be very interesting and helpful to look at the proposed > dynamic flooding from the point of experience of the Open/R and Terragrap= h. > > Regards, > Greg > > On Thu, Jan 4, 2018 at 3:13 PM, Robert Raszuk wrote: > >> Hi Alvaro, >> >> Happy New Year !!! >> >> > That was pretty much the question asked during the dcrouting BOF in >> Singapore. >> >> Well .. in Singapore and during most of list discussions dynamic floodin= g >> proposal was not on the table. Now it is. >> >> To me this is game changer and any conclusions reached previously IMHO >> should now be revisited. >> >> As far as outcome of the BOF - I am not sure how the conclusion was >> derived that we need new protocols - especially only those presented. In >> real practical cases a lot of DC clusters are build with at most few >> hundreds of L3 nodes which in all flavors of current link state >> implementations will work just fine as is. >> >> For MSDCs use of either eBGP or Open/R is deployed. >> >> Now dynamic flooding can extend link state to scale much larger. >> >> Personally IMHO this case is solved. Maybe time to move on to other area= s >> ? :) >> >> Best, >> R. >> >> >> >> On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana >> wrote: >> >>> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) >>> wrote: >>> >>> Robert: >>> >>> Hi! Happy New Year! >>> >>> Do we really need yet one more new routing protocol vs relatively minor >>> extension of existing link state protocols ? >>> >>> >>> That was pretty much the question asked during the dcrouting BOF in >>> Singapore. Starting from the assumption that one size doesn=E2=80=99t = fit all, the >>> room showed interest in working on solutions beyond the current work in >>> isis/ospf (which was also quickly reviewed there). >>> >>> To be clear, the intent of chartering rift doesn=E2=80=99t mean that wo= rk in >>> other WGs (including new proposals) should stop. Quite the contrary, i= f >>> there is sustained interest in this effort, then we will go on with it = =E2=80=94 if >>> there isn=E2=80=99t (for whatever reason), then it will be clear as wel= l. Note >>> that I asked the proponents to constrain the proposed charter to work i= tems >>> that should be able to be delivered within a short timeframe (around a >>> year) =E2=80=94 so that we can reassess the interest, and re-charter if= appropriate. >>> >>> The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m >>> cc=E2=80=99ing that list here to avoid repeating the discussion there. = Also, I >>> noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2= =80=99ing that list as >>> well. >>> >>> Thanks! >>> >>> Alvaro. >>> >> >> >> _______________________________________________ >> Dcrouting mailing list >> Dcrouting@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrouting >> >> > --94eb2c1b5622d6cfd405622318a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Greg,

> I believe it will = be very interesting and helpful to look at the proposed dynamic flooding fr= om the point of experience of the Open/R and Terragraph.

Honestly I don't think so.=C2=A0=

The reason is that wh= at Tony Li proposed is an update to classic link state flooding. In fact he= is reusing existing DR/DIS in his proposal.=C2=A0
=
Open/R is using message bus for control plane = transport which is a completely different paradigm.=C2=A0

I am not making any judgement here wh= ich is better or worse scale or convergence wise. But at least to me there = are apples and oranges and comparing or drawing any conclusion from the beh= avior of one to the other seems quite bizarre.=C2=A0

Personally I like a lot Open/R real pub-sub = model. We have been using BGP to propagate p2p messages within p2mp protoco= l for way too long now. That nonsense has to stop. RTC has been proposed fo= r other reasons and is not the right way to filter BGP information to stret= ch it as p2p database distribution protocol. It would be very interesting t= o see proposals for BGP intra-domain transport using message bus.=C2=A0

But for robust topology d= iscovery, computing SPF, local protection with no constrains on network top= ology I guess I will still value link state for a while :).=C2=A0=C2=A0

And as already stated for= 95% of DCs where cluster size is up to 100 racks I think there is no issue= to use currently shipping OSPF or ISIS. When you go beyond that (if you as= an enterprise ever do) there is for more optimizations. But from my person= al experience building huge flat DC clusters is only applicable to very few= customers.=C2=A0

Very= frankly even issuing RFC describing use of BGP for DC fabric confused numb= er of folks with 5-10 racks and made them to insist that only BGP will work= and ISIS or OSPF is a very bad idea. Others for the very same reasons use = BGP only deployments in campus networks.=C2=A0

=
Let's be very careful what we consider as good= IETF work items and what we define here as standard tracks documents as ev= en if not intended they do have a ricochet effect.=C2=A0

Best,
Robert= .


On Sat, Jan 6, 2018 at 10:35 PM= , Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Robert,
I= recall presentation by Petr Lapukhov on Open/R and Terragraph where the pr= inciple of optimized flooding was used. Of course, algorithms and mechanics= of the Open/R in Terragraph may be different from those proposed in the=C2=A0draft An Architecture for Dy= namic Flooding on Dense Graphs. I believe it will be very interesting and h= elpful to look at the proposed dynamic flooding from the point of experienc= e of the Open/R and Terragraph.

Regards,
Greg

On Thu, Jan 4, 2018 at 3:13 PM, Robe= rt Raszuk <robert@raszuk.net> wrote:
Hi Alvaro,

Happy New Year !!!

> That was pretty much the ques= tion asked during the dcrouting BOF in Singapore.=C2=A0

Well .. in Sing= apore and during most of list discussions dynamic flooding proposal was not= on the table. Now it is.=C2=A0

To me this is game changer and any conclusions reached previously IMH= O should now be revisited.=C2=A0

As far as outcome of the BOF - I am not sure how the conclusion was = derived that we need new protocols - especially only those presented. In re= al practical cases a lot of DC clusters are build with at most few hundreds= of L3 nodes which in all flavors=C2=A0of current link state implementation= s will work just fine as is.=C2=A0

For MSDCs use of either eBGP or Open/R is deplo= yed.
<= br>
Now dynamic flooding = can extend link state to scale much larger.=C2=A0

Personally=C2=A0IMHO this case is solved. Maybe time to move on to oth= er areas ? :)

=
Best,
R.


<= div class=3D"gmail-m_5204468319542514966h5">

=
On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <= span dir=3D"ltr"><aretana.ietf@gmail.com> wrote:
On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:

Robert:

Hi!=C2=A0 Happy New Year!
=
Do we really need yet one more new routing protocol v= s relatively minor extension of existing link state protocols ?=C2=A0

<= /div>
That was pr= etty much the question asked during the dcrouting BOF in Singapore.=C2=A0 S= tarting from the assumption that one size doesn=E2=80=99t fit all, the room= showed interest in working on solutions beyond the current work in isis/os= pf (which was also quickly reviewed there).

To be clear, the intent of chartering rift doesn=E2=80=99t mea= n that work in other WGs (including new proposals) should stop.=C2=A0 Quite= the contrary, if there is sustained interest in this effort, then we will = go on with it =E2=80=94 if there isn=E2=80=99t (for whatever reason), then = it will be clear as well.=C2=A0 Note that I asked the proponents to constra= in the proposed charter to work items that should be able to be delivered w= ithin a short timeframe (around a year) =E2=80=94 so that we can reassess t= he interest, and re-charter if appropriate.

The above obviously applies to the lsvr (aka BGP-SPF) proposal= , so I=E2=80=99m cc=E2=80=99ing that list here to avoid repeating the discu= ssion there.=C2=A0 Also, I noticed you forwarded your message to dcrouting,= so I=E2=80=99m cc=E2=80=99ing that list as well.

Thanks!

Alvaro.


________________________= _______________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>



--94eb2c1b5622d6cfd405622318a7-- From nobody Sun Jan 7 22:46:16 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BECF12711E for ; Sun, 7 Jan 2018 22:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 w2rkrNWSzD_1 for ; Sun, 7 Jan 2018 22:46:07 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 D2B2B120454 for ; Sun, 7 Jan 2018 22:46:07 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-08v.sys.comcast.net with ESMTP id YRC5eK2JNkQflYRCBe0Daa; Mon, 08 Jan 2018 06:46:07 +0000 Received: from [IPv6:2602:306:35a4:2190:68b4:6f9d:35f6:891c] ([IPv6:2602:306:35a4:2190:68b4:6f9d:35f6:891c]) by resomta-po-06v.sys.comcast.net with SMTP id YRBwe3hvKWQ7ZYRC2eAnl5; Mon, 08 Jan 2018 06:46:05 +0000 From: tony.li@tony.li Content-Type: multipart/alternative; boundary="Apple-Mail=_6AE5822C-4884-482C-B3D2-D2931E0866D2" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <61A9596C-8561-4AC0-868A-53BCEB6498F7@tony.li> References: <151539387793.11360.15792671551913855553.idtracker@ietfa.amsl.com> To: dcrouting@ietf.org, isis-wg@ietf.org Date: Sun, 7 Jan 2018 22:45:51 -0800 X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfM4T2xBwRrXKCugo0Y+hkoItmDKUhcKbc9FAjwM//+CTojDWRRcV4R1rFdyUJy7u8auBa2joFLH5M7cGqhxDFvtvZDDj0R+0a8eQJj8twIZwGxdOpUwV jtoZrtFz6/pRKm8lfyp7AbL3o2JTSVLgArwsZ+4L+jnQdQ9zagy8m4zFC9qrBAtCdNm/8ecZ9iWvimMXpmmMi99KJTiVGEQecgA= Archived-At: Subject: [Dcrouting] Fwd: New Version Notification for draft-li-dynamic-flooding-isis-00.txt X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 06:46:10 -0000 --Apple-Mail=_6AE5822C-4884-482C-B3D2-D2931E0866D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =09 FYI=E2=80=A6 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-li-dynamic-flooding-isis-00.txt > Date: January 7, 2018 at 10:44:37 PM PST > To: "Tony Li" >=20 >=20 > A new version of I-D, draft-li-dynamic-flooding-isis-00.txt > has been successfully submitted by Tony Li and posted to the > IETF repository. >=20 > Name: draft-li-dynamic-flooding-isis > Revision: 00 > Title: Dynamic Flooding for IS-IS > Document date: 2018-01-07 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-li-dynamic-flooding-isis-00.txt= > Status: = https://datatracker.ietf.org/doc/draft-li-dynamic-flooding-isis/ > Htmlized: = https://tools.ietf.org/html/draft-li-dynamic-flooding-isis-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-li-dynamic-flooding-isis-00 >=20 >=20 > Abstract: > Routing with link state protocols in dense network topologies can > result in sub-optimal convergence times due to the overhead > associated with flooding. This can be addressed by decreasing the > flooding topology so that it is less dense. >=20 > This document discusses extensions to the IS-IS routing protocol to > support a solution to flooding in dense subgraphs. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_6AE5822C-4884-482C-B3D2-D2931E0866D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =
FYI=E2=80=A6


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-li-dynamic-flooding-isis-00.txt
Date: = January 7, 2018 at 10:44:37 PM = PST
To: = "Tony Li" <tony.li@tony.li>

A new version of I-D, = draft-li-dynamic-flooding-isis-00.txt
has been = successfully submitted by Tony Li and posted to the
IETF = repository.

Name: = draft-li-dynamic-flooding-isis
Revision: 00
Title:= = Dynamic Flooding for IS-IS
Document date: = 2018-01-07
Group: Individual Submission
Pages:= = 8
URL: =            https://www.ietf.org/internet-drafts/draft-li-dynamic-flooding-= isis-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-li-dynamic-flooding-isis= /
Htmlized:       https://tools.ietf.org/html/draft-li-dynamic-flooding-isis-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-dynamic-flooding= -isis-00


Abstract:
  Routing with link state protocols in dense = network topologies can
  result in sub-optimal = convergence times due to the overhead
=   associated with flooding.  This can be addressed by = decreasing the
  flooding topology so that it = is less dense.

  This document = discusses extensions to the IS-IS routing protocol to
=   support a solution to flooding in dense subgraphs.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_6AE5822C-4884-482C-B3D2-D2931E0866D2-- From nobody Wed Jan 10 02:54:20 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18531200C1; Wed, 10 Jan 2018 02:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=nokia.onmicrosoft.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 TDQp71ihQw1u; Wed, 10 Jan 2018 02:50:36 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0111.outbound.protection.outlook.com [104.47.2.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CBF51200B9; Wed, 10 Jan 2018 02:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m5XhKtQPukH9s9a2h6PRqdrbm7RSkegy4Q0aLHVRvrc=; b=kfvg1R4olBjFLGFMC/St19T7mvo++I4AtcHDljhmPfCT5qtXwPLDoJHqz8ufHaecOjGMx0kIZC+nKJTAojhirivJt8sZVpfgKSbo5ucTL00o3dBPYqCnJkkVeNrrq86RFl0UX4DtuurO4kGd29bUArrkDwtzThbJGqmB+8sKDPE= Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2420.eurprd07.prod.outlook.com (10.169.153.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Wed, 10 Jan 2018 10:50:30 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::645d:a0f3:c36b:9aa3]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::645d:a0f3:c36b:9aa3%14]) with mapi id 15.20.0407.005; Wed, 10 Jan 2018 10:50:30 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "Lsvr@ietf.org" CC: "dcrouting@ietf.org" , "rtgwg@ietf.org" , "idr@ietf.org" , "Acee Lindem (acee)" , Keyur Patel , Shawn Zandi , Victor Kuarsingh , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Alvaro Retana Thread-Topic: Kicking off the LSVR (Link State Vector Routing) charter discussion Thread-Index: AdOJ/UwcaD75A6yMRfGV3jqNSACMxQ== Date: Wed, 10 Jan 2018 10:50:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:1810:4d67:a00:a943:b4dc:a5a0:53f3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2420; 7:wVbqS7ALT89fjooqDFdPpIzWFml18PF/V7wGWTFK2nnLycEvVm8yif3Ax5Dj6Uim82kWZLnIweImQSft5NzsfUGxfrWQz2pOkKtDGVG9aHyIRCVlquyTXexHjvgCzCT6smJqLyqyZF/FyjbHtAcPSBrV1P0L/bR1x24SPfqd6/tox4Q097b8zGAAslwBQA46PgVl7BYhwu0qFcEk0K5OasztuGSU8l+b0kkbjG/bzvLfUQb3fPv89rzzrhi9T8w3 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(396003)(366004)(346002)(376002)(199004)(189003)(105586002)(53936002)(5250100002)(2351001)(6506007)(33656002)(54906003)(6436002)(2501003)(106356001)(7696005)(39060400002)(6346003)(74316002)(25786009)(4326008)(6306002)(9686003)(305945005)(102836004)(97736004)(8656006)(6916009)(7736002)(966005)(59450400001)(478600001)(99286004)(316002)(6116002)(5660300001)(2906002)(5640700003)(14454004)(55016002)(3660700001)(81166006)(8676002)(81156014)(2900100001)(8936002)(86362001)(3280700002)(68736007)(437434002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2420; H:AM5PR0701MB2836.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 78050826-68ce-4a1b-8366-08d55817f76c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020049)(4652020)(4534079)(4602075)(4627175)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(48565401081)(2017052603307)(7193020); SRVR:AM5PR0701MB2420; x-ms-traffictypediagnostic: AM5PR0701MB2420: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231023)(11241501184)(806099)(944501119)(6055026)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:AM5PR0701MB2420; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2420; x-forefront-prvs: 0548586081 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-microsoft-antispam-message-info: fTFIAipZZTiGstQYvJSIsIGraU69ei72GJj2hN9x6UguZVuRSEuFVSQ0i3rcp7e7nvN3G04yVuaxtvGT7prpxXcLcfZA6hmlTYawkXhiYftc6jtGMUw7voCrurooVEnq spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78050826-68ce-4a1b-8366-08d55817f76c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2018 10:50:30.0744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2420 Archived-At: X-Mailman-Approved-At: Wed, 10 Jan 2018 02:54:19 -0800 Subject: [Dcrouting] Kicking off the LSVR (Link State Vector Routing) charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 10:50:39 -0000 [Note: Target audience, and discussions should happen on lsvr@ietf.org, how= ever "rtgwg", "idr" and "dcrouting" email lists have been added as the conc= epts originated in those working groups] Since dcrouting@ietf100, a few people have been discussing a possible WG ch= arter for LSVR (Link State Vector Routing). Here is what we have so far. Comments and improvements would be most welco= me.=20 WG page is to be setup soon. Subscription to LSVR mailing list: https://www.ietf.org/mailman/listinfo/ls= vr Feedback (comments, edits, corrections, etc) on the draft LSVR charter is = appreciated=20 ***** DRAFT CHARTER UPDATE - JAN 10 2018 ***** =A0 Charter: LSVR - Link State Vector Routing=A0 =A0 The Link-State Vector Routing (LSVR) Working Group is chartered to develop = and document a hybrid routing protocol utilizing a combination of link-stat= e and path-vector routing mechanisms. =A0The LSVR WG will utilize existing = the IPv4/IPv6 transport, packet formats, and error handling from BGP-4 (RFC= 4271). Additionally, the=A0BGP-LS NLRI encoding mechanisms defined in RFC77= 52 are utilized=A0to facilitate Link-State Vector (LSV) routing information= distribution. An LSV is intended to be specified as a data structure compr= ised of a link identification, link attributes, neighbor information, cost = toward neighbors, and other attributes that are defined for control plane f= unction and policy-based routing decisions. =A0 The LSVR specification is initially focused on operation within a single da= tacenter (DC) with preliminary focus on specifying functionality within a s= ingle distribution domain. =A0Routing protocol functionality defined by LSV= R would be typically routing within a datacenter's underlay routing plane.= =A0 =A0 In order to achieve the noted objective, the working group will focus on st= andardization of protocol functionality, defining Link-State Vectors (LSVs)= , and defining standard path-vector route selection utilizing existing Dijk= stra SPF based algorithm, BGP-4 protocol mechanics, and BGP-LS NRLI encodin= g. =A0 For the purposes of the initial work within the LSVR WG, and until further = specified by the WG, the following definitions apply to this charter. =A0 - Link-State Vector - An LSV is intended to represent a data structure (dat= a set) comprised of link identification, link attributes, neighbor informat= ion, cost towards neighbors, and other potential attributes that can be uti= lized to make routing decisions. - LSVR Distribution Domain - Initially scoped as a set of participating LSV= R nodes in a single administrative domain. =A0 =A0 The LSVR WG is chartered to deliver the following documents: =A0 - Publish Applicability Statement for the use of LSVR in the Datacenter - T= arget Status: Informational - Publish specification document describing LSV with standard Dijkstra SPF = route/path selection (calculation) utilizing existing BGP protocol baseline= functionality and BGP-LS packet encoding formats - Target: Standards Track= (Based on draft draft-keyupate-idr-bgp-spf) - Publish specification documenting protocol extensions required to efficie= ntly reuse BGP to distribute LSVs within an IPv4/IPv6 DC with scope to incl= ude privacy and security considerations - - Target: Standards Track - Publish YANG model specification for LSVR - - Target: Standards Track =A0 LSVR Milestones: =A0 - Applicability statement for LSVR in DCs: March 2019 - LSVR with standard Dijkstra path selection: March 2019 - LSV distribution using BGP transport: March 2019 - YANG specification for LSRV: July 2019 From nobody Thu Jan 11 01:30:12 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD4512EAD2; Thu, 11 Jan 2018 01:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkVx0_wrXYd6; Thu, 11 Jan 2018 01:30:08 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 D4B1912EAC4; Thu, 11 Jan 2018 01:30:02 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id f8so1559890wre.4; Thu, 11 Jan 2018 01:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=kh8T7brrv/cjhjR3OTaVmYAvcRZYJ+BCUuJ8lf9m7ps=; b=lzdbeFPNe0CGQSHrqbDeVhv7OV3PbN+iIYIzgMBBq0SZue6/+eWy/GACahvDIgFQu2 rAv2rKJGQp0l0PYAsy/SzRc0HO7nqpxQq7p1nEUBn2bTl+75fGbl4qpyIUpj9Natgdma sh1llgUskEJtelne6QdzqAd8O+arehmoB2wYZPm7gVNwUIumbFcaKDP665oW929sZ8eN Qc9bH0pSibr3Iuyf2S+ZSQAkXDT/S1vAqE7MfpP+fdbCe++Tir8hzO9oRVRvMQLKQE02 Y/IwyPuGXpxX7LeVUeK8h1YCsavehDvBpRWmLkW++S9dbBQg69nt2uc1ZJ57PmfjFEmH wSgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=kh8T7brrv/cjhjR3OTaVmYAvcRZYJ+BCUuJ8lf9m7ps=; b=igaBGZttTe1RW8hDBkQzQmwP48DgNHFVNKo4Udu2OKDQWbHHfeJbHGMRVW1fwftZCx HTQgZLPUZNL2ou71kq49pZMOGKR6+0bXp7GJp1qDqYcZY0WGB+I7lrqC5i/DBW/c63mt f37NZHqaKVOUg0Q29PPaVq5up2JVQH3+WyOLDMh9Ze1qRczgMAOTXOjxnkFCuIweXmgI gFcVQpkybSsGRxFCviaXi68VFFagp4wFzKcphvNDyhDo635mIk+i/HbUY+DyrJr4M67Q OviW9LqzmhKmiA/3InIHMdesc1cIAtxwJtpFKIa0x9dqBraeo3bHNBXXvN5aULwNzOvS zmbQ== X-Gm-Message-State: AKGB3mIS5vWi8b4EuljH9cFfSyn2yjgCbT4g+U3KW48Jzt7OZO20KE1S 9J0EffnjSoD5vttGpxd86sEXOWsM+YU0vseFhycBPA== X-Google-Smtp-Source: ACJfBouGfOqpROp74qVWV2bAPOh1k9+n/jJnzJbnwG8gHj3iTZTMXxEPccQQ3ct2PCtfRTj9wyF90HY7n4f5VyTHuew= X-Received: by 10.223.162.138 with SMTP id s10mr18444858wra.239.1515663000744; Thu, 11 Jan 2018 01:30:00 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Thu, 11 Jan 2018 01:30:00 -0800 (PST) From: Robert Raszuk Date: Thu, 11 Jan 2018 10:30:00 +0100 X-Google-Sender-Auth: J8FHB4iM-Aawfk291TNE-C289v0 Message-ID: To: rift@ietf.org Cc: spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045e97f8c2381405627cca15" Archived-At: Subject: [Dcrouting] draft-przygienda-rift-03 X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 09:30:10 -0000 --f403045e97f8c2381405627cca15 Content-Type: text/plain; charset="UTF-8" Hi, I have one little question/doubt on scalability point of RIFT ... Assume that someone would like to signal IPv6 prefix SID for Segment Routing in the underlay within RIFT. Wouldn't it result in amount of protocol state in full analogy to massive deaggregation - which as of today is designed to be very careful and limited operation only at moments of failure(s) ? I sort of find it a bit surprising that RIFT draft does not provide encoding for SID distribution when it is positioned as an alternative to other protocols (IGPs or BGP) which already provide ability to carry all types of SIDs. Cheers, Robert. PS1: Horizontal links which were discussed could be installed to offload from fabric transit massive amount of data (ex: storage mirroring) directly between leafs or L3 TORs and not to be treated as "backup". PS2: Restricting any protocol to specific topologies seems like pretty slippery slope to me. In any case if protocol does that it should also contain self detection mechanism of "unsupported topology" and flash red light in any NOC. --f403045e97f8c2381405627cca15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">I have one little question/doubt on scalability point of = RIFT ...=C2=A0

Assume = that someone would like to signal IPv6 prefix SID for Segment Routing in th= e underlay within RIFT.=C2=A0

Wouldn't it result in amount of protocol state in full analogy= to massive deaggregation - which as of today is designed to be very carefu= l and limited operation only at moments of failure(s) ?=C2=A0

I sort of find it a bit surprising = that RIFT draft does not provide encoding for SID distribution when it is p= ositioned as an alternative to other protocols (IGPs or BGP) which already = provide ability to carry all types of SIDs.=C2=A0
<= br>
Cheers,
Robert.

=
PS1: Horizontal links which were discussed could b= e installed to offload from fabric transit massive amount of data (ex: stor= age mirroring) directly between leafs or L3 TORs and not to be treated as &= quot;backup".=C2=A0

PS2: Restricting any protocol to specific topologies seems like pretty s= lippery slope to me. In any case if protocol does that it should also conta= in self detection mechanism of "unsupported topology" and flash r= ed light in any NOC.=C2=A0


--f403045e97f8c2381405627cca15-- From nobody Thu Jan 11 09:41:02 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3117A12D87A; Thu, 11 Jan 2018 09:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Yy0zFXMceXHE; Thu, 11 Jan 2018 09:40:47 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 D54EB12AF6E; Thu, 11 Jan 2018 09:40:46 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id g75so7192334wme.0; Thu, 11 Jan 2018 09:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=28LzpsAOotuG0kTesPyhckSUU7GjJaKZZTZr25OZ7Tg=; b=Kw5diFxbvFji8IgBYw826CWHCjtbP96aYs8CbS1/JyvEmCwfmDFf9BQemp5mcS107L hr4N2V8/IKTvPT1QoudwpMDGdVWEIVaav9bwSDKpeb0mXhDPGBU6fXeFdgbfAGd+i4QD EfWutEW92RR0o9iXBqaqc0lW8MyfVP4BMinovVMXWJv6K2hiaemFz/OZAwcZFaOMAqRW +By8fDok4BfHJ90XKp3N4ymo3aaI9CU/rqi9Y+XvIvDXcFy/smNNInn+f+/LI4OiIGfx BcRNRsDGat45w0VQK1TrQLdrh19YUdmpM+Xclz/j8Q7f91Y8xyKjIrMz5elvORs9qWOZ 7Sgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=28LzpsAOotuG0kTesPyhckSUU7GjJaKZZTZr25OZ7Tg=; b=fNe7RfolSDlRAAMWmZBiBg2WklZ1J7DRnqzI7rQpjlwdYIaOvKnM3lt+Qv/SBsMYuJ OlfdjlUoT/fahGK/s9D8pF/kgx2CdXiMUEHTwJG43BEuBbrZiYYiVCpR+KAOiVF5QkR+ 14IgSpQSMaiXPNGXw/esj0WyB1CYNZjmDGwRWhW6Wn4fi/EmTcaOPjlEkqeG5f6Gael2 jsOZtLurYqBSqTVaZBahMTdxAUn22dXvrXlMzT7b6DpPfQNLh2E12CrRy0yANRKLJYPI Vn5+5WNOzLgRsygly59ntTxLytRgAOPWlLbtnGOnAqKimyLizeB8xJpZPLbd+2t3clMq +JNg== X-Gm-Message-State: AKwxytet5jgPEkXfMU4oX1ivB70D5TIStn+7L8BCkwPYddQGCJLsoBny lP1cuZF6GohgkUW+Y39mMsJLttDolmILwJiFYcJ1JxLg X-Google-Smtp-Source: ACJfBovE+dv/dnxi+8dmmt3c/ip9MbCW3y43Z8k3L5C2aLetXu8D6giGDE0CiOCwP5PW8PuvFn5TXMVgvoTQ6fOcVL8= X-Received: by 10.80.153.139 with SMTP id m11mr13471418edb.145.1515692445175; Thu, 11 Jan 2018 09:40:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 09:40:04 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 11 Jan 2018 09:40:04 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0ec4fac89593056283a558" Archived-At: Subject: Re: [Dcrouting] draft-przygienda-rift-03 X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 17:40:50 -0000 --94eb2c0ec4fac89593056283a558 Content-Type: text/plain; charset="UTF-8" Robert, productive points, thanks for raising them ... I go a bit in depth 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you run RIFT). The only one that comes up regularly is egress engineering and that IMO is equivalent to SID=leaf address (which could be a HV address of course once you have RIFT all way down to server) so really, what's the point to have a SID? It's probably much smarter to use IBGP & so on overlay to do this kind of synchronization if needed since labels/SIDs become very useful in overlay to distinguish lots stuff there like VPNs/services which you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 address. Having said that, discussion always to be had if you pay me dinner ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but again, no _real_ use case so far. And if your only concern is to "shape towards a prefix" we have PGP in the draft which doesn't need new silicon ;-P And then ultimately, yes, if you really, really want a SID per prefix everywhere then you'll carry SIDs to everywhere since unicast SIDs are really just a glorified way to say "I have this non-aggreagable 20 bit IP host address" which architecturally is a very interesting proposition in terms of scaling (but then again, no account for taste and RFC1925 clause 3 applies) ... Your LSDB will be still much smaller, your SPF will be still simple on leaf in RIFT but your FIB will blow up and anything changing on a leaf shakes all other leafs (unless you start to run pollicies to control distribution @ which point in time you start to baby-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you will observe that RIFT can do anycast without need for ECMP, i.e. true anycast in a sense and with that having anycast SID serves no real purpose in RIFT and is actually generally much harder to do since you need globally unique label blocks and so on ... 2. Horizontal links on CLOSes are not used that way normally all I saw since your blocking goes to hell unless you provision some kind of really massive parallel links between ToRs _and_ understand your load. We _could_ build RIFT that way but you give up balancing through the fabric and loop-free property in a sense (that's a longish discussion and scaling since now you have prefixes showing up all kind of crazy places instead of default). I see enough demand, we get there ... Otherwise RFC1925 clause 10 and 5. 3. PS1: Yes, lots of things "could" be done and then we "could" build a protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal links, unless provisioned correctly will pretty much just ruin your blocking/loss on the fabric is the experience (which the math supports). In a sense if you know your big flows you can build a specialized topology to do the optimal distribution (MPLS tunnels anyone ;-) but the point of fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a good analogy would be that you like to build special RAM chips for the type of data structures you are storing and we know how well that scales over time. We know now that within 3-4 years characteristics of DC flows flip upside down without a sweat when people go from server/client to microservices, from servers to containers and so on and so on. So if you can't predict your load all the time you need a _regular_ topology where _regular_ is more of a mathematical than a protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and just stick them in" applies here. So RIFT is done largely to serve a well-known structure called a "lattice" (with some restrictions) since we need an "up" and "down". Things like hypercubes, thoroidal meshes and so on and so on exist but CLOS won for a very good reason in history for that kind of problems (once you move to NUMA other things win ;-) And if you know your loads and your can heft the OPEX and you like to play with protocols generally and if you can support the scale in terms of leaf FIB sizes, flooding, slower convergence & so on & so on and you run flat IGP on some kind of stuff that you build that doesn't even have to be regular in any sense. We spent many years solving THAT problem obviously and doing something like RIFT to replace normal IGP is of limited interest IMO (albeit certain aspects having to do with modern implemenation techniques may get us there one day but it's much less of pressing problem than solving specialized DC routing well IMO again). 3. PS2: RIFT cannot build an "unsupported topology" no matter how you cable (that's the point of it) or rather we have miscabling detection and do not form adjacencies when you read the draft carefully. That's your "flash red light" and it comes included for free with my compliments ;-) ... Otherwise RFC1925 clause 10. Otherwise, if you have concrete charter points you'd like to add, be more specific in your asks and we see what the list thinks after ... thanks --- tony On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: > Hi, > > I have one little question/doubt on scalability point of RIFT ... > > Assume that someone would like to signal IPv6 prefix SID for Segment > Routing in the underlay within RIFT. > > Wouldn't it result in amount of protocol state in full analogy to massive > deaggregation - which as of today is designed to be very careful and > limited operation only at moments of failure(s) ? > > I sort of find it a bit surprising that RIFT draft does not provide > encoding for SID distribution when it is positioned as an alternative to > other protocols (IGPs or BGP) which already provide ability to carry all > types of SIDs. > > Cheers, > Robert. > > PS1: Horizontal links which were discussed could be installed to offload > from fabric transit massive amount of data (ex: storage mirroring) directly > between leafs or L3 TORs and not to be treated as "backup". > > PS2: Restricting any protocol to specific topologies seems like pretty > slippery slope to me. In any case if protocol does that it should also > contain self detection mechanism of "unsupported topology" and flash red > light in any NOC. > > > > _______________________________________________ > Dcrouting mailing list > Dcrouting@ietf.org > https://www.ietf.org/mailman/listinfo/dcrouting > > --94eb2c0ec4fac89593056283a558 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Robert, productive points, thanks for raisi= ng them ... I go a bit in depth

1. I saw no _r= eal_ use-cases for SID in DC so far to be frank (once you run RIFT). The on= ly one that comes up regularly is egress engineering and that IMO is equiva= lent to SID=3Dleaf address (which could be a HV address of course once you = have RIFT all way down to server) so really, what's the point to have a= SID? It's probably much smarter to use IBGP & so on overlay to do = this kind of synchronization if needed since labels/SIDs become very useful= in overlay to distinguish lots stuff there like VPNs/services which you= 9;d carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 addr= ess. Having said that, discussion always to be had if you pay me dinner ;--= ) and I know _how_ we can do SIDs in RIFT since I thought it through but ag= ain, no _real_ use case so far. And if your only concern is to "shape = towards a prefix" we have PGP in the draft which doesn't need new = silicon ;-P And then ultimately, yes, if you really, really want a SID per = prefix everywhere then you'll carry=C2=A0 SIDs to everywhere since unic= ast SIDs are really just a glorified way to say "I have this non-aggre= agable 20 bit IP host address" which architecturally is a very interes= ting proposition in terms of scaling (but then again, no account for taste = and RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be still much smalle= r, your SPF will be still simple on leaf in RIFT but your FIB will blow up = and anything changing on a leaf shakes all other leafs (unless you start to= run pollicies to control distribution @ which point in time you start to b= aby-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID w= ould be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you read= RIFT draft carefully you will observe that RIFT can do anycast without nee= d for ECMP, i.e. true anycast in a sense and with that having anycast SID s= erves no real purpose in RIFT and is actually generally much harder to do s= ince you need globally unique label blocks and so on ...=C2=A0

2. Horizontal links on CLOSes are not used that way normally all I saw si= nce your blocking goes to hell unless you provision some kind of really mas= sive parallel links between ToRs _and_ understand your load. We _could_ bui= ld RIFT that way but you give up balancing through the fabric and loop-free= property in a sense (that's a longish discussion=C2=A0 and scaling sin= ce now you have prefixes showing up all kind of crazy places instead of def= ault). I see enough demand, we get there ...=C2=A0 Otherwise RFC1925 clause= 10 and 5.=C2=A0

3. PS1: Yes, lots of things &quo= t;could" be done and then we "could" build a protocol to do = that and RFC1925 clause 7 and 8 applies. Such horizontal links, unless prov= isioned correctly will pretty much just ruin your blocking/loss on the fabr= ic is the experience (which the math supports). In a sense if you know your= big flows you can build a specialized topology to do the optimal distribut= ion (MPLS tunnels anyone ;-) but the point of fabric is that it's a fab= ric (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a g= ood analogy would be that you like to build special RAM chips for the type = of data structures you are storing and we know how well that scales over ti= me. We know now that within 3-4 years characteristics of DC flows flip upsi= de down without a sweat when people go from server/client to microservices,= from servers to containers and so on and so on. So if you can't predic= t your load all the time you need a _regular_ topology where _regular_ is m= ore of a mathematical than a protocol discussion. Fabric analogy of "b= uy more RAM chips in Fry's and just stick them in" applies here. S= o RIFT is done largely to serve a well-known structure called a "latti= ce" (with some restrictions) since we need an "up" and "= ;down". Things like hypercubes, thoroidal meshes and so on and so on e= xist but CLOS won for a very good reason in history for that kind of proble= ms (once you move to NUMA other things win ;-) And if you know your loads a= nd your can heft the OPEX and you like to play with protocols generally and= if you can support the scale in terms of leaf FIB sizes, flooding, slower = convergence & so on & so on and you run flat IGP on some kind of st= uff that you build that doesn't even have to be regular in any sense. W= e spent many years solving THAT problem obviously and doing something like = RIFT to replace normal IGP is of limited interest IMO (albeit certain aspec= ts having to do with modern implemenation techniques may get us there one d= ay but it's much less of pressing problem than solving specialized DC r= outing well IMO again).

3. PS2: RIFT cannot build = an "unsupported topology" no matter how you cable (that's the= point of it) or rather we have miscabling detection and do not form adjace= ncies when you read the draft carefully. That's your "flash red li= ght" and it comes included for free with my compliments=C2=A0 ;-) ... = Otherwise RFC1925 clause 10.

Otherwise, if you have concrete = charter points you'd like to add, be more specific in your asks and we = see what the list thinks after ...

thanks

--- tony


On Thu, Jan 11, 2018 at 1:30 AM, Robe= rt Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little question/doubt on scalabi= lity point of RIFT ...=C2=A0

Assume that someone would like to signal = IPv6 prefix SID for Segment Routing in the underlay within RIFT.=C2=A0

=
Wouldn't it result in amount of protocol state in full analogy to mass= ive deaggregation - which as of today is designed to be very careful and li= mited operation only at moments of failure(s) ?=C2=A0

I sort of find = it a bit surprising that RIFT draft does not provide encoding for SID distr= ibution when it is positioned as an alternative to other protocols (IGPs or= BGP) which already provide ability to carry all types of SIDs.=C2=A0
=

<= /div>
= Cheers,
Robert.

PS1: Horizontal links which were discussed could be= installed to offload from fabric transit massive amount of data (ex: stora= ge mirroring) directly between leafs or L3 TORs and not to be treated as &q= uot;backup".=C2=A0

PS2: Restricting any protocol to specific topo= logies seems like pretty slippery slope to me. In any case if protocol does= that it should also contain self detection mechanism of "unsupported = topology" and flash red light in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>


--94eb2c0ec4fac89593056283a558-- From nobody Thu Jan 11 10:14:26 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25212EC15; Thu, 11 Jan 2018 10:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YOjNLfWGTShX; Thu, 11 Jan 2018 10:14:20 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 83B0D12EC19; Thu, 11 Jan 2018 10:14:20 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id g75so7377242wme.0; Thu, 11 Jan 2018 10:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UOdvwV2owj7LKJBCFUvzKuKbXklYBo2Tzi7cUB4ECRc=; b=IqXKUsHqGuE4APKsrKWL75XfXOBM2HR0zMqlYPlkiEr6TWFHeobqKTlJjeAG3ccE34 +L8onjMjMPPBXMWMdaxTZm4VZT+Y5l+NtV6h+w7zAg5QRtyx9RWJGQ4/mNHg1ixdm6KG gg7XhbAFl7hxaoY37DYa0Ou0DoIlO8A7fSKPzH2w69SxYjG++QxtNas/BYvHtmfrECWq qQOKJQn8Zxf+RfssAYJdYm6BWpek1Ea0RHYMYbVpZ4sHr0zCG3O0yLW65Skh5H7sR5AJ 8alFYYqovEKgfe+Y3VVoeQz3ksiY99WNHoZaNlOtCt6pHQj0J96DA29X2rajM2Vp5s2i OO3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UOdvwV2owj7LKJBCFUvzKuKbXklYBo2Tzi7cUB4ECRc=; b=SfIWI/8q38NpgdJKtLcrC3K0dVC09fOOez7zoAvxri0QDKTQGtyfgwwyzMLu5ThE1d jb+ERAlzmRU6ND9//z6jBNOFIUjpMw7dNJmCzEVjKWvYqlWxXGGaKSBKXnDRxNayYXT2 WbZ/qnqL+VCxJ8ic0mMuMDkNe6hM2LZBOBdrHC3igFv8PFKMKlbI95xZmyYhIr8s76UV erxxj48EximU8nkuBDCTJU/NKSWmE5PQ4Kteq/v5XVXPNM77ELwga+DFQ7VGJfV5SWBu BhSAyd5XStXk+q1FPN8cM+m0i5rdMjDb5fHRlvp9SwFbZS85uWWaaRhn/joaG26iNaji eNJQ== X-Gm-Message-State: AKGB3mLVKL6wQHc0WI1ee5Wm5GLbgPzq6n5RmD2xCVhkh/a96rJCF8nS LPllMHMDJmMzZJKieNK6dVWiBrw3o+b94TzeT0M= X-Google-Smtp-Source: ACJfBotIWCTtPLGvxSlzSPCOI090iis+G8Mp0Q1o6YOCSclT1TkiPamjc1ZPveo8AKu14+yM/XDB+0zjSUjjrpzLsgM= X-Received: by 10.80.155.89 with SMTP id a25mr32109737edj.290.1515694459077; Thu, 11 Jan 2018 10:14:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 10:13:38 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 11 Jan 2018 10:13:38 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1aec78d2475b0562841d15" Archived-At: Subject: Re: [Dcrouting] draft-przygienda-rift-03 X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 18:14:24 -0000 --94eb2c1aec78d2475b0562841d15 Content-Type: text/plain; charset="UTF-8" Having said that there are interesting use cases we talk of "some binding per node" but that's more of a KV store corner where people think it's very useful to have the spines pushing stuff down to all nodes or (at cost of stability) having a node push some stuff up that gets pushed down to all other nodes. That's more of a "per leaf node" information case and pretty good unless leafs go crazy doing dynamic re-assignment (but we can dampen that in spines @ every level if needed) but it's not _per prefix_ which you seemed to ask about .... --- tony On Thu, Jan 11, 2018 at 9:40 AM, Tony Przygienda wrote: > Robert, productive points, thanks for raising them ... I go a bit in depth > > 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you > run RIFT). The only one that comes up regularly is egress engineering and > that IMO is equivalent to SID=leaf address (which could be a HV address of > course once you have RIFT all way down to server) so really, what's the > point to have a SID? It's probably much smarter to use IBGP & so on overlay > to do this kind of synchronization if needed since labels/SIDs become very > useful in overlay to distinguish lots stuff there like VPNs/services which > you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 > address. Having said that, discussion always to be had if you pay me dinner > ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but > again, no _real_ use case so far. And if your only concern is to "shape > towards a prefix" we have PGP in the draft which doesn't need new silicon > ;-P And then ultimately, yes, if you really, really want a SID per prefix > everywhere then you'll carry SIDs to everywhere since unicast SIDs are > really just a glorified way to say "I have this non-aggreagable 20 bit IP > host address" which architecturally is a very interesting proposition in > terms of scaling (but then again, no account for taste and RFC1925 clause 3 > applies) ... Your LSDB will be still much smaller, your SPF will be still > simple on leaf in RIFT but your FIB will blow up and anything changing on a > leaf shakes all other leafs (unless you start to run pollicies to control > distribution @ which point in time you start to baby-sit your fabric @ high > OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast > (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you > will observe that RIFT can do anycast without need for ECMP, i.e. true > anycast in a sense and with that having anycast SID serves no real purpose > in RIFT and is actually generally much harder to do since you need globally > unique label blocks and so on ... > > 2. Horizontal links on CLOSes are not used that way normally all I saw > since your blocking goes to hell unless you provision some kind of really > massive parallel links between ToRs _and_ understand your load. We _could_ > build RIFT that way but you give up balancing through the fabric and > loop-free property in a sense (that's a longish discussion and scaling > since now you have prefixes showing up all kind of crazy places instead of > default). I see enough demand, we get there ... Otherwise RFC1925 clause > 10 and 5. > > 3. PS1: Yes, lots of things "could" be done and then we "could" build a > protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal > links, unless provisioned correctly will pretty much just ruin your > blocking/loss on the fabric is the experience (which the math supports). In > a sense if you know your big flows you can build a specialized topology to > do the optimal distribution (MPLS tunnels anyone ;-) but the point of > fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily > scalable). Otherwise a good analogy would be that you like to build special > RAM chips for the type of data structures you are storing and we know how > well that scales over time. We know now that within 3-4 years > characteristics of DC flows flip upside down without a sweat when people go > from server/client to microservices, from servers to containers and so on > and so on. So if you can't predict your load all the time you need a > _regular_ topology where _regular_ is more of a mathematical than a > protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and > just stick them in" applies here. So RIFT is done largely to serve a > well-known structure called a "lattice" (with some restrictions) since we > need an "up" and "down". Things like hypercubes, thoroidal meshes and so on > and so on exist but CLOS won for a very good reason in history for that > kind of problems (once you move to NUMA other things win ;-) And if you > know your loads and your can heft the OPEX and you like to play with > protocols generally and if you can support the scale in terms of leaf FIB > sizes, flooding, slower convergence & so on & so on and you run flat IGP on > some kind of stuff that you build that doesn't even have to be regular in > any sense. We spent many years solving THAT problem obviously and doing > something like RIFT to replace normal IGP is of limited interest IMO > (albeit certain aspects having to do with modern implemenation techniques > may get us there one day but it's much less of pressing problem than > solving specialized DC routing well IMO again). > > 3. PS2: RIFT cannot build an "unsupported topology" no matter how you > cable (that's the point of it) or rather we have miscabling detection and > do not form adjacencies when you read the draft carefully. That's your > "flash red light" and it comes included for free with my compliments ;-) > ... Otherwise RFC1925 clause 10. > > Otherwise, if you have concrete charter points you'd like to add, be more > specific in your asks and we see what the list thinks after ... > > thanks > > --- tony > > > On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: > >> Hi, >> >> I have one little question/doubt on scalability point of RIFT ... >> >> Assume that someone would like to signal IPv6 prefix SID for Segment >> Routing in the underlay within RIFT. >> >> Wouldn't it result in amount of protocol state in full analogy to massive >> deaggregation - which as of today is designed to be very careful and >> limited operation only at moments of failure(s) ? >> >> I sort of find it a bit surprising that RIFT draft does not provide >> encoding for SID distribution when it is positioned as an alternative to >> other protocols (IGPs or BGP) which already provide ability to carry all >> types of SIDs. >> >> Cheers, >> Robert. >> >> PS1: Horizontal links which were discussed could be installed to offload >> from fabric transit massive amount of data (ex: storage mirroring) directly >> between leafs or L3 TORs and not to be treated as "backup". >> >> PS2: Restricting any protocol to specific topologies seems like pretty >> slippery slope to me. In any case if protocol does that it should also >> contain self detection mechanism of "unsupported topology" and flash red >> light in any NOC. >> >> >> >> _______________________________________________ >> Dcrouting mailing list >> Dcrouting@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrouting >> >> > --94eb2c1aec78d2475b0562841d15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having said that there are interesting use cases we t= alk of "some binding per node" but that's more of a KV store = corner where people think it's very useful to have the spines pushing s= tuff down to all nodes or (at cost of stability) having a node push some st= uff up that gets pushed down to all other nodes. That's more of a "= ;per leaf node" information case and pretty good unless leafs go crazy= doing dynamic re-assignment (but we can dampen that in spines @ every leve= l if needed) but it's not _per prefix_ which you seemed to ask about ..= ..

--- tony

On Thu, Jan 11, 2018 at 9:40 AM, Tony Przygienda <ton= ysietf@gmail.com> wrote:
Robert, productive points, thanks for raising= them ... I go a bit in depth

1. I saw no _rea= l_ use-cases for SID in DC so far to be frank (once you run RIFT). The only= one that comes up regularly is egress engineering and that IMO is equivale= nt to SID=3Dleaf address (which could be a HV address of course once you ha= ve RIFT all way down to server) so really, what's the point to have a S= ID? It's probably much smarter to use IBGP & so on overlay to do th= is kind of synchronization if needed since labels/SIDs become very useful i= n overlay to distinguish lots stuff there like VPNs/services which you'= d carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 addres= s. Having said that, discussion always to be had if you pay me dinner ;--) = and I know _how_ we can do SIDs in RIFT since I thought it through but agai= n, no _real_ use case so far. And if your only concern is to "shape to= wards a prefix" we have PGP in the draft which doesn't need new si= licon ;-P And then ultimately, yes, if you really, really want a SID per pr= efix everywhere then you'll carry=C2=A0 SIDs to everywhere since unicas= t SIDs are really just a glorified way to say "I have this non-aggreag= able 20 bit IP host address" which architecturally is a very interesti= ng proposition in terms of scaling (but then again, no account for taste an= d RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be still much smaller,= your SPF will be still simple on leaf in RIFT but your FIB will blow up an= d anything changing on a leaf shakes all other leafs (unless you start to r= un pollicies to control distribution @ which point in time you start to bab= y-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID wou= ld be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you read R= IFT draft carefully you will observe that RIFT can do anycast without need = for ECMP, i.e. true anycast in a sense and with that having anycast SID ser= ves no real purpose in RIFT and is actually generally much harder to do sin= ce you need globally unique label blocks and so on ...=C2=A0

= 2. Horizontal links on CLOSes are not used that way normally all I saw sinc= e your blocking goes to hell unless you provision some kind of really massi= ve parallel links between ToRs _and_ understand your load. We _could_ build= RIFT that way but you give up balancing through the fabric and loop-free p= roperty in a sense (that's a longish discussion=C2=A0 and scaling since= now you have prefixes showing up all kind of crazy places instead of defau= lt). I see enough demand, we get there ...=C2=A0 Otherwise RFC1925 clause 1= 0 and 5.=C2=A0

3. PS1: Yes, lots of things "= could" be done and then we "could" build a protocol to do th= at and RFC1925 clause 7 and 8 applies. Such horizontal links, unless provis= ioned correctly will pretty much just ruin your blocking/loss on the fabric= is the experience (which the math supports). In a sense if you know your b= ig flows you can build a specialized topology to do the optimal distributio= n (MPLS tunnels anyone ;-) but the point of fabric is that it's a fabri= c (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a goo= d analogy would be that you like to build special RAM chips for the type of= data structures you are storing and we know how well that scales over time= . We know now that within 3-4 years characteristics of DC flows flip upside= down without a sweat when people go from server/client to microservices, f= rom servers to containers and so on and so on. So if you can't predict = your load all the time you need a _regular_ topology where _regular_ is mor= e of a mathematical than a protocol discussion. Fabric analogy of "buy= more RAM chips in Fry's and just stick them in" applies here. So = RIFT is done largely to serve a well-known structure called a "lattice= " (with some restrictions) since we need an "up" and "d= own". Things like hypercubes, thoroidal meshes and so on and so on exi= st but CLOS won for a very good reason in history for that kind of problems= (once you move to NUMA other things win ;-) And if you know your loads and= your can heft the OPEX and you like to play with protocols generally and i= f you can support the scale in terms of leaf FIB sizes, flooding, slower co= nvergence & so on & so on and you run flat IGP on some kind of stuf= f that you build that doesn't even have to be regular in any sense. We = spent many years solving THAT problem obviously and doing something like RI= FT to replace normal IGP is of limited interest IMO (albeit certain aspects= having to do with modern implemenation techniques may get us there one day= but it's much less of pressing problem than solving specialized DC rou= ting well IMO again).

3. PS2: RIFT cannot build an= "unsupported topology" no matter how you cable (that's the p= oint of it) or rather we have miscabling detection and do not form adjacenc= ies when you read the draft carefully. That's your "flash red ligh= t" and it comes included for free with my compliments=C2=A0 ;-) ... Ot= herwise RFC1925 clause 10.

Otherwise, if you have concrete ch= arter points you'd like to add, be more specific in your asks and we se= e what the list thinks after ...

thanks
<= div>
--- tony


On Thu, Jan 11, = 2018 at 1:30 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little question/doubt on scalability point of RIFT = ...=C2=A0

Assume that someone would like to signal IPv6 prefix SID for= Segment Routing in the underlay within RIFT.=C2=A0

Wouldn't it re= sult in amount of protocol state in full analogy to massive deaggregation -= which as of today is designed to be very careful and limited operation onl= y at moments of failure(s) ?=C2=A0

I sort of find it a bit surprising = that RIFT draft does not provide encoding for SID distribution when it is p= ositioned as an alternative to other protocols (IGPs or BGP) which already = provide ability to carry all types of SIDs.=C2=A0

Cheers,
Robert.
<= br>
PS1: Horizontal links which were discussed could be installed to offloa= d from fabric transit massive amount of data (ex: storage mirroring) direct= ly between leafs or L3 TORs and not to be treated as "backup".=C2= =A0

PS2: Restricting any protocol to specific topologies seems like pr= etty slippery slope to me. In any case if protocol does that it should also= contain self detection mechanism of "unsupported topology" and f= lash red light in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>



--94eb2c1aec78d2475b0562841d15-- From nobody Thu Jan 11 10:54:22 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C181512EC34; Thu, 11 Jan 2018 10:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX0ITynZDL13; Thu, 11 Jan 2018 10:54:11 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 ACB0212EC28; Thu, 11 Jan 2018 10:54:10 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id w50so3140129wrc.11; Thu, 11 Jan 2018 10:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XBsVJdwaPGx2Oe8DF2MuJoBW8K3GxaHJzU3Al3NBB+U=; b=Nt7rkPYr7f6vk4HjRj7UDA2KSVB0pEVn7NTdeuqVeKDjktCYqjWWSx1Il38FJ+jwSO UyFwFFGTnaZ/ZPUlCkPJ9KK62oo/gPKcqlJIcLMFIe3C8BJkoTXKuY486u4DsvmDeT8P pOQzAA3HUmko8J+TEBFy7lJ3yGh1Y+ZtwOaCAm9iJgvJqDKyY3UfKV/ldMYNDjH/C/PK n90Wiy3e2T7xO1udpNfRKzQtb95xc17hoL7sOHvmipsb+c8K2DBPAvzB45ogguMix50L SmYqZ0+LHcYKV6PbPmn+AWLSLXdpWp4u1O5sUFB3pyy6ffxu+r6+eJMaV07Gp7u+i4wU xKaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XBsVJdwaPGx2Oe8DF2MuJoBW8K3GxaHJzU3Al3NBB+U=; b=QzhyCYOdXWzumINHBMmuCisWDebI7BUNP0oHE7vbCtDHXbUmMCzqxxFXOZ58ueTzmL pbzva8xkVq1qfuO1O7t3u5GiPHEM4ZUTZ/iQdMoSnG37olajd8CZEQ7S5eGHyrOghwkf NckhMlrEB2fFlZXH6kVsXYTfyeii8A9IPjwIsu+sEAShA1ZY4uMemaj9HQfjhLf20VyG xPxMmYEzYQcXUe88OFTlQIn3Jj1wbJzEuE1MUyO3XzyAvBw88G3kH7XUVJLWn4f1ONpd 9X9G1ti0rsExftbIdLM9O9Givc63L2/KncL1E5FaoGVPL4uLLpw1tIoIVHNZjp+SjS+B OMhA== X-Gm-Message-State: AKGB3mIEXzjbpAchfFgyScXzCZ68e1L07Wd747tLA7+nXXxTvlNKmlBy hKu5ArOOparWWwLNCkrgn437OG5mXok6UsW6hnY= X-Google-Smtp-Source: ACJfBotWZ+6WURyNM6XicTV2WRXclCfOF6oQ4Mr+UIAmsuvJYxRfW/bOXoLrErmMb+VVDL2OOubqjQL4N/y/JiVWcYE= X-Received: by 10.223.162.138 with SMTP id s10mr19970405wra.239.1515696848935; Thu, 11 Jan 2018 10:54:08 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Thu, 11 Jan 2018 10:54:07 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Thu, 11 Jan 2018 19:54:07 +0100 X-Google-Sender-Auth: 6e6RpwM60kiISNZLH8BBjo12tnQ Message-ID: To: Tony Przygienda Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045e97f844a0bc056284ac2a" Archived-At: Subject: Re: [Dcrouting] draft-przygienda-rift-03 X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 18:54:14 -0000 --f403045e97f844a0bc056284ac2a Content-Type: text/plain; charset="UTF-8" Hi Tony, Thx for elaborating ... Two small comments: A) SID/SR use case in underlay could be as simple as gracefully taking a fabric node out of service. Not much OPEX needed if your NMS is decent. Otherwise in normal link state I can do overload bit, in BGP number of solutions from shutdown to MED to LP ... depending what is your BGP design. In RIFT how do you do that ? Note that overlay (if such exist) does not help here. B) For horizontal links imagine you have servers with 40 GB ports to TOR. Then you have Nx100 GB from TOR up. You are going to oversubscribe on TOR (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to interconnect TORs because I do know that servers behind those TORs need to talk to each other in a non blocking fashion _and_ I have spare 100 GB ports on TORs having routing protocol which does not allow me to do that seems pretty limited - wouldn't you agree ? Thx, R. On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda wrote: > Robert, productive points, thanks for raising them ... I go a bit in depth > > 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you > run RIFT). The only one that comes up regularly is egress engineering and > that IMO is equivalent to SID=leaf address (which could be a HV address of > course once you have RIFT all way down to server) so really, what's the > point to have a SID? It's probably much smarter to use IBGP & so on overlay > to do this kind of synchronization if needed since labels/SIDs become very > useful in overlay to distinguish lots stuff there like VPNs/services which > you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 > address. Having said that, discussion always to be had if you pay me dinner > ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but > again, no _real_ use case so far. And if your only concern is to "shape > towards a prefix" we have PGP in the draft which doesn't need new silicon > ;-P And then ultimately, yes, if you really, really want a SID per prefix > everywhere then you'll carry SIDs to everywhere since unicast SIDs are > really just a glorified way to say "I have this non-aggreagable 20 bit IP > host address" which architecturally is a very interesting proposition in > terms of scaling (but then again, no account for taste and RFC1925 clause 3 > applies) ... Your LSDB will be still much smaller, your SPF will be still > simple on leaf in RIFT but your FIB will blow up and anything changing on a > leaf shakes all other leafs (unless you start to run pollicies to control > distribution @ which point in time you start to baby-sit your fabric @ high > OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast > (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you > will observe that RIFT can do anycast without need for ECMP, i.e. true > anycast in a sense and with that having anycast SID serves no real purpose > in RIFT and is actually generally much harder to do since you need globally > unique label blocks and so on ... > > 2. Horizontal links on CLOSes are not used that way normally all I saw > since your blocking goes to hell unless you provision some kind of really > massive parallel links between ToRs _and_ understand your load. We _could_ > build RIFT that way but you give up balancing through the fabric and > loop-free property in a sense (that's a longish discussion and scaling > since now you have prefixes showing up all kind of crazy places instead of > default). I see enough demand, we get there ... Otherwise RFC1925 clause > 10 and 5. > > 3. PS1: Yes, lots of things "could" be done and then we "could" build a > protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal > links, unless provisioned correctly will pretty much just ruin your > blocking/loss on the fabric is the experience (which the math supports). In > a sense if you know your big flows you can build a specialized topology to > do the optimal distribution (MPLS tunnels anyone ;-) but the point of > fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily > scalable). Otherwise a good analogy would be that you like to build special > RAM chips for the type of data structures you are storing and we know how > well that scales over time. We know now that within 3-4 years > characteristics of DC flows flip upside down without a sweat when people go > from server/client to microservices, from servers to containers and so on > and so on. So if you can't predict your load all the time you need a > _regular_ topology where _regular_ is more of a mathematical than a > protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and > just stick them in" applies here. So RIFT is done largely to serve a > well-known structure called a "lattice" (with some restrictions) since we > need an "up" and "down". Things like hypercubes, thoroidal meshes and so on > and so on exist but CLOS won for a very good reason in history for that > kind of problems (once you move to NUMA other things win ;-) And if you > know your loads and your can heft the OPEX and you like to play with > protocols generally and if you can support the scale in terms of leaf FIB > sizes, flooding, slower convergence & so on & so on and you run flat IGP on > some kind of stuff that you build that doesn't even have to be regular in > any sense. We spent many years solving THAT problem obviously and doing > something like RIFT to replace normal IGP is of limited interest IMO > (albeit certain aspects having to do with modern implemenation techniques > may get us there one day but it's much less of pressing problem than > solving specialized DC routing well IMO again). > > 3. PS2: RIFT cannot build an "unsupported topology" no matter how you > cable (that's the point of it) or rather we have miscabling detection and > do not form adjacencies when you read the draft carefully. That's your > "flash red light" and it comes included for free with my compliments ;-) > ... Otherwise RFC1925 clause 10. > > Otherwise, if you have concrete charter points you'd like to add, be more > specific in your asks and we see what the list thinks after ... > > thanks > > --- tony > > > On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: > >> Hi, >> >> I have one little question/doubt on scalability point of RIFT ... >> >> Assume that someone would like to signal IPv6 prefix SID for Segment >> Routing in the underlay within RIFT. >> >> Wouldn't it result in amount of protocol state in full analogy to massive >> deaggregation - which as of today is designed to be very careful and >> limited operation only at moments of failure(s) ? >> >> I sort of find it a bit surprising that RIFT draft does not provide >> encoding for SID distribution when it is positioned as an alternative to >> other protocols (IGPs or BGP) which already provide ability to carry all >> types of SIDs. >> >> Cheers, >> Robert. >> >> PS1: Horizontal links which were discussed could be installed to offload >> from fabric transit massive amount of data (ex: storage mirroring) directly >> between leafs or L3 TORs and not to be treated as "backup". >> >> PS2: Restricting any protocol to specific topologies seems like pretty >> slippery slope to me. In any case if protocol does that it should also >> contain self detection mechanism of "unsupported topology" and flash red >> light in any NOC. >> >> >> >> _______________________________________________ >> Dcrouting mailing list >> Dcrouting@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrouting >> >> > --f403045e97f844a0bc056284ac2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,

Thx for elaborating ...

=
Two small comments:

A) SID/SR use case in underlay could be as simple as gracefully taking a = fabric node out of service. Not much OPEX needed if your NMS is decent. Oth= erwise in normal link state I can do overload bit, in BGP number of solutio= ns from shutdown to MED to LP ... depending what is your BGP design. In RIF= T how do you do that ? Note that overlay (if such exist) does not help here= .=C2=A0

B) For horizon= tal links imagine you have servers with 40 GB ports to TOR. Then you have N= x100 GB from TOR up. You are going to oversubscribe on TOR (servers to fabr= ic) most likely 2:1 .. 3:1 etc. So if I want to interconnect TORs because I= do know that servers behind those TORs need to talk to each other in a non= blocking fashion _and_ I have spare 100 GB ports on TORs having routing pr= otocol which does not allow me to do that seems pretty limited - wouldn'= ;t you agree ?=C2=A0

T= hx,
R.







On Thu, Jan 11, 2018 at 6:= 40 PM, Tony Przygienda <tonysietf@gmail.com> wrote:
Robert, product= ive points, thanks for raising them ... I go a bit in depth
<= br>
1. I saw no _real_ use-cases for SID in DC so far to be frank= (once you run RIFT). The only one that comes up regularly is egress engine= ering and that IMO is equivalent to SID=3Dleaf address (which could be a HV= address of course once you have RIFT all way down to server) so really, wh= at's the point to have a SID? It's probably much smarter to use IBG= P & so on overlay to do this kind of synchronization if needed since la= bels/SIDs become very useful in overlay to distinguish lots stuff there lik= e VPNs/services which you'd carry e.g. in MPLSoUDP. In underlay just us= e the destination v4/v6 address. Having said that, discussion always to be = had if you pay me dinner ;--) and I know _how_ we can do SIDs in RIFT since= I thought it through but again, no _real_ use case so far. And if your onl= y concern is to "shape towards a prefix" we have PGP in the draft= which doesn't need new silicon ;-P And then ultimately, yes, if you re= ally, really want a SID per prefix everywhere then you'll carry=C2=A0 S= IDs to everywhere since unicast SIDs are really just a glorified way to say= "I have this non-aggreagable 20 bit IP host address" which archi= tecturally is a very interesting proposition in terms of scaling (but then = again, no account for taste and RFC1925 clause 3 applies) ...=C2=A0 Your LS= DB will be still much smaller, your SPF will be still simple on leaf in RIF= T but your FIB will blow up and anything changing on a leaf shakes all othe= r leafs (unless you start to run pollicies to control distribution @ which = point in time you start to baby-sit your fabric @ high OPEX). One of the re= asons to do per-prefix SID would be non-ECMP anycast (where SIDs _are_ in f= act usefull) but if you read RIFT draft carefully you will observe that RIF= T can do anycast without need for ECMP, i.e. true anycast in a sense and wi= th that having anycast SID serves no real purpose in RIFT and is actually g= enerally much harder to do since you need globally unique label blocks and = so on ...=C2=A0

2. Horizontal links on CLOSes are not used th= at way normally all I saw since your blocking goes to hell unless you provi= sion some kind of really massive parallel links between ToRs _and_ understa= nd your load. We _could_ build RIFT that way but you give up balancing thro= ugh the fabric and loop-free property in a sense (that's a longish disc= ussion=C2=A0 and scaling since now you have prefixes showing up all kind of= crazy places instead of default). I see enough demand, we get there ...=C2= =A0 Otherwise RFC1925 clause 10 and 5.=C2=A0

3. P= S1: Yes, lots of things "could" be done and then we "could&q= uot; build a protocol to do that and RFC1925 clause 7 and 8 applies. Such h= orizontal links, unless provisioned correctly will pretty much just ruin yo= ur blocking/loss on the fabric is the experience (which the math supports).= In a sense if you know your big flows you can build a specialized topology= to do the optimal distribution (MPLS tunnels anyone ;-) but the point of f= abric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and eas= ily scalable). Otherwise a good analogy would be that you like to build spe= cial RAM chips for the type of data structures you are storing and we know = how well that scales over time. We know now that within 3-4 years character= istics of DC flows flip upside down without a sweat when people go from ser= ver/client to microservices, from servers to containers and so on and so on= . So if you can't predict your load all the time you need a _regular_ t= opology where _regular_ is more of a mathematical than a protocol discussio= n. Fabric analogy of "buy more RAM chips in Fry's and just stick t= hem in" applies here. So RIFT is done largely to serve a well-known st= ructure called a "lattice" (with some restrictions) since we need= an "up" and "down". Things like hypercubes, thoroidal = meshes and so on and so on exist but CLOS won for a very good reason in his= tory for that kind of problems (once you move to NUMA other things win ;-) = And if you know your loads and your can heft the OPEX and you like to play = with protocols generally and if you can support the scale in terms of leaf = FIB sizes, flooding, slower convergence & so on & so on and you run= flat IGP on some kind of stuff that you build that doesn't even have t= o be regular in any sense. We spent many years solving THAT problem obvious= ly and doing something like RIFT to replace normal IGP is of limited intere= st IMO (albeit certain aspects having to do with modern implemenation techn= iques may get us there one day but it's much less of pressing problem t= han solving specialized DC routing well IMO again).

3. PS2: RIFT cannot build an "unsupported topology" no matter h= ow you cable (that's the point of it) or rather we have miscabling dete= ction and do not form adjacencies when you read the draft carefully. That&#= 39;s your "flash red light" and it comes included for free with m= y compliments=C2=A0 ;-) ... Otherwise RFC1925 clause 10.

Othe= rwise, if you have concrete charter points you'd like to add, be more s= pecific in your asks and we see what the list thinks after ...
thanks

--- tony

On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk <robert@raszu= k.net> wrote:
<= div>
Hi,

I have one little question/doubt= on scalability point of RIFT ...=C2=A0

Assume that someone would like= to signal IPv6 prefix SID for Segment Routing in the underlay within RIFT.= =C2=A0

Wouldn't it result in amount of protocol state in full anal= ogy to massive deaggregation - which as of today is designed to be very car= eful and limited operation only at moments of failure(s) ?=C2=A0

=
I sor= t of find it a bit surprising that RIFT draft does not provide encoding for= SID distribution when it is positioned as an alternative to other protocol= s (IGPs or BGP) which already provide ability to carry all types of SIDs.= =C2=A0

Cheers,
Robert.

PS1: Horizontal links which were discus= sed could be installed to offload from fabric transit massive amount of dat= a (ex: storage mirroring) directly between leafs or L3 TORs and not to be t= reated as "backup".=C2=A0

PS2: Restricting any protocol to s= pecific topologies seems like pretty slippery slope to me. In any case if p= rotocol does that it should also contain self detection mechanism of "= unsupported topology" and flash red light in any NOC.=C2=A0

=

<= /div>

_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>



--f403045e97f844a0bc056284ac2a-- From nobody Thu Jan 11 13:20:12 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640F512DA47; Thu, 11 Jan 2018 13:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aDSWk7t2ahDJ; Thu, 11 Jan 2018 13:20:03 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 B2A6512EBEC; Thu, 11 Jan 2018 13:20:02 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id g75so8292981wme.0; Thu, 11 Jan 2018 13:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DQBG+dtO/SbWFKgey3PkCMYKx5eGzyyZTMSJYOrWMfM=; b=D1rlsc1hihilQE9BbfXvbsmZYe1oP+4sMkp2sn2plO6TUZnWDFZf7wt35GCbHUljyH CS+un3v+TcpgJep+Qsa0/uhzBuGQ5udaDvkQU/uN+oqPznJaaHZRMCW7rcmyPStnbQOF bAytvpDxImGs57nwBCl3Gnw6wHcpsNmg2aJTF9h7j+k6vAqE+/B6PH7OtCyNDqVx/JEn aCTZL659uRlgw3PxJLRVHP2YG2SwTiUYN/c9sc8tnYeaLcvrrs2JVAektj5kzGJ/YZTf 86BOx5XYQkNutvAAmYOGRo08/vmq8hs1LmCS1mDyGLzELzaikNkKRwCil2906iff4Ys1 +h0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DQBG+dtO/SbWFKgey3PkCMYKx5eGzyyZTMSJYOrWMfM=; b=nSb4RhHLesRidW85iCwfuNipkTJXM17HlHhCVoaCfkfKZ637xQ19jODk6SiuchVY33 6K/vaxvvmJLYI2Z8Qg6y5sRbvXJXqWg6YlfzT87a18o7dsNe8O1PDFv0p+NshWEy1Hfn UpKYOJXPlgRIcTXysfMn8Ee5DauuRHXUqx3t0Jd6xStbhAhTLH1tiKcToqk3dsupIY/r lUDJ9bWD7fUYwaK96zaJkSkcVHnpvQ4spqjFbMSPAKkdqCD1hLck0lpQjqczdlUcU7MM YLLQJ8ZPKEx+DDoHuzfjlAQwE2DBYyJnJfqdIO56na2kQrxQBO2CQtqvOQspJmZSuvjb lTOg== X-Gm-Message-State: AKGB3mLulbLZbBjDNq3xM3v7NKCLfbeboAauFL+OeD/XmClY+GqVKRJ0 RPdgBrvoueqlbjLE+j+bRu8uu7vP8rp+gT8IDnA= X-Google-Smtp-Source: ACJfBotzQdfSmgV6vxmSUH/XtR6ztc3QHiUuWfBZm0vAAPsLuvIaa8g+PrELdcO7WMpaMJmK2kUQefyTTPGhDuCkLvY= X-Received: by 10.80.205.203 with SMTP id h11mr32269245edj.159.1515705601209; Thu, 11 Jan 2018 13:20:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 13:19:20 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 11 Jan 2018 13:19:20 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045dc2e0f1b7d0056286b55a" Archived-At: Subject: Re: [Dcrouting] draft-przygienda-rift-03 X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 21:20:06 -0000 --f403045dc2e0f1b7d0056286b55a Content-Type: text/plain; charset="UTF-8" A. Reading the draft you'll find the overload bit on RIFT which IMO is the best out-of-production solution. B. Depends what your LEAF is. If LEAF is your TOR (most stuff today) then RIFT will do that just fine using LEAF2LEAF procedures in fact. If we start to run RIFT @ the server level then we'd need discuss but people do not do horizontal links in non-leaf-to-non-leaf as far I saw (except protection here and there) but then again, they mostly don't extend the fabric routing protocol into the server (which RIFT intends to do). So, for today you're good. Once you want RIFT on server I think having spine horizontals is not a good idea in general I hope that computes and I'd encourage you to read the draft again, maybe without the "it should work just like BGP or just like today's IGP" hat on ... ;-) Of course, paying me fancy dinners and asking questions, letting me ramble then is a valid substitute ;-) --- tony On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk wrote: > Hi Tony, > > Thx for elaborating ... > > Two small comments: > > A) SID/SR use case in underlay could be as simple as gracefully taking a > fabric node out of service. Not much OPEX needed if your NMS is decent. > Otherwise in normal link state I can do overload bit, in BGP number of > solutions from shutdown to MED to LP ... depending what is your BGP design. > In RIFT how do you do that ? Note that overlay (if such exist) does not > help here. > > B) For horizontal links imagine you have servers with 40 GB ports to TOR. > Then you have Nx100 GB from TOR up. You are going to oversubscribe on TOR > (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to > interconnect TORs because I do know that servers behind those TORs need to > talk to each other in a non blocking fashion _and_ I have spare 100 GB > ports on TORs having routing protocol which does not allow me to do that > seems pretty limited - wouldn't you agree ? > > Thx, > R. > > > > > > > > On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda > wrote: > >> Robert, productive points, thanks for raising them ... I go a bit in depth >> >> 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you >> run RIFT). The only one that comes up regularly is egress engineering and >> that IMO is equivalent to SID=leaf address (which could be a HV address of >> course once you have RIFT all way down to server) so really, what's the >> point to have a SID? It's probably much smarter to use IBGP & so on overlay >> to do this kind of synchronization if needed since labels/SIDs become very >> useful in overlay to distinguish lots stuff there like VPNs/services which >> you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 >> address. Having said that, discussion always to be had if you pay me dinner >> ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but >> again, no _real_ use case so far. And if your only concern is to "shape >> towards a prefix" we have PGP in the draft which doesn't need new silicon >> ;-P And then ultimately, yes, if you really, really want a SID per prefix >> everywhere then you'll carry SIDs to everywhere since unicast SIDs are >> really just a glorified way to say "I have this non-aggreagable 20 bit IP >> host address" which architecturally is a very interesting proposition in >> terms of scaling (but then again, no account for taste and RFC1925 clause 3 >> applies) ... Your LSDB will be still much smaller, your SPF will be still >> simple on leaf in RIFT but your FIB will blow up and anything changing on a >> leaf shakes all other leafs (unless you start to run pollicies to control >> distribution @ which point in time you start to baby-sit your fabric @ high >> OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast >> (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you >> will observe that RIFT can do anycast without need for ECMP, i.e. true >> anycast in a sense and with that having anycast SID serves no real purpose >> in RIFT and is actually generally much harder to do since you need globally >> unique label blocks and so on ... >> >> 2. Horizontal links on CLOSes are not used that way normally all I saw >> since your blocking goes to hell unless you provision some kind of really >> massive parallel links between ToRs _and_ understand your load. We _could_ >> build RIFT that way but you give up balancing through the fabric and >> loop-free property in a sense (that's a longish discussion and scaling >> since now you have prefixes showing up all kind of crazy places instead of >> default). I see enough demand, we get there ... Otherwise RFC1925 clause >> 10 and 5. >> >> 3. PS1: Yes, lots of things "could" be done and then we "could" build a >> protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal >> links, unless provisioned correctly will pretty much just ruin your >> blocking/loss on the fabric is the experience (which the math supports). In >> a sense if you know your big flows you can build a specialized topology to >> do the optimal distribution (MPLS tunnels anyone ;-) but the point of >> fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily >> scalable). Otherwise a good analogy would be that you like to build special >> RAM chips for the type of data structures you are storing and we know how >> well that scales over time. We know now that within 3-4 years >> characteristics of DC flows flip upside down without a sweat when people go >> from server/client to microservices, from servers to containers and so on >> and so on. So if you can't predict your load all the time you need a >> _regular_ topology where _regular_ is more of a mathematical than a >> protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and >> just stick them in" applies here. So RIFT is done largely to serve a >> well-known structure called a "lattice" (with some restrictions) since we >> need an "up" and "down". Things like hypercubes, thoroidal meshes and so on >> and so on exist but CLOS won for a very good reason in history for that >> kind of problems (once you move to NUMA other things win ;-) And if you >> know your loads and your can heft the OPEX and you like to play with >> protocols generally and if you can support the scale in terms of leaf FIB >> sizes, flooding, slower convergence & so on & so on and you run flat IGP on >> some kind of stuff that you build that doesn't even have to be regular in >> any sense. We spent many years solving THAT problem obviously and doing >> something like RIFT to replace normal IGP is of limited interest IMO >> (albeit certain aspects having to do with modern implemenation techniques >> may get us there one day but it's much less of pressing problem than >> solving specialized DC routing well IMO again). >> >> 3. PS2: RIFT cannot build an "unsupported topology" no matter how you >> cable (that's the point of it) or rather we have miscabling detection and >> do not form adjacencies when you read the draft carefully. That's your >> "flash red light" and it comes included for free with my compliments ;-) >> ... Otherwise RFC1925 clause 10. >> >> Otherwise, if you have concrete charter points you'd like to add, be more >> specific in your asks and we see what the list thinks after ... >> >> thanks >> >> --- tony >> >> >> On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: >> >>> Hi, >>> >>> I have one little question/doubt on scalability point of RIFT ... >>> >>> Assume that someone would like to signal IPv6 prefix SID for Segment >>> Routing in the underlay within RIFT. >>> >>> Wouldn't it result in amount of protocol state in full analogy to >>> massive deaggregation - which as of today is designed to be very careful >>> and limited operation only at moments of failure(s) ? >>> >>> I sort of find it a bit surprising that RIFT draft does not provide >>> encoding for SID distribution when it is positioned as an alternative to >>> other protocols (IGPs or BGP) which already provide ability to carry all >>> types of SIDs. >>> >>> Cheers, >>> Robert. >>> >>> PS1: Horizontal links which were discussed could be installed to offload >>> from fabric transit massive amount of data (ex: storage mirroring) directly >>> between leafs or L3 TORs and not to be treated as "backup". >>> >>> PS2: Restricting any protocol to specific topologies seems like pretty >>> slippery slope to me. In any case if protocol does that it should also >>> contain self detection mechanism of "unsupported topology" and flash red >>> light in any NOC. >>> >>> >>> >>> _______________________________________________ >>> Dcrouting mailing list >>> Dcrouting@ietf.org >>> https://www.ietf.org/mailman/listinfo/dcrouting >>> >>> >> > --f403045dc2e0f1b7d0056286b55a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A. Reading the draft you'll find the overloa= d bit on RIFT which IMO is the best out-of-production solution.
B.= Depends what your LEAF is. If LEAF is your TOR (most stuff today) then RIF= T will do that just fine using LEAF2LEAF procedures in fact. If we start to= run RIFT @ the server level then we'd need discuss but people do not d= o horizontal links in non-leaf-to-non-leaf as far I saw (except protection = here and there) but then again, they mostly don't extend the fabric rou= ting protocol into the server (which RIFT intends to do). So, for today you= 're good. Once you want RIFT on server I think having spine horizontals= is not a good idea in general

I hope that co= mputes and I'd encourage you to read the draft again, maybe without the= "it should work just like BGP or just like today's IGP" hat = on ...=C2=A0 ;-)=C2=A0 Of course, paying me fancy dinners and asking questi= ons, letting me ramble then is a valid substitute ;-)

--- tony

On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk <= ;robert@raszuk.net> wrote:
Hi Tony,

Thx for elaborating ...

Two small comments:

A) SID/SR use case= in underlay could be as simple as gracefully taking a fabric node out of s= ervice. Not much OPEX needed if your NMS is decent. Otherwise in normal lin= k state I can do overload bit, in BGP number of solutions from shutdown to = MED to LP ... depending what is your BGP design. In RIFT how do you do that= ? Note that overlay (if such exist) does not help here.=C2=A0

B) For horizontal links imagine yo= u have servers with 40 GB ports to TOR. Then you have Nx100 GB from TOR up.= You are going to oversubscribe on TOR (servers to fabric) most likely 2:1 = .. 3:1 etc. So if I want to interconnect TORs because I do know that server= s behind those TORs need to talk to each other in a non blocking fashion _a= nd_ I have spare 100 GB ports on TORs having routing protocol which does no= t allow me to do that seems pretty limited - wouldn't you agree ?=C2=A0=

Thx,
R.


=





On Th= u, Jan 11, 2018 at 6:40 PM, Tony Przygienda <tonysietf@gmail.com&g= t; wrote:
Robert, productive points, thanks for raising them ... I go a bit i= n depth

1. I saw no _real_ use-cases for SID i= n DC so far to be frank (once you run RIFT). The only one that comes up reg= ularly is egress engineering and that IMO is equivalent to SID=3Dleaf addre= ss (which could be a HV address of course once you have RIFT all way down t= o server) so really, what's the point to have a SID? It's probably = much smarter to use IBGP & so on overlay to do this kind of synchroniza= tion if needed since labels/SIDs become very useful in overlay to distingui= sh lots stuff there like VPNs/services which you'd carry e.g. in MPLSoU= DP. In underlay just use the destination v4/v6 address. Having said that, d= iscussion always to be had if you pay me dinner ;--) and I know _how_ we ca= n do SIDs in RIFT since I thought it through but again, no _real_ use case = so far. And if your only concern is to "shape towards a prefix" w= e have PGP in the draft which doesn't need new silicon ;-P And then ult= imately, yes, if you really, really want a SID per prefix everywhere then y= ou'll carry=C2=A0 SIDs to everywhere since unicast SIDs are really just= a glorified way to say "I have this non-aggreagable 20 bit IP host ad= dress" which architecturally is a very interesting proposition in term= s of scaling (but then again, no account for taste and RFC1925 clause 3 app= lies) ...=C2=A0 Your LSDB will be still much smaller, your SPF will be stil= l simple on leaf in RIFT but your FIB will blow up and anything changing on= a leaf shakes all other leafs (unless you start to run pollicies to contro= l distribution @ which point in time you start to baby-sit your fabric @ hi= gh OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast= (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully yo= u will observe that RIFT can do anycast without need for ECMP, i.e. true an= ycast in a sense and with that having anycast SID serves no real purpose in= RIFT and is actually generally much harder to do since you need globally u= nique label blocks and so on ...=C2=A0

2. Horizontal links on= CLOSes are not used that way normally all I saw since your blocking goes t= o hell unless you provision some kind of really massive parallel links betw= een ToRs _and_ understand your load. We _could_ build RIFT that way but you= give up balancing through the fabric and loop-free property in a sense (th= at's a longish discussion=C2=A0 and scaling since now you have prefixes= showing up all kind of crazy places instead of default). I see enough dema= nd, we get there ...=C2=A0 Otherwise RFC1925 clause 10 and 5.=C2=A0
<= div>
3. PS1: Yes, lots of things "could" be done an= d then we "could" build a protocol to do that and RFC1925 clause = 7 and 8 applies. Such horizontal links, unless provisioned correctly will p= retty much just ruin your blocking/loss on the fabric is the experience (wh= ich the math supports). In a sense if you know your big flows you can build= a specialized topology to do the optimal distribution (MPLS tunnels anyone= ;-) but the point of fabric is that it's a fabric (i.e. load agnostic,= cheap, no OPEX and easily scalable). Otherwise a good analogy would be tha= t you like to build special RAM chips for the type of data structures you a= re storing and we know how well that scales over time. We know now that wit= hin 3-4 years characteristics of DC flows flip upside down without a sweat = when people go from server/client to microservices, from servers to contain= ers and so on and so on. So if you can't predict your load all the time= you need a _regular_ topology where _regular_ is more of a mathematical th= an a protocol discussion. Fabric analogy of "buy more RAM chips in Fry= 's and just stick them in" applies here. So RIFT is done largely t= o serve a well-known structure called a "lattice" (with some rest= rictions) since we need an "up" and "down". Things like= hypercubes, thoroidal meshes and so on and so on exist but CLOS won for a = very good reason in history for that kind of problems (once you move to NUM= A other things win ;-) And if you know your loads and your can heft the OPE= X and you like to play with protocols generally and if you can support the = scale in terms of leaf FIB sizes, flooding, slower convergence & so on = & so on and you run flat IGP on some kind of stuff that you build that = doesn't even have to be regular in any sense. We spent many years solvi= ng THAT problem obviously and doing something like RIFT to replace normal I= GP is of limited interest IMO (albeit certain aspects having to do with mod= ern implemenation techniques may get us there one day but it's much les= s of pressing problem than solving specialized DC routing well IMO again). =

3. PS2: RIFT cannot build an "unsupported top= ology" no matter how you cable (that's the point of it) or rather = we have miscabling detection and do not form adjacencies when you read the = draft carefully. That's your "flash red light" and it comes i= ncluded for free with my compliments=C2=A0 ;-) ... Otherwise RFC1925 clause= 10.

Otherwise, if you have concrete charter points you'd= like to add, be more specific in your asks and we see what the list thinks= after ...

thanks

---= tony


On Thu, Jan 11, = 2018 at 1:30 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little question/doubt on scal= ability point of RIFT ...=C2=A0

Assume that someone would like to sign= al IPv6 prefix SID for Segment Routing in the underlay within RIFT.=C2=A0
<= br>
Wouldn't it result in amount of protocol state in full analogy to m= assive deaggregation - which as of today is designed to be very careful and= limited operation only at moments of failure(s) ?=C2=A0

I sort of fin= d it a bit surprising that RIFT draft does not provide encoding for SID dis= tribution when it is positioned as an alternative to other protocols (IGPs = or BGP) which already provide ability to carry all types of SIDs.=C2=A0
Cheers,
Robert.

PS1: Horizontal links which were discussed could = be installed to offload from fabric transit massive amount of data (ex: sto= rage mirroring) directly between leafs or L3 TORs and not to be treated as = "backup".=C2=A0

PS2: Restricting any protocol to specific to= pologies seems like pretty slippery slope to me. In any case if protocol do= es that it should also contain self detection mechanism of "unsupporte= d topology" and flash red light in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>




--f403045dc2e0f1b7d0056286b55a-- From nobody Thu Jan 11 14:24:03 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0B712E03C; Thu, 11 Jan 2018 14:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4yLoD9119feS; Thu, 11 Jan 2018 14:23:55 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 D177F12D87D; Thu, 11 Jan 2018 14:23:54 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id b141so8557859wme.1; Thu, 11 Jan 2018 14:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ewaw4bpqvf595bIP+ZoHK9BBdTwyxgGdIq3hywK3TNQ=; b=VGtaKbyisKwE8yd6Aj9wxlTWNA/havSM+XlKhAq/+gWmEBKaGzXNyDSvymO1IBgASX InTzfLXP0vS0E2Nm5Xqd5hzqhSYHwjMqmuH+XtjSimBeDl8wYxq3QLZrl3u1OB8MQiXK xniNoDh7LqYfd4RKWb/6kzbOX1rlZlmohNdyUgq7AqrTpfRdjhTyMnhSMJOPiN/TCb4p y1ebZIP4T8kQdMXQE3mdD1Bj+R7ugZKPJg+wwO1UQbniVnQWz1X3QRmei9RIwYYliWr/ NTjRfCv8g2pVk2oGGMJgnjjH1NR6ed5PXOD7Ufi0SLgGMljYmtUC2aVJDNV6Z4+8wmTw znuA== 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=ewaw4bpqvf595bIP+ZoHK9BBdTwyxgGdIq3hywK3TNQ=; b=fHrHn+e0RUJ9hkGrbPhX9GWKqTpWF2jddo67nPs/7xG38k/5fT4qXFkxdQpw+FQ0Vq MzjwedPwM+XXiqCTU0YeLtcGt8qUbeMAsfLrd6tU8C874TvSk1Jf5u6VryTARYF44bmA zgraSMHph1REJgvvmNVtXXVLc2U0oiP/G63x61oFsCjvr2H2RofwwNUkZJRyLMgpuRHf f7CvJn05ycMPsHEN3pUCJA6ZyGcsPPfddIJznYfECHkfat1fC+CKgMgMdrvV/wDodHps +n3DACwr3rrj+0xdObxa0j8kxKVxSaITxsnJ1LV8T3eY3n9q5cOhFDxCwdMhjf1VGyAF QuYA== X-Gm-Message-State: AKGB3mLGuZRIUzpDE0sfwDkKDcKljdf3ka339IeKXNFqcrBfIFhaJLSJ 8SMdXqjNZ/M6o4Ntxx9NwBM4Bl0Q9onppE27hNoE5TMa X-Google-Smtp-Source: ACJfBovXLIWYEtrtZFHaO5wDGC9RQYVziaZO+R5olK5tXUau0BhQ9dkQ1+belTayQNTDXYbWV8USUVDt8eRvrlC2YS4= X-Received: by 10.80.206.67 with SMTP id k3mr33495447edj.153.1515709433324; Thu, 11 Jan 2018 14:23:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 14:23:12 -0800 (PST) From: Tony Przygienda Date: Thu, 11 Jan 2018 14:23:12 -0800 Message-ID: To: rift@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045dbf005b28090562879a68" Archived-At: Subject: [Dcrouting] FYI: New version of RIFT published (-04) X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 22:23:57 -0000 --f403045dbf005b28090562879a68 Content-Type: text/plain; charset="UTF-8" A new version of https://datatracker.ietf.org/doc/draft-przygienda-rift/ has been published. The update incorporates a full ZTP solution which can be optionally applied on a node-by-node basis or on a whole IP fabric. Comments obviously welcome thanks --- tony --f403045dbf005b28090562879a68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The upda= te incorporates a full ZTP solution which can be optionally applied on a no= de-by-node basis or on a whole IP fabric.

Com= ments obviously welcome

thanks

--- tony=


--f403045dbf005b28090562879a68-- From nobody Sat Jan 13 10:17:40 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AF012D946; Sat, 13 Jan 2018 10:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 L4pFTk_zgke9; Sat, 13 Jan 2018 10:17:31 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 B43C312D944; Sat, 13 Jan 2018 10:17:30 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id 141so17378599wme.3; Sat, 13 Jan 2018 10:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KEI6utxYxohvgPc2yEgIZxMMdheZ0eskVDfyStQqha0=; b=Sk8NH1HfG0PY0gyzDlj9w1Ij2nKT+98SXG0NPhOkXshs+aWwY58gVqOKPvQPTSWZCW ccfu1eLX44WV+QHreRnXJNINWWF4jQR7PYS0JH3JyQgWU7fr0Kig1rg8XJyfNXkJ9R3a et91NjkBNVi322Iq3OrNlOQSWo6qT4l9baKtkNCII6csDaFMItDsirYLZQ+gZiYrrY5x JxdOT/17AFlIcrrAy0MUl2V0IsiL10IkP+LCvXj7BUnXKxW2j6iR+RXQbX3pPyPI0/3p DeayJrLB+8ZvF14OTJqd5jfNHoK3SQAmV3BEoRlnN378xQfHYll+xyzXdST6USKxEBX3 zwrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KEI6utxYxohvgPc2yEgIZxMMdheZ0eskVDfyStQqha0=; b=OZWssFTHkupDt5YmMS64e/d5XrERTfAASSrZYZiGZtUvV+eJGv+HtQ+L7SBjGV8XSi +K2H4ymA45qnUmdGjc177ac7tM04ICRwd/VTPdul2kjNV1SeDYGPOpjcsjIiyGQAdCIc fT9rpyK5UO+3MIVH1RM4hLDdT9ufRwHQ8EEudYlHRz8Ce8Msz9lylsIqvQA4w4b1MQwU ySWNXJPboWwRC0rbcd9P0ohMTm6sRGtn4M5A6jDUXca13bTBaUzsP/yQYxt+0nDGOnmD qknYHHwFMZdM7c9tFUfcvI+MdRHIx/ubH18ktTtKhL301m2Fx3zNughRUyl+H9MiaJI7 E0Kg== X-Gm-Message-State: AKwxytfzAWz+55nDjzSWUzBZxi7Umip6ukUlV3FJm5YiTQ1PMDTPue6g DbOwD8gI+WeEghjJE9op0++SvE7/5lj82J9Vj0s/XXVy X-Google-Smtp-Source: ACJfBotiqIl9QK6CNqU+43tkCk2tmza3axvtrupMxh/Sl6VmZAajWCZM71A5Yj9RFgKEQnaSZQinwyfNAypcyKWIvd4= X-Received: by 10.80.155.90 with SMTP id a26mr3233443edj.290.1515867449013; Sat, 13 Jan 2018 10:17:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Sat, 13 Jan 2018 10:16:48 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Sat, 13 Jan 2018 10:16:48 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1af462d338da0562ac649d" Archived-At: Subject: Re: [Dcrouting] draft-przygienda-rift-03 X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 18:17:35 -0000 --94eb2c1af462d338da0562ac649d Content-Type: text/plain; charset="UTF-8" So I thought over your horizontal link case to shortcut the spine levels for some kind of traffic again and I think the current draft actually covers that if you're willing to provision things correctly yourself via S-PGP. Let me see whether we agree on this picture first: . +--------+ +--------+ . | | | | ^ N . |Spine 21| |Spine 22| | .Level 2 ++-+--+-++ ++-+--+-++ <-*-> E/W . | | | | | | | | | . P111/2| |P121 | | | | S v . ^ ^ ^ ^ | | | | . | | | | | | | | . +--------------+ | +-----------+ | | | +---------------+ . | | | | | | | | . South +-----------------------------+ | | ^ . | | | | | | | All TIEs . 0/0 0/0 0/0 +-----------------------------+ | . v v v | | | | | . | | +-+ +<-0/0----------+ | | . | | | | | | | | .+-+----++ optional +-+----++ ++----+-+ ++-----++ .| | E/W link | +=====+ | | | .|Node111+----------+Node112| |Node121| |Node122| .+-+---+-+ ++----+-+ +-+---+-+ ++---+--+ . | | | South | | | | . | +---0/0--->-----+ 0/0 | +----------------+ | . 0/0 | | | | | | | . | +---<-0/0-----+ | v | +--------------+ | | . v | | | | | | | .+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+ .| | (L2L) | | | | Level 0 | | .|Leaf111~~~~~~~~~~~~Leaf112| |Leaf121| |Leaf122| .+-+-----+ +-+---+-+ +--+--+-+ +-+-----+ . + + \ / + + . Prefix111 Prefix112 \ / Prefix121 Prefix122 . multi-homed . Prefix .+---------- Pod 1 ---------+ +---------- Pod 2 ---------+ I assume here that what you ask for is the following scenario: a) POD1 being a compute generating very heavy load towards storage in Prefix121. b) traffic from POD1 NOT being balanced through the spines but taking a horizontal link Node112 to Node121 to reach your storage in Prefix121 to save bandwidth? or delay? c) The key to riches is -04 section4.2.5.1 . Northbound SPF in the paragraph "Other south prefixes found when crossing E-W link MAY be used IIF". Now, we could make it a MUST (but it's really an implementation knob IMO) and what it says is that if you are willing to inject an "S-PGP" @ Node121 for Prefix121 it will get flooded to Node112 and Node112 will have a more specific match than the default in N-SPF. From 121 normal RIFT takes over since the normal N-Prefix for Leaf121 kicks in on Node121. I assume Node112 policy on the ingress is to not propagate the S-PGP south but use it for N-SPF only. Observe that a) you have to switch off miscabling detection for PoD# on those nodes since you are "crossing PoDs illegally" b) if you want whole Pod#1 to do that you either cable Node111 to Node121 as well (which will load balance whole Pod#1 towards storage without using Spine) OR you propagate S-PGPs south towards leafs (which will cost you leaf FIB of course but make sure ALL traffic to storage goes over Node112 only). c) Your forwarding on Node112 can actually even go haywire & load-balance some of the traffic to Prefix121 using this S-PGP over Node121 and some still using the default route towards spine(which here is a blatant violation of LPM of course) and RIFT will work just fine (unless you loop yourself to death with PGPs you install) but that of course is a deep rathole in itself. I just mention it to show why the "non-looping" design is so important and makes for the shortcomings for the SPF on a fabric, predicted by the non-directional mesh property that Dijkstra solved in his time. so? --- tony On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk wrote: > Hi Tony, > > Thx for elaborating ... > > Two small comments: > > A) SID/SR use case in underlay could be as simple as gracefully taking a > fabric node out of service. Not much OPEX needed if your NMS is decent. > Otherwise in normal link state I can do overload bit, in BGP number of > solutions from shutdown to MED to LP ... depending what is your BGP design. > In RIFT how do you do that ? Note that overlay (if such exist) does not > help here. > > B) For horizontal links imagine you have servers with 40 GB ports to TOR. > Then you have Nx100 GB from TOR up. You are going to oversubscribe on TOR > (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to > interconnect TORs because I do know that servers behind those TORs need to > talk to each other in a non blocking fashion _and_ I have spare 100 GB > ports on TORs having routing protocol which does not allow me to do that > seems pretty limited - wouldn't you agree ? > > Thx, > R. > > > > > > > > On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda > wrote: > >> Robert, productive points, thanks for raising them ... I go a bit in depth >> >> 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you >> run RIFT). The only one that comes up regularly is egress engineering and >> that IMO is equivalent to SID=leaf address (which could be a HV address of >> course once you have RIFT all way down to server) so really, what's the >> point to have a SID? It's probably much smarter to use IBGP & so on overlay >> to do this kind of synchronization if needed since labels/SIDs become very >> useful in overlay to distinguish lots stuff there like VPNs/services which >> you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 >> address. Having said that, discussion always to be had if you pay me dinner >> ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but >> again, no _real_ use case so far. And if your only concern is to "shape >> towards a prefix" we have PGP in the draft which doesn't need new silicon >> ;-P And then ultimately, yes, if you really, really want a SID per prefix >> everywhere then you'll carry SIDs to everywhere since unicast SIDs are >> really just a glorified way to say "I have this non-aggreagable 20 bit IP >> host address" which architecturally is a very interesting proposition in >> terms of scaling (but then again, no account for taste and RFC1925 clause 3 >> applies) ... Your LSDB will be still much smaller, your SPF will be still >> simple on leaf in RIFT but your FIB will blow up and anything changing on a >> leaf shakes all other leafs (unless you start to run pollicies to control >> distribution @ which point in time you start to baby-sit your fabric @ high >> OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast >> (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you >> will observe that RIFT can do anycast without need for ECMP, i.e. true >> anycast in a sense and with that having anycast SID serves no real purpose >> in RIFT and is actually generally much harder to do since you need globally >> unique label blocks and so on ... >> >> 2. Horizontal links on CLOSes are not used that way normally all I saw >> since your blocking goes to hell unless you provision some kind of really >> massive parallel links between ToRs _and_ understand your load. We _could_ >> build RIFT that way but you give up balancing through the fabric and >> loop-free property in a sense (that's a longish discussion and scaling >> since now you have prefixes showing up all kind of crazy places instead of >> default). I see enough demand, we get there ... Otherwise RFC1925 clause >> 10 and 5. >> >> 3. PS1: Yes, lots of things "could" be done and then we "could" build a >> protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal >> links, unless provisioned correctly will pretty much just ruin your >> blocking/loss on the fabric is the experience (which the math supports). In >> a sense if you know your big flows you can build a specialized topology to >> do the optimal distribution (MPLS tunnels anyone ;-) but the point of >> fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily >> scalable). Otherwise a good analogy would be that you like to build special >> RAM chips for the type of data structures you are storing and we know how >> well that scales over time. We know now that within 3-4 years >> characteristics of DC flows flip upside down without a sweat when people go >> from server/client to microservices, from servers to containers and so on >> and so on. So if you can't predict your load all the time you need a >> _regular_ topology where _regular_ is more of a mathematical than a >> protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and >> just stick them in" applies here. So RIFT is done largely to serve a >> well-known structure called a "lattice" (with some restrictions) since we >> need an "up" and "down". Things like hypercubes, thoroidal meshes and so on >> and so on exist but CLOS won for a very good reason in history for that >> kind of problems (once you move to NUMA other things win ;-) And if you >> know your loads and your can heft the OPEX and you like to play with >> protocols generally and if you can support the scale in terms of leaf FIB >> sizes, flooding, slower convergence & so on & so on and you run flat IGP on >> some kind of stuff that you build that doesn't even have to be regular in >> any sense. We spent many years solving THAT problem obviously and doing >> something like RIFT to replace normal IGP is of limited interest IMO >> (albeit certain aspects having to do with modern implemenation techniques >> may get us there one day but it's much less of pressing problem than >> solving specialized DC routing well IMO again). >> >> 3. PS2: RIFT cannot build an "unsupported topology" no matter how you >> cable (that's the point of it) or rather we have miscabling detection and >> do not form adjacencies when you read the draft carefully. That's your >> "flash red light" and it comes included for free with my compliments ;-) >> ... Otherwise RFC1925 clause 10. >> >> Otherwise, if you have concrete charter points you'd like to add, be more >> specific in your asks and we see what the list thinks after ... >> >> thanks >> >> --- tony >> >> >> On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: >> >>> Hi, >>> >>> I have one little question/doubt on scalability point of RIFT ... >>> >>> Assume that someone would like to signal IPv6 prefix SID for Segment >>> Routing in the underlay within RIFT. >>> >>> Wouldn't it result in amount of protocol state in full analogy to >>> massive deaggregation - which as of today is designed to be very careful >>> and limited operation only at moments of failure(s) ? >>> >>> I sort of find it a bit surprising that RIFT draft does not provide >>> encoding for SID distribution when it is positioned as an alternative to >>> other protocols (IGPs or BGP) which already provide ability to carry all >>> types of SIDs. >>> >>> Cheers, >>> Robert. >>> >>> PS1: Horizontal links which were discussed could be installed to offload >>> from fabric transit massive amount of data (ex: storage mirroring) directly >>> between leafs or L3 TORs and not to be treated as "backup". >>> >>> PS2: Restricting any protocol to specific topologies seems like pretty >>> slippery slope to me. In any case if protocol does that it should also >>> contain self detection mechanism of "unsupported topology" and flash red >>> light in any NOC. >>> >>> >>> >>> _______________________________________________ >>> Dcrouting mailing list >>> Dcrouting@ietf.org >>> https://www.ietf.org/mailman/listinfo/dcrouting >>> >>> >> > --94eb2c1af462d338da0562ac649d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So I thought over your horizontal link case= to shortcut the spine levels
for some kind of traffic a= gain and I think the current draft actually
covers that = if you're willing to provision things correctly yourself via S-PGP.
Let me see whether we agree on this picture first:

= .=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--------+
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ^ N
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Spine 21|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Spine 22|=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.Level 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ++-+--+-++=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ++-+--+-++=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-*-> E/W=
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 P111/2|=C2=A0 |P121=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 S v
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ ^=C2=A0 ^ ^=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 |= |
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |
.=C2=A0 +------------= --+ |=C2=A0 +-----------+=C2=A0 | |=C2=A0 | +---------------+
.=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
. South +------= -----------------------+ |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^
.=C2=A0 |=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 All TIEs
.=C2=A0 0/0=C2=A0 0/0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0/0=C2=A0=C2=A0 +---------------------= --------+=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0 v=C2=A0=C2=A0=C2=A0 v=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+=C2=A0=C2=A0=C2=A0 += <-0/0----------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0 |
.+-+----++ optional +-+----++=C2=A0=C2=A0= =C2=A0=C2=A0 ++----+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 ++-----++
.|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | E/W link |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=3D=3D=3D=3D=3D+ =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.|Node111+----------+Node112|=C2= =A0=C2=A0=C2=A0=C2=A0 |Node121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |Node122|
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ++----+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++---+--+
.=C2=A0 |= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0 South=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0 +---0/0--->-----+ 0/0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 +----------------+= |
. 0/0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | |
.=C2=A0 |=C2=A0=C2=A0 += ---<-0/0-----+ |=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0 +--------------+ | |
.=C2=A0 v=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | |
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--+--+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +---+-+-+
.|=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 (L2L)=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= Level 0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.|Leaf111~~~~~~~~~~~~Le= af112|=C2=A0=C2=A0=C2=A0=C2=A0 |Leaf121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |Leaf122|
.+-+-----+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0 +--+--+-+=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-----+
.=C2=A0 +=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 /=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +
.=C2=A0 Prefix111=C2=A0=C2=A0 Pre= fix112=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0 Pref= ix121=C2=A0=C2=A0=C2=A0 Prefix122
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multi-homed
.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefi= x
.+---------- Pod 1 ---------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------- Pod = 2 ---------+

I assume here that what you ask for is the fo= llowing scenario:
a) POD1 being a compute generating very hea= vy load towards storage in
=C2=A0=C2=A0 Prefix121.
<= /span>
b) traffic from POD1 NOT being balanced through the spines but tak= ing
=C2=A0=C2=A0 a horizontal link Node112 to Node= 121 to reach your storage in Prefix121
=C2=A0=C2=A0 to s= ave bandwidth? or delay?
<= font size=3D"2">c) The key = to riches is -04 section
4.2.5.1. Northbound SPF

=C2=A0 in the paragraph "Other south prefixes found when crossing E= -W link MAY be used IIF". Now, we could make it a MUST (but it's r= eally an implementation knob IMO) and what it says is that if you are willi= ng to inject an "S-PGP" @ Node121 for Prefix121 it will get flood= ed to Node112 and Node112 will have a more specific match than the default = in N-SPF. From 121 normal RIFT takes over since the normal N-Prefix for Lea= f121 kicks in on Node121. I assume Node112 policy on the ingress is to not = propagate the S-PGP south but use it for N-SPF only.

=


Observe that

a) you have to switch off mis= cabling detection for PoD# on those nodes since you are "crossing PoDs= illegally"

b) if you want whole Pod#1 to do that you either cable Node111 to No= de121 as well (which will load balance whole Pod#1 towards storage without = using Spine)=C2=A0 OR you propagate S-PGPs south towards leafs (which will = cost you leaf FIB of course but make sure ALL traffic to storage goes over = Node112 only).

c) Your forwarding on Node112 can actually even go haywire & load= -balance some of the traffic to Prefix121 using this S-PGP over Node121 and= some still using the default route towards spine(which here is a blatant v= iolation of LPM of course) and RIFT will work just fine (unless you loop yo= urself to death with PGPs you install) but that of course is a deep rathole= in itself. I just mention it to show why the "non-looping" desig= n is so important and makes for the shortcomings for the SPF on a fabric, p= redicted by the non-directional mesh property that Dijkstra solved in his t= ime.

so?<= br>

--- tony <= br>






On Thu, Jan 11, 2018 at 10:= 54 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Tony,
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
Thx for elaborating ...

Two small comments:
A) SID/SR use case in underlay could be as simple= as gracefully taking a fabric node out of service. Not much OPEX needed if= your NMS is decent. Otherwise in normal link state I can do overload bit, = in BGP number of solutions from shutdown to MED to LP ... depending what is= your BGP design. In RIFT how do you do that ? Note that overlay (if such e= xist) does not help here.=C2=A0

B) For horizontal links imagine you have servers with 40 GB ports= to TOR. Then you have Nx100 GB from TOR up. You are going to oversubscribe= on TOR (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to int= erconnect TORs because I do know that servers behind those TORs need to tal= k to each other in a non blocking fashion _and_ I have spare 100 GB ports o= n TORs having routing protocol which does not allow me to do that seems pre= tty limited - wouldn't you agree ?=C2=A0

Thx,
R.





<= br>

On Thu, Jan 11, 2018 at 6:40 PM, Tony= Przygienda <tonysietf@gmail.com> wrote:
Robert, productive points,= thanks for raising them ... I go a bit in depth

1. I saw no _real_ use-cases for SID in DC so far to be frank (once you = run RIFT). The only one that comes up regularly is egress engineering and t= hat IMO is equivalent to SID=3Dleaf address (which could be a HV address of= course once you have RIFT all way down to server) so really, what's th= e point to have a SID? It's probably much smarter to use IBGP & so = on overlay to do this kind of synchronization if needed since labels/SIDs b= ecome very useful in overlay to distinguish lots stuff there like VPNs/serv= ices which you'd carry e.g. in MPLSoUDP. In underlay just use the desti= nation v4/v6 address. Having said that, discussion always to be had if you = pay me dinner ;--) and I know _how_ we can do SIDs in RIFT since I thought = it through but again, no _real_ use case so far. And if your only concern i= s to "shape towards a prefix" we have PGP in the draft which does= n't need new silicon ;-P And then ultimately, yes, if you really, reall= y want a SID per prefix everywhere then you'll carry=C2=A0 SIDs to ever= ywhere since unicast SIDs are really just a glorified way to say "I ha= ve this non-aggreagable 20 bit IP host address" which architecturally = is a very interesting proposition in terms of scaling (but then again, no a= ccount for taste and RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be = still much smaller, your SPF will be still simple on leaf in RIFT but your = FIB will blow up and anything changing on a leaf shakes all other leafs (un= less you start to run pollicies to control distribution @ which point in ti= me you start to baby-sit your fabric @ high OPEX). One of the reasons to do= per-prefix SID would be non-ECMP anycast (where SIDs _are_ in fact usefull= ) but if you read RIFT draft carefully you will observe that RIFT can do an= ycast without need for ECMP, i.e. true anycast in a sense and with that hav= ing anycast SID serves no real purpose in RIFT and is actually generally mu= ch harder to do since you need globally unique label blocks and so on ...= =C2=A0

2. Horizontal links on CLOSes are not used that way no= rmally all I saw since your blocking goes to hell unless you provision some= kind of really massive parallel links between ToRs _and_ understand your l= oad. We _could_ build RIFT that way but you give up balancing through the f= abric and loop-free property in a sense (that's a longish discussion=C2= =A0 and scaling since now you have prefixes showing up all kind of crazy pl= aces instead of default). I see enough demand, we get there ...=C2=A0 Other= wise RFC1925 clause 10 and 5.=C2=A0

3. PS1: Yes, = lots of things "could" be done and then we "could" buil= d a protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal= links, unless provisioned correctly will pretty much just ruin your blocki= ng/loss on the fabric is the experience (which the math supports). In a sen= se if you know your big flows you can build a specialized topology to do th= e optimal distribution (MPLS tunnels anyone ;-) but the point of fabric is = that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily scala= ble). Otherwise a good analogy would be that you like to build special RAM = chips for the type of data structures you are storing and we know how well = that scales over time. We know now that within 3-4 years characteristics of= DC flows flip upside down without a sweat when people go from server/clien= t to microservices, from servers to containers and so on and so on. So if y= ou can't predict your load all the time you need a _regular_ topology w= here _regular_ is more of a mathematical than a protocol discussion. Fabric= analogy of "buy more RAM chips in Fry's and just stick them in&qu= ot; applies here. So RIFT is done largely to serve a well-known structure c= alled a "lattice" (with some restrictions) since we need an "= ;up" and "down". Things like hypercubes, thoroidal meshes an= d so on and so on exist but CLOS won for a very good reason in history for = that kind of problems (once you move to NUMA other things win ;-) And if yo= u know your loads and your can heft the OPEX and you like to play with prot= ocols generally and if you can support the scale in terms of leaf FIB sizes= , flooding, slower convergence & so on & so on and you run flat IGP= on some kind of stuff that you build that doesn't even have to be regu= lar in any sense. We spent many years solving THAT problem obviously and do= ing something like RIFT to replace normal IGP is of limited interest IMO (a= lbeit certain aspects having to do with modern implemenation techniques may= get us there one day but it's much less of pressing problem than solvi= ng specialized DC routing well IMO again).

3. PS2:= RIFT cannot build an "unsupported topology" no matter how you ca= ble (that's the point of it) or rather we have miscabling detection and= do not form adjacencies when you read the draft carefully. That's your= "flash red light" and it comes included for free with my complim= ents=C2=A0 ;-) ... Otherwise RFC1925 clause 10.

Otherwise, if= you have concrete charter points you'd like to add, be more specific i= n your asks and we see what the list thinks after ...

thanks

--- tony

<= div class=3D"gmail_extra">
On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk <= robert@raszuk.net> wrote:
Hi,

=
I have one little question/doubt on scalability point of RIFT ...=C2=A0
Assume that someone would like to signal IPv6 prefix SID for Segment Rou= ting in the underlay within RIFT.=C2=A0

Wouldn't it result in amou= nt of protocol state in full analogy to massive deaggregation - which as of= today is designed to be very careful and limited operation only at moments= of failure(s) ?=C2=A0

I sort of find it a bit surprising that RIFT dr= aft does not provide encoding for SID distribution when it is positioned as= an alternative to other protocols (IGPs or BGP) which already provide abil= ity to carry all types of SIDs.=C2=A0

Cheers,
Robert.

PS1: Hor= izontal links which were discussed could be installed to offload from fabri= c transit massive amount of data (ex: storage mirroring) directly between l= eafs or L3 TORs and not to be treated as "backup".=C2=A0

PS2= : Restricting any protocol to specific topologies seems like pretty slipper= y slope to me. In any case if protocol does that it should also contain sel= f detection mechanism of "unsupported topology" and flash red lig= ht in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>




--94eb2c1af462d338da0562ac649d-- From nobody Sat Jan 13 11:21:48 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394B812DA18; Sat, 13 Jan 2018 11:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BnE0sAhOl5TL; Sat, 13 Jan 2018 11:21:37 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 671CC12D775; Sat, 13 Jan 2018 11:21:37 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id r78so17754724wme.0; Sat, 13 Jan 2018 11:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nDC5tEdZeKOJidfY4+fIen3tufn96hcV08bzyS97DBY=; b=uq7/lVnLKN9THamLL+QuLOXqHYDsQbuZmgE4q8ykpR1lRozFmggV8IzTQDG8PCcImA /aJ7cmwukbtYSxtEOiexfDuZ2Vyi556sG2+5ek4yp+GZqCHEYct/Yl/0rM3p3r2fxriW 1XEluU3FZUKoZQuzXQPfpTUJ4abh9LLs/hb1bINeR8VDY26EGrZKA46X6+7ZT68FIafV WD/E51+1Oiv41pF3X9ZinqqYH8S3eURgTNtmY0Yz0l5Z4jFdgNtGRjMCXGdNtmHrq+qM ZAdRenmZL/iQpfbNPLor0TAoJElIjxA0v/1mNf/Y2idRRA4LLxeOlspXvAbr6eViQEcY nWhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nDC5tEdZeKOJidfY4+fIen3tufn96hcV08bzyS97DBY=; b=EuvYl3OafrsaGw/KHmrXKIiypzqfIcPZOJUdh5CettTVMVN0PNN+/T9mXMlJg/UPiu ZpnOOwhqex4EBV898fFHIwoFDBoJ0jSniwqT0cJ62w35ni5NR0vGi3uMVjE/gXPM4UYm L1hFnQGyGoAFew/GitFZs28jIhvi3YbC8mKvxRtLlt1gWc6y6Pds5s2tOy80c3q7i/1T usAUx5W+mli4AN1vAwG/+b346nbsux+Xo4gGkfs8935YK9yjwssOD4/vzsmoXdGbJeqz I/9lkjLbVAMHh/4LGlRZVSLzbPCtduD/IWzLug34TWC+0Ng6etVJZsfjCZSpTtz/jjVn rptQ== X-Gm-Message-State: AKwxytc1Yd6CbN9nr/T92SEUTNq8RilyaAuFrs+ssDnaWsBqKchO6arV Y0Y/gW0DuF1Sy8QwsBm5Ti9ZPpyESYk3wifWdLe/ubjB X-Google-Smtp-Source: ACJfBovPpqxlmA8Hdn0xevvQ8aPWiVNMs3E4RVDtvAUmIrYUDwuXdxAel2FqRzKp13SlHk1Z/4fSUnIFmbsi8c2Klu4= X-Received: by 10.28.61.68 with SMTP id k65mr6530537wma.147.1515871295478; Sat, 13 Jan 2018 11:21:35 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Sat, 13 Jan 2018 11:21:34 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Sat, 13 Jan 2018 20:21:34 +0100 X-Google-Sender-Auth: 7dHHwjSzFZUKamPXnSNXUpgcBSE Message-ID: To: Tony Przygienda Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="001a114b2d02179ff90562ad4af1" Archived-At: Subject: Re: [Dcrouting] draft-przygienda-rift-03 X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 19:21:41 -0000 --001a114b2d02179ff90562ad4af1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tony, > =E2=80=8B if you're willing to provision things correctly yourself via S-PGP. I am not willing to do that. I would like routing to do it for me auto-magically. But yes you got the question right. I was asking for shortcuts between last levels of fabric. Not so much between Node 111 & Node 112 - but you said it is optional so ok. Side note: PGP abbrev. for vast majority of people means completely different thing then what you defined it to mean locally in your draft. I highly recommended you rename it in -05 version to PGD (policy guided destination(s) or PGR (policy guided reachability/routing). Now requirement to switch off miscabling detection is not acceptable. You are stating that only rift knows how should I cable my fabric ? And if I cable it some other way it will detect it as miscabling ? I think in most cases of correct cables check you actually define the intent then network detects if such intent is met. > Node112 can actually even go haywire That may be not best property of a routing protocol :) Best, R. On Sat, Jan 13, 2018 at 7:16 PM, Tony Przygienda wrote: > So I thought over your horizontal link case to shortcut the spine levels > for some kind of traffic again and I think the current draft actually > covers that > =E2=80=8B=E2=80=8B > if you're willing to provision things correctly yourself via S-PGP. > Let me see whether we agree on this picture first: > > . +--------+ +--------+ > . | | | | ^ N > . |Spine 21| |Spine 22| | > .Level 2 ++-+--+-++ ++-+--+-++ <-*-> E/W > . | | | | | | | | | > . P111/2| |P121 | | | | S v > . ^ ^ ^ ^ | | | | > . | | | | | | | | > . +--------------+ | +-----------+ | | | +---------------+ > . | | | | | | | | > . South +-----------------------------+ | | ^ > . | | | | | | | All TIEs > . 0/0 0/0 0/0 +-----------------------------+ | > . v v v | | | | | > . | | +-+ +<-0/0----------+ | | > . | | | | | | | | > .+-+----++ optional +-+----++ ++----+-+ ++-----++ > .| | E/W link | +=3D=3D=3D=3D=3D+ | | | > .|Node111+----------+Node112| |Node121| |Node122| > .+-+---+-+ ++----+-+ +-+---+-+ ++---+--+ > . | | | South | | | | > . | +---0/0--->-----+ 0/0 | +----------------+ | > . 0/0 | | | | | | | > . | +---<-0/0-----+ | v | +--------------+ | | > . v | | | | | | | > .+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+ > .| | (L2L) | | | | Level 0 | | > .|Leaf111~~~~~~~~~~~~Leaf112| |Leaf121| |Leaf122| > .+-+-----+ +-+---+-+ +--+--+-+ +-+-----+ > . + + \ / + + > . Prefix111 Prefix112 \ / Prefix121 Prefix122 > . multi-homed > . Prefix > .+---------- Pod 1 ---------+ +---------- Pod 2 ---------+ > > I assume here that what you ask for is the following scenario: > a) POD1 being a compute generating very heavy load towards storage in > Prefix121. > b) traffic from POD1 NOT being balanced through the spines but taking > a horizontal link Node112 to Node121 to reach your storage in > Prefix121 > to save bandwidth? or delay? > c) The key to riches is -04 section4.2.5.1 > . > Northbound SPF > > in the paragraph "Other south prefixes found when crossing E-W link MAY > be used IIF". Now, we could make it a MUST (but it's really an > implementation knob IMO) and what it says is that if you are willing to > inject an "S-PGP" @ Node121 for Prefix121 it will get flooded to Node112 > and Node112 will have a more specific match than the default in N-SPF. Fr= om > 121 normal RIFT takes over since the normal N-Prefix for Leaf121 kicks in > on Node121. I assume Node112 policy on the ingress is to not propagate th= e > S-PGP south but use it for N-SPF only. > > > Observe that > > a) you have to switch off miscabling detection for PoD# on those nodes > since you are "crossing PoDs illegally" > > b) if you want whole Pod#1 to do that you either cable Node111 to Node121 > as well (which will load balance whole Pod#1 towards storage without usin= g > Spine) OR you propagate S-PGPs south towards leafs (which will cost you > leaf FIB of course but make sure ALL traffic to storage goes over Node112 > only). > > c) Your forwarding on Node112 can actually even go haywire & load-balance > some of the traffic to Prefix121 using this S-PGP over Node121 and some > still using the default route towards spine(which here is a blatant > violation of LPM of course) and RIFT will work just fine (unless you loop > yourself to death with PGPs you install) but that of course is a deep > rathole in itself. I just mention it to show why the "non-looping" design > is so important and makes for the shortcomings for the SPF on a fabric, > predicted by the non-directional mesh property that Dijkstra solved in hi= s > time. > > so? > > --- tony > > > > > > > On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk wrote= : > >> Hi Tony, >> >> Thx for elaborating ... >> >> Two small comments: >> >> A) SID/SR use case in underlay could be as simple as gracefully taking a >> fabric node out of service. Not much OPEX needed if your NMS is decent. >> Otherwise in normal link state I can do overload bit, in BGP number of >> solutions from shutdown to MED to LP ... depending what is your BGP desi= gn. >> In RIFT how do you do that ? Note that overlay (if such exist) does not >> help here. >> >> B) For horizontal links imagine you have servers with 40 GB ports to TOR= . >> Then you have Nx100 GB from TOR up. You are going to oversubscribe on TO= R >> (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to >> interconnect TORs because I do know that servers behind those TORs need = to >> talk to each other in a non blocking fashion _and_ I have spare 100 GB >> ports on TORs having routing protocol which does not allow me to do that >> seems pretty limited - wouldn't you agree ? >> >> Thx, >> R. >> >> >> >> >> >> >> >> On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda >> wrote: >> >>> Robert, productive points, thanks for raising them ... I go a bit in >>> depth >>> >>> 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you >>> run RIFT). The only one that comes up regularly is egress engineering a= nd >>> that IMO is equivalent to SID=3Dleaf address (which could be a HV addre= ss of >>> course once you have RIFT all way down to server) so really, what's the >>> point to have a SID? It's probably much smarter to use IBGP & so on ove= rlay >>> to do this kind of synchronization if needed since labels/SIDs become v= ery >>> useful in overlay to distinguish lots stuff there like VPNs/services wh= ich >>> you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v= 6 >>> address. Having said that, discussion always to be had if you pay me di= nner >>> ;--) and I know _how_ we can do SIDs in RIFT since I thought it through= but >>> again, no _real_ use case so far. And if your only concern is to "shape >>> towards a prefix" we have PGP in the draft which doesn't need new silic= on >>> ;-P And then ultimately, yes, if you really, really want a SID per pref= ix >>> everywhere then you'll carry SIDs to everywhere since unicast SIDs are >>> really just a glorified way to say "I have this non-aggreagable 20 bit = IP >>> host address" which architecturally is a very interesting proposition i= n >>> terms of scaling (but then again, no account for taste and RFC1925 clau= se 3 >>> applies) ... Your LSDB will be still much smaller, your SPF will be st= ill >>> simple on leaf in RIFT but your FIB will blow up and anything changing = on a >>> leaf shakes all other leafs (unless you start to run pollicies to contr= ol >>> distribution @ which point in time you start to baby-sit your fabric @ = high >>> OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycas= t >>> (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully= you >>> will observe that RIFT can do anycast without need for ECMP, i.e. true >>> anycast in a sense and with that having anycast SID serves no real purp= ose >>> in RIFT and is actually generally much harder to do since you need glob= ally >>> unique label blocks and so on ... >>> >>> 2. Horizontal links on CLOSes are not used that way normally all I saw >>> since your blocking goes to hell unless you provision some kind of real= ly >>> massive parallel links between ToRs _and_ understand your load. We _cou= ld_ >>> build RIFT that way but you give up balancing through the fabric and >>> loop-free property in a sense (that's a longish discussion and scaling >>> since now you have prefixes showing up all kind of crazy places instead= of >>> default). I see enough demand, we get there ... Otherwise RFC1925 clau= se >>> 10 and 5. >>> >>> 3. PS1: Yes, lots of things "could" be done and then we "could" build a >>> protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal >>> links, unless provisioned correctly will pretty much just ruin your >>> blocking/loss on the fabric is the experience (which the math supports)= . In >>> a sense if you know your big flows you can build a specialized topology= to >>> do the optimal distribution (MPLS tunnels anyone ;-) but the point of >>> fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and ea= sily >>> scalable). Otherwise a good analogy would be that you like to build spe= cial >>> RAM chips for the type of data structures you are storing and we know h= ow >>> well that scales over time. We know now that within 3-4 years >>> characteristics of DC flows flip upside down without a sweat when peopl= e go >>> from server/client to microservices, from servers to containers and so = on >>> and so on. So if you can't predict your load all the time you need a >>> _regular_ topology where _regular_ is more of a mathematical than a >>> protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and >>> just stick them in" applies here. So RIFT is done largely to serve a >>> well-known structure called a "lattice" (with some restrictions) since = we >>> need an "up" and "down". Things like hypercubes, thoroidal meshes and s= o on >>> and so on exist but CLOS won for a very good reason in history for that >>> kind of problems (once you move to NUMA other things win ;-) And if you >>> know your loads and your can heft the OPEX and you like to play with >>> protocols generally and if you can support the scale in terms of leaf F= IB >>> sizes, flooding, slower convergence & so on & so on and you run flat IG= P on >>> some kind of stuff that you build that doesn't even have to be regular = in >>> any sense. We spent many years solving THAT problem obviously and doing >>> something like RIFT to replace normal IGP is of limited interest IMO >>> (albeit certain aspects having to do with modern implemenation techniqu= es >>> may get us there one day but it's much less of pressing problem than >>> solving specialized DC routing well IMO again). >>> >>> 3. PS2: RIFT cannot build an "unsupported topology" no matter how you >>> cable (that's the point of it) or rather we have miscabling detection a= nd >>> do not form adjacencies when you read the draft carefully. That's your >>> "flash red light" and it comes included for free with my compliments ;= -) >>> ... Otherwise RFC1925 clause 10. >>> >>> Otherwise, if you have concrete charter points you'd like to add, be >>> more specific in your asks and we see what the list thinks after ... >>> >>> thanks >>> >>> --- tony >>> >>> >>> On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk >>> wrote: >>> >>>> Hi, >>>> >>>> I have one little question/doubt on scalability point of RIFT ... >>>> >>>> Assume that someone would like to signal IPv6 prefix SID for Segment >>>> Routing in the underlay within RIFT. >>>> >>>> Wouldn't it result in amount of protocol state in full analogy to >>>> massive deaggregation - which as of today is designed to be very caref= ul >>>> and limited operation only at moments of failure(s) ? >>>> >>>> I sort of find it a bit surprising that RIFT draft does not provide >>>> encoding for SID distribution when it is positioned as an alternative = to >>>> other protocols (IGPs or BGP) which already provide ability to carry a= ll >>>> types of SIDs. >>>> >>>> Cheers, >>>> Robert. >>>> >>>> PS1: Horizontal links which were discussed could be installed to >>>> offload from fabric transit massive amount of data (ex: storage mirror= ing) >>>> directly between leafs or L3 TORs and not to be treated as "backup". >>>> >>>> PS2: Restricting any protocol to specific topologies seems like pretty >>>> slippery slope to me. In any case if protocol does that it should also >>>> contain self detection mechanism of "unsupported topology" and flash r= ed >>>> light in any NOC. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dcrouting mailing list >>>> Dcrouting@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dcrouting >>>> >>>> >>> >> > --001a114b2d02179ff90562ad4af1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,

> =E2=80=8B
if yo= u're willing to provision things correctly yourself via S-PGP.=C2=A0

I am not willing to do that. I would like routing to do it f= or me auto-magically. But yes you got the question right. I was asking for = shortcuts between last levels of fabric. Not so much between Node 111 &= Node 112 - but you said it is optional so ok.=C2=A0

<= div class=3D"gmail_default" style=3D"font-size:small">Side note: PGP abbrev. for vast majority of people means com= pletely different thing then what you defined it to mean locally in your dr= aft. I highly recommended you rename it in -05 version to PGD (policy guide= d destination(s) or PGR (policy guided reachability/routing).=C2=A0<= /div>

Now requirement to sw= itch off miscabling detection is not acceptable. You are stating that only = rift knows how should I cable my fabric ? And if I cable it some other way = it will detect it as miscabling ? I think in most cases of correct cables c= heck you actually define the intent then network detects if such intent is = met.=C2=A0

> Node112 can actually even go haywire

<= /div>
That may be not best property of a routing= protocol :)=C2=A0

Best,
R.

On Sat, Ja= n 13, 2018 at 7:16 PM, Tony Przygienda <tonysietf@gmail.com> wrote:
So I thought over your horizontal link case to shortcut= the spine levels
for some kind of traffic again and I t= hink the current draft actually
covers that
=E2=80=8B=E2=80=8B
if you're willing to pr= ovision things correctly yourself via S-PGP.
<= font size=3D"2">Let me see = whether we agree on this picture first:

.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-------= -+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+
.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ N
.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |Spine 21|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |Spine 22|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |.Level 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++-+--+-++=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++-+--+-++=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 <-*-> E/W
.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |= =C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 P111/2|=C2=A0 |P121=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S v=
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ ^=C2=A0 ^ ^=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |
.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | |=C2=A0 | |
.=C2=A0 +--------------+ |=C2=A0 +-----------+=C2= =A0 | |=C2=A0 | +---------------+
.=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 | |=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
. South +-----------------------------+ |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 All TIEs
.=C2=A0 0/0=C2=A0 0/0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 0/0=C2=A0=C2=A0 +-----------------------------+=C2=A0=C2= =A0=C2=A0=C2=A0 |
.=C2=A0 v=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+=C2=A0=C2=A0=C2=A0 +<-0/0----------+= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0 |
.+-+----++ optional +-+----++=C2=A0=C2=A0=C2=A0=C2=A0 ++----= +-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++-----++.|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | E/W link |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +=3D=3D=3D=3D=3D+ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
.|Node111+----------+Node112|=C2=A0=C2=A0=C2=A0= =C2=A0 |Node121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |Node122|
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ++----+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++---+--+
.=C2=A0 |=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0 South=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0 +---0/0--->-----+ 0/0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 +----------------+ |
. 0/0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | |
.=C2=A0 |=C2=A0=C2=A0 +---<-0/0-= ----+ |=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0 +--------------+ | |
.=C2=A0 v=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | |
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--+--+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +---+-+-+
.|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0 (L2L)=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Level 0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.|Leaf111~~~~~~~~~~~~Leaf112|=C2= =A0=C2=A0=C2=A0=C2=A0 |Leaf121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |Leaf122|
.+-+-----+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0 +--+--+-+=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-----+
.=C2=A0 +=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 /=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +
.=C2=A0 Prefix111=C2=A0=C2=A0 Prefix112= =C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0 Prefix121= =C2=A0=C2=A0=C2=A0 Prefix122
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multi-homed
.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefix
.= +---------- Pod 1 ---------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------- Pod 2 ----= -----+

I assume here that what you ask for is the followin= g scenario:
a) POD1 being a compute generating very heavy loa= d towards storage in
=C2=A0=C2=A0 Prefix121.
=
b) traffic from POD1 NOT being balanced through the spines but taking
=C2=A0=C2=A0 a horizontal <= span style=3D"font-family:monospace,monospace">link Node112 to Node121 to r= each your storage in Prefix121
=C2=A0=C2=A0 to save band= width? or delay?
c) The key to ric= hes is -04 section
4.2.5.1. Northbound= SPF

<= font size=3D"2">=C2=A0 in the paragraph "Other south prefixes found wh= en crossing E-W link MAY be used IIF". Now, we could make it a MUST (b= ut it's really an implementation knob IMO) and what it says is that if = you are willing to inject an "S-PGP" @ Node121 for Prefix121 it w= ill get flooded to Node112 and Node112 will have a more specific match than= the default in N-SPF. From 121 normal RIFT takes over since the normal N-P= refix for Leaf121 kicks in on Node121. I assume Node112 policy on the ingre= ss is to not propagate the S-PGP south but use it for N-SPF only.


=

Observe that

a) you have to s= witch off miscabling detection for PoD# on those nodes since you are "= crossing PoDs illegally"

b) if you want whole Pod#1 to do that you either cable = Node111 to Node121 as well (which will load balance whole Pod#1 towards sto= rage without using Spine)=C2=A0 OR you propagate S-PGPs south towards leafs= (which will cost you leaf FIB of course but make sure ALL traffic to stora= ge goes over Node112 only).

c) Your forwarding on Node112 can actually even go haywi= re & load-balance some of the traffic to Prefix121 using this S-PGP ove= r Node121 and some still using the default route towards spine(which here i= s a blatant violation of LPM of course) and RIFT will work just fine (unles= s you loop yourself to death with PGPs you install) but that of course is a= deep rathole in itself. I just mention it to show why the "non-loopin= g" design is so important and makes for the shortcomings for the SPF o= n a fabric, predicted by the non-directional mesh property that Dijkstra so= lved in his time.

so?

= --- tony

=




<= /span>
=

On Thu, Jan 11, 2018 at 10:= 54 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Tony,

Thx for = elaborating ...

Two small comments:

A) SID/SR use case in unde= rlay could be as simple as gracefully taking a fabric node out of service. = Not much OPEX needed if your NMS is decent. Otherwise in normal link state = I can do overload bit, in BGP number of solutions from shutdown to MED to L= P ... depending what is your BGP design. In RIFT how do you do that ? Note = that overlay (if such exist) does not help here.=C2=A0

B) For horizont= al links imagine you have servers with 40 GB ports to TOR. Then you have Nx= 100 GB from TOR up. You are going to oversubscribe on TOR (servers to fabri= c) most likely 2:1 .. 3:1 etc. So if I want to interconnect TORs because I = do know that servers behind those TORs need to talk to each other in a non = blocking fashion _and_ I have spare 100 GB ports on TORs having routing pro= tocol which does not allow me to do that seems pretty limited - wouldn'= t you agree ?=C2=A0

Thx,
R.







On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda <<= a href=3D"mailto:tonysietf@gmail.com" target=3D"_blank">tonysietf@gmail.com= > wrote:
Robert, productive points, thanks for rais= ing them ... I go a bit in depth

1. I saw no _= real_ use-cases for SID in DC so far to be frank (once you run RIFT). The o= nly one that comes up regularly is egress engineering and that IMO is equiv= alent to SID=3Dleaf address (which could be a HV address of course once you= have RIFT all way down to server) so really, what's the point to have = a SID? It's probably much smarter to use IBGP & so on overlay to do= this kind of synchronization if needed since labels/SIDs become very usefu= l in overlay to distinguish lots stuff there like VPNs/services which you&#= 39;d carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 add= ress. Having said that, discussion always to be had if you pay me dinner ;-= -) and I know _how_ we can do SIDs in RIFT since I thought it through but a= gain, no _real_ use case so far. And if your only concern is to "shape= towards a prefix" we have PGP in the draft which doesn't need new= silicon ;-P And then ultimately, yes, if you really, really want a SID per= prefix everywhere then you'll carry=C2=A0 SIDs to everywhere since uni= cast SIDs are really just a glorified way to say "I have this non-aggr= eagable 20 bit IP host address" which architecturally is a very intere= sting proposition in terms of scaling (but then again, no account for taste= and RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be still much small= er, your SPF will be still simple on leaf in RIFT but your FIB will blow up= and anything changing on a leaf shakes all other leafs (unless you start t= o run pollicies to control distribution @ which point in time you start to = baby-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID = would be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you rea= d RIFT draft carefully you will observe that RIFT can do anycast without ne= ed for ECMP, i.e. true anycast in a sense and with that having anycast SID = serves no real purpose in RIFT and is actually generally much harder to do = since you need globally unique label blocks and so on ...=C2=A0

2. Horizontal links on CLOSes are not used that way normally all I saw s= ince your blocking goes to hell unless you provision some kind of really ma= ssive parallel links between ToRs _and_ understand your load. We _could_ bu= ild RIFT that way but you give up balancing through the fabric and loop-fre= e property in a sense (that's a longish discussion=C2=A0 and scaling si= nce now you have prefixes showing up all kind of crazy places instead of de= fault). I see enough demand, we get there ...=C2=A0 Otherwise RFC1925 claus= e 10 and 5.=C2=A0

3. PS1: Yes, lots of things &qu= ot;could" be done and then we "could" build a protocol to do= that and RFC1925 clause 7 and 8 applies. Such horizontal links, unless pro= visioned correctly will pretty much just ruin your blocking/loss on the fab= ric is the experience (which the math supports). In a sense if you know you= r big flows you can build a specialized topology to do the optimal distribu= tion (MPLS tunnels anyone ;-) but the point of fabric is that it's a fa= bric (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a = good analogy would be that you like to build special RAM chips for the type= of data structures you are storing and we know how well that scales over t= ime. We know now that within 3-4 years characteristics of DC flows flip ups= ide down without a sweat when people go from server/client to microservices= , from servers to containers and so on and so on. So if you can't predi= ct your load all the time you need a _regular_ topology where _regular_ is = more of a mathematical than a protocol discussion. Fabric analogy of "= buy more RAM chips in Fry's and just stick them in" applies here. = So RIFT is done largely to serve a well-known structure called a "latt= ice" (with some restrictions) since we need an "up" and &quo= t;down". Things like hypercubes, thoroidal meshes and so on and so on = exist but CLOS won for a very good reason in history for that kind of probl= ems (once you move to NUMA other things win ;-) And if you know your loads = and your can heft the OPEX and you like to play with protocols generally an= d if you can support the scale in terms of leaf FIB sizes, flooding, slower= convergence & so on & so on and you run flat IGP on some kind of s= tuff that you build that doesn't even have to be regular in any sense. = We spent many years solving THAT problem obviously and doing something like= RIFT to replace normal IGP is of limited interest IMO (albeit certain aspe= cts having to do with modern implemenation techniques may get us there one = day but it's much less of pressing problem than solving specialized DC = routing well IMO again).

3. PS2: RIFT cannot build= an "unsupported topology" no matter how you cable (that's th= e point of it) or rather we have miscabling detection and do not form adjac= encies when you read the draft carefully. That's your "flash red l= ight" and it comes included for free with my compliments=C2=A0 ;-) ...= Otherwise RFC1925 clause 10.

Otherwise, if you have concrete= charter points you'd like to add, be more specific in your asks and we= see what the list thinks after ...

thanks

--- tony


On Thu, Jan 11, 2018 at 1:30 AM, Robert = Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little q= uestion/doubt on scalability point of RIFT ...=C2=A0

Assume that som= eone would like to signal IPv6 prefix SID for Segment Routing in the underl= ay within RIFT.=C2=A0

Wouldn't it result in amount of protocol sta= te in full analogy to massive deaggregation - which as of today is designed= to be very careful and limited operation only at moments of failure(s) ?= =C2=A0

I sort of find it a bit surprising that RIFT draft does not pro= vide encoding for SID distribution when it is positioned as an alternative = to other protocols (IGPs or BGP) which already provide ability to carry all= types of SIDs.=C2=A0

Cheers,
Robert.

PS1: Horizontal links wh= ich were discussed could be installed to offload from fabric transit massiv= e amount of data (ex: storage mirroring) directly between leafs or L3 TORs = and not to be treated as "backup".=C2=A0

PS2: Restricting an= y protocol to specific topologies seems like pretty slippery slope to me. I= n any case if protocol does that it should also contain self detection mech= anism of "unsupported topology" and flash red light in any NOC.= =C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>





--001a114b2d02179ff90562ad4af1-- From nobody Sat Jan 13 12:06:33 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E956612DA45; Sat, 13 Jan 2018 12:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 O0Czzf8z_CFd; Sat, 13 Jan 2018 12:06:24 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 3C75A12785F; Sat, 13 Jan 2018 12:06:24 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id 81so6974156wmb.1; Sat, 13 Jan 2018 12:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M6tStLQI2nMWJkmv3cYNWsAz2C4w7C4yQit3Yek2nxM=; b=bjp42liFBKDgjbXHjRbJCNG7zjVdX9c8coJHTMAVkU7vbTjhkLTF3BKnWg8cl9oB5E eNamGvU0SaND0A+lVuDYT9bAfi3BqAbLZhRzFkOQTu1CzB0SBQoWJFa31BdchOjkjlGe LP1yFBSlKaWfzAGub++6REcXkPPUqAAKuq/0SriEiRmU26+Yo0E8md8IgqnAHGGgknfm ZgxLnSuRATfi8YF65t675rNztSY/sJamESkt0bxIiH8wxUOzcZYRVpyFjjFwdP0OFIlK YG43dhb7GMgK6wkpifzfxVF4LodO4jYIIseEFhiOJTVjbBk7fdQTTczRKyZ6plgGiimk 76Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M6tStLQI2nMWJkmv3cYNWsAz2C4w7C4yQit3Yek2nxM=; b=hOtXTOuCPymc4VitxiS3RRJPv5m0ktu6agDNXcne62IcUnHq4MdavXYuUXAq31PAi4 VNiWTQAq+J7AoTFE0bkSagbd+ZfqiygpvaCtPlV3BBCqrZavMcVcB3wETADlDMM7bpHs xLsHMPaYMimdxLm0RCvyB4+ccp9jNDH/GBLmZkY582L20W71LRw9P64zLALlMLQPzQo5 CxcvV1lWJfRHPkA7eVZRJhxb/RkJrBlBbk+Ql5hI1MlGLB7CbxUJNfkK+79CaS3E7uax hw6EceSbkigjCrzGI0zwEEJog0d+s+iszVROzk/bGFrRp0J4Jx7M4XNhe947DnCXpGHR ny8Q== X-Gm-Message-State: AKwxyteHH3PH9cp1au6INBn/u3j4folZFC31DDZBhUP4tntN9vt9jf8j 1pqJ+x0HtcNgtBhuBqfpsh4AJVr+7iWUhhPkYaPsvw== X-Google-Smtp-Source: ACJfBosSCqJa79P15j3WrVpS9xs0vvhDNOAsuM56a+S7ar0hMu/L+t5hiMtcFIxzoJRDJ3HX1T2hArViavNSoSEef98= X-Received: by 10.80.148.217 with SMTP id t25mr3272264eda.121.1515873982606; Sat, 13 Jan 2018 12:06:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Sat, 13 Jan 2018 12:05:42 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Sat, 13 Jan 2018 12:05:42 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045c231641f1bf0562adea23" Archived-At: Subject: Re: [Dcrouting] draft-przygienda-rift-03 X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 20:06:26 -0000 --f403045c231641f1bf0562adea23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk wrote: > Hi Tony, > > > =E2=80=8B > if you're willing to provision things correctly yourself via S-PGP. > > I am not willing to do that. I would like routing to do it for me > auto-magically. > The price of that would be that you can run strict SPF only then and loose all the non-equal cost forwarding, including true anycast. Plus, once you think that through in general sense you basically end up with host addresses everywhere (since if you use aggregates you'll blackhole on link failures). If you want to avoid SPF and host routes while still asking for all the things you ask, then as a very experienced and highly regarded architect here puts it to end such discussions "your problem is overly constrained" and there is no protocol/algebra whatsoever that will give you that ... > But yes you got the question right. I was asking for shortcuts between > last levels of fabric. Not so much between Node 111 & Node 112 - but you > said it is optional so ok. > > Side note: PGP abbrev. for vast majority of people means completely > different thing then what you defined it to mean locally in your draft. I > highly recommended you rename it in -05 version to PGD (policy guided > destination(s) or PGR (policy guided reachability/routing). > Sigh, I warned when the acronym was picked. Come up with something that is a word, the funnier the better, easier to remember for our brains that way. Can be 4 letters ;-) and will get you an Ack mention l;-) > > Now requirement to switch off miscabling detection is not acceptable. You > are stating that only rift knows how should I cable my fabric ? > No, it doesn't. You asked in your previous email for "red lights" when topology is built incorrectly and you have it. Now you don't want it. Both states cannot be true @ the same time unless you are entangled ;-) > Node112 can actually even go haywire > > That may be not best property of a routing protocol :) > > "haywire" is the wrong word. Rather, I should have said "it will even allow that". Now, why would you want the same src/dst pair sometimes shortcut on the horizontal link and sometimes go up to spine I can't imagine but you ask for all kind of very non-obvious things you seem to like so I'm just pointing the space of possibilities out to you ... -- tony --f403045c231641f1bf0562adea23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:
Hi Tony,

> =E2=80=8B
if you're willing to provis= ion things correctly yourself via S-PGP.=C2=A0

I am not willing to do that. I would like routing = to do it for me auto-magically.

The price of that would be that you can run strict SPF only then a= nd loose all the non-equal cost forwarding, including true anycast. Plus, o= nce you think that through in general sense you basically end up with host = addresses everywhere (since if you use aggregates you'll blackhole on l= ink failures). If you want to avoid SPF and host routes while still asking = for all the things you ask, then as a very experienced and highly regarded = architect here puts it to end such discussions "your problem is overly= constrained" and there is no protocol/algebra whatsoever that will gi= ve you that ...
=C2=A0
<= div dir=3D"ltr">
But yes you got = the question right. I was asking for shortcuts between last levels of fabri= c. Not so much between Node 111 & Node 112 - but you said it is optiona= l so ok.=C2=A0

<= /span>
Side note: PGP abbrev. for vast majority of people means completely dif= ferent thing then what you defined it to mean locally in your draft. I high= ly recommended you rename it in -05 version to PGD (policy guided destinati= on(s) or PGR (policy guided reachability/routing).=C2=A0
=

Sigh, I warned when the acronym was picked= .=C2=A0 Come up with something that is a word, the funnier the better, easi= er to remember for our brains that way. Can be 4 letters ;-)=C2=A0 and will= get you an Ack mention l;-)
=C2=A0

Now requirement to switch off miscabling de= tection is not acceptable. You are stating that only rift knows how should = I cable my fabric ?

No,= it doesn't. You asked in your previous email for "red lights"= ; when topology is built incorrectly and you have it. Now you don't wan= t it. Both states cannot be true @ the same time unless you are entangled ;= -)=C2=A0

> Node112 can actually even go haywire

That may be not best property of a routing protocol :)=C2=A0


&quo= t;haywire" is the wrong word. Rather,=C2=A0 I should have said "i= t will even allow that". Now, why would you want the same src/dst pair= sometimes shortcut on the horizontal link and sometimes go up to spine I c= an't imagine but you ask for all kind of very non-obvious things you se= em to like so I'm just pointing the space of possibilities out to you .= ..


-- tony
--f403045c231641f1bf0562adea23-- From nobody Sat Jan 13 13:37:37 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBD512DB6D; Sat, 13 Jan 2018 13:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxFdkbiV-xJb; Sat, 13 Jan 2018 13:37:34 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 0F74012DA6B; Sat, 13 Jan 2018 13:37:33 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id g21so8215473wrb.13; Sat, 13 Jan 2018 13:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Bjm5Czc5xjrY6UBeaM1gFgjOnLr74zNjwlIqSs7533A=; b=dAUhUHQCxBFwpePgRTGBGM9QfC+nXZbI2eyenyikuZBnLs021RGkgaC3zbb0tPQ+yS tSwtgLRWD0RSxHes/0L+/2cj2JhMKOV8zSfbzRHmtaFX7cNU/vnZ4Bwjnh2QcDxSwRXq QxhXhYCVVI5RH3PVkmqW9ietUvWxKHreV0mWkOjqagR7Pc2IGxjeFnVs06nv9xORDD4M yI24pNZYqXOVe9wTRH+acfqWjbGFV8Ylj5hs4BB1O83KG9IW9aJSAyrrQv1x+1m7H9gv 7V8jqswROQIc/hSe0gqWYEY/LHcrYVakxE9rM9j/wJeHx/QMZLGLk/gv3PmmlS/iYqg2 Qk7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Bjm5Czc5xjrY6UBeaM1gFgjOnLr74zNjwlIqSs7533A=; b=WkIIDsMbreIiCSHc+hqbZnfsQXxnB1Corpxv2qT6CynZLQAKYEyzb1Cex8zzWg4jgZ L8iFOvdTFRyOye66lAxFzvGYY6kMTfIH+FrVX8ailxoSlC0SfBRLeWFIeCfKUSz0qJwb vUACIE73CMe8Sa7it/Pf0WuzWSqW3aZr4YxydQnpp9yQti4JssRhkVlAZfICCPkeBOrJ yWaIIGrp6zQ/WSHd26kSGfkdPO74FoAb45tEumaomRT8nBvsA0SqwEtvILuXczr1eO55 4ukS48gaUs6AySfa9yLXVZowegWBRp58tS4ko3LSWUZyUoIjmrN5kY8YHYGKd7HMMjkM 1P0A== X-Gm-Message-State: AKwxytejqIx55lAu/DKEHeJpd1S/HJmpD40jY+GDLD3PYsh6mAg9IFF5 ZtxREMIjv4TzS/BSh1IRcYc5gTs+PndD6JmQWbI= X-Google-Smtp-Source: ACJfBotV/qx9Bu4066HISmr0EA5JqSt8IG/Uz8OjTM2eN+xycprV5DDnQZQgZ2cZJxA1IuukhX3seih8G0wJxYPf6Rs= X-Received: by 10.223.138.133 with SMTP id y5mr6035043wry.224.1515879451701; Sat, 13 Jan 2018 13:37:31 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Sat, 13 Jan 2018 13:37:30 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Sat, 13 Jan 2018 22:37:30 +0100 X-Google-Sender-Auth: MvTUuWUvbGroOZvv_J7rPbzIbEc Message-ID: To: Tony Przygienda Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="001a113c2ca23db6000562af300b" Archived-At: Subject: Re: [Dcrouting] draft-przygienda-rift-03 X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 21:37:36 -0000 --001a113c2ca23db6000562af300b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tony, > The price of that would be that you can run strict SPF only then and loose all the non-equal cost forwarding, including true anycast. 1. Did anyone really asked that we should refrain from running "strict SPF" in DCs ? Contrary I see group of folks keen on running it based on BGP-LS like feeds :) 2. Is non-ECMP fwd-ing a feature or a bug in DC fabric ? When I described to customers that with MPLS you can run non ECMP load balancing it was shock .. but in WAN there are some use cases for it. But in DC fabric - I doubt it. 3. True anycast is clearly possible with native link state and native distance vector. Why the new "hybrid" glue of both would not allow it ? Because it counts on massive aggregation - right ? > Plus, once you think that through in general sense you basically end up with host addresses everywhere (since if you use aggregates you'll blackhole on link failures). If you want to avoid SPF and host routes Host routes are just leaves so they hang off nodes and do not make SPF any harder. Besides I am not convinced that building flat underlays with 1M host routes is the right architecture - even if some folks ask you about it. Best, R. On Sat, Jan 13, 2018 at 9:05 PM, Tony Przygienda wrote: > > > On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk wrote= : > >> Hi Tony, >> >> > =E2=80=8B >> if you're willing to provision things correctly yourself via S-PGP. >> >> I am not willing to do that. I would like routing to do it for me >> auto-magically. >> > > The price of that would be that you can run strict SPF only then and loos= e > all the non-equal cost forwarding, including true anycast. Plus, once you > think that through in general sense you basically end up with host > addresses everywhere (since if you use aggregates you'll blackhole on lin= k > failures). If you want to avoid SPF and host routes while still asking fo= r > all the things you ask, then as a very experienced and highly regarded > architect here puts it to end such discussions "your problem is overly > constrained" and there is no protocol/algebra whatsoever that will give y= ou > that ... > > >> But yes you got the question right. I was asking for shortcuts between >> last levels of fabric. Not so much between Node 111 & Node 112 - but you >> said it is optional so ok. >> >> Side note: PGP abbrev. for vast majority of people means completely >> different thing then what you defined it to mean locally in your draft. = I >> highly recommended you rename it in -05 version to PGD (policy guided >> destination(s) or PGR (policy guided reachability/routing). >> > > Sigh, I warned when the acronym was picked. Come up with something that > is a word, the funnier the better, easier to remember for our brains that > way. Can be 4 letters ;-) and will get you an Ack mention l;-) > > >> >> Now requirement to switch off miscabling detection is not acceptable. Yo= u >> are stating that only rift knows how should I cable my fabric ? >> > > No, it doesn't. You asked in your previous email for "red lights" when > topology is built incorrectly and you have it. Now you don't want it. Bot= h > states cannot be true @ the same time unless you are entangled ;-) > > > Node112 can actually even go haywire >> >> That may be not best property of a routing protocol :) >> >> > "haywire" is the wrong word. Rather, I should have said "it will even > allow that". Now, why would you want the same src/dst pair sometimes > shortcut on the horizontal link and sometimes go up to spine I can't > imagine but you ask for all kind of very non-obvious things you seem to > like so I'm just pointing the space of possibilities out to you ... > > > -- tony > --001a113c2ca23db6000562af300b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony,

> The price of that would be that you can run strict SPF only the= n and loose all the non-equal cost forwarding, including true anycast.=C2= =A0

1. Did anyone really asked t= hat we should refrain from running "strict SPF" in DCs ? Contrary= I see group of folks keen on running it based on BGP-LS like feeds :)=C2= =A0

2. Is non-ECMP fwd-ing a fea= ture or a bug in DC fabric ? When I described to customers that with MPLS y= ou can run non ECMP load balancing it was shock .. but in WAN there are som= e use cases for it. But in DC fabric - I doubt it.=C2=A0
=
3. True anycast is clearly possible with native link= state and native distance vector. Why the new "hybrid" glue of b= oth would not allow it ? Because it counts on massive aggregation - right ?= =C2=A0

> Plus, once you think t= hat through in general sense you basically end up with host addresses every= where (since if you use aggregates you'll blackhole on link failures). = If you want to avoid SPF and host routes

<= /div>
Host routes are just leaves so they hang off nodes and do not make SPF a= ny harder. Besides I am not convinced that building flat underlays with 1M = host routes is the right architecture - even if some folks ask you about it= .=C2=A0

= Best,
R.

<= /div>



On Sat, Jan 13, 2018 at 9:05 PM, To= ny Przygienda <tonysietf@gmail.com> wrote:


On Sat, Jan 13, 2018 at 11:21 AM, R= obert Raszuk <robert@raszuk.net> wrote:
Hi Tony,

> =E2=80=8B
if you're willing to provision things correctly yours= elf via S-PGP.=C2=A0

I am not willing to do that. I would like routing to d= o it for me auto-magically.
The price of that would be that you can run strict SPF only the= n and loose all the non-equal cost forwarding, including true anycast. Plus= , once you think that through in general sense you basically end up with ho= st addresses everywhere (since if you use aggregates you'll blackhole o= n link failures). If you want to avoid SPF and host routes while still aski= ng for all the things you ask, then as a very experienced and highly regard= ed architect here puts it to end such discussions "your problem is ove= rly constrained" and there is no protocol/algebra whatsoever that will= give you that ...
=C2=A0
But yes you got the question right. I was asking for shortcuts between = last levels of fabric. Not so much between Node 111 & Node 112 - but yo= u said it is optional so ok.=C2=A0

Side note: PGP abbrev. for vast majority of peopl= e means completely different thing then what you defined it to mean locally= in your draft. I highly recommended you rename it in -05 version to PGD (p= olicy guided destination(s) or PGR (policy guided reachability/routing).=C2= =A0

Sigh, I warne= d when the acronym was picked.=C2=A0 Come up with something that is a word,= the funnier the better, easier to remember for our brains that way. Can be= 4 letters ;-)=C2=A0 and will get you an Ack mention l;-)
=C2=A0
=

Now requirement to switch off miscabling detection is not acceptable. You = are stating that only rift knows how should I cable my fabric ?

No, it doesn't. You ask= ed in your previous email for "red lights" when topology is built= incorrectly and you have it. Now you don't want it. Both states cannot= be true @ the same time unless you are entangled ;-)=C2=A0

=
> Node112 can actually even go haywire

That m= ay be not best property of a routing protocol :)=C2=A0


"haywire&qu= ot; is the wrong word. Rather,=C2=A0 I should have said "it will even = allow that". Now, why would you want the same src/dst pair sometimes s= hortcut on the horizontal link and sometimes go up to spine I can't ima= gine but you ask for all kind of very non-obvious things you seem to like s= o I'm just pointing the space of possibilities out to you ...
=

-- tony

--001a113c2ca23db6000562af300b-- From nobody Tue Jan 16 09:39:10 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7312E872 for ; Tue, 16 Jan 2018 09:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 WWm15khHLFCM for ; Tue, 16 Jan 2018 09:39:07 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 6750A12E86D for ; Tue, 16 Jan 2018 09:39:07 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-02v.sys.comcast.net with ESMTP id bVCSe2BaKXw3xbVCVeRuFO; Tue, 16 Jan 2018 17:39:07 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-14v.sys.comcast.net with SMTP id bVAQe81YOLDiCbVASe62VZ; Tue, 16 Jan 2018 17:37:05 +0000 From: tony.li@tony.li Content-Type: multipart/alternative; boundary="Apple-Mail=_9EC48122-31C9-4B2F-85E8-22D9717CE2A3" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <1E07900E-F65C-4FA5-B4D8-238968EFB4BD@tony.li> References: <151612415176.27368.13587433207765022617.idtracker@ietfa.amsl.com> To: dcrouting@ietf.org Date: Tue, 16 Jan 2018 09:36:57 -0800 X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfCkhpiLdWGxbPd3/fRDQADfQYn5IB46gl2Le5jwtUyjXMDJTqVWb/KGumZWXB3djl4LxcUhQ4JDqvwFekCYGgE0EJZ435jHu2kNYCtu2PqDx/ggkPTQC 6XqlrRTeeT4MqF/SGTLTz/AssHTsCKtY+r89F1VZBYc2Sx2DdjQmySDz Archived-At: Subject: [Dcrouting] Fwd: New Version Notification for draft-li-dynamic-flooding-01.txt X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 17:39:09 -0000 --Apple-Mail=_9EC48122-31C9-4B2F-85E8-22D9717CE2A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI.=20 Minor updates. Tony > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-li-dynamic-flooding-01.txt > Date: January 16, 2018 at 9:35:51 AM PST > To: "Tony Li" >=20 >=20 > A new version of I-D, draft-li-dynamic-flooding-01.txt > has been successfully submitted by Tony Li and posted to the > IETF repository. >=20 > Name: draft-li-dynamic-flooding > Revision: 01 > Title: An Architecture for Dynamic Flooding on Dense = Graphs > Document date: 2018-01-14 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-li-dynamic-flooding-01.txt > Status: = https://datatracker.ietf.org/doc/draft-li-dynamic-flooding/ > Htmlized: = https://tools.ietf.org/html/draft-li-dynamic-flooding-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-li-dynamic-flooding-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-li-dynamic-flooding-01 >=20 > Abstract: > Routing with link state protocols in dense network topologies can > result in sub-optimal convergence times due to the overhead > associated with flooding. This can be addressed by decreasing the > flooding topology so that it is less dense. >=20 > This document discusses the problem in some depth and an > architectural solution. Specific protocol changes are not described > in this document. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_9EC48122-31C9-4B2F-85E8-22D9717CE2A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

FYI. 

Minor updates.

Tony


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-li-dynamic-flooding-01.txt
Date: = January 16, 2018 at 9:35:51 AM = PST
To: = "Tony Li" <tony.li@tony.li>

A new version of I-D, draft-li-dynamic-flooding-01.txt
has been successfully submitted by Tony Li and posted to = the
IETF repository.

Name: = draft-li-dynamic-flooding
Revision: 01
Title:= = An Architecture for Dynamic Flooding on Dense Graphs
Document date: 2018-01-14
Group:= = Individual Submission
Pages: 8
URL: =            https://www.ietf.org/internet-drafts/draft-li-dynamic-flooding-= 01.txt
Status: =         https://datatracker.ietf.org/doc/draft-li-dynamic-flooding/=
Htmlized:       https://tools.ietf.org/html/draft-li-dynamic-flooding-01Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-dynamic-flooding= -01
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-li-dynamic-flooding-0= 1

Abstract:
=   Routing with link state protocols in dense network = topologies can
  result in sub-optimal = convergence times due to the overhead
=   associated with flooding.  This can be addressed by = decreasing the
  flooding topology so that it = is less dense.

  This document = discusses the problem in some depth and an
=   architectural solution.  Specific protocol changes are = not described
  in this document.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_9EC48122-31C9-4B2F-85E8-22D9717CE2A3-- From nobody Tue Jan 23 13:54:07 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CDD12D84A for ; Tue, 23 Jan 2018 13:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 P7qyjtOkd3ug for ; Tue, 23 Jan 2018 13:54:04 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DD412D84B for ; Tue, 23 Jan 2018 13:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9972; q=dns/txt; s=iport; t=1516744444; x=1517954044; h=from:to:subject:date:message-id:mime-version; bh=Ag3NDCnLaifEwa69bCrZmtTChH3V8BqI3gI2kdqNijU=; b=FV4+wQNXisosvHrCbhw4PmxAPUBK0wzGWFeK/Wc4BJPrQhHGCNOfxdVT T0yJVnnXY45v20/UtspPZqnPtH7d5fdIzBRHG4EP4Zi415atA50vfYqpe GCyD4YvMM/xK8VJA5Q0bZJr+7ZGPptEcx/Qu6tzlf1a+OA55gJF4hUiDa Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiAQAjrmda/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKeGZ0JweNeo5lggKRaoVUghcKI4oQVBgBAQEBAQEBAQJrHQu?= =?us-ascii?q?FJAEEAS1KBw0BCBJmFw8BBBsTiTZcCBC1V4pKAQEBAQEBBAEBAQEBAR0FhEuCF?= =?us-ascii?q?YFXhRaDLwEBAgEBF4dSBZI0kUoCiBKNQJQsjVSJTwIRGQGBOwEfOYFQcBUZgk6?= =?us-ascii?q?EV3gBjQKBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,403,1511827200"; d="scan'208,217";a="349940472" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2018 21:54:02 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0NLs2v0001535 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Jan 2018 21:54:02 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 23 Jan 2018 15:54:01 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Tue, 23 Jan 2018 15:54:02 -0600 From: "Jakob Heitz (jheitz)" To: "dcrouting@ietf.org" Thread-Topic: Re: New Version Notification for draft-li-dynamic-flooding-01.txt Thread-Index: AdOUg0o5CY59FwFET6KfZbsQE+6/8Q== Date: Tue, 23 Jan 2018 21:54:02 +0000 Message-ID: <43088d7a0d2c44038d4d6bdcce4fca9a@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.198.47] Content-Type: multipart/alternative; boundary="_000_43088d7a0d2c44038d4d6bdcce4fca9aXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dcrouting] New Version Notification for draft-li-dynamic-flooding-01.txt X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 21:54:06 -0000 --_000_43088d7a0d2c44038d4d6bdcce4fca9aXCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This looks to me like a good idea. It does not require a separate management network. A small flooding topology would be a spanning tree. This would assume that upon a link failure, both ends of a p2p link detect = the failure and send an LSA within an acceptable time. If not, then I would add a second link to any nodes that have only one link= in the spanning tree. Thanks, Jakob > Name: draft-li-dynamic-flooding > Revision: 01 > Title: An Architecture for Dynamic Flooding on Dense Graphs > Document date: 2018-01-14 > Group: Individual Submission > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-li-dynamic-flo= oding-01.txt > Status: https://datatracker.ietf.org/doc/draft-li-dynamic-floodin= g/ > Htmlized: https://tools.ietf.org/html/draft-li-dynamic-flooding-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-li-dynamic-fl= ooding-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-li-dynamic-floo= ding-01 > > Abstract: > Routing with link state protocols in dense network topologies can > result in sub-optimal convergence times due to the overhead > associated with flooding. This can be addressed by decreasing the > flooding topology so that it is less dense. > > This document discusses the problem in some depth and an > architectural solution. Specific protocol changes are not described > in this document. --_000_43088d7a0d2c44038d4d6bdcce4fca9aXCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This looks to me like a good idea.

It does not require a separate management ne= twork.

A small flooding topology would be a spannin= g tree.

This would assume that upon a link failure, = both ends of a p2p link detect the failure and send an LSA within an accept= able time.

If not, then I would add a second link to an= y nodes that have only one link in the spanning tree.

 

Thanks,

Jakob

 

> Name:     &nbs= p;     draft-li-dynamic-flooding

> Revision: 01

> Title:     &nb= sp;    An Architecture for Dynamic Flooding on Dense Graphs<= o:p>

> Document date:  2018-01-14

> Group:     &nb= sp;    Individual Submission

> Pages:     &nb= sp;    8

> URL:      = ;      https://www.ietf.org/internet-drafts/draft-li-dynamic-flooding-01.tx= t

> Status:     &n= bsp;   htt= ps://datatracker.ietf.org/doc/draft-li-dynamic-flooding/

> Htmlized:     =   https:= //tools.ietf.org/html/draft-li-dynamic-flooding-01

> Htmlized:     =   https://datatracker.ietf.org/doc/html/draft-li-dynamic-flooding-01<= o:p>

> Diff:     &nbs= p;     https://www.ietf.org/rfcdiff?url2=3Ddraft-li-dynamic-flooding-01=

>

> Abstract:

>   Routing with link state pro= tocols in dense network topologies can

>   result in sub-optimal conve= rgence times due to the overhead

>   associated with flooding.&n= bsp; This can be addressed by decreasing the

>   flooding topology so that i= t is less dense.

>

>   This document discusses the= problem in some depth and an

>   architectural solution.&nbs= p; Specific protocol changes are not described

>   in this document.

 

--_000_43088d7a0d2c44038d4d6bdcce4fca9aXCHALN014ciscocom_-- From nobody Tue Jan 23 13:58:16 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6901112D84E; Tue, 23 Jan 2018 13:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ddEQq8SPRaoA; Tue, 23 Jan 2018 13:57:59 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEBD12D84B; Tue, 23 Jan 2018 13:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23106; q=dns/txt; s=iport; t=1516744679; x=1517954279; h=from:to:cc:subject:date:message-id:mime-version; bh=3BQhvScy3i1D9Oip5OTegSLx6U6qb6t4KZaXrGLgzKM=; b=KNN6JXTWTuAx23TbfLutVC+UzvfMbyhXrH9VvpF/jLsymKdWobX6Az6A Xq+Uve+ZdIeVGkTQkXjOFi/yTw7kmzeJOIRIAizsXNMEbgknQQoq9yv6D Ib2HJd2e4x4VwaTAGEoQnvEp3SDumF3Kpul12hC3LojAlanlcIp8LJvBG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAQCQrmda/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKeGZ0JweDVookjmWCAnyQboVUFYICChgBCoUYAhqEXFQYAQE?= =?us-ascii?q?BAQEBAQECayiFIwECBAEBIUsLEgEIEQMBAg4aAwIEJQsUCQoEAQ0FiVFkELMbg?= =?us-ascii?q?ieKSgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhEuCFYM/KYJPNoMvAQECgTwBEgE?= =?us-ascii?q?/FgKCXzGCNAWLY44hiXoChxmEdYlNghuSCIp3jCwCERkBgTsBHzlgcHAVPSoBg?= =?us-ascii?q?X8JhE54i16BJYEXAQEB?= X-IronPort-AV: E=Sophos; i="5.46,403,1511827200"; d="scan'208,217"; a="60685326" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2018 21:57:58 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w0NLvwGo011079 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jan 2018 21:57:58 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 23 Jan 2018 15:57:57 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Tue, 23 Jan 2018 15:57:57 -0600 From: "Serpil Bayraktar (serpil)" To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "Lsvr@ietf.org" CC: "idr@ietf.org" , "dcrouting@ietf.org" , Victor Kuarsingh , Keyur Patel , Shawn Zandi , "rtgwg@ietf.org" Thread-Topic: [Idr] Kicking off the LSVR (Link State Vector Routing) charter discussion Thread-Index: AQHTlJU6QgS+h9p2QUuvsW8I9ysSgg== Date: Tue, 23 Jan 2018 21:57:57 +0000 Message-ID: <52BDDB18-139A-486C-A3EF-33C794DC4F5A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.21.67] Content-Type: multipart/alternative; boundary="_000_52BDDB18139A486CA3EF33C794DC4F5Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dcrouting] [Idr] Kicking off the LSVR (Link State Vector Routing) charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 21:58:02 -0000 --_000_52BDDB18139A486CA3EF33C794DC4F5Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhbiBpbnRlcmVzdGluZyAoYW5kIHVzZWZ1bCkgYXBwcm9hY2guIEkgYW0gdmVyeSBp bnRlcmVzdGVkIGluIHBhcnRpY2lwYXRpbmcuDQoNClNlcnBpbA0KDQpGcm9tOiBJZHIgPGlkci1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIlZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tp YSAtIEJFL0FudHdlcnApIiA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+DQpEYXRlOiBU dWVzZGF5LCBKYW51YXJ5IDIzLCAyMDE4IGF0IDExOjA3IEFNDQpUbzogIkxzdnJAaWV0Zi5vcmci IDxMc3ZyQGlldGYub3JnPg0KQ2M6ICJpZHJAaWV0Zi5vcmciIDxpZHJAaWV0Zi5vcmc+LCAiZGNy b3V0aW5nQGlldGYub3JnIiA8ZGNyb3V0aW5nQGlldGYub3JnPiwgVmljdG9yIEt1YXJzaW5naCA8 dmljdG9yLmt1YXJzaW5naEBvcmFjbGUuY29tPiwgS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5j b20+LCAiVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkiIDxndW50ZXIu dmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4sIFNoYXduIFphbmRpIDxzemFuZGlAbGlua2VkaW4uY29t PiwgInJ0Z3dnQGlldGYub3JnIiA8cnRnd2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSWRyXSBLaWNr aW5nIG9mZiB0aGUgTFNWUiAoTGluayBTdGF0ZSBWZWN0b3IgUm91dGluZykgY2hhcnRlciBkaXNj dXNzaW9uDQoNCltOb3RlOiBUYXJnZXQgYXVkaWVuY2UsIGFuZCBkaXNjdXNzaW9ucyBzaG91bGQg aGFwcGVuIG9uIGxzdnJAaWV0Zi5vcmc8bWFpbHRvOmxzdnJAaWV0Zi5vcmc+LCBob3dldmVyICJy dGd3ZyIsICJpZHIiIGFuZCAiZGNyb3V0aW5nIiBlbWFpbCBsaXN0cyBoYXZlIGJlZW4gYWRkZWQg YXMgdGhlIGNvbmNlcHRzIG9yaWdpbmF0ZWQgaW4gdGhvc2Ugd29ya2luZyBncm91cHNdDQoNClNp bmNlIGRjcm91dGluZ0BpZXRmMTAwLCBhIGZldyBwZW9wbGUgaGF2ZSBiZWVuIGRpc2N1c3Npbmcg YSBwb3NzaWJsZSBXRyBjaGFydGVyIGZvciBMU1ZSIChMaW5rIFN0YXRlIFZlY3RvciBSb3V0aW5n KS4NCkhlcmUgaXMgd2hhdCB3ZSBoYXZlIHNvIGZhci4gIENvbW1lbnRzIGFuZCBpbXByb3ZlbWVu dHMgd291bGQgYmUgbW9zdCB3ZWxjb21lLg0KDQpXRyBwYWdlIGlzIHRvIGJlIHNldHVwIHNvb24u DQpTdWJzY3JpcHRpb24gdG8gTFNWUiBtYWlsaW5nIGxpc3Q6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbHN2cg0KDQpGZWVkYmFjayAoY29tbWVudHMsIGVkaXRzLCBjb3Jy ZWN0aW9ucywgZXRjKSAgb24gdGhlIGRyYWZ0IExTVlIgY2hhcnRlciBpcyBhcHByZWNpYXRlZA0K DQoNCioqKioqIERSQUZUIENIQVJURVIgVVBEQVRFIC0gSkFOIDEwIDIwMTggKioqKioNCg0KQ2hh cnRlcjogTFNWUiAtIExpbmsgU3RhdGUgVmVjdG9yIFJvdXRpbmcNCg0KVGhlIExpbmstU3RhdGUg VmVjdG9yIFJvdXRpbmcgKExTVlIpIFdvcmtpbmcgR3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVs b3AgYW5kIGRvY3VtZW50IGEgaHlicmlkIHJvdXRpbmcgcHJvdG9jb2wgdXRpbGl6aW5nIGEgY29t YmluYXRpb24gb2YgbGluay1zdGF0ZSBhbmQgcGF0aC12ZWN0b3Igcm91dGluZyBtZWNoYW5pc21z LiAgVGhlIExTVlIgV0cgd2lsbCB1dGlsaXplIGV4aXN0aW5nIHRoZSBJUHY0L0lQdjYgdHJhbnNw b3J0LCBwYWNrZXQgZm9ybWF0cywgYW5kIGVycm9yIGhhbmRsaW5nIGZyb20gQkdQLTQgKFJGQzQy NzEpLiBBZGRpdGlvbmFsbHksIHRoZSBCR1AtTFMgTkxSSSBlbmNvZGluZyBtZWNoYW5pc21zIGRl ZmluZWQgaW4gUkZDNzc1MiBhcmUgdXRpbGl6ZWQgdG8gZmFjaWxpdGF0ZSBMaW5rLVN0YXRlIFZl Y3RvciAoTFNWKSByb3V0aW5nIGluZm9ybWF0aW9uIGRpc3RyaWJ1dGlvbi4gQW4gTFNWIGlzIGlu dGVuZGVkIHRvIGJlIHNwZWNpZmllZCBhcyBhIGRhdGEgc3RydWN0dXJlIGNvbXByaXNlZCBvZiBh IGxpbmsgaWRlbnRpZmljYXRpb24sIGxpbmsgYXR0cmlidXRlcywgbmVpZ2hib3IgaW5mb3JtYXRp b24sIGNvc3QgdG93YXJkIG5laWdoYm9ycywgYW5kIG90aGVyIGF0dHJpYnV0ZXMgdGhhdCBhcmUg ZGVmaW5lZCBmb3IgY29udHJvbCBwbGFuZSBmdW5jdGlvbiBhbmQgcG9saWN5LWJhc2VkIHJvdXRp bmcgZGVjaXNpb25zLg0KDQpUaGUgTFNWUiBzcGVjaWZpY2F0aW9uIGlzIGluaXRpYWxseSBmb2N1 c2VkIG9uIG9wZXJhdGlvbiB3aXRoaW4gYSBzaW5nbGUgZGF0YWNlbnRlciAoREMpIHdpdGggcHJl bGltaW5hcnkgZm9jdXMgb24gc3BlY2lmeWluZyBmdW5jdGlvbmFsaXR5IHdpdGhpbiBhIHNpbmds ZSBkaXN0cmlidXRpb24gZG9tYWluLiAgUm91dGluZyBwcm90b2NvbCBmdW5jdGlvbmFsaXR5IGRl ZmluZWQgYnkgTFNWUiB3b3VsZCBiZSB0eXBpY2FsbHkgcm91dGluZyB3aXRoaW4gYSBkYXRhY2Vu dGVyJ3MgdW5kZXJsYXkgcm91dGluZyBwbGFuZS4NCg0KSW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGUg bm90ZWQgb2JqZWN0aXZlLCB0aGUgd29ya2luZyBncm91cCB3aWxsIGZvY3VzIG9uIHN0YW5kYXJk aXphdGlvbiBvZiBwcm90b2NvbCBmdW5jdGlvbmFsaXR5LCBkZWZpbmluZyBMaW5rLVN0YXRlIFZl Y3RvcnMgKExTVnMpLCBhbmQgZGVmaW5pbmcgc3RhbmRhcmQgcGF0aC12ZWN0b3Igcm91dGUgc2Vs ZWN0aW9uIHV0aWxpemluZyBleGlzdGluZyBEaWprc3RyYSBTUEYgYmFzZWQgYWxnb3JpdGhtLCBC R1AtNCBwcm90b2NvbCBtZWNoYW5pY3MsIGFuZCBCR1AtTFMgTlJMSSBlbmNvZGluZy4NCg0KRm9y IHRoZSBwdXJwb3NlcyBvZiB0aGUgaW5pdGlhbCB3b3JrIHdpdGhpbiB0aGUgTFNWUiBXRywgYW5k IHVudGlsIGZ1cnRoZXIgc3BlY2lmaWVkIGJ5IHRoZSBXRywgdGhlIGZvbGxvd2luZyBkZWZpbml0 aW9ucyBhcHBseSB0byB0aGlzIGNoYXJ0ZXIuDQoNCi0gTGluay1TdGF0ZSBWZWN0b3IgLSBBbiBM U1YgaXMgaW50ZW5kZWQgdG8gcmVwcmVzZW50IGEgZGF0YSBzdHJ1Y3R1cmUgKGRhdGEgc2V0KSBj b21wcmlzZWQgb2YgbGluayBpZGVudGlmaWNhdGlvbiwgbGluayBhdHRyaWJ1dGVzLCBuZWlnaGJv ciBpbmZvcm1hdGlvbiwgY29zdCB0b3dhcmRzIG5laWdoYm9ycywgYW5kIG90aGVyIHBvdGVudGlh bCBhdHRyaWJ1dGVzIHRoYXQgY2FuIGJlIHV0aWxpemVkIHRvIG1ha2Ugcm91dGluZyBkZWNpc2lv bnMuDQotIExTVlIgRGlzdHJpYnV0aW9uIERvbWFpbiAtIEluaXRpYWxseSBzY29wZWQgYXMgYSBz ZXQgb2YgcGFydGljaXBhdGluZyBMU1ZSIG5vZGVzIGluIGEgc2luZ2xlIGFkbWluaXN0cmF0aXZl IGRvbWFpbi4NCg0KDQpUaGUgTFNWUiBXRyBpcyBjaGFydGVyZWQgdG8gZGVsaXZlciB0aGUgZm9s bG93aW5nIGRvY3VtZW50czoNCg0KLSBQdWJsaXNoIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50IGZv ciB0aGUgdXNlIG9mIExTVlIgaW4gdGhlIERhdGFjZW50ZXIgLSBUYXJnZXQgU3RhdHVzOiBJbmZv cm1hdGlvbmFsDQotIFB1Ymxpc2ggc3BlY2lmaWNhdGlvbiBkb2N1bWVudCBkZXNjcmliaW5nIExT ViB3aXRoIHN0YW5kYXJkIERpamtzdHJhIFNQRiByb3V0ZS9wYXRoIHNlbGVjdGlvbiAoY2FsY3Vs YXRpb24pIHV0aWxpemluZyBleGlzdGluZyBCR1AgcHJvdG9jb2wgYmFzZWxpbmUgZnVuY3Rpb25h bGl0eSBhbmQgQkdQLUxTIHBhY2tldCBlbmNvZGluZyBmb3JtYXRzIC0gVGFyZ2V0OiBTdGFuZGFy ZHMgVHJhY2sgKEJhc2VkIG9uIGRyYWZ0IGRyYWZ0LWtleXVwYXRlLWlkci1iZ3Atc3BmKQ0KLSBQ dWJsaXNoIHNwZWNpZmljYXRpb24gZG9jdW1lbnRpbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucyByZXF1 aXJlZCB0byBlZmZpY2llbnRseSByZXVzZSBCR1AgdG8gZGlzdHJpYnV0ZSBMU1ZzIHdpdGhpbiBh biBJUHY0L0lQdjYgREMgd2l0aCBzY29wZSB0byBpbmNsdWRlIHByaXZhY3kgYW5kIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIC0gLSBUYXJnZXQ6IFN0YW5kYXJkcyBUcmFjaw0KLSBQdWJsaXNoIFlB TkcgbW9kZWwgc3BlY2lmaWNhdGlvbiBmb3IgTFNWUiAtIC0gVGFyZ2V0OiBTdGFuZGFyZHMgVHJh Y2sNCg0KTFNWUiBNaWxlc3RvbmVzOg0KDQotIEFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGZvciBM U1ZSIGluIERDczogTWFyY2ggMjAxOQ0KLSBMU1ZSIHdpdGggc3RhbmRhcmQgRGlqa3N0cmEgcGF0 aCBzZWxlY3Rpb246IE1hcmNoIDIwMTkNCi0gTFNWIGRpc3RyaWJ1dGlvbiB1c2luZyBCR1AgdHJh bnNwb3J0OiBNYXJjaCAyMDE5DQotIFlBTkcgc3BlY2lmaWNhdGlvbiBmb3IgTFNSVjogSnVseSAy MDE5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ ZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCg== --_000_52BDDB18139A486CA3EF33C794DC4F5Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <70C6FBFA508F114CBDE2F1B629A31462@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgKGFuZCB1c2VmdWwpIGFwcHJvYWNoLiBJ IGFtIHZlcnkgaW50ZXJlc3RlZCBpbiBwYXJ0aWNpcGF0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TZXJwaWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPklk ciAmbHQ7aWRyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtWYW4gRGUg VmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSZxdW90OyAmbHQ7Z3VudGVyLnZhbl9k ZV92ZWxkZUBub2tpYS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEphbnVhcnkg MjMsIDIwMTggYXQgMTE6MDcgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O0xzdnJAaWV0Zi5vcmcm cXVvdDsgJmx0O0xzdnJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtpZHJAaWV0 Zi5vcmcmcXVvdDsgJmx0O2lkckBpZXRmLm9yZyZndDssICZxdW90O2Rjcm91dGluZ0BpZXRmLm9y ZyZxdW90OyAmbHQ7ZGNyb3V0aW5nQGlldGYub3JnJmd0OywgVmljdG9yIEt1YXJzaW5naCAmbHQ7 dmljdG9yLmt1YXJzaW5naEBvcmFjbGUuY29tJmd0OywgS2V5dXIgUGF0ZWwgJmx0O2tleXVyQGFy cmN1cy5jb20mZ3Q7LCAmcXVvdDtWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3 ZXJwKSZxdW90OyAmbHQ7Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20mZ3Q7LCBTaGF3biBa YW5kaSAmbHQ7c3phbmRpQGxpbmtlZGluLmNvbSZndDssDQogJnF1b3Q7cnRnd2dAaWV0Zi5vcmcm cXVvdDsgJmx0O3J0Z3dnQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bSWRyXSBL aWNraW5nIG9mZiB0aGUgTFNWUiAoTGluayBTdGF0ZSBWZWN0b3IgUm91dGluZykgY2hhcnRlciBk aXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+W05vdGU6IFRhcmdldCBh dWRpZW5jZSwgYW5kIGRpc2N1c3Npb25zIHNob3VsZCBoYXBwZW4gb24NCjwvYT48YSBocmVmPSJt YWlsdG86bHN2ckBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+bHN2ckBpZXRmLm9yZzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPiwgaG93ZXZlciAmcXVvdDtydGd3ZyZxdW90OywgJnF1b3Q7aWRyJnF1 b3Q7IGFuZCAmcXVvdDtkY3JvdXRpbmcmcXVvdDsgZW1haWwgbGlzdHMgaGF2ZQ0KIGJlZW4gYWRk ZWQgYXMgdGhlIGNvbmNlcHRzIG9yaWdpbmF0ZWQgaW4gdGhvc2Ugd29ya2luZyBncm91cHNdPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+U2luY2UgZGNyb3V0aW5n QGlldGYxMDAsIGEgZmV3IHBlb3BsZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBhIHBvc3NpYmxlIFdH IGNoYXJ0ZXIgZm9yIExTVlIgKExpbmsgU3RhdGUgVmVjdG9yIFJvdXRpbmcpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkhlcmUgaXMgd2hhdCB3ZSBoYXZl IHNvIGZhci4mbmJzcDsmbmJzcDtDb21tZW50cyBhbmQgaW1wcm92ZW1lbnRzIHdvdWxkIGJlIG1v c3Qgd2VsY29tZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PldHIHBhZ2UgaXMgdG8gYmUgc2V0dXAgc29vbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij5TdWJzY3JpcHRpb24gdG8gTFNWUiBtYWlsaW5nIGxpc3Q6DQo8 L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3Zy Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzdnI8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5GZWVkYmFjayAoY29tbWVudHMsIGVkaXRzLCBjb3JyZWN0aW9ucywgZXRj KSZuYnNwOyZuYnNwO29uIHRoZSBkcmFmdCBMU1ZSIGNoYXJ0ZXIgaXMgYXBwcmVjaWF0ZWQNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPioqKioqIERSQUZUIENIQVJU RVIgVVBEQVRFIC0gSkFOIDEwIDIwMTggKioqKio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5DaGFydGVyOiBMU1ZSIC0gTGluayBTdGF0ZSBWZWN0b3IgUm91dGlu ZyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlRoZSBM aW5rLVN0YXRlIFZlY3RvciBSb3V0aW5nIChMU1ZSKSBXb3JraW5nIEdyb3VwIGlzIGNoYXJ0ZXJl ZCB0byBkZXZlbG9wIGFuZCBkb2N1bWVudCBhIGh5YnJpZCByb3V0aW5nIHByb3RvY29sIHV0aWxp emluZyBhIGNvbWJpbmF0aW9uIG9mIGxpbmstc3RhdGUgYW5kIHBhdGgtdmVjdG9yIHJvdXRpbmcg bWVjaGFuaXNtcy4gJm5ic3A7VGhlDQogTFNWUiBXRyB3aWxsIHV0aWxpemUgZXhpc3RpbmcgdGhl IElQdjQvSVB2NiB0cmFuc3BvcnQsIHBhY2tldCBmb3JtYXRzLCBhbmQgZXJyb3IgaGFuZGxpbmcg ZnJvbSBCR1AtNCAoUkZDNDI3MSkuIEFkZGl0aW9uYWxseSwgdGhlJm5ic3A7QkdQLUxTIE5MUkkg ZW5jb2RpbmcgbWVjaGFuaXNtcyBkZWZpbmVkIGluIFJGQzc3NTIgYXJlIHV0aWxpemVkJm5ic3A7 dG8gZmFjaWxpdGF0ZSBMaW5rLVN0YXRlIFZlY3RvciAoTFNWKSByb3V0aW5nIGluZm9ybWF0aW9u IGRpc3RyaWJ1dGlvbi4NCiBBbiBMU1YgaXMgaW50ZW5kZWQgdG8gYmUgc3BlY2lmaWVkIGFzIGEg ZGF0YSBzdHJ1Y3R1cmUgY29tcHJpc2VkIG9mIGEgbGluayBpZGVudGlmaWNhdGlvbiwgbGluayBh dHRyaWJ1dGVzLCBuZWlnaGJvciBpbmZvcm1hdGlvbiwgY29zdCB0b3dhcmQgbmVpZ2hib3JzLCBh bmQgb3RoZXIgYXR0cmlidXRlcyB0aGF0IGFyZSBkZWZpbmVkIGZvciBjb250cm9sIHBsYW5lIGZ1 bmN0aW9uIGFuZCBwb2xpY3ktYmFzZWQgcm91dGluZyBkZWNpc2lvbnMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VGhlIExTVlIgc3BlY2lmaWNhdGlvbiBpcyBp bml0aWFsbHkgZm9jdXNlZCBvbiBvcGVyYXRpb24gd2l0aGluIGEgc2luZ2xlIGRhdGFjZW50ZXIg KERDKSB3aXRoIHByZWxpbWluYXJ5IGZvY3VzIG9uIHNwZWNpZnlpbmcgZnVuY3Rpb25hbGl0eSB3 aXRoaW4gYSBzaW5nbGUgZGlzdHJpYnV0aW9uIGRvbWFpbi4gJm5ic3A7Um91dGluZyBwcm90b2Nv bA0KIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZCBieSBMU1ZSIHdvdWxkIGJlIHR5cGljYWxseSByb3V0 aW5nIHdpdGhpbiBhIGRhdGFjZW50ZXIncyB1bmRlcmxheSByb3V0aW5nIHBsYW5lLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkluIG9yZGVyIHRvIGFj aGlldmUgdGhlIG5vdGVkIG9iamVjdGl2ZSwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBmb2N1cyBv biBzdGFuZGFyZGl6YXRpb24gb2YgcHJvdG9jb2wgZnVuY3Rpb25hbGl0eSwgZGVmaW5pbmcgTGlu ay1TdGF0ZSBWZWN0b3JzIChMU1ZzKSwgYW5kIGRlZmluaW5nIHN0YW5kYXJkIHBhdGgtdmVjdG9y IHJvdXRlDQogc2VsZWN0aW9uIHV0aWxpemluZyBleGlzdGluZyBEaWprc3RyYSBTUEYgYmFzZWQg YWxnb3JpdGhtLCBCR1AtNCBwcm90b2NvbCBtZWNoYW5pY3MsIGFuZCBCR1AtTFMgTlJMSSBlbmNv ZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5Gb3IgdGhl IHB1cnBvc2VzIG9mIHRoZSBpbml0aWFsIHdvcmsgd2l0aGluIHRoZSBMU1ZSIFdHLCBhbmQgdW50 aWwgZnVydGhlciBzcGVjaWZpZWQgYnkgdGhlIFdHLCB0aGUgZm9sbG93aW5nIGRlZmluaXRpb25z IGFwcGx5IHRvIHRoaXMgY2hhcnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij4tIExpbmstU3RhdGUgVmVjdG9yIC0gQW4gTFNWIGlzIGludGVuZGVkIHRvIHJl cHJlc2VudCBhIGRhdGEgc3RydWN0dXJlIChkYXRhIHNldCkgY29tcHJpc2VkIG9mIGxpbmsgaWRl bnRpZmljYXRpb24sIGxpbmsgYXR0cmlidXRlcywgbmVpZ2hib3IgaW5mb3JtYXRpb24sIGNvc3Qg dG93YXJkcyBuZWlnaGJvcnMsIGFuZCBvdGhlciBwb3RlbnRpYWwNCiBhdHRyaWJ1dGVzIHRoYXQg Y2FuIGJlIHV0aWxpemVkIHRvIG1ha2Ugcm91dGluZyBkZWNpc2lvbnMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+LSBMU1ZSIERpc3RyaWJ1dGlvbiBEb21h aW4gLSBJbml0aWFsbHkgc2NvcGVkIGFzIGEgc2V0IG9mIHBhcnRpY2lwYXRpbmcgTFNWUiBub2Rl cyBpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+VGhlIExTVlIgV0cgaXMgY2hhcnRlcmVkIHRvIGRlbGl2ZXIg dGhlIGZvbGxvd2luZyBkb2N1bWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+LSBQdWJsaXNoIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50IGZvciB0aGUgdXNl IG9mIExTVlIgaW4gdGhlIERhdGFjZW50ZXIgLSBUYXJnZXQgU3RhdHVzOiBJbmZvcm1hdGlvbmFs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+LSBQdWJsaXNo IHNwZWNpZmljYXRpb24gZG9jdW1lbnQgZGVzY3JpYmluZyBMU1Ygd2l0aCBzdGFuZGFyZCBEaWpr c3RyYSBTUEYgcm91dGUvcGF0aCBzZWxlY3Rpb24gKGNhbGN1bGF0aW9uKSB1dGlsaXppbmcgZXhp c3RpbmcgQkdQIHByb3RvY29sIGJhc2VsaW5lIGZ1bmN0aW9uYWxpdHkgYW5kIEJHUC1MUyBwYWNr ZXQgZW5jb2RpbmcNCiBmb3JtYXRzIC0gVGFyZ2V0OiBTdGFuZGFyZHMgVHJhY2sgKEJhc2VkIG9u IGRyYWZ0IGRyYWZ0LWtleXVwYXRlLWlkci1iZ3Atc3BmKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPi0gUHVibGlzaCBzcGVjaWZpY2F0aW9uIGRvY3VtZW50 aW5nIHByb3RvY29sIGV4dGVuc2lvbnMgcmVxdWlyZWQgdG8gZWZmaWNpZW50bHkgcmV1c2UgQkdQ IHRvIGRpc3RyaWJ1dGUgTFNWcyB3aXRoaW4gYW4gSVB2NC9JUHY2IERDIHdpdGggc2NvcGUgdG8g aW5jbHVkZSBwcml2YWN5IGFuZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyAtDQogLSBUYXJnZXQ6 IFN0YW5kYXJkcyBUcmFjazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPi0gUHVibGlzaCBZQU5HIG1vZGVsIHNwZWNpZmljYXRpb24gZm9yIExTVlIgLSAtIFRh cmdldDogU3RhbmRhcmRzIFRyYWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+TFNWUiBNaWxlc3RvbmVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPi0gQXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZm9yIExTVlIgaW4gRENzOiBN YXJjaCAyMDE5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ LSBMU1ZSIHdpdGggc3RhbmRhcmQgRGlqa3N0cmEgcGF0aCBzZWxlY3Rpb246IE1hcmNoIDIwMTk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4tIExTViBkaXN0 cmlidXRpb24gdXNpbmcgQkdQIHRyYW5zcG9ydDogTWFyY2ggMjAxOTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPi0gWUFORyBzcGVjaWZpY2F0aW9uIGZvciBM U1JWOiBKdWx5IDIwMTk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPklkciBtYWlsaW5nIGxpc3Q8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEg aHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+SWRyQGlldGYub3JnPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjwvc3Bhbj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_52BDDB18139A486CA3EF33C794DC4F5Aciscocom_-- From nobody Tue Jan 23 14:09:17 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7D012D850 for ; Tue, 23 Jan 2018 14:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1SiRg5spea1 for ; Tue, 23 Jan 2018 14:09:14 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 B510D12D851 for ; Tue, 23 Jan 2018 14:09:14 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id i66so1410683pfd.7 for ; Tue, 23 Jan 2018 14:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=By6DAuDt5zyUH+bQj+OVkCaFUdAuKLoSmZuS5JZZg6w=; b=Seaoa/cZiiUFE6aUYip+uzxH6UMvzs+vkmvKJEfX8/MRZh+qUlSkmYYhwW1LTlzDVk dnEnWjHwYl3S9RSoDlegmsjkrqQ05YTovgNPw8ZtI5FHJwO7ecI3N7hK/fW7QmrBKArZ kpSligfS/i3apHVLaCZyi8/IXkqB5tTBSAjjdbYFAiw2QXw4z2hEEOzTV/d562KdSOdJ meF2AjzIZjcaSltjUHRxBYg65RGzurlox9vUvQ2qQ/5V6WEaBHLmAYGuRxLrfrGwTvlG /nQ2UArS/LvbRFszeRWyt5AWIOMWfh+iWduCpE0NK63k0oE/e+DaBeANBA4Sq4U1hzVJ 4V5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=By6DAuDt5zyUH+bQj+OVkCaFUdAuKLoSmZuS5JZZg6w=; b=TXuOksxcNeZslbh8ueEjEZBNoM3owzsTHmMaOGg2hz+TGX3IlZxgVJmnnB3w5zXcPP +E/TdJJ9fDTLB+DFT5hbY/3SX3HEGegdNSF+FmZS/syWJt0mAMjud78haI57qsN1quYt sJAN6m7TNf5Ggh2Lvdp+yAOjdGTkgivW+d+kwBV3qakb9mR2mLQtogGT5n9BRWesq0DK U+u4fw4qyxq3dw+QOQvvUg9tdUItNZgCezPGpLxnCRfHz2GUOG2QN1O7XfQilpFbXod2 6U0qvIfsoBxd/VVBOdXpykc9vkC76gLYSNXvapxQMiOad5LqlCQoTyWxxq4E0rtf4iWo WOcQ== X-Gm-Message-State: AKwxytcEmjp7EhnZ5o9G12igZSPBVEjVdxLCCjtpiZuZqx8TK/0YbXTZ 88lhvPYCyNzYD6xWeiglZiQ= X-Google-Smtp-Source: AH8x227lODVj0rEVP8A63zPtX8jG1rrSUm8J86Jei2csRiWKQTT/q0voxsN9xdL4/VJc4/z7LbFKzA== X-Received: by 10.99.123.27 with SMTP id w27mr9500423pgc.49.1516745354245; Tue, 23 Jan 2018 14:09:14 -0800 (PST) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id k195sm26639343pgc.61.2018.01.23.14.09.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jan 2018 14:09:13 -0800 (PST) From: Tony Li Message-Id: <6F7FAE9D-6080-4636-A4BE-A77A2EA65B46@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9942FF6C-FBEA-4AA0-A009-7BD8556A7152" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 23 Jan 2018 14:09:12 -0800 In-Reply-To: <43088d7a0d2c44038d4d6bdcce4fca9a@XCH-ALN-014.cisco.com> Cc: "dcrouting@ietf.org" To: "Jakob Heitz (jheitz)" References: <43088d7a0d2c44038d4d6bdcce4fca9a@XCH-ALN-014.cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Dcrouting] New Version Notification for draft-li-dynamic-flooding-01.txt X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 22:09:16 -0000 --Apple-Mail=_9942FF6C-FBEA-4AA0-A009-7BD8556A7152 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jakob, Thank you for the kind words! > This looks to me like a good idea. > It does not require a separate management network. > A small flooding topology would be a spanning tree. > This would assume that upon a link failure, both ends of a p2p link = detect the failure and send an LSA within an acceptable time. Which is possible, but it also implies that systems on the other side of = the failure would only see one side of the failure immediately and the = other side might take some time to propagate. While SPF might still = calculate good results, I would definitely prefer to see a fully = consistent database sooner rather than later. Also, if there is a second = failure on the far side of the first failure, that might be invisible = for some time. > If not, then I would add a second link to any nodes that have only one = link in the spanning tree. And this is why I suggested a cyclic topology with minimal diameter and = minimal node degree. Tony --Apple-Mail=_9942FF6C-FBEA-4AA0-A009-7BD8556A7152 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Jakob,

Thank you for the kind words!

This looks to me like a good idea.
It does not require a = separate management network.
A small flooding topology would be a = spanning tree.
This would assume that = upon a link failure, both ends of a p2p link detect the failure and send = an LSA within an acceptable = time.


Which is possible, but it also implies that = systems on the other side of the failure would only see one side of the = failure immediately and the other side might take some time to = propagate. While SPF might still calculate good results, I would = definitely prefer to see a fully consistent database sooner rather than = later. Also, if there is a second failure on the far side of the first = failure, that might be invisible for some time.


If not, then I would add a second link to = any nodes that have only one link in the spanning = tree.


And this is why I = suggested a cyclic topology with minimal diameter and minimal node = degree.

Tony


= --Apple-Mail=_9942FF6C-FBEA-4AA0-A009-7BD8556A7152-- From nobody Tue Jan 23 15:58:20 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D5112D811 for ; Tue, 23 Jan 2018 15:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 SIOCobGZ00Jg for ; Tue, 23 Jan 2018 15:58:13 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBE112D940 for ; Tue, 23 Jan 2018 15:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8365; q=dns/txt; s=iport; t=1516751893; x=1517961493; h=from:to:subject:date:message-id:mime-version; bh=wqWBXfhQrfFccoTKqJznUJuQOoMtaxAxHhZMYFdtEbM=; b=djSPzzsghP2GEzsukriUwIB8/EeAN7xKaSqZdPj42cd7rB+Ta8a6GSle qAmVHmaGzKuUvKexzJeoYlCJjz0yzNbrPWvV0sqICkbIi6Y4IQ5ZtLSf4 lxcFqCENL+2DJOievGVABqZS/5PQiV19jS8+f63gF3t459lvqPxIINNDA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BhAQBHy2da/4YNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRzFmdC6Neo5lk2yFVIIXCoozVBgBAQEBAQEBAQJrHQuFJAY?= =?us-ascii?q?tXgEIeCYBBBuJSWS1W4pVAQEBAQYBAQEBAQEihEuCFYFXgWiDLoseBaN+ApVSl?= =?us-ascii?q?CyXIwIRGQGBOwEfOT+BEXAVgmiEVo17gRcBAQE?= X-IronPort-AV: E=Sophos; i="5.46,403,1511827200"; d="scan'208,217"; a="60181387" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2018 23:58:12 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w0NNwCEH025637 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Jan 2018 23:58:12 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 23 Jan 2018 17:58:11 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Tue, 23 Jan 2018 17:58:12 -0600 From: "Jakob Heitz (jheitz)" To: "dcrouting@ietf.org" Thread-Topic: Re: DC Routing requirements draft Thread-Index: AdOUomg9Bp6KcO+RQf69MwGkCayIdQ== Date: Tue, 23 Jan 2018 23:58:11 +0000 Message-ID: <00db7d5f09b5415ebb42c73e42d2baf6@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.198.47] Content-Type: multipart/alternative; boundary="_000_00db7d5f09b5415ebb42c73e42d2baf6XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dcrouting] DC Routing requirements draft X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 23:58:15 -0000 --_000_00db7d5f09b5415ebb42c73e42d2baf6XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-dt-rtgwg-dcrouting-requirements I'd like to expand on the ZTP requirement. It is ok to pre-configure devices with items such as a unique identifier, c= apabilities, port types and so on. It is not ok to require any of the configured items to depend upon the loca= tion of the device in the topology. In other words, it should be possible to remove a device from any part of t= he network and put it into another part of the network without any manual c= onfiguration. The auto-configuration protocol should recognize the move and= reconfigure a moved device. It should be possible to have multiple networks that are individually auto-= configured to be connected to each other in such a way that the auto-config= uration of one network does not interfere with the auto-configuration of an= adjoining network. The DC routing protocol should be able to auto-configure and route multiple= CLOS networks that are interconnected with a loose data-center-interconnec= t (DCI) network. The auto-configuration protocol should be able to discover= and configure all the datacenters in a DCI as a single network. The auto-configuration protocol should not require a dedicated (out-of-band= ) network. Each device should not be required to know the topology outside of its imme= diate neighbors. It should be sufficient for a device to know about distant= devices in the aggregate. Specific knowledge of certain distant devices sh= ould be for special cases only. For example, a network controller is expect= ed to know precise topology information about its domain of control. In par= ticular, each device must not store a complete link state database of the w= hole network or IP addresses of every leaf in the datacenter. Thanks, Jakob --_000_00db7d5f09b5415ebb42c73e42d2baf6XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments on dr= aft-dt-rtgwg-dcrouting-requirements

 

I'd like to expand on the ZTP requirement.

It is ok to pre-configure devices with items= such as a unique identifier, capabilities, port types and so on.

It is not ok to require any of the configure= d items to depend upon the location of the device in the topology.

In other words, it should be possible to rem= ove a device from any part of the network and put it into another part of t= he network without any manual configuration. The auto-configuration protocol should recognize the move and reconfigure a mo= ved device.

 

It should be possible to have multiple netwo= rks that are individually auto-configured to be connected to each other in = such a way that the auto-configuration of one network does not interfere with the auto-configuration of an adjoining net= work.

 

The DC routing protocol should be able to au= to-configure and route multiple CLOS networks that are interconnected with = a loose data-center-interconnect (DCI) network. The auto-configuration protocol should be able to discover and configure a= ll the datacenters in a DCI as a single network.

 

The auto-configuration protocol should not r= equire a dedicated (out-of-band) network.

 

Each device should not be required to know t= he topology outside of its immediate neighbors. It should be sufficient for= a device to know about distant devices in the aggregate. Specific knowledge of certain distant devices should be for spe= cial cases only. For example, a network controller is expected to know prec= ise topology information about its domain of control. In particular, each d= evice must not store a complete link state database of the whole network or IP addresses of every leaf in = the datacenter.

 

Thanks,

Jakob

 

--_000_00db7d5f09b5415ebb42c73e42d2baf6XCHALN014ciscocom_-- From nobody Tue Jan 23 16:12:37 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E747512D88E for ; Tue, 23 Jan 2018 16:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 Qf9pgDOEPtBR for ; Tue, 23 Jan 2018 16:12:33 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 4EF5812D811 for ; Tue, 23 Jan 2018 16:12:33 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id r71so5182865wmd.1 for ; Tue, 23 Jan 2018 16:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pan64OVMnF30WDKmThA31oQHeP6zIbF4QvaKntcsw8o=; b=Rv+UN3sVmCZOqs7Iszg93yC5bQH9MNArOFOKn4zCZIoowbxpeWA0ANYLWxyEA0BFLd 0IgZoXGhEA2u/s6cqzJgVZaMMCFmXRhVI4MhwNLXNeMsZTH2zIFfCK27eC2p6u3O+2Mh J7dMPQB5B4ttDDueLpC4atEky504Q+ti3sg2snNNlKaVuSmLOP5jrZ4Gmd+8avhoGMi+ Ii1OWD2rB4DGhmboaXgNkT8f74OOX3FQtdqsOkvkcYMijqahieMgtGudL0yV2f33dRGZ MU/WlNL7IP/n8FwnnB6orXAMXcpMS1ivmf/cgm1+yLaMYbt6ITdex3X+QSReqxOcOojJ J/jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pan64OVMnF30WDKmThA31oQHeP6zIbF4QvaKntcsw8o=; b=KmXhRHiPs//vZaF0Iahj2BBis/wzibnmZMY9gqVyB3tASfNjBEGofqSnD34NW/WGNs Rz8DKLDeqh89jzREx7ZS7qAqdnVVSzHxcbtA++ZqnM8ws8vPZ3106p5SoPUVsEK8ul9D wMz+b4MN02vTEQHZyZfeOkpz9L6pNw5oVJ+vq6BKjgNUPku2v1PzUejEBep6fPoGNGYm Mzm53OObjL3tGCeF+gNxYJK5M+8bylqf64n5mfL2B7jIDI99ht7BSYN0eXVgfCyvW0u+ 43c4HJThetYrqPPxI54SXJhEpao1uBE8edhxW/ATgxMOB52I7a4Y3tVoKatMUA99/fiY qrpg== X-Gm-Message-State: AKwxytd17lnNrlClsOJBh8AXM2piRtjk1NwuykARReoRXkanr+bwYOY8 6ad9s9FBNXGV5SSrMZ5bPmMtFuSec2AUrQwdOW8= X-Google-Smtp-Source: AH8x226ZQP+TcPsrU4NL2oREcq+Ams8d9qLsApgUT4rL9Bm6TyzA1MkeApDOZXeVgiu6JkpkwJ7d0g6/19+UG4nGuB4= X-Received: by 10.80.217.10 with SMTP id t10mr21606125edj.171.1516752751865; Tue, 23 Jan 2018 16:12:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.239 with HTTP; Tue, 23 Jan 2018 16:11:51 -0800 (PST) In-Reply-To: <00db7d5f09b5415ebb42c73e42d2baf6@XCH-ALN-014.cisco.com> References: <00db7d5f09b5415ebb42c73e42d2baf6@XCH-ALN-014.cisco.com> From: Tony Przygienda Date: Tue, 23 Jan 2018 16:11:51 -0800 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "dcrouting@ietf.org" Content-Type: multipart/alternative; boundary="089e08220f18fcb34f05637a84c9" Archived-At: Subject: Re: [Dcrouting] DC Routing requirements draft X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 00:12:36 -0000 --089e08220f18fcb34f05637a84c9 Content-Type: text/plain; charset="UTF-8" Largely agreed. One observation only. Trying to extend a single ZTP over a very large area like DCI IMO is a perilous idea due to the lack of separation of the fabrics (i.e. if that implies that one device flap could shake another DC fabric that way) ... DCI ZTP is probably a different problem than DC fabric ZTP due to the fact that fabrics internally are ideally run on private addressing or even no addressing at all (or only local addressing if must be). DCI is more of a public address problem IMO but one could argue against that as well if the DCIs extend over LSPs or some kind of overlay ... thanks --- tony On Tue, Jan 23, 2018 at 3:58 PM, Jakob Heitz (jheitz) wrote: > Comments on draft-dt-rtgwg-dcrouting-requirements > > > > I'd like to expand on the ZTP requirement. > > It is ok to pre-configure devices with items such as a unique identifier, > capabilities, port types and so on. > > It is not ok to require any of the configured items to depend upon the > location of the device in the topology. > > In other words, it should be possible to remove a device from any part of > the network and put it into another part of the network without any manual > configuration. The auto-configuration protocol should recognize the move > and reconfigure a moved device. > > > > It should be possible to have multiple networks that are individually > auto-configured to be connected to each other in such a way that the > auto-configuration of one network does not interfere with the > auto-configuration of an adjoining network. > > > > The DC routing protocol should be able to auto-configure and route > multiple CLOS networks that are interconnected with a loose > data-center-interconnect (DCI) network. The auto-configuration protocol > should be able to discover and configure all the datacenters in a DCI as a > single network. > > > > The auto-configuration protocol should not require a dedicated > (out-of-band) network. > > > > Each device should not be required to know the topology outside of its > immediate neighbors. It should be sufficient for a device to know about > distant devices in the aggregate. Specific knowledge of certain distant > devices should be for special cases only. For example, a network controller > is expected to know precise topology information about its domain of > control. In particular, each device must not store a complete link state > database of the whole network or IP addresses of every leaf in the > datacenter. > > > > Thanks, > > Jakob > > > > _______________________________________________ > Dcrouting mailing list > Dcrouting@ietf.org > https://www.ietf.org/mailman/listinfo/dcrouting > > --089e08220f18fcb34f05637a84c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Largely agreed. One observation only.=C2=A0
=
Trying to extend a single ZTP over a very large area like DCI IMO is a = perilous idea due to the lack of separation of the fabrics (i.e. if that im= plies that one device flap could shake another DC fabric that way) ... DCI = ZTP is probably a different problem than DC fabric ZTP due to the fact that= fabrics internally are ideally run on private addressing or even no addres= sing at all (or only local addressing if must be). DCI is more of a public = address problem IMO but one could argue against that as well if the DCIs ex= tend over LSPs or some kind of overlay ...

thanks

--- tony

On Tue, Jan 23, 2018 at 3:58 PM, Jakob Heitz (jheitz) <jheitz@cisco.co= m> wrote:

Comments on dr= aft-dt-rtgwg-dcrouting-requirements

=C2=A0

I'd like to expand on the ZTP requiremen= t.

It is ok to pre-configure devices with items= such as a unique identifier, capabilities, port types and so on.=

It is not ok to require any of the configure= d items to depend upon the location of the device in the topology.

In other words, it should be possible to rem= ove a device from any part of the network and put it into another part of t= he network without any manual configuration. The auto-configuration protocol should recognize the move and reconfigure a mo= ved device.

=C2=A0

It should be possible to have multiple netwo= rks that are individually auto-configured to be connected to each other in = such a way that the auto-configuration of one network does not interfere with the auto-configuration of an adjoining net= work.

=C2=A0

The DC routing protocol should be able to au= to-configure and route multiple CLOS networks that are interconnected with = a loose data-center-interconnect (DCI) network. The auto-configuration protocol should be able to discover and configure a= ll the datacenters in a DCI as a single network.

=C2=A0

The auto-configuration protocol should not r= equire a dedicated (out-of-band) network.

=C2=A0

Each device should not be required to know t= he topology outside of its immediate neighbors. It should be sufficient for= a device to know about distant devices in the aggregate. Specific knowledge of certain distant devices should be for spe= cial cases only. For example, a network controller is expected to know prec= ise topology information about its domain of control. In particular, each d= evice must not store a complete link state database of the whole network or IP addresses of every leaf in = the datacenter.

=C2=A0

Thanks,

Jakob

=C2=A0


_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>


--089e08220f18fcb34f05637a84c9-- From nobody Tue Jan 23 16:19:29 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4221F12D7F6 for ; Tue, 23 Jan 2018 16:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Uoeg9SNe2g6C for ; Tue, 23 Jan 2018 16:19:26 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C674612D574 for ; Tue, 23 Jan 2018 16:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18860; q=dns/txt; s=iport; t=1516753165; x=1517962765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J9E3bmSjznZ+xag0VbSVd0RvbVr6aDy9xzZYRtvPuLY=; b=M1616AJutZuUBb91wa1rwhM75LxxpecaO6S3Yz70DQoMDgY2Mt16b2Qn GWSAb7WG9T6Gx8k4tC9i/753IN/tfTzYyp13vj2GFXnbbH1WZd7SnPO+t gWZqbrFT/iOhgUy1wFfa/DdWzvWFAWPGUyT70SqVUMl3A5ADDc99mdJul M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AwDGz2da/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRzFmdCcHg1aZCYICiQ+IW4VUghcKGAEKhElPAhqEXFYWAQE?= =?us-ascii?q?BAQEBAQECayiFIwEBAQQBASEKQQsQAgEIEQQBASgDAgICHwYLFAkIAgQOBQiJS?= =?us-ascii?q?UwDFRCzM4Inh0MNgwUBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYRLghWBV4Fogy6?= =?us-ascii?q?Ca0QBAQKCJYJhgmUFi2OXXj0CkFaEfJQsjhqJCQIRGQGBOwEmBS0/gRFwFT2CK?= =?us-ascii?q?gmETniNA4EXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,404,1511827200"; d="scan'208,217";a="129012896" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 00:19:24 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w0O0JO9k001080 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jan 2018 00:19:24 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 23 Jan 2018 18:19:24 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Tue, 23 Jan 2018 18:19:24 -0600 From: "Jakob Heitz (jheitz)" To: Tony Przygienda CC: "dcrouting@ietf.org" Thread-Topic: [Dcrouting] DC Routing requirements draft Thread-Index: AQHTlKgJ7bHCAkVu5UmqDxkZ80WB/6OCJzFQ Date: Wed, 24 Jan 2018 00:19:24 +0000 Message-ID: <1ab7acef55f34c4588b19c516a4c919a@XCH-ALN-014.cisco.com> References: <00db7d5f09b5415ebb42c73e42d2baf6@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.198.47] Content-Type: multipart/alternative; boundary="_000_1ab7acef55f34c4588b19c516a4c919aXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dcrouting] DC Routing requirements draft X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 00:19:28 -0000 --_000_1ab7acef55f34c4588b19c516a4c919aXCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGxpa2VsaWhvb2Qgb2YgYSBwZXJ0dXJiYXRpb24gaW4gb25lIHBhcnQgb2YgdGhlIG5ldHdv cmsgc2hha2luZyBzb21ldGhpbmcgZGlzdGFudCBpcyBvbmUgcmVhc29uIEkgYWRkZWQgdGhhdCBh IGRldmljZSBzaG91bGQgb25seSBrbm93IGFib3V0IGRpc3RhbnQgZGV2aWNlcyBpbiB0aGUgYWdn cmVnYXRlLiBZb3UgY291bGQgbWFrZSBpdCBtb3JlIGV4cGxpY2l0OiBUaGUgYmxhc3QgcmFkaXVz IG9mIGEgZmFpbHVyZSBzaG91bGQgYmUgc21hbGwuIEl0J3MgYSBiaXQgZGlmZmljdWx0IHRvIHNw ZWNpZnkgZXhhY3RseSBob3cgc21hbGwuDQoNClRoYW5rcywNCkpha29iDQoNCkZyb206IFRvbnkg UHJ6eWdpZW5kYSBbbWFpbHRvOnRvbnlzaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBK YW51YXJ5IDIzLCAyMDE4IDQ6MTIgUE0NClRvOiBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6 QGNpc2NvLmNvbT4NCkNjOiBkY3JvdXRpbmdAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGNyb3V0 aW5nXSBEQyBSb3V0aW5nIHJlcXVpcmVtZW50cyBkcmFmdA0KDQpMYXJnZWx5IGFncmVlZC4gT25l IG9ic2VydmF0aW9uIG9ubHkuDQoNClRyeWluZyB0byBleHRlbmQgYSBzaW5nbGUgWlRQIG92ZXIg YSB2ZXJ5IGxhcmdlIGFyZWEgbGlrZSBEQ0kgSU1PIGlzIGEgcGVyaWxvdXMgaWRlYSBkdWUgdG8g dGhlIGxhY2sgb2Ygc2VwYXJhdGlvbiBvZiB0aGUgZmFicmljcyAoaS5lLiBpZiB0aGF0IGltcGxp ZXMgdGhhdCBvbmUgZGV2aWNlIGZsYXAgY291bGQgc2hha2UgYW5vdGhlciBEQyBmYWJyaWMgdGhh dCB3YXkpIC4uLiBEQ0kgWlRQIGlzIHByb2JhYmx5IGEgZGlmZmVyZW50IHByb2JsZW0gdGhhbiBE QyBmYWJyaWMgWlRQIGR1ZSB0byB0aGUgZmFjdCB0aGF0IGZhYnJpY3MgaW50ZXJuYWxseSBhcmUg aWRlYWxseSBydW4gb24gcHJpdmF0ZSBhZGRyZXNzaW5nIG9yIGV2ZW4gbm8gYWRkcmVzc2luZyBh dCBhbGwgKG9yIG9ubHkgbG9jYWwgYWRkcmVzc2luZyBpZiBtdXN0IGJlKS4gRENJIGlzIG1vcmUg b2YgYSBwdWJsaWMgYWRkcmVzcyBwcm9ibGVtIElNTyBidXQgb25lIGNvdWxkIGFyZ3VlIGFnYWlu c3QgdGhhdCBhcyB3ZWxsIGlmIHRoZSBEQ0lzIGV4dGVuZCBvdmVyIExTUHMgb3Igc29tZSBraW5k IG9mIG92ZXJsYXkgLi4uDQp0aGFua3MNCi0tLSB0b255DQoNCk9uIFR1ZSwgSmFuIDIzLCAyMDE4 IGF0IDM6NTggUE0sIEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPG1haWx0 bzpqaGVpdHpAY2lzY28uY29tPj4gd3JvdGU6DQpDb21tZW50cyBvbiBkcmFmdC1kdC1ydGd3Zy1k Y3JvdXRpbmctcmVxdWlyZW1lbnRzDQoNCkknZCBsaWtlIHRvIGV4cGFuZCBvbiB0aGUgWlRQIHJl cXVpcmVtZW50Lg0KSXQgaXMgb2sgdG8gcHJlLWNvbmZpZ3VyZSBkZXZpY2VzIHdpdGggaXRlbXMg c3VjaCBhcyBhIHVuaXF1ZSBpZGVudGlmaWVyLCBjYXBhYmlsaXRpZXMsIHBvcnQgdHlwZXMgYW5k IHNvIG9uLg0KSXQgaXMgbm90IG9rIHRvIHJlcXVpcmUgYW55IG9mIHRoZSBjb25maWd1cmVkIGl0 ZW1zIHRvIGRlcGVuZCB1cG9uIHRoZSBsb2NhdGlvbiBvZiB0aGUgZGV2aWNlIGluIHRoZSB0b3Bv bG9neS4NCkluIG90aGVyIHdvcmRzLCBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gcmVtb3ZlIGEg ZGV2aWNlIGZyb20gYW55IHBhcnQgb2YgdGhlIG5ldHdvcmsgYW5kIHB1dCBpdCBpbnRvIGFub3Ro ZXIgcGFydCBvZiB0aGUgbmV0d29yayB3aXRob3V0IGFueSBtYW51YWwgY29uZmlndXJhdGlvbi4g VGhlIGF1dG8tY29uZmlndXJhdGlvbiBwcm90b2NvbCBzaG91bGQgcmVjb2duaXplIHRoZSBtb3Zl IGFuZCByZWNvbmZpZ3VyZSBhIG1vdmVkIGRldmljZS4NCg0KSXQgc2hvdWxkIGJlIHBvc3NpYmxl IHRvIGhhdmUgbXVsdGlwbGUgbmV0d29ya3MgdGhhdCBhcmUgaW5kaXZpZHVhbGx5IGF1dG8tY29u ZmlndXJlZCB0byBiZSBjb25uZWN0ZWQgdG8gZWFjaCBvdGhlciBpbiBzdWNoIGEgd2F5IHRoYXQg dGhlIGF1dG8tY29uZmlndXJhdGlvbiBvZiBvbmUgbmV0d29yayBkb2VzIG5vdCBpbnRlcmZlcmUg d2l0aCB0aGUgYXV0by1jb25maWd1cmF0aW9uIG9mIGFuIGFkam9pbmluZyBuZXR3b3JrLg0KDQpU aGUgREMgcm91dGluZyBwcm90b2NvbCBzaG91bGQgYmUgYWJsZSB0byBhdXRvLWNvbmZpZ3VyZSBh bmQgcm91dGUgbXVsdGlwbGUgQ0xPUyBuZXR3b3JrcyB0aGF0IGFyZSBpbnRlcmNvbm5lY3RlZCB3 aXRoIGEgbG9vc2UgZGF0YS1jZW50ZXItaW50ZXJjb25uZWN0IChEQ0kpIG5ldHdvcmsuIFRoZSBh dXRvLWNvbmZpZ3VyYXRpb24gcHJvdG9jb2wgc2hvdWxkIGJlIGFibGUgdG8gZGlzY292ZXIgYW5k IGNvbmZpZ3VyZSBhbGwgdGhlIGRhdGFjZW50ZXJzIGluIGEgRENJIGFzIGEgc2luZ2xlIG5ldHdv cmsuDQoNClRoZSBhdXRvLWNvbmZpZ3VyYXRpb24gcHJvdG9jb2wgc2hvdWxkIG5vdCByZXF1aXJl IGEgZGVkaWNhdGVkIChvdXQtb2YtYmFuZCkgbmV0d29yay4NCg0KRWFjaCBkZXZpY2Ugc2hvdWxk IG5vdCBiZSByZXF1aXJlZCB0byBrbm93IHRoZSB0b3BvbG9neSBvdXRzaWRlIG9mIGl0cyBpbW1l ZGlhdGUgbmVpZ2hib3JzLiBJdCBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgYSBkZXZpY2UgdG8g a25vdyBhYm91dCBkaXN0YW50IGRldmljZXMgaW4gdGhlIGFnZ3JlZ2F0ZS4gU3BlY2lmaWMga25v d2xlZGdlIG9mIGNlcnRhaW4gZGlzdGFudCBkZXZpY2VzIHNob3VsZCBiZSBmb3Igc3BlY2lhbCBj YXNlcyBvbmx5LiBGb3IgZXhhbXBsZSwgYSBuZXR3b3JrIGNvbnRyb2xsZXIgaXMgZXhwZWN0ZWQg dG8ga25vdyBwcmVjaXNlIHRvcG9sb2d5IGluZm9ybWF0aW9uIGFib3V0IGl0cyBkb21haW4gb2Yg Y29udHJvbC4gSW4gcGFydGljdWxhciwgZWFjaCBkZXZpY2UgbXVzdCBub3Qgc3RvcmUgYSBjb21w bGV0ZSBsaW5rIHN0YXRlIGRhdGFiYXNlIG9mIHRoZSB3aG9sZSBuZXR3b3JrIG9yIElQIGFkZHJl c3NlcyBvZiBldmVyeSBsZWFmIGluIHRoZSBkYXRhY2VudGVyLg0KDQpUaGFua3MsDQpKYWtvYg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEY3Jv dXRpbmcgbWFpbGluZyBsaXN0DQpEY3JvdXRpbmdAaWV0Zi5vcmc8bWFpbHRvOkRjcm91dGluZ0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGNyb3V0aW5n DQoNCg== --_000_1ab7acef55f34c4588b19c516a4c919aXCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJY29sb3I6IzcwMzBBMDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhlIGxpa2VsaWhv b2Qgb2YgYSBwZXJ0dXJiYXRpb24gaW4gb25lIHBhcnQgb2YgdGhlIG5ldHdvcmsgc2hha2luZyBz b21ldGhpbmcgZGlzdGFudCBpcyBvbmUgcmVhc29uIEkgYWRkZWQgdGhhdCBhIGRldmljZSBzaG91 bGQgb25seSBrbm93DQogYWJvdXQgZGlzdGFudCBkZXZpY2VzIGluIHRoZSBhZ2dyZWdhdGUuIFlv dSBjb3VsZCBtYWtlIGl0IG1vcmUgZXhwbGljaXQ6IFRoZSBibGFzdCByYWRpdXMgb2YgYSBmYWls dXJlIHNob3VsZCBiZSBzbWFsbC4gSXQncyBhIGJpdCBkaWZmaWN1bHQgdG8gc3BlY2lmeSBleGFj dGx5IGhvdyBzbWFsbC48bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9z ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SmFrb2I8bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVG9ueSBQcnp5Z2llbmRh IFttYWlsdG86dG9ueXNpZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBKYW51YXJ5IDIzLCAyMDE4IDQ6MTIgUE08YnI+DQo8Yj5Ubzo8L2I+IEpha29iIEhlaXR6IChq aGVpdHopICZsdDtqaGVpdHpAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gZGNyb3V0aW5n QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRGNyb3V0aW5nXSBEQyBSb3V0aW5n IHJlcXVpcmVtZW50cyBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5MYXJnZWx5IGFncmVl ZC4gT25lIG9ic2VydmF0aW9uIG9ubHkuJm5ic3A7DQo8YnI+DQo8YnI+DQpUcnlpbmcgdG8gZXh0 ZW5kIGEgc2luZ2xlIFpUUCBvdmVyIGEgdmVyeSBsYXJnZSBhcmVhIGxpa2UgRENJIElNTyBpcyBh IHBlcmlsb3VzIGlkZWEgZHVlIHRvIHRoZSBsYWNrIG9mIHNlcGFyYXRpb24gb2YgdGhlIGZhYnJp Y3MgKGkuZS4gaWYgdGhhdCBpbXBsaWVzIHRoYXQgb25lIGRldmljZSBmbGFwIGNvdWxkIHNoYWtl IGFub3RoZXIgREMgZmFicmljIHRoYXQgd2F5KSAuLi4gRENJIFpUUCBpcyBwcm9iYWJseSBhIGRp ZmZlcmVudCBwcm9ibGVtDQogdGhhbiBEQyBmYWJyaWMgWlRQIGR1ZSB0byB0aGUgZmFjdCB0aGF0 IGZhYnJpY3MgaW50ZXJuYWxseSBhcmUgaWRlYWxseSBydW4gb24gcHJpdmF0ZSBhZGRyZXNzaW5n IG9yIGV2ZW4gbm8gYWRkcmVzc2luZyBhdCBhbGwgKG9yIG9ubHkgbG9jYWwgYWRkcmVzc2luZyBp ZiBtdXN0IGJlKS4gRENJIGlzIG1vcmUgb2YgYSBwdWJsaWMgYWRkcmVzcyBwcm9ibGVtIElNTyBi dXQgb25lIGNvdWxkIGFyZ3VlIGFnYWluc3QgdGhhdCBhcyB3ZWxsIGlmIHRoZQ0KIERDSXMgZXh0 ZW5kIG92ZXIgTFNQcyBvciBzb21lIGtpbmQgb2Ygb3ZlcmxheSAuLi4gPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+dGhhbmtzIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LS0gdG9ueSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFR1ZSwgSmFuIDIzLCAyMDE4IGF0IDM6NTggUE0sIEpha29iIEhlaXR6IChqaGVpdHopICZsdDs8 YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpoZWl0ekBj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+ Q29tbWVudHMgb24NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+ZHJhZnQtZHQtcnRnd2ctZGNyb3V0aW5nLXJlcXVp cmVtZW50czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5JJ2QgbGlrZSB0byBleHBh bmQgb24gdGhlIFpUUCByZXF1aXJlbWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPkl0IGlzIG9rIHRvIHByZS1j b25maWd1cmUgZGV2aWNlcyB3aXRoIGl0ZW1zIHN1Y2ggYXMgYSB1bmlxdWUgaWRlbnRpZmllciwg Y2FwYWJpbGl0aWVzLCBwb3J0IHR5cGVzIGFuZCBzbw0KIG9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SXQgaXMg bm90IG9rIHRvIHJlcXVpcmUgYW55IG9mIHRoZSBjb25maWd1cmVkIGl0ZW1zIHRvIGRlcGVuZCB1 cG9uIHRoZSBsb2NhdGlvbiBvZiB0aGUgZGV2aWNlIGluIHRoZSB0b3BvbG9neS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMw QTAiPkluIG90aGVyIHdvcmRzLCBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gcmVtb3ZlIGEgZGV2 aWNlIGZyb20gYW55IHBhcnQgb2YgdGhlIG5ldHdvcmsgYW5kIHB1dCBpdCBpbnRvIGFub3RoZXIN CiBwYXJ0IG9mIHRoZSBuZXR3b3JrIHdpdGhvdXQgYW55IG1hbnVhbCBjb25maWd1cmF0aW9uLiBU aGUgYXV0by1jb25maWd1cmF0aW9uIHByb3RvY29sIHNob3VsZCByZWNvZ25pemUgdGhlIG1vdmUg YW5kIHJlY29uZmlndXJlIGEgbW92ZWQgZGV2aWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj NzAzMEEwIj5JdCBzaG91bGQgYmUgcG9zc2libGUgdG8gaGF2ZSBtdWx0aXBsZSBuZXR3b3JrcyB0 aGF0IGFyZSBpbmRpdmlkdWFsbHkgYXV0by1jb25maWd1cmVkIHRvIGJlIGNvbm5lY3RlZCB0byBl YWNoDQogb3RoZXIgaW4gc3VjaCBhIHdheSB0aGF0IHRoZSBhdXRvLWNvbmZpZ3VyYXRpb24gb2Yg b25lIG5ldHdvcmsgZG9lcyBub3QgaW50ZXJmZXJlIHdpdGggdGhlIGF1dG8tY29uZmlndXJhdGlv biBvZiBhbiBhZGpvaW5pbmcgbmV0d29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBB MCI+VGhlIERDIHJvdXRpbmcgcHJvdG9jb2wgc2hvdWxkIGJlIGFibGUgdG8gYXV0by1jb25maWd1 cmUgYW5kIHJvdXRlIG11bHRpcGxlIENMT1MgbmV0d29ya3MgdGhhdCBhcmUgaW50ZXJjb25uZWN0 ZWQNCiB3aXRoIGEgbG9vc2UgZGF0YS1jZW50ZXItaW50ZXJjb25uZWN0IChEQ0kpIG5ldHdvcmsu IFRoZSBhdXRvLWNvbmZpZ3VyYXRpb24gcHJvdG9jb2wgc2hvdWxkIGJlIGFibGUgdG8gZGlzY292 ZXIgYW5kIGNvbmZpZ3VyZSBhbGwgdGhlIGRhdGFjZW50ZXJzIGluIGEgRENJIGFzIGEgc2luZ2xl IG5ldHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNzAzMEEwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlRoZSBhdXRvLWNvbmZp Z3VyYXRpb24gcHJvdG9jb2wgc2hvdWxkIG5vdCByZXF1aXJlIGEgZGVkaWNhdGVkIChvdXQtb2Yt YmFuZCkgbmV0d29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+RWFjaCBkZXZp Y2Ugc2hvdWxkIG5vdCBiZSByZXF1aXJlZCB0byBrbm93IHRoZSB0b3BvbG9neSBvdXRzaWRlIG9m IGl0cyBpbW1lZGlhdGUgbmVpZ2hib3JzLiBJdCBzaG91bGQgYmUgc3VmZmljaWVudA0KIGZvciBh IGRldmljZSB0byBrbm93IGFib3V0IGRpc3RhbnQgZGV2aWNlcyBpbiB0aGUgYWdncmVnYXRlLiBT cGVjaWZpYyBrbm93bGVkZ2Ugb2YgY2VydGFpbiBkaXN0YW50IGRldmljZXMgc2hvdWxkIGJlIGZv ciBzcGVjaWFsIGNhc2VzIG9ubHkuIEZvciBleGFtcGxlLCBhIG5ldHdvcmsgY29udHJvbGxlciBp cyBleHBlY3RlZCB0byBrbm93IHByZWNpc2UgdG9wb2xvZ3kgaW5mb3JtYXRpb24gYWJvdXQgaXRz IGRvbWFpbiBvZiBjb250cm9sLiBJbg0KIHBhcnRpY3VsYXIsIGVhY2ggZGV2aWNlIG11c3Qgbm90 IHN0b3JlIGEgY29tcGxldGUgbGluayBzdGF0ZSBkYXRhYmFzZSBvZiB0aGUgd2hvbGUgbmV0d29y ayBvciBJUCBhZGRyZXNzZXMgb2YgZXZlcnkgbGVhZiBpbiB0aGUgZGF0YWNlbnRlci48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3 MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SmFrb2I8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpEY3JvdXRpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOkRjcm91dGluZ0BpZXRmLm9yZyI+RGNyb3V0aW5nQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGNyb3V0aW5nIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kY3Jv dXRpbmc8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_1ab7acef55f34c4588b19c516a4c919aXCHALN014ciscocom_-- From nobody Tue Jan 23 17:46:49 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0E2120047; Tue, 23 Jan 2018 17:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 2wC6YbDKaLhh; Tue, 23 Jan 2018 17:46:39 -0800 (PST) Received: from out0-231.mail.aliyun.com (out0-231.mail.aliyun.com [140.205.0.231]) (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 1E277124205; Tue, 23 Jan 2018 17:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1516758392; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=1rPKhIM7S6bvbdpAbMR2eXpwkxE6t1n/icIFamzCcuo=; b=fCAJatUzvlrY1qZr+WcefFE0qhlVfYiv9/UF5zYqX16NxqUJAqVqK8pNxiKNQwbj1I++GHDLU7xA6yt89xykBAxeOLNks72RQ+ds5kZamGpWMhR4Am/chVZNW38RS+1hlOXql4P9VktFWmsMRW6oNVfkdQFYZEg8uSm6C/LVY98= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R351e4; CH=green; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04486; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=9; SR=0; TI=W4_5166270_DEFAULT_0A9326EA_1516757754918_o7001c17r; Received: from WS-web (xiaohu.xxh@alibaba-inc.com[W4_5166270_DEFAULT_0A9326EA_1516757754918_o7001c17r]) by e02c03269.eu6 at Wed, 24 Jan 2018 09:46:29 +0800 Date: Wed, 24 Jan 2018 09:46:29 +0800 From: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" To: "=?UTF-8?B?VmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCk=?=" , "Lsvr@ietf.org" , "Idr" Cc: "idr@ietf.org" , "dcrouting@ietf.org" , "Victor Kuarsingh" , "Keyur Patel" , "Shawn Zandi" , "rtgwg@ietf.org" Reply-To: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" Message-ID: X-Mailer: [Alimail-Mailagent][W4_5166270][DEFAULT][Safari] MIME-Version: 1.0 References: 31C68D70-CEC8-419E-BAD3-F1F7D55907FA@nokia.com In-Reply-To: 31C68D70-CEC8-419E-BAD3-F1F7D55907FA@nokia.com x-aliyun-mail-creator: W4_5166270_DEFAULT_QvNTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfMykgQXBwbGVXZWJLaXQvNjAyLjQuOCAoS0hUTUwsIGxpa2UgR2Vja28pIFZlcnNpb24vMTAuMC4zIFNhZmFyaS82MDIuNC44La Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_97843_4c867940_5a67e575_1a4037" Archived-At: Subject: [Dcrouting] =?utf-8?b?5Zue5aSN77yaW0lkcl0gW0xzdnJdIEtpY2tpbmcg?= =?utf-8?q?off_the_LSVR_=28Link_State_Vector_Routing=29_charter_discussion?= X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 01:46:43 -0000 ------=ALIBOUNDARY_97843_4c867940_5a67e575_1a4037 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SnVzdCBhIG1pbm9yIHF1ZXN0aW9uOiB3aHkgY2FsbCBpdMKgYcKgaHlicmlkwqByb3V0aW5nwqBw cm90b2NvbMKgdXRpbGl6aW5nwqBhwqBjb21iaW5hdGlvbsKgb2bCoGxpbmstc3RhdGXCoGFuZMKg cGF0aC12ZWN0b3LCoHJvdXRpbmfCoG1lY2hhbmlzbXM/IG1vcmUgc3BlY2lmaWNhbGx5LCB3aGF0 IHBhcnQgb2YgdGhlIEJHUC1TUEYgcmVzb3J0cyB0byB0aGUgcGF0aC12ZWN0b3Igcm91dGluZyBt ZWNoYW5pc20/IElNSE8sIEJHUC1TUEYgaGFzIHRyYW5zZm9ybWVkIHRoZSB0cmFkaXRpb25hbCBC R1AgdG8gYSBjb21wbGV0ZSBsaW5rLXN0YXRlIHJvdXRpbmcgcHJvdG9jb2wgZnJvbSB0aGUgcGVy c3BlY3RpdmUgb2YgdGhlIHJvdXRpbmcgY29tcHV0aW5nIGFsZ29yaXRobSwgbm8/CkJlc3QgcmVn YXJkcyxYaWFvaHUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS3lj5Hku7bkurrvvJpSYWJhZGFuLCBKb3JnZSAoTm9raWEgLSBV Uy9Nb3VudGFpbiBWaWV3KSA8am9yZ2UucmFiYWRhbkBub2tpYS5jb20+5Y+R6YCB5pe26Ze077ya MjAxOOW5tDHmnIgyNOaXpSjmmJ/mnJ/kuIkpIDAzOjA35pS25Lu25Lq677yaIlZhbiBEZSBWZWxk ZSwgR3VudGVyIChOb2tpYSAtIEJFL0FudHdlcnApIiA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tp YS5jb20+OyBMc3ZyQGlldGYub3JnIDxMc3ZyQGlldGYub3JnPuaKhOOAgOmAge+8mmlkckBpZXRm Lm9yZyA8aWRyQGlldGYub3JnPjsgZGNyb3V0aW5nQGlldGYub3JnIDxkY3JvdXRpbmdAaWV0Zi5v cmc+OyBWaWN0b3IgS3VhcnNpbmdoIDx2aWN0b3Iua3VhcnNpbmdoQG9yYWNsZS5jb20+OyBLZXl1 ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNvbT47IFNoYXduIFphbmRpIDxzemFuZGlAbGlua2VkaW4u Y29tPjsgcnRnd2dAaWV0Zi5vcmcgPHJ0Z3dnQGlldGYub3JnPuS4u+OAgOmimO+8mlJlOiBbSWRy XSBbTHN2cl0gS2lja2luZyBvZmYgdGhlIExTVlIgKExpbmsgU3RhdGUgVmVjdG9yIFJvdXRpbmcp IGNoYXJ0ZXIgZGlzY3Vzc2lvbgpBZnRlcsKgZ29pbmfCoHRocm91Z2jCoHRoZcKgY2hhcnRlcsKg dGV4dCzCoEnCoGJlbGlldmXCoGl0wqBpc8KgYcKgdmVyecKgZ29vZMKgc3RhcnRpbmfCoHBvaW50 LgpMb29raW5nwqBmb3J3YXJkwqB0b8Kgc2VlaW5nwqBmcnVpdGZ1bMKgZGlzY3Vzc2lvbnMuCgpU aGFua3MuCkpvcmdlCgrCoC0tLS0tT3JpZ2luYWzCoE1lc3NhZ2UtLS0tLQpGcm9tOsKgTHN2csKg PGxzdnItYm91bmNlc0BpZXRmLm9yZz7CoG9uwqBiZWhhbGbCoG9mwqAiVmFuwqBEZcKgVmVsZGUs wqBHdW50ZXLCoChOb2tpYcKgLcKgQkUvQW50d2VycCkiwqA8Z3VudGVyLnZhbl9kZV92ZWxkZUBu b2tpYS5jb20+CkRhdGU6wqBXZWRuZXNkYXkswqBKYW51YXJ5wqAxMCzCoDIwMTjCoGF0wqAxMTo1 MsKgQU0KVG86wqAiTHN2ckBpZXRmLm9yZyLCoDxMc3ZyQGlldGYub3JnPgpDYzrCoCJpZHJAaWV0 Zi5vcmciwqA8aWRyQGlldGYub3JnPizCoCJkY3JvdXRpbmdAaWV0Zi5vcmciwqA8ZGNyb3V0aW5n QGlldGYub3JnPizCoFZpY3RvcsKgS3VhcnNpbmdowqA8dmljdG9yLmt1YXJzaW5naEBvcmFjbGUu Y29tPizCoEtleXVywqBQYXRlbMKgPGtleXVyQGFycmN1cy5jb20+LMKgIlZhbsKgRGXCoFZlbGRl LMKgR3VudGVywqAoTm9raWHCoC3CoEJFL0FudHdlcnApIsKgPGd1bnRlci52YW5fZGVfdmVsZGVA bm9raWEuY29tPizCoFNoYXduwqBaYW5kacKgPHN6YW5kaUBsaW5rZWRpbi5jb20+LMKgQWx2YXJv wqBSZXRhbmHCoDxhcmV0YW5hLmlldGZAZ21haWwuY29tPizCoCJBY2VlwqBMaW5kZW3CoChhY2Vl KSLCoDxhY2VlQGNpc2NvLmNvbT4swqAicnRnd2dAaWV0Zi5vcmciwqA8cnRnd2dAaWV0Zi5vcmc+ ClN1YmplY3Q6wqBbTHN2cl3CoEtpY2tpbmfCoG9mZsKgdGhlwqBMU1ZSwqAoTGlua8KgU3RhdGXC oFZlY3RvcsKgUm91dGluZynCoGNoYXJ0ZXLCoGRpc2N1c3Npb24KCsKgwqDCoMKgW05vdGU6wqBU YXJnZXTCoGF1ZGllbmNlLMKgYW5kwqBkaXNjdXNzaW9uc8Kgc2hvdWxkwqBoYXBwZW7CoG9uwqBs c3ZyQGlldGYub3JnLMKgaG93ZXZlcsKgInJ0Z3dnIizCoCJpZHIiwqBhbmTCoCJkY3JvdXRpbmci wqBlbWFpbMKgbGlzdHPCoGhhdmXCoGJlZW7CoGFkZGVkwqBhc8KgdGhlwqBjb25jZXB0c8Kgb3Jp Z2luYXRlZMKgaW7CoHRob3NlwqB3b3JraW5nwqBncm91cHNdCsKgwqDCoMKgCsKgwqDCoMKgU2lu Y2XCoGRjcm91dGluZ0BpZXRmMTAwLMKgYcKgZmV3wqBwZW9wbGXCoGhhdmXCoGJlZW7CoGRpc2N1 c3NpbmfCoGHCoHBvc3NpYmxlwqBXR8KgY2hhcnRlcsKgZm9ywqBMU1ZSwqAoTGlua8KgU3RhdGXC oFZlY3RvcsKgUm91dGluZykuCsKgwqDCoMKgSGVyZcKgaXPCoHdoYXTCoHdlwqBoYXZlwqBzb8Kg ZmFyLsKgwqBDb21tZW50c8KgYW5kwqBpbXByb3ZlbWVudHPCoHdvdWxkwqBiZcKgbW9zdMKgd2Vs Y29tZS7CoArCoMKgwqDCoArCoMKgwqDCoFdHwqBwYWdlwqBpc8KgdG/CoGJlwqBzZXR1cMKgc29v bi4KwqDCoMKgwqBTdWJzY3JpcHRpb27CoHRvwqBMU1ZSwqBtYWlsaW5nwqBsaXN0OsKgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3ZyCsKgwqDCoMKgCsKgwqDCoMKgRmVl ZGJhY2vCoChjb21tZW50cyzCoGVkaXRzLMKgY29ycmVjdGlvbnMswqBldGMpwqDCoG9uwqB0aGXC oGRyYWZ0wqBMU1ZSwqBjaGFydGVywqBpc8KgYXBwcmVjaWF0ZWTCoArCoMKgwqDCoArCoMKgwqDC oArCoMKgwqDCoCoqKioqwqBEUkFGVMKgQ0hBUlRFUsKgVVBEQVRFwqAtwqBKQU7CoDEwwqAyMDE4 wqAqKioqKgrCoMKgwqDCoMKgCsKgwqDCoMKgQ2hhcnRlcjrCoExTVlLCoC3CoExpbmvCoFN0YXRl wqBWZWN0b3LCoFJvdXRpbmfCoArCoMKgwqDCoMKgCsKgwqDCoMKgVGhlwqBMaW5rLVN0YXRlwqBW ZWN0b3LCoFJvdXRpbmfCoChMU1ZSKcKgV29ya2luZ8KgR3JvdXDCoGlzwqBjaGFydGVyZWTCoHRv wqBkZXZlbG9wwqBhbmTCoGRvY3VtZW50wqBhwqBoeWJyaWTCoHJvdXRpbmfCoHByb3RvY29swqB1 dGlsaXppbmfCoGHCoGNvbWJpbmF0aW9uwqBvZsKgbGluay1zdGF0ZcKgYW5kwqBwYXRoLXZlY3Rv csKgcm91dGluZ8KgbWVjaGFuaXNtcy7CoMKgVGhlwqBMU1ZSwqBXR8Kgd2lsbMKgdXRpbGl6ZcKg ZXhpc3RpbmfCoHRoZcKgSVB2NC9JUHY2wqB0cmFuc3BvcnQswqBwYWNrZXTCoGZvcm1hdHMswqBh bmTCoGVycm9ywqBoYW5kbGluZ8KgZnJvbcKgQkdQLTTCoChSRkM0MjcxKS7CoEFkZGl0aW9uYWxs eSzCoHRoZcKgQkdQLUxTwqBOTFJJwqBlbmNvZGluZ8KgbWVjaGFuaXNtc8KgZGVmaW5lZMKgaW7C oFJGQzc3NTLCoGFyZcKgdXRpbGl6ZWTCoHRvwqBmYWNpbGl0YXRlwqBMaW5rLVN0YXRlwqBWZWN0 b3LCoChMU1YpwqByb3V0aW5nwqBpbmZvcm1hdGlvbsKgZGlzdHJpYnV0aW9uLsKgQW7CoExTVsKg aXPCoGludGVuZGVkwqB0b8KgYmXCoHNwZWNpZmllZMKgYXPCoGHCoGRhdGHCoHN0cnVjdHVyZcKg Y29tcHJpc2VkwqBvZsKgYcKgbGlua8KgaWRlbnRpZmljYXRpb24swqBsaW5rwqBhdHRyaWJ1dGVz LMKgbmVpZ2hib3LCoGluZm9ybWF0aW9uLMKgY29zdMKgdG93YXJkwqBuZWlnaGJvcnMswqBhbmTC oG90aGVywqBhdHRyaWJ1dGVzwqB0aGF0wqBhcmXCoGRlZmluZWTCoGZvcsKgY29udHJvbMKgcGxh bmXCoGZ1bmN0aW9uwqBhbmTCoHBvbGljeS1iYXNlZMKgcm91dGluZ8KgZGVjaXNpb25zLgrCoMKg wqDCoMKgCsKgwqDCoMKgVGhlwqBMU1ZSwqBzcGVjaWZpY2F0aW9uwqBpc8KgaW5pdGlhbGx5wqBm b2N1c2VkwqBvbsKgb3BlcmF0aW9uwqB3aXRoaW7CoGHCoHNpbmdsZcKgZGF0YWNlbnRlcsKgKERD KcKgd2l0aMKgcHJlbGltaW5hcnnCoGZvY3VzwqBvbsKgc3BlY2lmeWluZ8KgZnVuY3Rpb25hbGl0 ecKgd2l0aGluwqBhwqBzaW5nbGXCoGRpc3RyaWJ1dGlvbsKgZG9tYWluLsKgwqBSb3V0aW5nwqBw cm90b2NvbMKgZnVuY3Rpb25hbGl0ecKgZGVmaW5lZMKgYnnCoExTVlLCoHdvdWxkwqBiZcKgdHlw aWNhbGx5wqByb3V0aW5nwqB3aXRoaW7CoGHCoGRhdGFjZW50ZXInc8KgdW5kZXJsYXnCoHJvdXRp bmfCoHBsYW5lLsKgCsKgwqDCoMKgwqAKwqDCoMKgwqBJbsKgb3JkZXLCoHRvwqBhY2hpZXZlwqB0 aGXCoG5vdGVkwqBvYmplY3RpdmUswqB0aGXCoHdvcmtpbmfCoGdyb3VwwqB3aWxswqBmb2N1c8Kg b27CoHN0YW5kYXJkaXphdGlvbsKgb2bCoHByb3RvY29swqBmdW5jdGlvbmFsaXR5LMKgZGVmaW5p bmfCoExpbmstU3RhdGXCoFZlY3RvcnPCoChMU1ZzKSzCoGFuZMKgZGVmaW5pbmfCoHN0YW5kYXJk wqBwYXRoLXZlY3RvcsKgcm91dGXCoHNlbGVjdGlvbsKgdXRpbGl6aW5nwqBleGlzdGluZ8KgRGlq a3N0cmHCoFNQRsKgYmFzZWTCoGFsZ29yaXRobSzCoEJHUC00wqBwcm90b2NvbMKgbWVjaGFuaWNz LMKgYW5kwqBCR1AtTFPCoE5STEnCoGVuY29kaW5nLgrCoMKgwqDCoMKgCsKgwqDCoMKgRm9ywqB0 aGXCoHB1cnBvc2VzwqBvZsKgdGhlwqBpbml0aWFswqB3b3JrwqB3aXRoaW7CoHRoZcKgTFNWUsKg V0cswqBhbmTCoHVudGlswqBmdXJ0aGVywqBzcGVjaWZpZWTCoGJ5wqB0aGXCoFdHLMKgdGhlwqBm b2xsb3dpbmfCoGRlZmluaXRpb25zwqBhcHBsecKgdG/CoHRoaXPCoGNoYXJ0ZXIuCsKgwqDCoMKg wqAKwqDCoMKgwqAtwqBMaW5rLVN0YXRlwqBWZWN0b3LCoC3CoEFuwqBMU1bCoGlzwqBpbnRlbmRl ZMKgdG/CoHJlcHJlc2VudMKgYcKgZGF0YcKgc3RydWN0dXJlwqAoZGF0YcKgc2V0KcKgY29tcHJp c2VkwqBvZsKgbGlua8KgaWRlbnRpZmljYXRpb24swqBsaW5rwqBhdHRyaWJ1dGVzLMKgbmVpZ2hi b3LCoGluZm9ybWF0aW9uLMKgY29zdMKgdG93YXJkc8KgbmVpZ2hib3JzLMKgYW5kwqBvdGhlcsKg cG90ZW50aWFswqBhdHRyaWJ1dGVzwqB0aGF0wqBjYW7CoGJlwqB1dGlsaXplZMKgdG/CoG1ha2XC oHJvdXRpbmfCoGRlY2lzaW9ucy4KwqDCoMKgwqAtwqBMU1ZSwqBEaXN0cmlidXRpb27CoERvbWFp bsKgLcKgSW5pdGlhbGx5wqBzY29wZWTCoGFzwqBhwqBzZXTCoG9mwqBwYXJ0aWNpcGF0aW5nwqBM U1ZSwqBub2Rlc8KgaW7CoGHCoHNpbmdsZcKgYWRtaW5pc3RyYXRpdmXCoGRvbWFpbi4KwqDCoMKg wqDCoArCoMKgwqDCoMKgCsKgwqDCoMKgVGhlwqBMU1ZSwqBXR8KgaXPCoGNoYXJ0ZXJlZMKgdG/C oGRlbGl2ZXLCoHRoZcKgZm9sbG93aW5nwqBkb2N1bWVudHM6CsKgwqDCoMKgwqAKwqDCoMKgwqAt wqBQdWJsaXNowqBBcHBsaWNhYmlsaXR5wqBTdGF0ZW1lbnTCoGZvcsKgdGhlwqB1c2XCoG9mwqBM U1ZSwqBpbsKgdGhlwqBEYXRhY2VudGVywqAtwqBUYXJnZXTCoFN0YXR1czrCoEluZm9ybWF0aW9u YWwKwqDCoMKgwqAtwqBQdWJsaXNowqBzcGVjaWZpY2F0aW9uwqBkb2N1bWVudMKgZGVzY3JpYmlu Z8KgTFNWwqB3aXRowqBzdGFuZGFyZMKgRGlqa3N0cmHCoFNQRsKgcm91dGUvcGF0aMKgc2VsZWN0 aW9uwqAoY2FsY3VsYXRpb24pwqB1dGlsaXppbmfCoGV4aXN0aW5nwqBCR1DCoHByb3RvY29swqBi YXNlbGluZcKgZnVuY3Rpb25hbGl0ecKgYW5kwqBCR1AtTFPCoHBhY2tldMKgZW5jb2RpbmfCoGZv cm1hdHPCoC3CoFRhcmdldDrCoFN0YW5kYXJkc8KgVHJhY2vCoChCYXNlZMKgb27CoGRyYWZ0wqBk cmFmdC1rZXl1cGF0ZS1pZHItYmdwLXNwZikKwqDCoMKgwqAtwqBQdWJsaXNowqBzcGVjaWZpY2F0 aW9uwqBkb2N1bWVudGluZ8KgcHJvdG9jb2zCoGV4dGVuc2lvbnPCoHJlcXVpcmVkwqB0b8KgZWZm aWNpZW50bHnCoHJldXNlwqBCR1DCoHRvwqBkaXN0cmlidXRlwqBMU1ZzwqB3aXRoaW7CoGFuwqBJ UHY0L0lQdjbCoERDwqB3aXRowqBzY29wZcKgdG/CoGluY2x1ZGXCoHByaXZhY3nCoGFuZMKgc2Vj dXJpdHnCoGNvbnNpZGVyYXRpb25zwqAtwqAtwqBUYXJnZXQ6wqBTdGFuZGFyZHPCoFRyYWNrCsKg wqDCoMKgLcKgUHVibGlzaMKgWUFOR8KgbW9kZWzCoHNwZWNpZmljYXRpb27CoGZvcsKgTFNWUsKg LcKgLcKgVGFyZ2V0OsKgU3RhbmRhcmRzwqBUcmFjawrCoMKgwqDCoMKgCsKgwqDCoMKgTFNWUsKg TWlsZXN0b25lczoKwqDCoMKgwqDCoArCoMKgwqDCoC3CoEFwcGxpY2FiaWxpdHnCoHN0YXRlbWVu dMKgZm9ywqBMU1ZSwqBpbsKgRENzOsKgTWFyY2jCoDIwMTkKwqDCoMKgwqAtwqBMU1ZSwqB3aXRo wqBzdGFuZGFyZMKgRGlqa3N0cmHCoHBhdGjCoHNlbGVjdGlvbjrCoE1hcmNowqAyMDE5CsKgwqDC oMKgLcKgTFNWwqBkaXN0cmlidXRpb27CoHVzaW5nwqBCR1DCoHRyYW5zcG9ydDrCoE1hcmNowqAy MDE5CsKgwqDCoMKgLcKgWUFOR8Kgc3BlY2lmaWNhdGlvbsKgZm9ywqBMU1JWOsKgSnVsecKgMjAx OQrCoMKgwqDCoArCoMKgwqDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCsKgwqDCoMKgTHN2csKgbWFpbGluZ8KgbGlzdArCoMKgwqDCoExzdnJAaWV0Zi5v cmcKwqDCoMKgwqBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzdnIKwqDC oMKgwqAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCklk csKgbWFpbGluZ8KgbGlzdApJZHJAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZHIKCg== ------=ALIBOUNDARY_97843_4c867940_5a67e575_1a4037 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImNsZWFy OmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNp bVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7Ij5KdXN0IGEgbWlub3IgcXVlc3Rp b246IHdoeSBjYWxsIGl0Jm5ic3A7PC9zcGFuPmEmbmJzcDtoeWJyaWQmbmJzcDtyb3V0aW5nJm5i c3A7cHJvdG9jb2wmbmJzcDt1dGlsaXppbmcmbmJzcDthJm5ic3A7Y29tYmluYXRpb24mbmJzcDtv ZiZuYnNwO2xpbmstc3RhdGUmbmJzcDthbmQmbmJzcDtwYXRoLXZlY3RvciZuYnNwO3JvdXRpbmcm bmJzcDttZWNoYW5pc21zPyBtb3JlIHNwZWNpZmljYWxseSwgd2hhdCBwYXJ0IG9mIHRoZSBCR1At U1BGIHJlc29ydHMgdG8gdGhlIHBhdGgtdmVjdG9yIHJvdXRpbmcgbWVjaGFuaXNtPyBJTUhPLCBC R1AtU1BGIGhhcyB0cmFuc2Zvcm1lZCB0aGUgdHJhZGl0aW9uYWwgQkdQIHRvIGEgY29tcGxldGUg bGluay1zdGF0ZSByb3V0aW5nIHByb3RvY29sIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBy b3V0aW5nIGNvbXB1dGluZyBhbGdvcml0aG0sIG5vPzwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpi b3RoOyI+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5 OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAw MDA7Ij48YnIgPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxk aXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWEs QXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+QmVz dCByZWdhcmRzLDwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxk aXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWEs QXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+WGlh b2h1PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PGRpdiAgc3R5 bGU9ImNsZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxT VEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7Ij4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQt ZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9y OiMwMDAwMDA7Ij7lj5Hku7bkurrvvJpSYWJhZGFuLCBKb3JnZSAoTm9raWEgLSBVUy9Nb3VudGFp biBWaWV3KSAmbHQ7am9yZ2UucmFiYWRhbkBub2tpYS5jb20mZ3Q7PC9zcGFuPjwvZGl2PjxkaXYg IHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWEsQXJp YWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+5Y+R6YCB 5pe26Ze077yaMjAxOOW5tDHmnIgyNOaXpSjmmJ/mnJ/kuIkpIDAzOjA3PC9zcGFuPjwvZGl2Pjxk aXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWEs QXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+5pS2 5Lu25Lq677yaIlZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtIEJFL0FudHdlcnApIiAmbHQ7 Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20mZ3Q7OyBMc3ZyQGlldGYub3JnICZsdDtMc3Zy QGlldGYub3JnJmd0Ozwvc3Bhbj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFu ICBzdHlsZT0iZm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6 ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsiPuaKhOOAgOmAge+8mmlkckBpZXRmLm9yZyAmbHQ7aWRy QGlldGYub3JnJmd0OzsgZGNyb3V0aW5nQGlldGYub3JnICZsdDtkY3JvdXRpbmdAaWV0Zi5vcmcm Z3Q7OyBWaWN0b3IgS3VhcnNpbmdoICZsdDt2aWN0b3Iua3VhcnNpbmdoQG9yYWNsZS5jb20mZ3Q7 OyBLZXl1ciBQYXRlbCAmbHQ7a2V5dXJAYXJyY3VzLmNvbSZndDs7IFNoYXduIFphbmRpICZsdDtz emFuZGlAbGlua2VkaW4uY29tJmd0OzsgcnRnd2dAaWV0Zi5vcmcgJmx0O3J0Z3dnQGlldGYub3Jn Jmd0Ozwvc3Bhbj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0i Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7 Y29sb3I6IzAwMDAwMDsiPuS4u+OAgOmimO+8mlJlOiBbSWRyXSBbTHN2cl0gS2lja2luZyBvZmYg dGhlIExTVlIgKExpbmsgU3RhdGUgVmVjdG9yIFJvdXRpbmcpIGNoYXJ0ZXIgZGlzY3Vzc2lvbjwv c3Bhbj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iZm9udC1m YW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6 IzAwMDAwMDsiPjxiciA+PC9zcGFuPjwvZGl2PkFmdGVyJm5ic3A7Z29pbmcmbmJzcDt0aHJvdWdo Jm5ic3A7dGhlJm5ic3A7Y2hhcnRlciZuYnNwO3RleHQsJm5ic3A7SSZuYnNwO2JlbGlldmUmbmJz cDtpdCZuYnNwO2lzJm5ic3A7YSZuYnNwO3ZlcnkmbmJzcDtnb29kJm5ic3A7c3RhcnRpbmcmbmJz cDtwb2ludC48YnIgPkxvb2tpbmcmbmJzcDtmb3J3YXJkJm5ic3A7dG8mbmJzcDtzZWVpbmcmbmJz cDtmcnVpdGZ1bCZuYnNwO2Rpc2N1c3Npb25zLjxiciA+PGJyID5UaGFua3MuPGJyID5Kb3JnZTxi ciA+PGJyID4mbmJzcDstLS0tLU9yaWdpbmFsJm5ic3A7TWVzc2FnZS0tLS0tPGJyID5Gcm9tOiZu YnNwO0xzdnImbmJzcDsmbHQ7bHN2ci1ib3VuY2VzQGlldGYub3JnJmd0OyZuYnNwO29uJm5ic3A7 YmVoYWxmJm5ic3A7b2YmbmJzcDsiVmFuJm5ic3A7RGUmbmJzcDtWZWxkZSwmbmJzcDtHdW50ZXIm bmJzcDsoTm9raWEmbmJzcDstJm5ic3A7QkUvQW50d2VycCkiJm5ic3A7Jmx0O2d1bnRlci52YW5f ZGVfdmVsZGVAbm9raWEuY29tJmd0OzxiciA+RGF0ZTombmJzcDtXZWRuZXNkYXksJm5ic3A7SmFu dWFyeSZuYnNwOzEwLCZuYnNwOzIwMTgmbmJzcDthdCZuYnNwOzExOjUyJm5ic3A7QU08YnIgPlRv OiZuYnNwOyJMc3ZyQGlldGYub3JnIiZuYnNwOyZsdDtMc3ZyQGlldGYub3JnJmd0OzxiciA+Q2M6 Jm5ic3A7ImlkckBpZXRmLm9yZyImbmJzcDsmbHQ7aWRyQGlldGYub3JnJmd0OywmbmJzcDsiZGNy b3V0aW5nQGlldGYub3JnIiZuYnNwOyZsdDtkY3JvdXRpbmdAaWV0Zi5vcmcmZ3Q7LCZuYnNwO1Zp Y3RvciZuYnNwO0t1YXJzaW5naCZuYnNwOyZsdDt2aWN0b3Iua3VhcnNpbmdoQG9yYWNsZS5jb20m Z3Q7LCZuYnNwO0tleXVyJm5ic3A7UGF0ZWwmbmJzcDsmbHQ7a2V5dXJAYXJyY3VzLmNvbSZndDss Jm5ic3A7IlZhbiZuYnNwO0RlJm5ic3A7VmVsZGUsJm5ic3A7R3VudGVyJm5ic3A7KE5va2lhJm5i c3A7LSZuYnNwO0JFL0FudHdlcnApIiZuYnNwOyZsdDtndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lh LmNvbSZndDssJm5ic3A7U2hhd24mbmJzcDtaYW5kaSZuYnNwOyZsdDtzemFuZGlAbGlua2VkaW4u Y29tJmd0OywmbmJzcDtBbHZhcm8mbmJzcDtSZXRhbmEmbmJzcDsmbHQ7YXJldGFuYS5pZXRmQGdt YWlsLmNvbSZndDssJm5ic3A7IkFjZWUmbmJzcDtMaW5kZW0mbmJzcDsoYWNlZSkiJm5ic3A7Jmx0 O2FjZWVAY2lzY28uY29tJmd0OywmbmJzcDsicnRnd2dAaWV0Zi5vcmciJm5ic3A7Jmx0O3J0Z3dn QGlldGYub3JnJmd0OzxiciA+U3ViamVjdDombmJzcDtbTHN2cl0mbmJzcDtLaWNraW5nJm5ic3A7 b2ZmJm5ic3A7dGhlJm5ic3A7TFNWUiZuYnNwOyhMaW5rJm5ic3A7U3RhdGUmbmJzcDtWZWN0b3Im bmJzcDtSb3V0aW5nKSZuYnNwO2NoYXJ0ZXImbmJzcDtkaXNjdXNzaW9uPGJyID48YnIgPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO1tOb3RlOiZuYnNwO1RhcmdldCZuYnNwO2F1ZGllbmNlLCZuYnNw O2FuZCZuYnNwO2Rpc2N1c3Npb25zJm5ic3A7c2hvdWxkJm5ic3A7aGFwcGVuJm5ic3A7b24mbmJz cDtsc3ZyQGlldGYub3JnLCZuYnNwO2hvd2V2ZXImbmJzcDsicnRnd2ciLCZuYnNwOyJpZHIiJm5i c3A7YW5kJm5ic3A7ImRjcm91dGluZyImbmJzcDtlbWFpbCZuYnNwO2xpc3RzJm5ic3A7aGF2ZSZu YnNwO2JlZW4mbmJzcDthZGRlZCZuYnNwO2FzJm5ic3A7dGhlJm5ic3A7Y29uY2VwdHMmbmJzcDtv cmlnaW5hdGVkJm5ic3A7aW4mbmJzcDt0aG9zZSZuYnNwO3dvcmtpbmcmbmJzcDtncm91cHNdPGJy ID4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Np bmNlJm5ic3A7ZGNyb3V0aW5nQGlldGYxMDAsJm5ic3A7YSZuYnNwO2ZldyZuYnNwO3Blb3BsZSZu YnNwO2hhdmUmbmJzcDtiZWVuJm5ic3A7ZGlzY3Vzc2luZyZuYnNwO2EmbmJzcDtwb3NzaWJsZSZu YnNwO1dHJm5ic3A7Y2hhcnRlciZuYnNwO2ZvciZuYnNwO0xTVlImbmJzcDsoTGluayZuYnNwO1N0 YXRlJm5ic3A7VmVjdG9yJm5ic3A7Um91dGluZykuPGJyID4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtIZXJlJm5ic3A7aXMmbmJzcDt3aGF0Jm5ic3A7d2UmbmJzcDtoYXZlJm5ic3A7c28mbmJzcDtm YXIuJm5ic3A7Jm5ic3A7Q29tbWVudHMmbmJzcDthbmQmbmJzcDtpbXByb3ZlbWVudHMmbmJzcDt3 b3VsZCZuYnNwO2JlJm5ic3A7bW9zdCZuYnNwO3dlbGNvbWUuJm5ic3A7PGJyID4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1dHJm5ic3A7cGFnZSZu YnNwO2lzJm5ic3A7dG8mbmJzcDtiZSZuYnNwO3NldHVwJm5ic3A7c29vbi48YnIgPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1N1YnNjcmlwdGlvbiZuYnNwO3RvJm5ic3A7TFNWUiZuYnNwO21haWxp bmcmbmJzcDtsaXN0OiZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHN2cjxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGJyID4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtGZWVkYmFjayZuYnNwOyhjb21tZW50cywmbmJzcDtlZGl0cywmbmJzcDtjb3JyZWN0aW9u cywmbmJzcDtldGMpJm5ic3A7Jm5ic3A7b24mbmJzcDt0aGUmbmJzcDtkcmFmdCZuYnNwO0xTVlIm bmJzcDtjaGFydGVyJm5ic3A7aXMmbmJzcDthcHByZWNpYXRlZCZuYnNwOzxiciA+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGJyID4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnIgPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyoqKioqJm5ic3A7RFJBRlQmbmJzcDtDSEFSVEVSJm5ic3A7VVBEQVRF Jm5ic3A7LSZuYnNwO0pBTiZuYnNwOzEwJm5ic3A7MjAxOCZuYnNwOyoqKioqPGJyID4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NoYXJ0 ZXI6Jm5ic3A7TFNWUiZuYnNwOy0mbmJzcDtMaW5rJm5ic3A7U3RhdGUmbmJzcDtWZWN0b3ImbmJz cDtSb3V0aW5nJm5ic3A7PGJyID4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnIgPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSZuYnNwO0xpbmstU3RhdGUmbmJzcDtWZWN0b3ImbmJz cDtSb3V0aW5nJm5ic3A7KExTVlIpJm5ic3A7V29ya2luZyZuYnNwO0dyb3VwJm5ic3A7aXMmbmJz cDtjaGFydGVyZWQmbmJzcDt0byZuYnNwO2RldmVsb3AmbmJzcDthbmQmbmJzcDtkb2N1bWVudCZu YnNwO2EmbmJzcDtoeWJyaWQmbmJzcDtyb3V0aW5nJm5ic3A7cHJvdG9jb2wmbmJzcDt1dGlsaXpp bmcmbmJzcDthJm5ic3A7Y29tYmluYXRpb24mbmJzcDtvZiZuYnNwO2xpbmstc3RhdGUmbmJzcDth bmQmbmJzcDtwYXRoLXZlY3RvciZuYnNwO3JvdXRpbmcmbmJzcDttZWNoYW5pc21zLiZuYnNwOyZu YnNwO1RoZSZuYnNwO0xTVlImbmJzcDtXRyZuYnNwO3dpbGwmbmJzcDt1dGlsaXplJm5ic3A7ZXhp c3RpbmcmbmJzcDt0aGUmbmJzcDtJUHY0L0lQdjYmbmJzcDt0cmFuc3BvcnQsJm5ic3A7cGFja2V0 Jm5ic3A7Zm9ybWF0cywmbmJzcDthbmQmbmJzcDtlcnJvciZuYnNwO2hhbmRsaW5nJm5ic3A7ZnJv bSZuYnNwO0JHUC00Jm5ic3A7KFJGQzQyNzEpLiZuYnNwO0FkZGl0aW9uYWxseSwmbmJzcDt0aGUm bmJzcDtCR1AtTFMmbmJzcDtOTFJJJm5ic3A7ZW5jb2RpbmcmbmJzcDttZWNoYW5pc21zJm5ic3A7 ZGVmaW5lZCZuYnNwO2luJm5ic3A7UkZDNzc1MiZuYnNwO2FyZSZuYnNwO3V0aWxpemVkJm5ic3A7 dG8mbmJzcDtmYWNpbGl0YXRlJm5ic3A7TGluay1TdGF0ZSZuYnNwO1ZlY3RvciZuYnNwOyhMU1Yp Jm5ic3A7cm91dGluZyZuYnNwO2luZm9ybWF0aW9uJm5ic3A7ZGlzdHJpYnV0aW9uLiZuYnNwO0Fu Jm5ic3A7TFNWJm5ic3A7aXMmbmJzcDtpbnRlbmRlZCZuYnNwO3RvJm5ic3A7YmUmbmJzcDtzcGVj aWZpZWQmbmJzcDthcyZuYnNwO2EmbmJzcDtkYXRhJm5ic3A7c3RydWN0dXJlJm5ic3A7Y29tcHJp c2VkJm5ic3A7b2YmbmJzcDthJm5ic3A7bGluayZuYnNwO2lkZW50aWZpY2F0aW9uLCZuYnNwO2xp bmsmbmJzcDthdHRyaWJ1dGVzLCZuYnNwO25laWdoYm9yJm5ic3A7aW5mb3JtYXRpb24sJm5ic3A7 Y29zdCZuYnNwO3Rvd2FyZCZuYnNwO25laWdoYm9ycywmbmJzcDthbmQmbmJzcDtvdGhlciZuYnNw O2F0dHJpYnV0ZXMmbmJzcDt0aGF0Jm5ic3A7YXJlJm5ic3A7ZGVmaW5lZCZuYnNwO2ZvciZuYnNw O2NvbnRyb2wmbmJzcDtwbGFuZSZuYnNwO2Z1bmN0aW9uJm5ic3A7YW5kJm5ic3A7cG9saWN5LWJh c2VkJm5ic3A7cm91dGluZyZuYnNwO2RlY2lzaW9ucy48YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlJm5ic3A7TFNWUiZuYnNw O3NwZWNpZmljYXRpb24mbmJzcDtpcyZuYnNwO2luaXRpYWxseSZuYnNwO2ZvY3VzZWQmbmJzcDtv biZuYnNwO29wZXJhdGlvbiZuYnNwO3dpdGhpbiZuYnNwO2EmbmJzcDtzaW5nbGUmbmJzcDtkYXRh Y2VudGVyJm5ic3A7KERDKSZuYnNwO3dpdGgmbmJzcDtwcmVsaW1pbmFyeSZuYnNwO2ZvY3VzJm5i c3A7b24mbmJzcDtzcGVjaWZ5aW5nJm5ic3A7ZnVuY3Rpb25hbGl0eSZuYnNwO3dpdGhpbiZuYnNw O2EmbmJzcDtzaW5nbGUmbmJzcDtkaXN0cmlidXRpb24mbmJzcDtkb21haW4uJm5ic3A7Jm5ic3A7 Um91dGluZyZuYnNwO3Byb3RvY29sJm5ic3A7ZnVuY3Rpb25hbGl0eSZuYnNwO2RlZmluZWQmbmJz cDtieSZuYnNwO0xTVlImbmJzcDt3b3VsZCZuYnNwO2JlJm5ic3A7dHlwaWNhbGx5Jm5ic3A7cm91 dGluZyZuYnNwO3dpdGhpbiZuYnNwO2EmbmJzcDtkYXRhY2VudGVyJ3MmbmJzcDt1bmRlcmxheSZu YnNwO3JvdXRpbmcmbmJzcDtwbGFuZS4mbmJzcDs8YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4mbmJzcDtvcmRlciZuYnNwO3Rv Jm5ic3A7YWNoaWV2ZSZuYnNwO3RoZSZuYnNwO25vdGVkJm5ic3A7b2JqZWN0aXZlLCZuYnNwO3Ro ZSZuYnNwO3dvcmtpbmcmbmJzcDtncm91cCZuYnNwO3dpbGwmbmJzcDtmb2N1cyZuYnNwO29uJm5i c3A7c3RhbmRhcmRpemF0aW9uJm5ic3A7b2YmbmJzcDtwcm90b2NvbCZuYnNwO2Z1bmN0aW9uYWxp dHksJm5ic3A7ZGVmaW5pbmcmbmJzcDtMaW5rLVN0YXRlJm5ic3A7VmVjdG9ycyZuYnNwOyhMU1Zz KSwmbmJzcDthbmQmbmJzcDtkZWZpbmluZyZuYnNwO3N0YW5kYXJkJm5ic3A7cGF0aC12ZWN0b3Im bmJzcDtyb3V0ZSZuYnNwO3NlbGVjdGlvbiZuYnNwO3V0aWxpemluZyZuYnNwO2V4aXN0aW5nJm5i c3A7RGlqa3N0cmEmbmJzcDtTUEYmbmJzcDtiYXNlZCZuYnNwO2FsZ29yaXRobSwmbmJzcDtCR1At NCZuYnNwO3Byb3RvY29sJm5ic3A7bWVjaGFuaWNzLCZuYnNwO2FuZCZuYnNwO0JHUC1MUyZuYnNw O05STEkmbmJzcDtlbmNvZGluZy48YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxi ciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yJm5ic3A7dGhlJm5ic3A7cHVycG9zZXMmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luaXRpYWwmbmJzcDt3b3JrJm5ic3A7d2l0aGluJm5ic3A7dGhl Jm5ic3A7TFNWUiZuYnNwO1dHLCZuYnNwO2FuZCZuYnNwO3VudGlsJm5ic3A7ZnVydGhlciZuYnNw O3NwZWNpZmllZCZuYnNwO2J5Jm5ic3A7dGhlJm5ic3A7V0csJm5ic3A7dGhlJm5ic3A7Zm9sbG93 aW5nJm5ic3A7ZGVmaW5pdGlvbnMmbmJzcDthcHBseSZuYnNwO3RvJm5ic3A7dGhpcyZuYnNwO2No YXJ0ZXIuPGJyID4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnIgPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOy0mbmJzcDtMaW5rLVN0YXRlJm5ic3A7VmVjdG9yJm5ic3A7LSZuYnNwO0Fu Jm5ic3A7TFNWJm5ic3A7aXMmbmJzcDtpbnRlbmRlZCZuYnNwO3RvJm5ic3A7cmVwcmVzZW50Jm5i c3A7YSZuYnNwO2RhdGEmbmJzcDtzdHJ1Y3R1cmUmbmJzcDsoZGF0YSZuYnNwO3NldCkmbmJzcDtj b21wcmlzZWQmbmJzcDtvZiZuYnNwO2xpbmsmbmJzcDtpZGVudGlmaWNhdGlvbiwmbmJzcDtsaW5r Jm5ic3A7YXR0cmlidXRlcywmbmJzcDtuZWlnaGJvciZuYnNwO2luZm9ybWF0aW9uLCZuYnNwO2Nv c3QmbmJzcDt0b3dhcmRzJm5ic3A7bmVpZ2hib3JzLCZuYnNwO2FuZCZuYnNwO290aGVyJm5ic3A7 cG90ZW50aWFsJm5ic3A7YXR0cmlidXRlcyZuYnNwO3RoYXQmbmJzcDtjYW4mbmJzcDtiZSZuYnNw O3V0aWxpemVkJm5ic3A7dG8mbmJzcDttYWtlJm5ic3A7cm91dGluZyZuYnNwO2RlY2lzaW9ucy48 YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtMU1ZSJm5ic3A7RGlzdHJpYnV0aW9u Jm5ic3A7RG9tYWluJm5ic3A7LSZuYnNwO0luaXRpYWxseSZuYnNwO3Njb3BlZCZuYnNwO2FzJm5i c3A7YSZuYnNwO3NldCZuYnNwO29mJm5ic3A7cGFydGljaXBhdGluZyZuYnNwO0xTVlImbmJzcDtu b2RlcyZuYnNwO2luJm5ic3A7YSZuYnNwO3NpbmdsZSZuYnNwO2FkbWluaXN0cmF0aXZlJm5ic3A7 ZG9tYWluLjxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGJyID4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSZuYnNw O0xTVlImbmJzcDtXRyZuYnNwO2lzJm5ic3A7Y2hhcnRlcmVkJm5ic3A7dG8mbmJzcDtkZWxpdmVy Jm5ic3A7dGhlJm5ic3A7Zm9sbG93aW5nJm5ic3A7ZG9jdW1lbnRzOjxiciA+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGJyID4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7UHVi bGlzaCZuYnNwO0FwcGxpY2FiaWxpdHkmbmJzcDtTdGF0ZW1lbnQmbmJzcDtmb3ImbmJzcDt0aGUm bmJzcDt1c2UmbmJzcDtvZiZuYnNwO0xTVlImbmJzcDtpbiZuYnNwO3RoZSZuYnNwO0RhdGFjZW50 ZXImbmJzcDstJm5ic3A7VGFyZ2V0Jm5ic3A7U3RhdHVzOiZuYnNwO0luZm9ybWF0aW9uYWw8YnIg PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtQdWJsaXNoJm5ic3A7c3BlY2lmaWNhdGlv biZuYnNwO2RvY3VtZW50Jm5ic3A7ZGVzY3JpYmluZyZuYnNwO0xTViZuYnNwO3dpdGgmbmJzcDtz dGFuZGFyZCZuYnNwO0RpamtzdHJhJm5ic3A7U1BGJm5ic3A7cm91dGUvcGF0aCZuYnNwO3NlbGVj dGlvbiZuYnNwOyhjYWxjdWxhdGlvbikmbmJzcDt1dGlsaXppbmcmbmJzcDtleGlzdGluZyZuYnNw O0JHUCZuYnNwO3Byb3RvY29sJm5ic3A7YmFzZWxpbmUmbmJzcDtmdW5jdGlvbmFsaXR5Jm5ic3A7 YW5kJm5ic3A7QkdQLUxTJm5ic3A7cGFja2V0Jm5ic3A7ZW5jb2RpbmcmbmJzcDtmb3JtYXRzJm5i c3A7LSZuYnNwO1RhcmdldDombmJzcDtTdGFuZGFyZHMmbmJzcDtUcmFjayZuYnNwOyhCYXNlZCZu YnNwO29uJm5ic3A7ZHJhZnQmbmJzcDtkcmFmdC1rZXl1cGF0ZS1pZHItYmdwLXNwZik8YnIgPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtQdWJsaXNoJm5ic3A7c3BlY2lmaWNhdGlvbiZu YnNwO2RvY3VtZW50aW5nJm5ic3A7cHJvdG9jb2wmbmJzcDtleHRlbnNpb25zJm5ic3A7cmVxdWly ZWQmbmJzcDt0byZuYnNwO2VmZmljaWVudGx5Jm5ic3A7cmV1c2UmbmJzcDtCR1AmbmJzcDt0byZu YnNwO2Rpc3RyaWJ1dGUmbmJzcDtMU1ZzJm5ic3A7d2l0aGluJm5ic3A7YW4mbmJzcDtJUHY0L0lQ djYmbmJzcDtEQyZuYnNwO3dpdGgmbmJzcDtzY29wZSZuYnNwO3RvJm5ic3A7aW5jbHVkZSZuYnNw O3ByaXZhY3kmbmJzcDthbmQmbmJzcDtzZWN1cml0eSZuYnNwO2NvbnNpZGVyYXRpb25zJm5ic3A7 LSZuYnNwOy0mbmJzcDtUYXJnZXQ6Jm5ic3A7U3RhbmRhcmRzJm5ic3A7VHJhY2s8YnIgPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtQdWJsaXNoJm5ic3A7WUFORyZuYnNwO21vZGVsJm5i c3A7c3BlY2lmaWNhdGlvbiZuYnNwO2ZvciZuYnNwO0xTVlImbmJzcDstJm5ic3A7LSZuYnNwO1Rh cmdldDombmJzcDtTdGFuZGFyZHMmbmJzcDtUcmFjazxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGJyID4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtMU1ZSJm5ic3A7TWlsZXN0b25l czo8YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxiciA+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7LSZuYnNwO0FwcGxpY2FiaWxpdHkmbmJzcDtzdGF0ZW1lbnQmbmJzcDtmb3ImbmJz cDtMU1ZSJm5ic3A7aW4mbmJzcDtEQ3M6Jm5ic3A7TWFyY2gmbmJzcDsyMDE5PGJyID4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7TFNWUiZuYnNwO3dpdGgmbmJzcDtzdGFuZGFyZCZuYnNw O0RpamtzdHJhJm5ic3A7cGF0aCZuYnNwO3NlbGVjdGlvbjombmJzcDtNYXJjaCZuYnNwOzIwMTk8 YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtMU1YmbmJzcDtkaXN0cmlidXRpb24m bmJzcDt1c2luZyZuYnNwO0JHUCZuYnNwO3RyYW5zcG9ydDombmJzcDtNYXJjaCZuYnNwOzIwMTk8 YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtZQU5HJm5ic3A7c3BlY2lmaWNhdGlv biZuYnNwO2ZvciZuYnNwO0xTUlY6Jm5ic3A7SnVseSZuYnNwOzIwMTk8YnIgPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO0xzdnImbmJzcDttYWlsaW5nJm5ic3A7bGlzdDxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7THN2ckBpZXRmLm9yZzxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3ZyPGJyID4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YnIgPjxiciA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnIgPklkciZuYnNwO21haWxpbmcmbmJzcDtsaXN0PGJyID5JZHJAaWV0Zi5vcmc8YnIgPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyPGJyID48L2Rpdj48ZGl2ID48 YnIgPjwvZGl2PjwvZGl2Pg== ------=ALIBOUNDARY_97843_4c867940_5a67e575_1a4037-- From nobody Tue Jan 23 18:39:17 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232AC12D88D; Tue, 23 Jan 2018 18:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JGNWGDRFUHN3; Tue, 23 Jan 2018 18:39:03 -0800 (PST) Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) (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 0086012D775; Tue, 23 Jan 2018 18:39:02 -0800 (PST) Received: by mail-vk0-f46.google.com with SMTP id m197so1644229vka.3; Tue, 23 Jan 2018 18:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tl/U7B+gydWwJMxgRPp02L3uwyMcppZhuboSgnxpR8E=; b=NzVrRbyCSbTkdym90ddGS/7Vb7O6g5Jhynuh2/JlRPBPeTjwd2ooKuD0im2oqsqyrH WNSq0iyLxKK7jahLAB01SpQoJxbb6nv2403A96FzqJJKfMuoo3ekSH4b6JaAOBSKfIxd 4xmopuyQKPhmP23gHa0EMkFKRCIUPQqIoqU2i/Ek12usF72z5VpKfYmEe/x8LqT6aZx/ snArSsCcK7hhSqjSU++1XNoz0Bv0OG6grEscn1z1S72c0cYFJLdY7XOXrHJ6PW5miE1y DJJjUWhTPsXZ5sKQDn4iqVTJIwzmqDvCkZS9zEUCjoAxFHSmnL3u7IBEbYKbqajnIgLU kZPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tl/U7B+gydWwJMxgRPp02L3uwyMcppZhuboSgnxpR8E=; b=E9rWv4lEJsAn35XcwzkgVJQrr4ogHoxulOHWgHmf7K/C0VW9CG9yKy4Sjp8nwnGZek nELAgPw+lDJkRRGZtelCg3taz3Ts0YCulzhk4m/lfixsAeujHAWXMhplhEVQo6CTEKXk Kxad45Myl1Y2ezY1tuh7SW9ojPJvDR6zJETeCWeK3L0K6LkLiwQkAUeJUiyxuG2XRdvA MbEJNTJw0vpdy+W8dJq2a+R1NgyO8OZF9bwgzyuGisPweCdRxUmkbpWFmmrqVlz9j9ct nBprIsz8p0OvnIpl2FMonnYv32EFVYpkVhvINlcQBf8W+SkkdTli0EyNF6JsSdox6JU9 fKxw== X-Gm-Message-State: AKwxytfEDWBEBGajn7yoQqko6LWmXZzILW5I7PbSYBTUJilpKCfZVl7Q CmqQpT8gfqUOGMsa4X91K4HqmzOxnPVcWgYtAYA= X-Google-Smtp-Source: AH8x225yxWvMlHiNq4mWn/q/PnEBA0poanE4CVEFS6eGelyX8yqR8LigAXlNdyQTY5Fm8kyKFOrmqP5r486t+1in7rg= X-Received: by 10.31.98.68 with SMTP id w65mr20487vkb.181.1516761481762; Tue, 23 Jan 2018 18:38:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.32.66 with HTTP; Tue, 23 Jan 2018 18:38:01 -0800 (PST) In-Reply-To: <52BDDB18-139A-486C-A3EF-33C794DC4F5A@cisco.com> References: <52BDDB18-139A-486C-A3EF-33C794DC4F5A@cisco.com> From: Padma Pillay-Esnault Date: Wed, 24 Jan 2018 03:38:01 +0100 Message-ID: To: "Lsvr@ietf.org" Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "idr@ietf.org" , "dcrouting@ietf.org" , Victor Kuarsingh , Keyur Patel , Shawn Zandi , "rtgwg@ietf.org" , "Serpil Bayraktar (serpil)" Content-Type: multipart/alternative; boundary="94eb2c08f932545cf505637c8dc1" Archived-At: Subject: Re: [Dcrouting] [Idr] Kicking off the LSVR (Link State Vector Routing) charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 02:39:06 -0000 --94eb2c08f932545cf505637c8dc1 Content-Type: text/plain; charset="UTF-8" Interesting. +1 on participating Padma On Tue, Jan 23, 2018 at 10:57 PM, Serpil Bayraktar (serpil) < serpil@cisco.com> wrote: > This is an interesting (and useful) approach. I am very interested in > participating. > > > > Serpil > > > > *From: *Idr on behalf of "Van De Velde, Gunter > (Nokia - BE/Antwerp)" > *Date: *Tuesday, January 23, 2018 at 11:07 AM > *To: *"Lsvr@ietf.org" > *Cc: *"idr@ietf.org" , "dcrouting@ietf.org" < > dcrouting@ietf.org>, Victor Kuarsingh , > Keyur Patel , "Van De Velde, Gunter (Nokia - > BE/Antwerp)" , Shawn Zandi < > szandi@linkedin.com>, "rtgwg@ietf.org" > *Subject: *[Idr] Kicking off the LSVR (Link State Vector Routing) charter > discussion > > > > [Note: Target audience, and discussions should happen on lsvr@ietf.org, > however "rtgwg", "idr" and "dcrouting" email lists have been added as the > concepts originated in those working groups] > > > > Since dcrouting@ietf100, a few people have been discussing a possible WG > charter for LSVR (Link State Vector Routing). > > Here is what we have so far. Comments and improvements would be most > welcome. > > > > WG page is to be setup soon. > > Subscription to LSVR mailing list: https://www.ietf.org/mailman/ > listinfo/lsvr > > > > Feedback (comments, edits, corrections, etc) on the draft LSVR charter is > appreciated > > > > > > ***** DRAFT CHARTER UPDATE - JAN 10 2018 ***** > > > > Charter: LSVR - Link State Vector Routing > > > > The Link-State Vector Routing (LSVR) Working Group is chartered to develop > and document a hybrid routing protocol utilizing a combination of > link-state and path-vector routing mechanisms. The LSVR WG will utilize > existing the IPv4/IPv6 transport, packet formats, and error handling from > BGP-4 (RFC4271). Additionally, the BGP-LS NLRI encoding mechanisms defined > in RFC7752 are utilized to facilitate Link-State Vector (LSV) routing > information distribution. An LSV is intended to be specified as a data > structure comprised of a link identification, link attributes, neighbor > information, cost toward neighbors, and other attributes that are defined > for control plane function and policy-based routing decisions. > > > > The LSVR specification is initially focused on operation within a single > datacenter (DC) with preliminary focus on specifying functionality within a > single distribution domain. Routing protocol functionality defined by LSVR > would be typically routing within a datacenter's underlay routing plane. > > > > In order to achieve the noted objective, the working group will focus on > standardization of protocol functionality, defining Link-State Vectors > (LSVs), and defining standard path-vector route selection utilizing > existing Dijkstra SPF based algorithm, BGP-4 protocol mechanics, and BGP-LS > NRLI encoding. > > > > For the purposes of the initial work within the LSVR WG, and until further > specified by the WG, the following definitions apply to this charter. > > > > - Link-State Vector - An LSV is intended to represent a data structure > (data set) comprised of link identification, link attributes, neighbor > information, cost towards neighbors, and other potential attributes that > can be utilized to make routing decisions. > > - LSVR Distribution Domain - Initially scoped as a set of participating > LSVR nodes in a single administrative domain. > > > > > > The LSVR WG is chartered to deliver the following documents: > > > > - Publish Applicability Statement for the use of LSVR in the Datacenter - > Target Status: Informational > > - Publish specification document describing LSV with standard Dijkstra SPF > route/path selection (calculation) utilizing existing BGP protocol baseline > functionality and BGP-LS packet encoding formats - Target: Standards Track > (Based on draft draft-keyupate-idr-bgp-spf) > > - Publish specification documenting protocol extensions required to > efficiently reuse BGP to distribute LSVs within an IPv4/IPv6 DC with scope > to include privacy and security considerations - - Target: Standards Track > > - Publish YANG model specification for LSVR - - Target: Standards Track > > > > LSVR Milestones: > > > > - Applicability statement for LSVR in DCs: March 2019 > > - LSVR with standard Dijkstra path selection: March 2019 > > - LSV distribution using BGP transport: March 2019 > > - YANG specification for LSRV: July 2019 > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > --94eb2c08f932545cf505637c8dc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interesting.
+1 on participating

Padma

On Tue, Jan 23, 2018 at 10:57 PM, Serpil Bayraktar (serpil) <serpil@cisco= .com> wrote:

This is an interesting (and useful) approach. I am v= ery interested in participating.

=C2=A0

Serpil

=C2=A0

From= : Idr <idr-bounces@ietf.org= > on behalf of "Van De Velde, Gunter (Nokia - BE/Antwerp)" <= ;gunter.= van_de_velde@nokia.com>
Date: Tuesday, January 23, 2018 at 11:07 AM
To: "Lsvr@ie= tf.org" <Lsv= r@ietf.org>
Cc: "idr@ietf= .org" <idr@ie= tf.org>, "dcrouting@ietf.org" <dcrouting@ietf.org>, Victor Kuarsingh <victor.kuarsingh@= oracle.com>, Keyur Patel <keyur@arrcus.com>, "Van De Velde, Gunter (Nokia = - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, Shawn Zandi <= ;szandi@linkedin.c= om>, "rtgwg@ietf.org" <rtgwg@ietf= .org>
Subject: [Idr] Kicking off the LSVR (Link State Vector Routing) char= ter discussion

=C2=A0

[Note: Target audience, and discussions should happen on lsvr@ietf.org<= /span>, however "rtgwg", "idr" a= nd "dcrouting" email lists have been added as the concepts originated in those working groups]

=C2=A0

Since dcrouting@ietf100, a few people have bee= n discussing a possible WG charter for LSVR (Link State Vector Routing).=

Here is what we have so far.=C2=A0=C2=A0Commen= ts and improvements would be most welcome.

=C2=A0

WG page is to be setup soon.

Subscription to LSVR mailing list: https://www.ietf.org/mailman/listinfo/lsvr

=C2=A0

Feedback (comments, edits, corrections, etc)= =C2=A0=C2=A0on the draft LSVR charter is appreciated

=C2=A0

=C2=A0

***** DRAFT CHARTER UPDATE - JAN 10 2018 *****=

=C2=A0

Charter: LSVR - Link State Vector Routing=C2= =A0

=C2=A0

The Link-State Vector Routing (LSVR) Working G= roup is chartered to develop and document a hybrid routing protocol utilizi= ng a combination of link-state and path-vector routing mechanisms.=C2=A0 Th= e LSVR WG will utilize existing the IPv4/IPv6 transport, packet formats, and= error handling from BGP-4 (RFC4271). Additionally, the=C2=A0BGP-LS NLRI en= coding mechanisms defined in RFC7752 are utilized=C2=A0to facilitate Link-S= tate Vector (LSV) routing information distribution. An LSV is intended to be specified as a data structure comprised of a link= identification, link attributes, neighbor information, cost toward neighbo= rs, and other attributes that are defined for control plane function and po= licy-based routing decisions.

=C2=A0

The LSVR specification is initially focused on= operation within a single datacenter (DC) with preliminary focus on specif= ying functionality within a single distribution domain.=C2=A0 Routing proto= col functionality defined by LSVR would be typically routing within a datacent= er's underlay routing plane.=C2=A0

=C2=A0

In order to achieve the noted objective, the w= orking group will focus on standardization of protocol functionality, defin= ing Link-State Vectors (LSVs), and defining standard path-vector route selection utilizing existing Dijkstra SPF based algorithm, BGP-4 protocol = mechanics, and BGP-LS NRLI encoding.

=C2=A0

For the purposes of the initial work within th= e LSVR WG, and until further specified by the WG, the following definitions= apply to this charter.

=C2=A0

- Link-State Vector - An LSV is intended to re= present a data structure (data set) comprised of link identification, link = attributes, neighbor information, cost towards neighbors, and other potenti= al attributes that can be utilized to make routing decisions.

- LSVR Distribution Domain - Initially scoped = as a set of participating LSVR nodes in a single administrative domain.<= /u>

=C2=A0

=C2=A0

The LSVR WG is chartered to deliver the follow= ing documents:

=C2=A0

- Publish Applicability Statement for the use = of LSVR in the Datacenter - Target Status: Informational

- Publish specification document describing LS= V with standard Dijkstra SPF route/path selection (calculation) utilizing e= xisting BGP protocol baseline functionality and BGP-LS packet encoding formats - Target: Standards Track (Based on draft draft-keyupate-idr-bgp-s= pf)

- Publish specification documenting protocol e= xtensions required to efficiently reuse BGP to distribute LSVs within an IP= v4/IPv6 DC with scope to include privacy and security considerations - - Target: Standards Track

- Publish YANG model specification for LSVR - = - Target: Standards Track

=C2=A0

LSVR Milestones:

=C2=A0

- Applicability statement for LSVR in DCs: Mar= ch 2019

- LSVR with standard Dijkstra path selection: = March 2019

- LSV distribution using BGP transport: March = 2019

- YANG specification for LSRV: July 2019

=C2=A0

_________________________________________= ______

Idr mailing list

Idr@ietf.org<= /span>

=C2=A0


_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg


--94eb2c08f932545cf505637c8dc1-- From nobody Wed Jan 24 11:10:49 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C351C12773A; Wed, 24 Jan 2018 11:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 spgBPBqIAUIF; Wed, 24 Jan 2018 11:10:45 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0056.outbound.protection.outlook.com [104.47.32.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AF81275FD; Wed, 24 Jan 2018 11:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pleWXv2S/Njnu0CR9/Y8uiqnZrhEULjMFJKxGuBwYQ4=; b=XbMnfO9K/h68sBq5hXkboCt+lF0fKf89Ny6a6xJq33DjEm8EEcHCYvIFZjaeZBejt4orJI5ZZAD834crUmGuzCxqT4e0wYd/LNK6BDuIgMN8POC5hQWUU+CTp/ltwM6KO89Y62uhEYNE43O81p6CELBfSM/iK+JiUAw72L3TEY8= Received: from BY2PR18MB0328.namprd18.prod.outlook.com (10.163.192.30) by BY2PR18MB0325.namprd18.prod.outlook.com (10.163.192.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Wed, 24 Jan 2018 19:10:42 +0000 Received: from BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) by BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) with mapi id 15.20.0428.024; Wed, 24 Jan 2018 19:10:42 +0000 From: Keyur Patel To: =?utf-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?= , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "Lsvr@ietf.org" , Idr CC: "idr@ietf.org" , "dcrouting@ietf.org" , Victor Kuarsingh , Shawn Zandi , "rtgwg@ietf.org" Thread-Topic: =?utf-8?B?W0lkcl0g5Zue5aSN77yaIFtMc3ZyXSBLaWNraW5nIG9mZiB0aGUgTFNWUiAo?= =?utf-8?Q?Link_State_Vector_Routing)_charter_discussion?= Thread-Index: AQHTlLU43aeicP2z0kCnXG6MqUB/YKOC3niA Date: Wed, 24 Jan 2018 19:10:42 +0000 Message-ID: <5CD802DC-D344-4619-A1B9-A000F29D6875@arrcus.com> References: <31C68D70-CEC8-419E-BAD3-F1F7D55907FA@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [2602:306:3005:4f60:dd3a:a414:ec0f:60b5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR18MB0325; 7:FB45+T4tJlajhQU6ZKrVVy+OJD76HUN5k4f1YdVWMeXCX+NMIglG1uw4jigE+NRgKYVHt6yzMI8RZaU4K7MJLQfJnHdVArfYTs5fuQTEx0+h+38cIqT4+/pOtP1kNlGqTN4fiK1Z6YSqHJI6tnqHL1pCkZT5ZudLTP3k1Bjhu8f8YZLghTET7KEMyldzeGTn5ZRCA76TuMmPS7tfaN9WTsQ3rEbA/H0nhb3bluFmYlazeuSxHTPcpr50yrWvOMyC x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d190e0fc-14f8-41d9-90b1-08d5635e2a1d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR18MB0325; x-ms-traffictypediagnostic: BY2PR18MB0325: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(93897516114553)(192374486261705)(82608151540597)(85827821059158)(95692535739014)(21748063052155)(81160342030619)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041288)(20161123562045)(2016111802025)(20161123558120)(20161123564045)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:BY2PR18MB0325; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0325; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(39830400003)(376002)(396003)(346002)(13464003)(189003)(199004)(68736007)(86362001)(81156014)(77096007)(81166006)(33656002)(8936002)(102836004)(3660700001)(83716003)(54906003)(9326002)(14454004)(53546011)(2906002)(105586002)(2501003)(54896002)(6306002)(25786009)(36756003)(6116002)(2950100002)(76176011)(5660300001)(53936002)(6512007)(6246003)(99286004)(6436002)(6486002)(6506007)(3280700002)(4326008)(59450400001)(45080400002)(316002)(7736002)(97736004)(110136005)(966005)(229853002)(224303003)(82746002)(2900100001)(478600001)(8656006)(106356001)(186003)(437434002)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0325; H:BY2PR18MB0328.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: a7HEs2iKAH9d+HGz7W1yo+KhGB3HVlkRLKv7p09THybDob4ti2Eq+gQASkrPLJvrnDeRDuii2a09/WpobsWs4w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5CD802DCD3444619A1B9A000F29D6875arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: d190e0fc-14f8-41d9-90b1-08d5635e2a1d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 19:10:42.6043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0325 Archived-At: Subject: Re: [Dcrouting] =?utf-8?b?W0lkcl0g5Zue5aSN77yaIFtMc3ZyXSBLaWNraW5n?= =?utf-8?q?_off_the_LSVR_=28Link_State_Vector_Routing=29_charter_discussio?= =?utf-8?q?n?= X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 19:10:49 -0000 --_000_5CD802DCD3444619A1B9A000F29D6875arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWGlhb2h1LA0KDQpZb3VyIHJpZ2h0LiBIYXZpbmcgc2FpZCB0aGF0IHRoZSBiYXNpYyBCR1Ag bmVpZ2hib3IgaGFuZGxpbmcgbWVjaGFuaXNtLCB1cGRhdGUgaGFuZGxpbmcsIGFuZCBhbnkgaW1w bGVtZW50YXRpb24gc3BlY2lmaWMga25vYnMgdGhhdCBjYW4gYmUgbGV2ZXJhZ2VkIGFyZW7igJl0 IGV4cGxpY2l0bHkgZWxpbWluYXRlZCBhcyBwYXJ0IG9mIEJHUC1TUEYgKGFuZCBoZW5jZSB0aGUg cmVmZXJlbmNlIHRvIHRoZSBoeWJyaWQgcm91dGluZyBwcm90b2NvbCkuDQoNClJlZ2FyZHMsDQpL ZXl1cg0KDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIuW+ kOWwj+iZjijkuYnlhYgpIiA8eGlhb2h1Lnh4aEBhbGliYWJhLWluYy5jb20+DQpSZXBseS1Ubzog IuW+kOWwj+iZjijkuYnlhYgpIiA8eGlhb2h1Lnh4aEBhbGliYWJhLWluYy5jb20+DQpEYXRlOiBU dWVzZGF5LCBKYW51YXJ5IDIzLCAyMDE4IGF0IDU6NDYgUE0NClRvOiAiVmFuIERlIFZlbGRlLCBH dW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkiIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNv bT4sICJMc3ZyQGlldGYub3JnIiA8THN2ckBpZXRmLm9yZz4sIElkciA8aWRyLWJvdW5jZXNAaWV0 Zi5vcmc+DQpDYzogImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4sICJkY3JvdXRpbmdAaWV0 Zi5vcmciIDxkY3JvdXRpbmdAaWV0Zi5vcmc+LCBWaWN0b3IgS3VhcnNpbmdoIDx2aWN0b3Iua3Vh cnNpbmdoQG9yYWNsZS5jb20+LCBLZXl1ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNvbT4sIFNoYXdu IFphbmRpIDxzemFuZGlAbGlua2VkaW4uY29tPiwgInJ0Z3dnQGlldGYub3JnIiA8cnRnd2dAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbSWRyXSDlm57lpI3vvJogW0xzdnJdIEtpY2tpbmcgb2ZmIHRoZSBM U1ZSIChMaW5rIFN0YXRlIFZlY3RvciBSb3V0aW5nKSBjaGFydGVyIGRpc2N1c3Npb24NCg0KSnVz dCBhIG1pbm9yIHF1ZXN0aW9uOiB3aHkgY2FsbCBpdCBhIGh5YnJpZCByb3V0aW5nIHByb3RvY29s IHV0aWxpemluZyBhIGNvbWJpbmF0aW9uIG9mIGxpbmstc3RhdGUgYW5kIHBhdGgtdmVjdG9yIHJv dXRpbmcgbWVjaGFuaXNtcz8gbW9yZSBzcGVjaWZpY2FsbHksIHdoYXQgcGFydCBvZiB0aGUgQkdQ LVNQRiByZXNvcnRzIHRvIHRoZSBwYXRoLXZlY3RvciByb3V0aW5nIG1lY2hhbmlzbT8gSU1ITywg QkdQLVNQRiBoYXMgdHJhbnNmb3JtZWQgdGhlIHRyYWRpdGlvbmFsIEJHUCB0byBhIGNvbXBsZXRl IGxpbmstc3RhdGUgcm91dGluZyBwcm90b2NvbCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUg cm91dGluZyBjb21wdXRpbmcgYWxnb3JpdGhtLCBubz8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCuWPkeS7tuS6uu+8mlJhYmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTL01vdW50 YWluIFZpZXcpIDxqb3JnZS5yYWJhZGFuQG5va2lhLmNvbT4NCuWPkemAgeaXtumXtO+8mjIwMTjl ubQx5pyIMjTml6Uo5pif5pyf5LiJKSAwMzowNw0K5pS25Lu25Lq677yaIlZhbiBEZSBWZWxkZSwg R3VudGVyIChOb2tpYSAtIEJFL0FudHdlcnApIiA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5j b20+OyBMc3ZyQGlldGYub3JnIDxMc3ZyQGlldGYub3JnPg0K5oqE44CA6YCB77yaaWRyQGlldGYu b3JnIDxpZHJAaWV0Zi5vcmc+OyBkY3JvdXRpbmdAaWV0Zi5vcmcgPGRjcm91dGluZ0BpZXRmLm9y Zz47IFZpY3RvciBLdWFyc2luZ2ggPHZpY3Rvci5rdWFyc2luZ2hAb3JhY2xlLmNvbT47IEtleXVy IFBhdGVsIDxrZXl1ckBhcnJjdXMuY29tPjsgU2hhd24gWmFuZGkgPHN6YW5kaUBsaW5rZWRpbi5j b20+OyBydGd3Z0BpZXRmLm9yZyA8cnRnd2dAaWV0Zi5vcmc+DQrkuLvjgIDpopjvvJpSZTogW0lk cl0gW0xzdnJdIEtpY2tpbmcgb2ZmIHRoZSBMU1ZSIChMaW5rIFN0YXRlIFZlY3RvciBSb3V0aW5n KSBjaGFydGVyIGRpc2N1c3Npb24NCg0KQWZ0ZXIgZ29pbmcgdGhyb3VnaCB0aGUgY2hhcnRlciB0 ZXh0LCBJIGJlbGlldmUgaXQgaXMgYSB2ZXJ5IGdvb2Qgc3RhcnRpbmcgcG9pbnQuDQpMb29raW5n IGZvcndhcmQgdG8gc2VlaW5nIGZydWl0ZnVsIGRpc2N1c3Npb25zLg0KDQpUaGFua3MuDQpKb3Jn ZQ0KDQogLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExzdnIgPGxzdnItYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mICJWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBC RS9BbnR3ZXJwKSIgPGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPg0KRGF0ZTogV2VkbmVz ZGF5LCBKYW51YXJ5IDEwLCAyMDE4IGF0IDExOjUyIEFNDQpUbzogIkxzdnJAaWV0Zi5vcmciIDxM c3ZyQGlldGYub3JnPg0KQ2M6ICJpZHJAaWV0Zi5vcmciIDxpZHJAaWV0Zi5vcmc+LCAiZGNyb3V0 aW5nQGlldGYub3JnIiA8ZGNyb3V0aW5nQGlldGYub3JnPiwgVmljdG9yIEt1YXJzaW5naCA8dmlj dG9yLmt1YXJzaW5naEBvcmFjbGUuY29tPiwgS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5jb20+ LCAiVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkiIDxndW50ZXIudmFu X2RlX3ZlbGRlQG5va2lhLmNvbT4sIFNoYXduIFphbmRpIDxzemFuZGlAbGlua2VkaW4uY29tPiwg QWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4sICJBY2VlIExpbmRlbSAoYWNl ZSkiIDxhY2VlQGNpc2NvLmNvbT4sICJydGd3Z0BpZXRmLm9yZyIgPHJ0Z3dnQGlldGYub3JnPg0K U3ViamVjdDogW0xzdnJdIEtpY2tpbmcgb2ZmIHRoZSBMU1ZSIChMaW5rIFN0YXRlIFZlY3RvciBS b3V0aW5nKSBjaGFydGVyIGRpc2N1c3Npb24NCg0KICAgIFtOb3RlOiBUYXJnZXQgYXVkaWVuY2Us IGFuZCBkaXNjdXNzaW9ucyBzaG91bGQgaGFwcGVuIG9uIGxzdnJAaWV0Zi5vcmcsIGhvd2V2ZXIg InJ0Z3dnIiwgImlkciIgYW5kICJkY3JvdXRpbmciIGVtYWlsIGxpc3RzIGhhdmUgYmVlbiBhZGRl ZCBhcyB0aGUgY29uY2VwdHMgb3JpZ2luYXRlZCBpbiB0aG9zZSB3b3JraW5nIGdyb3Vwc10NCg0K ICAgIFNpbmNlIGRjcm91dGluZ0BpZXRmMTAwLCBhIGZldyBwZW9wbGUgaGF2ZSBiZWVuIGRpc2N1 c3NpbmcgYSBwb3NzaWJsZSBXRyBjaGFydGVyIGZvciBMU1ZSIChMaW5rIFN0YXRlIFZlY3RvciBS b3V0aW5nKS4NCiAgICBIZXJlIGlzIHdoYXQgd2UgaGF2ZSBzbyBmYXIuICBDb21tZW50cyBhbmQg aW1wcm92ZW1lbnRzIHdvdWxkIGJlIG1vc3Qgd2VsY29tZS4NCg0KICAgIFdHIHBhZ2UgaXMgdG8g YmUgc2V0dXAgc29vbi4NCiAgICBTdWJzY3JpcHRpb24gdG8gTFNWUiBtYWlsaW5nIGxpc3Q6IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHN2cg0KDQogICAgRmVlZGJhY2sg KGNvbW1lbnRzLCBlZGl0cywgY29ycmVjdGlvbnMsIGV0YykgIG9uIHRoZSBkcmFmdCBMU1ZSIGNo YXJ0ZXIgaXMgYXBwcmVjaWF0ZWQNCg0KDQogICAgKioqKiogRFJBRlQgQ0hBUlRFUiBVUERBVEUg LSBKQU4gMTAgMjAxOCAqKioqKg0KDQogICAgQ2hhcnRlcjogTFNWUiAtIExpbmsgU3RhdGUgVmVj dG9yIFJvdXRpbmcNCg0KICAgIFRoZSBMaW5rLVN0YXRlIFZlY3RvciBSb3V0aW5nIChMU1ZSKSBX b3JraW5nIEdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGFuZCBkb2N1bWVudCBhIGh5YnJp ZCByb3V0aW5nIHByb3RvY29sIHV0aWxpemluZyBhIGNvbWJpbmF0aW9uIG9mIGxpbmstc3RhdGUg YW5kIHBhdGgtdmVjdG9yIHJvdXRpbmcgbWVjaGFuaXNtcy4gIFRoZSBMU1ZSIFdHIHdpbGwgdXRp bGl6ZSBleGlzdGluZyB0aGUgSVB2NC9JUHY2IHRyYW5zcG9ydCwgcGFja2V0IGZvcm1hdHMsIGFu ZCBlcnJvciBoYW5kbGluZyBmcm9tIEJHUC00IChSRkM0MjcxKS4gQWRkaXRpb25hbGx5LCB0aGUg QkdQLUxTIE5MUkkgZW5jb2RpbmcgbWVjaGFuaXNtcyBkZWZpbmVkIGluIFJGQzc3NTIgYXJlIHV0 aWxpemVkIHRvIGZhY2lsaXRhdGUgTGluay1TdGF0ZSBWZWN0b3IgKExTVikgcm91dGluZyBpbmZv cm1hdGlvbiBkaXN0cmlidXRpb24uIEFuIExTViBpcyBpbnRlbmRlZCB0byBiZSBzcGVjaWZpZWQg YXMgYSBkYXRhIHN0cnVjdHVyZSBjb21wcmlzZWQgb2YgYSBsaW5rIGlkZW50aWZpY2F0aW9uLCBs aW5rIGF0dHJpYnV0ZXMsIG5laWdoYm9yIGluZm9ybWF0aW9uLCBjb3N0IHRvd2FyZCBuZWlnaGJv cnMsIGFuZCBvdGhlciBhdHRyaWJ1dGVzIHRoYXQgYXJlIGRlZmluZWQgZm9yIGNvbnRyb2wgcGxh bmUgZnVuY3Rpb24gYW5kIHBvbGljeS1iYXNlZCByb3V0aW5nIGRlY2lzaW9ucy4NCg0KICAgIFRo ZSBMU1ZSIHNwZWNpZmljYXRpb24gaXMgaW5pdGlhbGx5IGZvY3VzZWQgb24gb3BlcmF0aW9uIHdp dGhpbiBhIHNpbmdsZSBkYXRhY2VudGVyIChEQykgd2l0aCBwcmVsaW1pbmFyeSBmb2N1cyBvbiBz cGVjaWZ5aW5nIGZ1bmN0aW9uYWxpdHkgd2l0aGluIGEgc2luZ2xlIGRpc3RyaWJ1dGlvbiBkb21h aW4uICBSb3V0aW5nIHByb3RvY29sIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZCBieSBMU1ZSIHdvdWxk IGJlIHR5cGljYWxseSByb3V0aW5nIHdpdGhpbiBhIGRhdGFjZW50ZXIncyB1bmRlcmxheSByb3V0 aW5nIHBsYW5lLg0KDQogICAgSW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGUgbm90ZWQgb2JqZWN0aXZl LCB0aGUgd29ya2luZyBncm91cCB3aWxsIGZvY3VzIG9uIHN0YW5kYXJkaXphdGlvbiBvZiBwcm90 b2NvbCBmdW5jdGlvbmFsaXR5LCBkZWZpbmluZyBMaW5rLVN0YXRlIFZlY3RvcnMgKExTVnMpLCBh bmQgZGVmaW5pbmcgc3RhbmRhcmQgcGF0aC12ZWN0b3Igcm91dGUgc2VsZWN0aW9uIHV0aWxpemlu ZyBleGlzdGluZyBEaWprc3RyYSBTUEYgYmFzZWQgYWxnb3JpdGhtLCBCR1AtNCBwcm90b2NvbCBt ZWNoYW5pY3MsIGFuZCBCR1AtTFMgTlJMSSBlbmNvZGluZy4NCg0KICAgIEZvciB0aGUgcHVycG9z ZXMgb2YgdGhlIGluaXRpYWwgd29yayB3aXRoaW4gdGhlIExTVlIgV0csIGFuZCB1bnRpbCBmdXJ0 aGVyIHNwZWNpZmllZCBieSB0aGUgV0csIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbnMgYXBwbHkg dG8gdGhpcyBjaGFydGVyLg0KDQogICAgLSBMaW5rLVN0YXRlIFZlY3RvciAtIEFuIExTViBpcyBp bnRlbmRlZCB0byByZXByZXNlbnQgYSBkYXRhIHN0cnVjdHVyZSAoZGF0YSBzZXQpIGNvbXByaXNl ZCBvZiBsaW5rIGlkZW50aWZpY2F0aW9uLCBsaW5rIGF0dHJpYnV0ZXMsIG5laWdoYm9yIGluZm9y bWF0aW9uLCBjb3N0IHRvd2FyZHMgbmVpZ2hib3JzLCBhbmQgb3RoZXIgcG90ZW50aWFsIGF0dHJp YnV0ZXMgdGhhdCBjYW4gYmUgdXRpbGl6ZWQgdG8gbWFrZSByb3V0aW5nIGRlY2lzaW9ucy4NCiAg ICAtIExTVlIgRGlzdHJpYnV0aW9uIERvbWFpbiAtIEluaXRpYWxseSBzY29wZWQgYXMgYSBzZXQg b2YgcGFydGljaXBhdGluZyBMU1ZSIG5vZGVzIGluIGEgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGRv bWFpbi4NCg0KDQogICAgVGhlIExTVlIgV0cgaXMgY2hhcnRlcmVkIHRvIGRlbGl2ZXIgdGhlIGZv bGxvd2luZyBkb2N1bWVudHM6DQoNCiAgICAtIFB1Ymxpc2ggQXBwbGljYWJpbGl0eSBTdGF0ZW1l bnQgZm9yIHRoZSB1c2Ugb2YgTFNWUiBpbiB0aGUgRGF0YWNlbnRlciAtIFRhcmdldCBTdGF0dXM6 IEluZm9ybWF0aW9uYWwNCiAgICAtIFB1Ymxpc2ggc3BlY2lmaWNhdGlvbiBkb2N1bWVudCBkZXNj cmliaW5nIExTViB3aXRoIHN0YW5kYXJkIERpamtzdHJhIFNQRiByb3V0ZS9wYXRoIHNlbGVjdGlv biAoY2FsY3VsYXRpb24pIHV0aWxpemluZyBleGlzdGluZyBCR1AgcHJvdG9jb2wgYmFzZWxpbmUg ZnVuY3Rpb25hbGl0eSBhbmQgQkdQLUxTIHBhY2tldCBlbmNvZGluZyBmb3JtYXRzIC0gVGFyZ2V0 OiBTdGFuZGFyZHMgVHJhY2sgKEJhc2VkIG9uIGRyYWZ0IGRyYWZ0LWtleXVwYXRlLWlkci1iZ3At c3BmKQ0KICAgIC0gUHVibGlzaCBzcGVjaWZpY2F0aW9uIGRvY3VtZW50aW5nIHByb3RvY29sIGV4 dGVuc2lvbnMgcmVxdWlyZWQgdG8gZWZmaWNpZW50bHkgcmV1c2UgQkdQIHRvIGRpc3RyaWJ1dGUg TFNWcyB3aXRoaW4gYW4gSVB2NC9JUHY2IERDIHdpdGggc2NvcGUgdG8gaW5jbHVkZSBwcml2YWN5 IGFuZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyAtIC0gVGFyZ2V0OiBTdGFuZGFyZHMgVHJhY2sN CiAgICAtIFB1Ymxpc2ggWUFORyBtb2RlbCBzcGVjaWZpY2F0aW9uIGZvciBMU1ZSIC0gLSBUYXJn ZXQ6IFN0YW5kYXJkcyBUcmFjaw0KDQogICAgTFNWUiBNaWxlc3RvbmVzOg0KDQogICAgLSBBcHBs aWNhYmlsaXR5IHN0YXRlbWVudCBmb3IgTFNWUiBpbiBEQ3M6IE1hcmNoIDIwMTkNCiAgICAtIExT VlIgd2l0aCBzdGFuZGFyZCBEaWprc3RyYSBwYXRoIHNlbGVjdGlvbjogTWFyY2ggMjAxOQ0KICAg IC0gTFNWIGRpc3RyaWJ1dGlvbiB1c2luZyBCR1AgdHJhbnNwb3J0OiBNYXJjaCAyMDE5DQogICAg LSBZQU5HIHNwZWNpZmljYXRpb24gZm9yIExTUlY6IEp1bHkgMjAxOQ0KDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBMc3ZyIG1haWxpbmcg bGlzdA0KICAgIExzdnJAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xzdnINCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQo= --_000_5CD802DCD3444619A1B9A000F29D6875arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <7130C6350EEFC64C8F101B4B21DB476E@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ SGkgWGlhb2h1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPllvdXIgcmlnaHQuIEhhdmluZyBz YWlkIHRoYXQgdGhlIGJhc2ljIEJHUCBuZWlnaGJvciBoYW5kbGluZyBtZWNoYW5pc20sIHVwZGF0 ZSBoYW5kbGluZywgYW5kIGFueSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBrbm9icyB0aGF0IGNh biBiZSBsZXZlcmFnZWQgYXJlbuKAmXQgZXhwbGljaXRseSBlbGltaW5hdGVkIGFzIHBhcnQNCiBv ZiBCR1AtU1BGIChhbmQgaGVuY2UgdGhlIHJlZmVyZW5jZSB0byB0aGUgaHlicmlkIHJvdXRpbmcg cHJvdG9jb2wpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPktleXVyPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+SWRyICZsdDtpZHItYm91bmNlc0Bp ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mICZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7O2NvbG9yOmJsYWNrIj7lvpDlsI/omY48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPig8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5LmJ5YWIPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4pJnF1b3Q7DQogJmx0 O3hpYW9odS54eGhAYWxpYmFiYS1pbmMuY29tJmd0Ozxicj4NCjxiPlJlcGx5LVRvOiA8L2I+JnF1 b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDs7 Y29sb3I6YmxhY2siPuW+kOWwj+iZjjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTtjb2xvcjpibGFjayI+KDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu O2NvbG9yOmJsYWNrIj7kuYnlhYg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2siPikmcXVvdDsgJmx0O3hpYW9odS54eGhAYWxpYmFiYS1pbmMuY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDIzLCAyMDE4IGF0IDU6NDYgUE08 YnI+DQo8Yj5UbzogPC9iPiZxdW90O1ZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtIEJFL0Fu dHdlcnApJnF1b3Q7ICZsdDtndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbSZndDssICZxdW90 O0xzdnJAaWV0Zi5vcmcmcXVvdDsgJmx0O0xzdnJAaWV0Zi5vcmcmZ3Q7LCBJZHIgJmx0O2lkci1i b3VuY2VzQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7aWRyQGlldGYub3JnJnF1 b3Q7ICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkY3JvdXRpbmdAaWV0Zi5vcmcmcXVvdDsg Jmx0O2Rjcm91dGluZ0BpZXRmLm9yZyZndDssIFZpY3RvciBLdWFyc2luZ2ggJmx0O3ZpY3Rvci5r dWFyc2luZ2hAb3JhY2xlLmNvbSZndDssIEtleXVyIFBhdGVsICZsdDtrZXl1ckBhcnJjdXMuY29t Jmd0OywgU2hhd24gWmFuZGkgJmx0O3N6YW5kaUBsaW5rZWRpbi5jb20mZ3Q7LCAmcXVvdDtydGd3 Z0BpZXRmLm9yZyZxdW90OyAmbHQ7cnRnd2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPltJZHJdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hv JnF1b3Q7O2NvbG9yOmJsYWNrIj7lm57lpI3vvJo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiBbTHN2cl0gS2lja2luZyBvZmYgdGhlIExTVlIgKExp bmsgU3RhdGUgVmVjdG9yIFJvdXRpbmcpIGNoYXJ0ZXIgZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlRhaG9tYTtjb2xvcjpibGFj ayI+SnVzdCBhIG1pbm9yIHF1ZXN0aW9uOiB3aHkgY2FsbCBpdCZuYnNwOzwvc3Bhbj5hJm5ic3A7 aHlicmlkJm5ic3A7cm91dGluZyZuYnNwO3Byb3RvY29sJm5ic3A7dXRpbGl6aW5nJm5ic3A7YSZu YnNwO2NvbWJpbmF0aW9uJm5ic3A7b2YmbmJzcDtsaW5rLXN0YXRlJm5ic3A7YW5kJm5ic3A7cGF0 aC12ZWN0b3ImbmJzcDtyb3V0aW5nJm5ic3A7bWVjaGFuaXNtcz8gbW9yZSBzcGVjaWZpY2FsbHks IHdoYXQgcGFydCBvZg0KIHRoZSBCR1AtU1BGIHJlc29ydHMgdG8gdGhlIHBhdGgtdmVjdG9yIHJv dXRpbmcgbWVjaGFuaXNtPyBJTUhPLCBCR1AtU1BGIGhhcyB0cmFuc2Zvcm1lZCB0aGUgdHJhZGl0 aW9uYWwgQkdQIHRvIGEgY29tcGxldGUgbGluay1zdGF0ZSByb3V0aW5nIHByb3RvY29sIGZyb20g dGhlIHBlcnNwZWN0aXZlIG9mIHRoZSByb3V0aW5nIGNvbXB1dGluZyBhbGdvcml0aG0sIG5vPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6VGFob21hO2NvbG9yOmJsYWNrIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6VGFob21hO2NvbG9yOmJsYWNr Ij5YaWFvaHU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTpUYWhvbWE7Y29sb3I6YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Y+R5Lu25Lq6 77yaPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlRhaG9t YTtjb2xvcjpibGFjayI+UmFiYWRhbiwgSm9yZ2UgKE5va2lhIC0gVVMvTW91bnRhaW4gVmlldykg Jmx0O2pvcmdlLnJhYmFkYW5Abm9raWEuY29tJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Y+R6YCB5pe26Ze077yaPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlRhaG9tYTtjb2xv cjpibGFjayI+MjAxODwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDs7Y29sb3I6YmxhY2siPuW5tDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpUYWhvbWE7Y29sb3I6YmxhY2siPjE8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg TWluY2hvJnF1b3Q7O2NvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6VGFob21hO2NvbG9yOmJsYWNrIj4yNDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDs7 Y29sb3I6YmxhY2siPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpUYWhvbWE7Y29sb3I6YmxhY2siPig8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7O2NvbG9yOmJsYWNrIj7m mJ/mnJ/kuIk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 VGFob21hO2NvbG9yOmJsYWNrIj4pDQogMDM6MDc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDs7Y29sb3I6YmxhY2siPuaUtuS7 tuS6uu+8mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpU YWhvbWE7Y29sb3I6YmxhY2siPiZxdW90O1ZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtIEJF L0FudHdlcnApJnF1b3Q7ICZsdDtndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbSZndDs7IExz dnJAaWV0Zi5vcmcgJmx0O0xzdnJAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7O2NvbG9yOmJsYWNrIj7m ioTjgIDpgIHvvJo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6VGFob21hO2NvbG9yOmJsYWNrIj5pZHJAaWV0Zi5vcmcgJmx0O2lkckBpZXRmLm9yZyZndDs7 IGRjcm91dGluZ0BpZXRmLm9yZyAmbHQ7ZGNyb3V0aW5nQGlldGYub3JnJmd0OzsgVmljdG9yIEt1 YXJzaW5naCAmbHQ7dmljdG9yLmt1YXJzaW5naEBvcmFjbGUuY29tJmd0OzsNCiBLZXl1ciBQYXRl bCAmbHQ7a2V5dXJAYXJyY3VzLmNvbSZndDs7IFNoYXduIFphbmRpICZsdDtzemFuZGlAbGlua2Vk aW4uY29tJmd0OzsgcnRnd2dAaWV0Zi5vcmcgJmx0O3J0Z3dnQGlldGYub3JnJmd0Ozwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90 Oztjb2xvcjpibGFjayI+5Li744CAPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+6aKYPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90Oztjb2xvcjpi bGFjayI+77yaPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OlRhaG9tYTtjb2xvcjpibGFjayI+UmU6DQogW0lkcl0gW0xzdnJdIEtpY2tpbmcgb2ZmIHRoZSBM U1ZSIChMaW5rIFN0YXRlIFZlY3RvciBSb3V0aW5nKSBjaGFydGVyIGRpc2N1c3Npb248L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWZ0ZXImbmJz cDtnb2luZyZuYnNwO3Rocm91Z2gmbmJzcDt0aGUmbmJzcDtjaGFydGVyJm5ic3A7dGV4dCwmbmJz cDtJJm5ic3A7YmVsaWV2ZSZuYnNwO2l0Jm5ic3A7aXMmbmJzcDthJm5ic3A7dmVyeSZuYnNwO2dv b2QmbmJzcDtzdGFydGluZyZuYnNwO3BvaW50Ljxicj4NCkxvb2tpbmcmbmJzcDtmb3J3YXJkJm5i c3A7dG8mbmJzcDtzZWVpbmcmbmJzcDtmcnVpdGZ1bCZuYnNwO2Rpc2N1c3Npb25zLjxicj4NCjxi cj4NClRoYW5rcy48YnI+DQpKb3JnZTxicj4NCjxicj4NCiZuYnNwOy0tLS0tT3JpZ2luYWwmbmJz cDtNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiZuYnNwO0xzdnImbmJzcDsmbHQ7bHN2ci1ib3VuY2Vz QGlldGYub3JnJmd0OyZuYnNwO29uJm5ic3A7YmVoYWxmJm5ic3A7b2YmbmJzcDsmcXVvdDtWYW4m bmJzcDtEZSZuYnNwO1ZlbGRlLCZuYnNwO0d1bnRlciZuYnNwOyhOb2tpYSZuYnNwOy0mbmJzcDtC RS9BbnR3ZXJwKSZxdW90OyZuYnNwOyZsdDtndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbSZn dDs8YnI+DQpEYXRlOiZuYnNwO1dlZG5lc2RheSwmbmJzcDtKYW51YXJ5Jm5ic3A7MTAsJm5ic3A7 MjAxOCZuYnNwO2F0Jm5ic3A7MTE6NTImbmJzcDtBTTxicj4NClRvOiZuYnNwOyZxdW90O0xzdnJA aWV0Zi5vcmcmcXVvdDsmbmJzcDsmbHQ7THN2ckBpZXRmLm9yZyZndDs8YnI+DQpDYzombmJzcDsm cXVvdDtpZHJAaWV0Zi5vcmcmcXVvdDsmbmJzcDsmbHQ7aWRyQGlldGYub3JnJmd0OywmbmJzcDsm cXVvdDtkY3JvdXRpbmdAaWV0Zi5vcmcmcXVvdDsmbmJzcDsmbHQ7ZGNyb3V0aW5nQGlldGYub3Jn Jmd0OywmbmJzcDtWaWN0b3ImbmJzcDtLdWFyc2luZ2gmbmJzcDsmbHQ7dmljdG9yLmt1YXJzaW5n aEBvcmFjbGUuY29tJmd0OywmbmJzcDtLZXl1ciZuYnNwO1BhdGVsJm5ic3A7Jmx0O2tleXVyQGFy cmN1cy5jb20mZ3Q7LCZuYnNwOyZxdW90O1ZhbiZuYnNwO0RlJm5ic3A7VmVsZGUsJm5ic3A7R3Vu dGVyJm5ic3A7KE5va2lhJm5ic3A7LSZuYnNwO0JFL0FudHdlcnApJnF1b3Q7Jm5ic3A7Jmx0O2d1 bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tJmd0OywmbmJzcDtTaGF3biZuYnNwO1phbmRpJm5i c3A7Jmx0O3N6YW5kaUBsaW5rZWRpbi5jb20mZ3Q7LCZuYnNwO0FsdmFybyZuYnNwO1JldGFuYSZu YnNwOyZsdDthcmV0YW5hLmlldGZAZ21haWwuY29tJmd0OywmbmJzcDsmcXVvdDtBY2VlJm5ic3A7 TGluZGVtJm5ic3A7KGFjZWUpJnF1b3Q7Jm5ic3A7Jmx0O2FjZWVAY2lzY28uY29tJmd0OywmbmJz cDsmcXVvdDtydGd3Z0BpZXRmLm9yZyZxdW90OyZuYnNwOyZsdDtydGd3Z0BpZXRmLm9yZyZndDs8 YnI+DQpTdWJqZWN0OiZuYnNwO1tMc3ZyXSZuYnNwO0tpY2tpbmcmbmJzcDtvZmYmbmJzcDt0aGUm bmJzcDtMU1ZSJm5ic3A7KExpbmsmbmJzcDtTdGF0ZSZuYnNwO1ZlY3RvciZuYnNwO1JvdXRpbmcp Jm5ic3A7Y2hhcnRlciZuYnNwO2Rpc2N1c3Npb248YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtbTm90ZTombmJzcDtUYXJnZXQmbmJzcDthdWRpZW5jZSwmbmJzcDthbmQmbmJzcDtk aXNjdXNzaW9ucyZuYnNwO3Nob3VsZCZuYnNwO2hhcHBlbiZuYnNwO29uJm5ic3A7bHN2ckBpZXRm Lm9yZywmbmJzcDtob3dldmVyJm5ic3A7JnF1b3Q7cnRnd2cmcXVvdDssJm5ic3A7JnF1b3Q7aWRy JnF1b3Q7Jm5ic3A7YW5kJm5ic3A7JnF1b3Q7ZGNyb3V0aW5nJnF1b3Q7Jm5ic3A7ZW1haWwmbmJz cDtsaXN0cyZuYnNwO2hhdmUmbmJzcDtiZWVuJm5ic3A7YWRkZWQmbmJzcDthcyZuYnNwO3RoZSZu YnNwO2NvbmNlcHRzJm5ic3A7b3JpZ2luYXRlZCZuYnNwO2luJm5ic3A7dGhvc2UmbmJzcDt3b3Jr aW5nJm5ic3A7Z3JvdXBzXTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO1NpbmNlJm5ic3A7ZGNyb3V0aW5nQGlldGYxMDAsJm5ic3A7YSZu YnNwO2ZldyZuYnNwO3Blb3BsZSZuYnNwO2hhdmUmbmJzcDtiZWVuJm5ic3A7ZGlzY3Vzc2luZyZu YnNwO2EmbmJzcDtwb3NzaWJsZSZuYnNwO1dHJm5ic3A7Y2hhcnRlciZuYnNwO2ZvciZuYnNwO0xT VlImbmJzcDsoTGluayZuYnNwO1N0YXRlJm5ic3A7VmVjdG9yJm5ic3A7Um91dGluZykuPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SGVyZSZuYnNwO2lzJm5ic3A7d2hhdCZuYnNwO3dlJm5i c3A7aGF2ZSZuYnNwO3NvJm5ic3A7ZmFyLiZuYnNwOyZuYnNwO0NvbW1lbnRzJm5ic3A7YW5kJm5i c3A7aW1wcm92ZW1lbnRzJm5ic3A7d291bGQmbmJzcDtiZSZuYnNwO21vc3QmbmJzcDt3ZWxjb21l LiZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO1dHJm5ic3A7cGFnZSZuYnNwO2lzJm5ic3A7dG8mbmJzcDtiZSZuYnNwO3NldHVw Jm5ic3A7c29vbi48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTdWJzY3JpcHRpb24mbmJz cDt0byZuYnNwO0xTVlImbmJzcDttYWlsaW5nJm5ic3A7bGlzdDombmJzcDtodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzdnI8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtGZWVkYmFjayZuYnNwOyhjb21tZW50cywm bmJzcDtlZGl0cywmbmJzcDtjb3JyZWN0aW9ucywmbmJzcDtldGMpJm5ic3A7Jm5ic3A7b24mbmJz cDt0aGUmbmJzcDtkcmFmdCZuYnNwO0xTVlImbmJzcDtjaGFydGVyJm5ic3A7aXMmbmJzcDthcHBy ZWNpYXRlZCZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyoqKioqJm5ic3A7 RFJBRlQmbmJzcDtDSEFSVEVSJm5ic3A7VVBEQVRFJm5ic3A7LSZuYnNwO0pBTiZuYnNwOzEwJm5i c3A7MjAxOCZuYnNwOyoqKioqPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q2hhcnRlcjombmJzcDtMU1ZSJm5ic3A7LSZuYnNw O0xpbmsmbmJzcDtTdGF0ZSZuYnNwO1ZlY3RvciZuYnNwO1JvdXRpbmcmbmJzcDs8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtU aGUmbmJzcDtMaW5rLVN0YXRlJm5ic3A7VmVjdG9yJm5ic3A7Um91dGluZyZuYnNwOyhMU1ZSKSZu YnNwO1dvcmtpbmcmbmJzcDtHcm91cCZuYnNwO2lzJm5ic3A7Y2hhcnRlcmVkJm5ic3A7dG8mbmJz cDtkZXZlbG9wJm5ic3A7YW5kJm5ic3A7ZG9jdW1lbnQmbmJzcDthJm5ic3A7aHlicmlkJm5ic3A7 cm91dGluZyZuYnNwO3Byb3RvY29sJm5ic3A7dXRpbGl6aW5nJm5ic3A7YSZuYnNwO2NvbWJpbmF0 aW9uJm5ic3A7b2YmbmJzcDtsaW5rLXN0YXRlJm5ic3A7YW5kJm5ic3A7cGF0aC12ZWN0b3ImbmJz cDtyb3V0aW5nJm5ic3A7bWVjaGFuaXNtcy4mbmJzcDsmbmJzcDtUaGUmbmJzcDtMU1ZSJm5ic3A7 V0cmbmJzcDt3aWxsJm5ic3A7dXRpbGl6ZSZuYnNwO2V4aXN0aW5nJm5ic3A7dGhlJm5ic3A7SVB2 NC9JUHY2Jm5ic3A7dHJhbnNwb3J0LCZuYnNwO3BhY2tldCZuYnNwO2Zvcm1hdHMsJm5ic3A7YW5k Jm5ic3A7ZXJyb3ImbmJzcDtoYW5kbGluZyZuYnNwO2Zyb20mbmJzcDtCR1AtNCZuYnNwOyhSRkM0 MjcxKS4mbmJzcDtBZGRpdGlvbmFsbHksJm5ic3A7dGhlJm5ic3A7QkdQLUxTJm5ic3A7TkxSSSZu YnNwO2VuY29kaW5nJm5ic3A7bWVjaGFuaXNtcyZuYnNwO2RlZmluZWQmbmJzcDtpbiZuYnNwO1JG Qzc3NTImbmJzcDthcmUmbmJzcDt1dGlsaXplZCZuYnNwO3RvJm5ic3A7ZmFjaWxpdGF0ZSZuYnNw O0xpbmstU3RhdGUmbmJzcDtWZWN0b3ImbmJzcDsoTFNWKSZuYnNwO3JvdXRpbmcmbmJzcDtpbmZv cm1hdGlvbiZuYnNwO2Rpc3RyaWJ1dGlvbi4mbmJzcDtBbiZuYnNwO0xTViZuYnNwO2lzJm5ic3A7 aW50ZW5kZWQmbmJzcDt0byZuYnNwO2JlJm5ic3A7c3BlY2lmaWVkJm5ic3A7YXMmbmJzcDthJm5i c3A7ZGF0YSZuYnNwO3N0cnVjdHVyZSZuYnNwO2NvbXByaXNlZCZuYnNwO29mJm5ic3A7YSZuYnNw O2xpbmsmbmJzcDtpZGVudGlmaWNhdGlvbiwmbmJzcDtsaW5rJm5ic3A7YXR0cmlidXRlcywmbmJz cDtuZWlnaGJvciZuYnNwO2luZm9ybWF0aW9uLCZuYnNwO2Nvc3QmbmJzcDt0b3dhcmQmbmJzcDtu ZWlnaGJvcnMsJm5ic3A7YW5kJm5ic3A7b3RoZXImbmJzcDthdHRyaWJ1dGVzJm5ic3A7dGhhdCZu YnNwO2FyZSZuYnNwO2RlZmluZWQmbmJzcDtmb3ImbmJzcDtjb250cm9sJm5ic3A7cGxhbmUmbmJz cDtmdW5jdGlvbiZuYnNwO2FuZCZuYnNwO3BvbGljeS1iYXNlZCZuYnNwO3JvdXRpbmcmbmJzcDtk ZWNpc2lvbnMuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlJm5ic3A7TFNWUiZuYnNwO3NwZWNpZmljYXRpb24mbmJzcDtp cyZuYnNwO2luaXRpYWxseSZuYnNwO2ZvY3VzZWQmbmJzcDtvbiZuYnNwO29wZXJhdGlvbiZuYnNw O3dpdGhpbiZuYnNwO2EmbmJzcDtzaW5nbGUmbmJzcDtkYXRhY2VudGVyJm5ic3A7KERDKSZuYnNw O3dpdGgmbmJzcDtwcmVsaW1pbmFyeSZuYnNwO2ZvY3VzJm5ic3A7b24mbmJzcDtzcGVjaWZ5aW5n Jm5ic3A7ZnVuY3Rpb25hbGl0eSZuYnNwO3dpdGhpbiZuYnNwO2EmbmJzcDtzaW5nbGUmbmJzcDtk aXN0cmlidXRpb24mbmJzcDtkb21haW4uJm5ic3A7Jm5ic3A7Um91dGluZyZuYnNwO3Byb3RvY29s Jm5ic3A7ZnVuY3Rpb25hbGl0eSZuYnNwO2RlZmluZWQmbmJzcDtieSZuYnNwO0xTVlImbmJzcDt3 b3VsZCZuYnNwO2JlJm5ic3A7dHlwaWNhbGx5Jm5ic3A7cm91dGluZyZuYnNwO3dpdGhpbiZuYnNw O2EmbmJzcDtkYXRhY2VudGVyJ3MmbmJzcDt1bmRlcmxheSZuYnNwO3JvdXRpbmcmbmJzcDtwbGFu ZS4mbmJzcDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtJbiZuYnNwO29yZGVyJm5ic3A7dG8mbmJzcDthY2hpZXZlJm5ic3A7 dGhlJm5ic3A7bm90ZWQmbmJzcDtvYmplY3RpdmUsJm5ic3A7dGhlJm5ic3A7d29ya2luZyZuYnNw O2dyb3VwJm5ic3A7d2lsbCZuYnNwO2ZvY3VzJm5ic3A7b24mbmJzcDtzdGFuZGFyZGl6YXRpb24m bmJzcDtvZiZuYnNwO3Byb3RvY29sJm5ic3A7ZnVuY3Rpb25hbGl0eSwmbmJzcDtkZWZpbmluZyZu YnNwO0xpbmstU3RhdGUmbmJzcDtWZWN0b3JzJm5ic3A7KExTVnMpLCZuYnNwO2FuZCZuYnNwO2Rl ZmluaW5nJm5ic3A7c3RhbmRhcmQmbmJzcDtwYXRoLXZlY3RvciZuYnNwO3JvdXRlJm5ic3A7c2Vs ZWN0aW9uJm5ic3A7dXRpbGl6aW5nJm5ic3A7ZXhpc3RpbmcmbmJzcDtEaWprc3RyYSZuYnNwO1NQ RiZuYnNwO2Jhc2VkJm5ic3A7YWxnb3JpdGhtLCZuYnNwO0JHUC00Jm5ic3A7cHJvdG9jb2wmbmJz cDttZWNoYW5pY3MsJm5ic3A7YW5kJm5ic3A7QkdQLUxTJm5ic3A7TlJMSSZuYnNwO2VuY29kaW5n Ljxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0ZvciZuYnNwO3RoZSZuYnNwO3B1cnBvc2VzJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtpbml0aWFsJm5ic3A7d29yayZuYnNwO3dpdGhpbiZuYnNwO3RoZSZuYnNwO0xTVlImbmJzcDtX RywmbmJzcDthbmQmbmJzcDt1bnRpbCZuYnNwO2Z1cnRoZXImbmJzcDtzcGVjaWZpZWQmbmJzcDti eSZuYnNwO3RoZSZuYnNwO1dHLCZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZyZuYnNwO2RlZmluaXRp b25zJm5ic3A7YXBwbHkmbmJzcDt0byZuYnNwO3RoaXMmbmJzcDtjaGFydGVyLjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0m bmJzcDtMaW5rLVN0YXRlJm5ic3A7VmVjdG9yJm5ic3A7LSZuYnNwO0FuJm5ic3A7TFNWJm5ic3A7 aXMmbmJzcDtpbnRlbmRlZCZuYnNwO3RvJm5ic3A7cmVwcmVzZW50Jm5ic3A7YSZuYnNwO2RhdGEm bmJzcDtzdHJ1Y3R1cmUmbmJzcDsoZGF0YSZuYnNwO3NldCkmbmJzcDtjb21wcmlzZWQmbmJzcDtv ZiZuYnNwO2xpbmsmbmJzcDtpZGVudGlmaWNhdGlvbiwmbmJzcDtsaW5rJm5ic3A7YXR0cmlidXRl cywmbmJzcDtuZWlnaGJvciZuYnNwO2luZm9ybWF0aW9uLCZuYnNwO2Nvc3QmbmJzcDt0b3dhcmRz Jm5ic3A7bmVpZ2hib3JzLCZuYnNwO2FuZCZuYnNwO290aGVyJm5ic3A7cG90ZW50aWFsJm5ic3A7 YXR0cmlidXRlcyZuYnNwO3RoYXQmbmJzcDtjYW4mbmJzcDtiZSZuYnNwO3V0aWxpemVkJm5ic3A7 dG8mbmJzcDttYWtlJm5ic3A7cm91dGluZyZuYnNwO2RlY2lzaW9ucy48YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDstJm5ic3A7TFNWUiZuYnNwO0Rpc3RyaWJ1dGlvbiZuYnNwO0RvbWFpbiZu YnNwOy0mbmJzcDtJbml0aWFsbHkmbmJzcDtzY29wZWQmbmJzcDthcyZuYnNwO2EmbmJzcDtzZXQm bmJzcDtvZiZuYnNwO3BhcnRpY2lwYXRpbmcmbmJzcDtMU1ZSJm5ic3A7bm9kZXMmbmJzcDtpbiZu YnNwO2EmbmJzcDtzaW5nbGUmbmJzcDthZG1pbmlzdHJhdGl2ZSZuYnNwO2RvbWFpbi48YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUmbmJzcDtMU1ZSJm5ic3A7 V0cmbmJzcDtpcyZuYnNwO2NoYXJ0ZXJlZCZuYnNwO3RvJm5ic3A7ZGVsaXZlciZuYnNwO3RoZSZu YnNwO2ZvbGxvd2luZyZuYnNwO2RvY3VtZW50czo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7UHVibGlzaCZuYnNw O0FwcGxpY2FiaWxpdHkmbmJzcDtTdGF0ZW1lbnQmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2Um bmJzcDtvZiZuYnNwO0xTVlImbmJzcDtpbiZuYnNwO3RoZSZuYnNwO0RhdGFjZW50ZXImbmJzcDst Jm5ic3A7VGFyZ2V0Jm5ic3A7U3RhdHVzOiZuYnNwO0luZm9ybWF0aW9uYWw8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7UHVibGlzaCZuYnNwO3NwZWNpZmljYXRpb24mbmJzcDtk b2N1bWVudCZuYnNwO2Rlc2NyaWJpbmcmbmJzcDtMU1YmbmJzcDt3aXRoJm5ic3A7c3RhbmRhcmQm bmJzcDtEaWprc3RyYSZuYnNwO1NQRiZuYnNwO3JvdXRlL3BhdGgmbmJzcDtzZWxlY3Rpb24mbmJz cDsoY2FsY3VsYXRpb24pJm5ic3A7dXRpbGl6aW5nJm5ic3A7ZXhpc3RpbmcmbmJzcDtCR1AmbmJz cDtwcm90b2NvbCZuYnNwO2Jhc2VsaW5lJm5ic3A7ZnVuY3Rpb25hbGl0eSZuYnNwO2FuZCZuYnNw O0JHUC1MUyZuYnNwO3BhY2tldCZuYnNwO2VuY29kaW5nJm5ic3A7Zm9ybWF0cyZuYnNwOy0mbmJz cDtUYXJnZXQ6Jm5ic3A7U3RhbmRhcmRzJm5ic3A7VHJhY2smbmJzcDsoQmFzZWQmbmJzcDtvbiZu YnNwO2RyYWZ0Jm5ic3A7ZHJhZnQta2V5dXBhdGUtaWRyLWJncC1zcGYpPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7LSZuYnNwO1B1Ymxpc2gmbmJzcDtzcGVjaWZpY2F0aW9uJm5ic3A7ZG9j dW1lbnRpbmcmbmJzcDtwcm90b2NvbCZuYnNwO2V4dGVuc2lvbnMmbmJzcDtyZXF1aXJlZCZuYnNw O3RvJm5ic3A7ZWZmaWNpZW50bHkmbmJzcDtyZXVzZSZuYnNwO0JHUCZuYnNwO3RvJm5ic3A7ZGlz dHJpYnV0ZSZuYnNwO0xTVnMmbmJzcDt3aXRoaW4mbmJzcDthbiZuYnNwO0lQdjQvSVB2NiZuYnNw O0RDJm5ic3A7d2l0aCZuYnNwO3Njb3BlJm5ic3A7dG8mbmJzcDtpbmNsdWRlJm5ic3A7cHJpdmFj eSZuYnNwO2FuZCZuYnNwO3NlY3VyaXR5Jm5ic3A7Y29uc2lkZXJhdGlvbnMmbmJzcDstJm5ic3A7 LSZuYnNwO1RhcmdldDombmJzcDtTdGFuZGFyZHMmbmJzcDtUcmFjazxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOy0mbmJzcDtQdWJsaXNoJm5ic3A7WUFORyZuYnNwO21vZGVsJm5ic3A7c3Bl Y2lmaWNhdGlvbiZuYnNwO2ZvciZuYnNwO0xTVlImbmJzcDstJm5ic3A7LSZuYnNwO1RhcmdldDom bmJzcDtTdGFuZGFyZHMmbmJzcDtUcmFjazxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0xTVlImbmJzcDtNaWxlc3RvbmVzOjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOy0mbmJzcDtBcHBsaWNhYmlsaXR5Jm5ic3A7c3RhdGVtZW50Jm5ic3A7Zm9yJm5ic3A7 TFNWUiZuYnNwO2luJm5ic3A7RENzOiZuYnNwO01hcmNoJm5ic3A7MjAxOTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtMU1ZSJm5ic3A7d2l0aCZuYnNwO3N0YW5kYXJkJm5ic3A7 RGlqa3N0cmEmbmJzcDtwYXRoJm5ic3A7c2VsZWN0aW9uOiZuYnNwO01hcmNoJm5ic3A7MjAxOTxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtMU1YmbmJzcDtkaXN0cmlidXRpb24m bmJzcDt1c2luZyZuYnNwO0JHUCZuYnNwO3RyYW5zcG9ydDombmJzcDtNYXJjaCZuYnNwOzIwMTk8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7WUFORyZuYnNwO3NwZWNpZmljYXRp b24mbmJzcDtmb3ImbmJzcDtMU1JWOiZuYnNwO0p1bHkmbmJzcDsyMDE5PGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtMc3ZyJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtMc3ZyQGlldGYub3JnPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3ZyPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpJZHImbmJzcDttYWlsaW5nJm5ic3A7bGlzdDxicj4NCklkckBpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5CD802DCD3444619A1B9A000F29D6875arrcuscom_-- From nobody Wed Jan 24 18:24:06 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7184212778E; Wed, 24 Jan 2018 18:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no 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 YXcVC3fSOH9O; Wed, 24 Jan 2018 18:24:02 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 67819127286; Wed, 24 Jan 2018 18:24:02 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.249.181; From: "Susan Hares" To: "'Van De Velde, Gunter \(Nokia - BE/Antwerp\)'" , Cc: , , "'Victor Kuarsingh'" , "'Keyur Patel'" , "'Shawn Zandi'" , References: In-Reply-To: Date: Wed, 24 Jan 2018 21:23:43 -0500 Message-ID: <00ce01d39583$862e1de0$928a59a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLB9sUCoOZJmFAqxdxYC+t36B9J46GnGIBA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Dcrouting] [Idr] Kicking off the LSVR (Link State Vector Routing) charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 02:24:04 -0000 Gunter: First all - I'm thrilled to see the work in the IETF. =20 I am a long term supporter advancing SSPV (link state path-vector) algorithms (starting in 1999/2000). =20 Second, you have my assurance that we will fast-track any BGP-LS you = deem critical (just as we do for spring, BESS, Grow and other BGP related = WGs).=20 Third, you might want to put coordinate with IDR into your charter. =20 Cheerily, Susan Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Van De Velde, = Gunter (Nokia - BE/Antwerp) Sent: Wednesday, January 10, 2018 5:51 AM To: Lsvr@ietf.org Cc: idr@ietf.org; dcrouting@ietf.org; Victor Kuarsingh; Keyur Patel; Van = De Velde, Gunter (Nokia - BE/Antwerp); Shawn Zandi; rtgwg@ietf.org Subject: [Idr] Kicking off the LSVR (Link State Vector Routing) charter discussion [Note: Target audience, and discussions should happen on lsvr@ietf.org, however "rtgwg", "idr" and "dcrouting" email lists have been added as = the concepts originated in those working groups] Since dcrouting@ietf100, a few people have been discussing a possible WG charter for LSVR (Link State Vector Routing). Here is what we have so far. Comments and improvements would be most welcome.=20 WG page is to be setup soon. Subscription to LSVR mailing list: https://www.ietf.org/mailman/listinfo/lsvr Feedback (comments, edits, corrections, etc) on the draft LSVR charter = is appreciated=20 ***** DRAFT CHARTER UPDATE - JAN 10 2018 ***** =A0 Charter: LSVR - Link State Vector Routing=A0 =A0 The Link-State Vector Routing (LSVR) Working Group is chartered to = develop and document a hybrid routing protocol utilizing a combination of = link-state and path-vector routing mechanisms. =A0The LSVR WG will utilize existing = the IPv4/IPv6 transport, packet formats, and error handling from BGP-4 (RFC4271). Additionally, the=A0BGP-LS NLRI encoding mechanisms defined = in RFC7752 are utilized=A0to facilitate Link-State Vector (LSV) routing information distribution. An LSV is intended to be specified as a data structure comprised of a link identification, link attributes, neighbor information, cost toward neighbors, and other attributes that are = defined for control plane function and policy-based routing decisions. =A0 The LSVR specification is initially focused on operation within a single datacenter (DC) with preliminary focus on specifying functionality = within a single distribution domain. =A0Routing protocol functionality defined by = LSVR would be typically routing within a datacenter's underlay routing = plane.=A0 =A0 In order to achieve the noted objective, the working group will focus on standardization of protocol functionality, defining Link-State Vectors (LSVs), and defining standard path-vector route selection utilizing = existing Dijkstra SPF based algorithm, BGP-4 protocol mechanics, and BGP-LS NRLI encoding. =A0 For the purposes of the initial work within the LSVR WG, and until = further specified by the WG, the following definitions apply to this charter. =A0 - Link-State Vector - An LSV is intended to represent a data structure = (data set) comprised of link identification, link attributes, neighbor information, cost towards neighbors, and other potential attributes that = can be utilized to make routing decisions. - LSVR Distribution Domain - Initially scoped as a set of participating = LSVR nodes in a single administrative domain. =A0 =A0 The LSVR WG is chartered to deliver the following documents: =A0 - Publish Applicability Statement for the use of LSVR in the Datacenter = - Target Status: Informational - Publish specification document describing LSV with standard Dijkstra = SPF route/path selection (calculation) utilizing existing BGP protocol = baseline functionality and BGP-LS packet encoding formats - Target: Standards = Track (Based on draft draft-keyupate-idr-bgp-spf) - Publish specification documenting protocol extensions required to efficiently reuse BGP to distribute LSVs within an IPv4/IPv6 DC with = scope to include privacy and security considerations - - Target: Standards = Track - Publish YANG model specification for LSVR - - Target: Standards Track =A0 LSVR Milestones: =A0 - Applicability statement for LSVR in DCs: March 2019 - LSVR with standard Dijkstra path selection: March 2019 - LSV distribution using BGP transport: March 2019 - YANG specification for LSRV: July 2019 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jan 24 18:41:36 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94504124205; Wed, 24 Jan 2018 18:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no 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 yGzB43pPSdB5; Wed, 24 Jan 2018 18:41:33 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A35AD120047; Wed, 24 Jan 2018 18:41:32 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.249.181; From: "Susan Hares" To: "'Van De Velde, Gunter \(Nokia - BE/Antwerp\)'" , Cc: , , "'Victor Kuarsingh'" , "'Keyur Patel'" , "'Shawn Zandi'" , References: <00ce01d39583$862e1de0$928a59a0$@ndzh.com> In-Reply-To: <00ce01d39583$862e1de0$928a59a0$@ndzh.com> Date: Wed, 24 Jan 2018 21:41:17 -0500 Message-ID: <00f801d39585$fa3c4840$eeb4d8c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLB9sUCoOZJmFAqxdxYC+t36B9J4wIAFu+EoZcaXZA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Dcrouting] [Idr] Kicking off the LSVR (Link State Vector Routing) charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 02:41:34 -0000 Gunter: It looks like my keyboard bounced - I am a long term support of LSPV = (link state path vector).=20 Thank you for arranging this work.=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, January 24, 2018 9:24 PM To: 'Van De Velde, Gunter (Nokia - BE/Antwerp)'; Lsvr@ietf.org Cc: idr@ietf.org; dcrouting@ietf.org; 'Victor Kuarsingh'; 'Keyur Patel'; 'Shawn Zandi'; rtgwg@ietf.org Subject: Re: [Idr] Kicking off the LSVR (Link State Vector Routing) = charter discussion Gunter: First all - I'm thrilled to see the work in the IETF. =20 I am a long term supporter advancing SSPV (link state path-vector) algorithms (starting in 1999/2000). =20 Second, you have my assurance that we will fast-track any BGP-LS you = deem critical (just as we do for spring, BESS, Grow and other BGP related = WGs).=20 Third, you might want to put coordinate with IDR into your charter. =20 Cheerily, Susan Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Van De Velde, = Gunter (Nokia - BE/Antwerp) Sent: Wednesday, January 10, 2018 5:51 AM To: Lsvr@ietf.org Cc: idr@ietf.org; dcrouting@ietf.org; Victor Kuarsingh; Keyur Patel; Van = De Velde, Gunter (Nokia - BE/Antwerp); Shawn Zandi; rtgwg@ietf.org Subject: [Idr] Kicking off the LSVR (Link State Vector Routing) charter discussion [Note: Target audience, and discussions should happen on lsvr@ietf.org, however "rtgwg", "idr" and "dcrouting" email lists have been added as = the concepts originated in those working groups] Since dcrouting@ietf100, a few people have been discussing a possible WG charter for LSVR (Link State Vector Routing). Here is what we have so far. Comments and improvements would be most welcome.=20 WG page is to be setup soon. Subscription to LSVR mailing list: https://www.ietf.org/mailman/listinfo/lsvr Feedback (comments, edits, corrections, etc) on the draft LSVR charter = is appreciated=20 ***** DRAFT CHARTER UPDATE - JAN 10 2018 ***** =A0 Charter: LSVR - Link State Vector Routing=A0 =A0 The Link-State Vector Routing (LSVR) Working Group is chartered to = develop and document a hybrid routing protocol utilizing a combination of = link-state and path-vector routing mechanisms. =A0The LSVR WG will utilize existing = the IPv4/IPv6 transport, packet formats, and error handling from BGP-4 (RFC4271). Additionally, the=A0BGP-LS NLRI encoding mechanisms defined = in RFC7752 are utilized=A0to facilitate Link-State Vector (LSV) routing information distribution. An LSV is intended to be specified as a data structure comprised of a link identification, link attributes, neighbor information, cost toward neighbors, and other attributes that are = defined for control plane function and policy-based routing decisions. =A0 The LSVR specification is initially focused on operation within a single datacenter (DC) with preliminary focus on specifying functionality = within a single distribution domain. =A0Routing protocol functionality defined by = LSVR would be typically routing within a datacenter's underlay routing = plane.=A0 =A0 In order to achieve the noted objective, the working group will focus on standardization of protocol functionality, defining Link-State Vectors (LSVs), and defining standard path-vector route selection utilizing = existing Dijkstra SPF based algorithm, BGP-4 protocol mechanics, and BGP-LS NRLI encoding. =A0 For the purposes of the initial work within the LSVR WG, and until = further specified by the WG, the following definitions apply to this charter. =A0 - Link-State Vector - An LSV is intended to represent a data structure = (data set) comprised of link identification, link attributes, neighbor information, cost towards neighbors, and other potential attributes that = can be utilized to make routing decisions. - LSVR Distribution Domain - Initially scoped as a set of participating = LSVR nodes in a single administrative domain. =A0 =A0 The LSVR WG is chartered to deliver the following documents: =A0 - Publish Applicability Statement for the use of LSVR in the Datacenter = - Target Status: Informational - Publish specification document describing LSV with standard Dijkstra = SPF route/path selection (calculation) utilizing existing BGP protocol = baseline functionality and BGP-LS packet encoding formats - Target: Standards = Track (Based on draft draft-keyupate-idr-bgp-spf) - Publish specification documenting protocol extensions required to efficiently reuse BGP to distribute LSVs within an IPv4/IPv6 DC with = scope to include privacy and security considerations - - Target: Standards = Track - Publish YANG model specification for LSVR - - Target: Standards Track =A0 LSVR Milestones: =A0 - Applicability statement for LSVR in DCs: March 2019 - LSVR with standard Dijkstra path selection: March 2019 - LSV distribution using BGP transport: March 2019 - YANG specification for LSRV: July 2019 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Jan 25 14:28:56 2018 Return-Path: X-Original-To: dcrouting@ietfa.amsl.com Delivered-To: dcrouting@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D00312D777; Thu, 25 Jan 2018 14:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 rmcFvMJbDAAy; Thu, 25 Jan 2018 14:28:47 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 968A3129C6D; Thu, 25 Jan 2018 14:28:47 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id c8so6613153oiy.9; Thu, 25 Jan 2018 14:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=aZhSLqSflOjY0NC+UUX7KJiChNagCzsNd0RPpNnAHz0=; b=doTit4MHTxTqZAcFKUEHf5MKH3Jp9wkg8ghZfq/igHW9OqKi/5jsNpWMKJxDA59akN 3DVv6W8SijK4YAeW4nNbztxlm9LaWxj07BfmGVoF1FoAFkhDVBwlCrykgp8QKrDh4MVk zF/i9oKZJILzsJ7YWXF3cO/Kqek1GQ0hq3T5q81gihck1Z7z3RjnWESQGjr7TGTezsj2 lv8wOVizmfsl79e/2lBROdGTgx44dUM6GSJ6fkHKcNyUeJL2dtn5JkLj0DQx3Lsa8xV+ T51XSxTgHcU6gFnyERvygyFfQ+pAtHPFVBtw8SZvtIZ31T1L4GoQvPq1XdTRI7cEUVN+ o+/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=aZhSLqSflOjY0NC+UUX7KJiChNagCzsNd0RPpNnAHz0=; b=k6FAekknwXj+NlmrPUxCGXMk1sszIhj+3UHehgOZ0ImRaRxaFwXjuJ9zp9MhmNZf3M vHCcBDLV4yQc0pIiyHB8KPDsv37ty/hxRDdjOt5pBdqKsd3Qo9FKVah7NDrupsYK0GqH IHPCFUhEP7oQ+gocg+Iyc29h4aCBL7y827nO62XmQGqUJbXp3CacSpwneOPjGeOjMs/3 M9pNmSXg3Zc3Lpje2N380/u4sgKw6fvAI//IpKU7f1yB72UEtikV/hgaVLxhlPf74U4C /+HTIw61I87nhbBoHZktho2YV2P2G3FyApAV0zTwmbEBY2/IUv7DkCnvw6EPcq1n+nbx 4lvQ== X-Gm-Message-State: AKwxytcM9GcAeR1+qCJOiTvTQngatOcH6u8cJys5xjFJiTkoZBAiBV/8 Mj5jmJC70LVHwHLI3zOhOBpc1G8UIDMUtQSbY7M= X-Google-Smtp-Source: AH8x225NtAiTu/AoewMYe58cRmDmCq38hYKMTBQoTDfTwv3Urxo/6BlID1wAeByqrYeGTnnGbuX2a0cFS8t6vnqWIXM= X-Received: by 10.202.72.69 with SMTP id v66mr10904410oia.214.1516919326988; Thu, 25 Jan 2018 14:28:46 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jan 2018 14:28:46 -0800 From: Alvaro Retana In-Reply-To: <00ce01d39583$862e1de0$928a59a0$@ndzh.com> References: <00ce01d39583$862e1de0$928a59a0$@ndzh.com> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 25 Jan 2018 14:28:46 -0800 Message-ID: To: Susan Hares , lsvr@ietf.org, "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: Victor Kuarsingh , dcrouting@ietf.org, rtgwg@ietf.org, idr@ietf.org, Keyur Patel , Shawn Zandi Content-Type: multipart/alternative; boundary="001a1134fe58a35f690563a14de8" Archived-At: Subject: Re: [Dcrouting] [Idr] Kicking off the LSVR (Link State Vector Routing) charter discussion X-BeenThere: dcrouting@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 22:28:49 -0000 --001a1134fe58a35f690563a14de8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On January 24, 2018 at 9:24:07 PM, Susan Hares (shares@ndzh.com) wrote: Third, you might want to put coordinate with IDR into your charter. Yes, definitely! I=E2=80=99ll add that to the working copy. Thanks! Alvaro. --001a1134fe58a35f690563a14de8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On January 24,= 2018 at 9:24:07 PM, Susan Hares (shares= @ndzh.com) wrote:

Third, you might want to put coordinate with IDR into your c= harter.=C2=A0

Yes, defini= tely!=C2=A0 I=E2=80=99ll add that to the working copy.

Thanks!
Alvaro.
--001a1134fe58a35f690563a14de8--