From nobody Wed Jan 1 07:37:03 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75AC120033 for ; Wed, 1 Jan 2020 07:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Tc0b-4ulG2Zy for ; Wed, 1 Jan 2020 07:37:00 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 D841B12000F for ; Wed, 1 Jan 2020 07:36:59 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id v15so32419670iln.0 for ; Wed, 01 Jan 2020 07:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KaVtVw7Wxh1bhi8b5Ao8CO+9MCFkNblja1cIjkm56k0=; b=vNEdqke8YJ8MRBEqCvzHuIqjKXgkaupf93tsB1iYWwX3qd5gxJQPNyNM9cN2NROfo2 CRupBWaivXkF/2mkYHjrqPhWC0NucCmEKR9lgLRpmZQu8mP6k3VeQfo5Pk4LpjImUzSc d9DD6GZ93x2rxdT9C24TGX8l6AkmotCQsTwC5VRtwvMBeu4HQVh4KOYJ9POHnshi6G1M KVtoPSIvJ/QZYD6EmSQg6Xm8FO22emLY1Hlh54LpTMElGih7WsT5y6GD7kXrCCs63DDx L30Nn2LbbX6A3j5v13/QyTEdp/IrtxlXTLzy2DeJT1JM4xxd4UNwCSY+QWuQa5kKsa4D Ay4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KaVtVw7Wxh1bhi8b5Ao8CO+9MCFkNblja1cIjkm56k0=; b=or3KqN+u46SLEMEQni9FW0fwpGG/1ZuqGwm47ujp7wDM23OwaPB+TLR35EmpdDJg4q swWrOLqhA6iCxh9Am5L/BkK/yRGv3I1m4obfRBqVXFcJL6dLDMBGT28VuWCJV/G09Igp OfhA3QvM8YlhZWe+gz2iGh9t5ANPjSJCXL0FVD+QN3UWd3rn/sQvYCS4AqRsVhDQ1lv+ VfP90RoLUm7Cnrqn6FHP1qnBkA4I16WNpABm+TmDVnCF1FdM5+YPV+5D9FvZgw+UnJra zesZeYQUksu121ludh0sBnnLCDv1e0xkUq6jQ9oW+tbN1icZ9y5jT+2odmAaFLr8FDNH 5VSA== X-Gm-Message-State: APjAAAXdcmrDesj1vKgC8hHUpEJvJN2cnDSvSbwmkVxaqXKVw3Q5bKW2 h24wVqxh0p1HXwVb0IqTeUISmuOngKOqA+uwMsuZ4DLv X-Google-Smtp-Source: APXvYqxBbEH3xS3l1kVGkINXae3Gktms8z8rHHxf5Ni7UQAJOskbVS+F7pqhkmBcaMYU5NNLEfSzzFH7UadtmZQDX90= X-Received: by 2002:a92:4e:: with SMTP id 75mr65758778ila.276.1577893018870; Wed, 01 Jan 2020 07:36:58 -0800 (PST) MIME-Version: 1.0 References: <157785269015.23329.2395522887141300513@ietfa.amsl.com> In-Reply-To: <157785269015.23329.2395522887141300513@ietfa.amsl.com> From: Donald Eastlake Date: Wed, 1 Jan 2020 10:36:47 -0500 Message-ID: To: "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 15:37:02 -0000 A new draft for a new year. Please take a look. It uses a different registry for L2 Flow-spec components, just like there are different registries for IPv4 and IPv6 components, so it can be implemented without any need for early allocations. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Tue, Dec 31, 2019 at 11:25 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing WG of the IETF. > > Title : BGP Dissemination of L2 Flow Specification Rules > Authors : Weiguo Hao > Donald E. Eastlake > James Uttaro > Stephane Litkowski > Shunwan Zhuang > Filename : draft-ietf-idr-flowspec-l2vpn-13.txt > Pages : 22 > Date : 2019-12-31 > > Abstract: > This document defines a Border Gateway Protocol (BGP) Flow-spec > extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual > Private Network (L2VPN) traffic filtering rules either by themselves > or in conjunction with L3 Flow-specs. AFI/SAFI 6/133 and 25/134 are > used for these purposes. New component types and an extended > community also are defined. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-l2vpn-13 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Jan 2 13:18:35 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E50120143; Thu, 2 Jan 2020 13:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 header.b=MRmwAFHu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HfgHPw+E 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 ddanxPHdF7OU; Thu, 2 Jan 2020 13:18:33 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDA512004D; Thu, 2 Jan 2020 13:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4434; q=dns/txt; s=iport; t=1577999912; x=1579209512; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RCIkOJE1ag6v3HuL28j8f+KS93SNOQyw+m/odAVm8zI=; b=MRmwAFHu6OPnSYNCgGGQ2JpB+O6HUXD3XXXA7x0Gy7COCqaaRmIK1iAh 06199eRAvqokoq3jOpHgdvKl9FsTookauq0x7J0EL9NyXoxJvSuorAOrp 15VNtpMDfp0Bhor4v/s5Ab2u3Lyy8d9WcUREwaQp7W+GNFHUwmwVn6vGg U=; IronPort-PHdr: =?us-ascii?q?9a23=3A5rguARIX0lKZsSwu79mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuMAkD2BPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+BQDnXQ5e/5pdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBVFAFbFggBAsqhAiDRgOLAYI6mC+CUgNUCQEBAQwBARgLCgI?= =?us-ascii?q?BAYRAAheBUiQ4EwIDDQEBBAEBAQIBBQRthTcMhV8CAQMBARAREQwBASwLAQ8?= =?us-ascii?q?CAQgaAiYCAgIlCxUQAgQBDQUbB4MAAYJGAy4BAgygTwKBOIhhdYEygn4BAQW?= =?us-ascii?q?BSUGCfBiCDAMGgQ4ojBkaggCBEScMFIJMPoJkAQEDAYFJgyYyggoikD2eWwq?= =?us-ascii?q?CNYczikSEIhuaV45SiFKSBAIEAgQFAg4BAQWBaSKBWHAVOyoBgkFQGA2NEoN?= =?us-ascii?q?zhRSFP3SBKItXAiYEA4IUAQE?= X-IronPort-AV: E=Sophos;i="5.69,388,1571702400"; d="scan'208";a="606664222" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Jan 2020 21:18:28 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 002LISCb018735 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Jan 2020 21:18:28 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 2 Jan 2020 15:18:28 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 2 Jan 2020 16:18:27 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 2 Jan 2020 16:18:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WQ8NuxhTiD74fWEi8KaHkgjeCMul1WUFrFMB77x+60ssd55WV35MDGdmAv6RiHqZk+/MuOG8+3GipuacqTBoeCE+vZ+CvfHhn1o8w5NQqUBu+yq9Zvl2rhCDyJ8Kh/8gVDlJAUZ2wctslGPuOY0bTIcEdNVJdZaMr7YN+18X7A7XsM8vNvG0bBddMmh7zYr0To56XknoAflWThfTYo/SJrQvd6D9l2UWlRL2gCxfG3oi/C5/PdTUGNEiYmmlV6kQRlB97T+30qlG0wjt69LA+zAC+r08pbd4sv2vOvFtx+WFS5O0O7DgPIjw78ulPc3HeME8wi3zBIG5fS2Q3VPWow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RCIkOJE1ag6v3HuL28j8f+KS93SNOQyw+m/odAVm8zI=; b=NhaPRsrZ8H20OBGXabG9yFSHWZaJ8iJlmzdTUK6h64u7QeTFg1J+wYyniCsUEXrCoAldm5tSQ9nhWFcCNYwxBpy3HpbYrqdkrD/x3AsFUPwuyyIBlO5HDSpWzFLpkBtbyLC+zyyjwinJLXycM22YpbMrqnEDMSanYWaUXe1bwx3Qe8hd/q7gvxNYlb+tvGf/oaU+Izui0eGW6ieGc5c0bIL8vsEQxIZvmGbvC2CHKU9M9cCkig3FZ1+FDDghDiPGWVxv32cnupbpfzCaHOiwilfWjiQCyQsgvOdx326DpL/XaDsdxIwqzUC0aqxwx1qPolRtNuxzuwwrx3AKqTxYmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RCIkOJE1ag6v3HuL28j8f+KS93SNOQyw+m/odAVm8zI=; b=HfgHPw+ExU+jLE2KME5q7h396g2aEwrPPxcP5U25udpxqzi5eXDtGrT5kCgDLFS01LMNIgNF2b7BxJtUofX3YmClZoQpKExa+RT4c5xsxLiY09zgsYGLBF4zYXnVouAS85koRi6Sl9Ww15dHDfjGz8yFbsfNAxxuEP1bdLVZq6s= Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB4349.namprd11.prod.outlook.com (10.255.90.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Thu, 2 Jan 2020 21:18:26 +0000 Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::f065:2931:17b6:7b5d]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::f065:2931:17b6:7b5d%3]) with mapi id 15.20.2581.014; Thu, 2 Jan 2020 21:18:26 +0000 From: "Acee Lindem (acee)" To: Andy Bierman , "yang-doctors@ietf.org" CC: "idr@ietf.org" , "draft-ietf-idr-bgp-model.all@ietf.org" Thread-Topic: [yang-doctors] Yangdoctors early review of draft-ietf-idr-bgp-model-07 Thread-Index: AQHVv0o85gO0fPk7v0iiC+7A5IPHoqfXkewA Date: Thu, 2 Jan 2020 21:18:26 +0000 Message-ID: <168831D6-8542-4762-9400-0D6D632619FC@cisco.com> References: <157773531468.4577.5049465733732578910@ietfa.amsl.com> In-Reply-To: <157773531468.4577.5049465733732578910@ietfa.amsl.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=acee@cisco.com; x-originating-ip: [2001:420:c0c8:1002::1d5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3c0b98ad-b067-41c3-5cc4-08d78fc94e72 x-ms-traffictypediagnostic: MN2PR11MB4349: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39860400002)(366004)(396003)(189003)(199004)(4326008)(6512007)(6486002)(33656002)(2906002)(71200400001)(2616005)(8936002)(6506007)(316002)(966005)(81156014)(66556008)(64756008)(66446008)(5660300002)(478600001)(86362001)(36756003)(91956017)(76116006)(66476007)(8676002)(66946007)(81166006)(110136005)(54906003)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4349; H:MN2PR11MB4221.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iqk4BQ8xi5vloFzkrXFwH8ONnMDX3PyFJbw1u4suNsUIuViKCl262Kty79o4ASgh7B4/zaPlXkwE84q9IsrnZ7YlzbG1kozSfujKkVLi+OlPhX3UCC0s+BfHnXEntZnVk1R67al5csI8vXScSniIopYx2vey79vbUgVSopSPQxG8EWnN6Ft7fA7KrfZC5PU76TdOE1Snf0N6EoDtZZHEhR2a3m6s+JGTZoSKxdt4QVEYTE37yASc2O+UE1jTP64MvXNO4yyws2n7cP9CrWhxfOTldcZNV+0KhSP+jR9O1MfP03o9qkwQsKoQMEWcKC3OoNUfzPl9YZJim7SMrG9F4T05yfAYY+MeuecnuOQFmEoAZHrlydCLQvC5/dBhAOFiC4fWMcneTN53p49WL2TY60TrXKvHdvXOsE412xQbmllIGdzhGp2Jqizewx/z1IIR9MdYkZO3qtIXTwltJ3YO36OpIc9bbcMTwfGPpV2/dok= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <10EB9D4CDEAF7344864514E26EB02A2F@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3c0b98ad-b067-41c3-5cc4-08d78fc94e72 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2020 21:18:26.1851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: M0Nh7onk2xNkQikJsfeNjyL+k9RYoJevr2e28rypYFKIHcQlie+9juaaQicClEvm X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4349 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Idr] [yang-doctors] Yangdoctors early review of draft-ietf-idr-bgp-model-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 21:18:35 -0000 SGkgQW5keSwgZXQgYWwsIA0KDQrvu79PbiAxMi8zMC8xOSwgMjo0OSBQTSwgInlhbmctZG9jdG9y cyBvbiBiZWhhbGYgb2YgQW5keSBCaWVybWFuIHZpYSBEYXRhdHJhY2tlciIgPHlhbmctZG9jdG9y cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBub3JlcGx5QGlldGYub3JnPiB3cm90ZToN Cg0KICAgIFJldmlld2VyOiBBbmR5IEJpZXJtYW4NCiAgICBSZXZpZXcgcmVzdWx0OiBPbiB0aGUg UmlnaHQgVHJhY2sNCiAgICANCiAgICANCiAgICBNYWpvciBpc3N1ZXM6DQogICAgDQogICAgICAt IFRoZSBpZXRmLWJncCBtb2R1bGUgdXNlcyAobGVnYWwpIFlBTkcgMS4xIGNvbnN0cnVjdHMgdGhh dCBhcmUNCiAgICAgICAgbm90IHN1cHBvcnRlZCBieSBhdmFpbGFibGUgdG9vbHMgc28gaXQgY2Fu bm90IGJlIHZhbGlkYXRlZC4NCiAgICAgICAgVGhlIHNvbHV0aW9uIG9wdGlvbnMgYXJlDQogICAg ICAgIChBKSByZXdyaXRlIHRoZSBtb2R1bGUgc28gaXQgZG9lcyBub3QgcGxhY2UgYW55IGRlZmlu aXRpb25zDQogICAgICAgICAgICBpbiB0aGUgbWFpbiBtb2R1bGUuICBJbnN0ZWFkIHBsYWNlIGFs bCBkZWZpbml0aW9ucyBpbg0KICAgICAgICAgICAgc3VibW9kdWxlcy4gQWRkIFlBTkcgMS4wIGlu Y2x1ZGUtc3RtdHMgYXMgbmVlZGVkIHNvIHB5YW5nDQogICAgICAgICAgICBjYW4gdmFsaWRhdGUg dGhlIG1vZHVsZQ0KICAgICAgICAoQikgd2FpdCB1bnRpbCB0aGUgb3BlbnNvdXJjZSB0b29scyBw cm9wZXJseSBzdXBwb3J0IHRoaXMNCiAgICAgICAgICAgIFlBTkcgMS4xIHVzYWdlIGFuZCByZXN1 Ym1pdCB0aGUgbW9kdWxlIGF0IHRoYXQgdGltZQ0KICAgIA0KICAgICAgLSBUaGUgbW9kdWxlcyBp bXBvcnQgaWV0Zi1yb3V0aW5nLXBvbGljeS4gVmVyc2lvbiB1c2VkIHdhcw0KICAgICAgICAyMDE5 LTAzLTA0LiAgVGhpcyBtb2R1bGUgaGFzIGEgZmF0YWwgZXJyb3IgY2F1c2VkIGJlY2F1c2UNCiAg ICAgICAgaWV0Zi1pbnRlcmZhY2UtY29tbW9uIGhhcyBhcHBhcmVudGx5IGJlZW4gcmVwbGFjZWQg d2l0aA0KICAgICAgICBpZXRmLWlmLWV4dGVuc2lvbnNAMjAxOS0xMS0wNA0KICAgIA0KICAgICAg ICAgIGxlYWYgc3ViaW50ZXJmYWNlIHsNCiAgICAgICAgICAgIHR5cGUgbGVhZnJlZiB7DQogICAg ICAgICAgICAgIHBhdGggIi9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZS9pZi1jbW46ZW5jYXBz dWxhdGlvbiINCiAgICAgICAgICAgICAgICAgKyAiL2lmLWwzLXZsYW46ZG90MXEtdmxhbiINCiAg ICAgICAgICAgICAgICAgKyAiL2lmLWwzLXZsYW46b3V0ZXItdGFnL2lmLWwzLXZsYW46dmxhbi1p ZCI7DQogICAgICAgICAgICB9DQogICAgDQogICAgICAgIFRoZSBwYXRoIGV4cHJlc3Npb24gaXMg d3JvbmcuIGlmLWNtbjplbmNhcHN1bGF0aW9uIGlzIG5vdw0KICAgICAgICBpZi1leHQ6ZW5jYXBz dWxhdGlvbi4gIFlvdSBuZWVkIHRvIGNoZWNrIHRoZSBYUGF0aCBldmVyeXdoZXJlDQogICAgICAg IHdoZW4geW91IHJlZmFjdG9yIFlBTkcgbW9kdWxlcy4NCg0KSSBoYXZlIGZpeGVkIHRoaXMgaW4g dGhlIC0wOCB2ZXJzaW9uLiANCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1ydGd3Zy1wb2xpY3ktbW9kZWwvDQoNCk5vdywgaWYgb25seSB3ZSBjb3VsZCBnZXQg dGhlIElFVEYgdG9vbHMgdG8gaW5jbHVkZSB0aGUgaWVlZTgwMi1kb3QxcS10eXBlcy55YW5nIG1v ZGVsIHNvIHRoYXQgaWV0Zi1pZi1sMy12bGFuLnlhbmcgcGFyc2VzLi4uLg0KDQpUaGFua3MsDQpB Y2VlIA0KICAgIA0KICAgICAgLSBGdWxsIHJldmlldyBvZiB0aGVzZSBtb2R1bGVzIGlzIG5vdCBw b3NzaWJsZSBhdCB0aGlzIHRpbWUgd2l0aG91dA0KICAgICAgICBwcm9wZXIgb3BlbnNvdXJjZSB0 b29scy4gUHJvY2Vzc2luZyB0aGUgWUFORyBzdGF0ZW1lbnRzDQogICAgICAgIGJ5IGhhbmQgaXMg ZXh0cmVtZWx5IGRpZmZpY3VsdCwgZ2l2ZW4gdGhlIGxhcmdlIGFtb3VudA0KICAgICAgICBvZiBn cm91cGluZ3MgdXNlZCB3aGljaCBhcmUgc3ByZWFkIGFjcm9zcyBtYW55IG1vZHVsZXMgYW5kDQog ICAgICAgIHN1Ym1vZHVsZXMuDQogICAgDQogICAgDQogICAgTWlub3IgSXNzdWVzDQogICAgDQog ICAgICAtIFRoZSAiY2xlYXIiIGFjdGlvbnMgbmVlZCB0byBiZSBzcGVjaWZpYyBhYm91dCB0aGUg ZXhhY3Qgc2V0DQogICAgICAgIG9mIG9iamVjdHMgdGhhdCBhcmUgYWZmZWN0ZWQuIFRoZSB2YWx1 ZSBvZiBlYWNoIG9iamVjdCBvbmNlIGl0DQogICAgICAgIGlzIGNsZWFyZWQgbmVlZHMgdG8gYmUg c3BlY2lmaWVkIGluIGV2ZXJ5IG9iamVjdCB0aGF0IGlzIGFmZmVjdGVkDQogICAgICAgIGJ5IHRo ZSBhY3Rpb24uICBJbXBhY3Qgb24gb3BlcmF0aW9ucyBzaG91bGQgYmUgZXhwbGFpbmVkIGluDQog ICAgICAgIGVhY2ggYWN0aW9uLXN0bXQNCiAgICANCiAgICAgIC0gU29tZSBUT0RPIGl0ZW1zIHN0 aWxsIHJlbWFpbiBpbmRpY2F0aW5nIHRoZSBZQU5HIGRlZmluaXRpb25zDQogICAgICAgIGFyZSB0 ZW1wb3JhcnkgYW5kIHdpbGwgYmUgcmVwbGFjZWQgYnkgbW9yZSBjb3JyZWN0IHN0YXRlbWVudHMu DQogICAgDQogICAgICAtIEFkZGl0aW9uYWwgcmVmZXJlbmNlLXN0bXRzIHdvdWxkIGJlIHVzZWZ1 bCB0byBpbXBsZW1lbnRvcnMNCiAgICAgICAgd2hvIGFyZSBmYW1pbGFyIHdpdGggdGhlIHJvdXRp bmcgUkZDcyB0aGF0IHRoZSBZQU5HIG9iamVjdHMNCiAgICAgICAgYXJlIGJhc2VkIG9uDQogICAg DQogICAgRWRpdG9yaWFsIENvbW1lbnRzDQogICAgDQogICAgICAtIFRoZSBpbXBsZW1lbnRhdGlv biBjb21wbGV4aXR5IGFwcGVhcnMgdG8gYmUgdmVyeSBoaWdoDQogICAgICAgIGZvciBib3RoIHNl cnZlciBhbmQgY2xpZW50IGRldmVsb3BlcnMuICBUaGUgaW50ZXJhY3Rpb25zIGJldHdlZW4NCiAg ICAgICAgc3VidHJlZXMgaXMgbm9uLXRyaXZpYWwgYW5kIHByb2JhYmx5IHJlcXVpcmVzIG1vcmUg Y2xhcmlmaWNhdGlvbnMuDQogICAgICAgIFRoaXMgbmVlZHMgdG8gYmUgZG9uZSBieSBpbXBsZW1l bnRvcnMsIG5vdCBkb2N1bWVudCByZXZpZXdlcnMuDQogICAgDQogICAgDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICB5YW5nLWRvY3RvcnMg bWFpbGluZyBsaXN0DQogICAgeWFuZy1kb2N0b3JzQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby95YW5nLWRvY3RvcnMNCiAgICANCg0K From nobody Thu Jan 2 13:28:23 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E0F120164 for ; Thu, 2 Jan 2020 13:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-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 XfHWuaf6-tld for ; Thu, 2 Jan 2020 13:28:15 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 49A7B12004D for ; Thu, 2 Jan 2020 13:28:15 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id b15so30732539lfc.4 for ; Thu, 02 Jan 2020 13:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CbMxM3zr+jg9dlsaqJdw4+Zc9avO6OsckYoIXHUhbLA=; b=1XvMGa9GYGvSUjbCzWxJco1UqD5q2XKKERTKZG738OSMFmyemG6d5FCI+qZJV/AY7+ A2NF66WYrLkjJ1bz+oX5NHdTtqqr3SQXR2M2V0caYh35sXu047ahUTjkr2aL6ibtywIt a33ZvsgUYaMEx4TWcyYVEIEPdw6LA8BqOl9IaF1gW4+8im60cSbtWHo1LIjMR3cRDGib iWZ4p0uJNGiUWyfbLnrWupDOaEqq0RAjxs0vdovdkLhRv1OTpcsM7kgdNbYEwWA2baox 6oJZ2NWOhM2Bv0lA8JxaYT6oab/t8Acr4UvZKz02AYwP/s/PCO6TL+S5eGprtPoece5o 6v3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CbMxM3zr+jg9dlsaqJdw4+Zc9avO6OsckYoIXHUhbLA=; b=bS09w1Q/l5T6rEnaGxsnRP+9kMcOMilMfHWui+g7DI3q59kD8VpHCzQmc3G6R0xcZI 0eb9wlaA4rpnU9JVK8sJOCrpmrFS3lPxhkl5ET+JKfXz1xN0F2WlApbKLLZwbemQxBJG Ij0T5P+TtpDTbqY6qoYOWDNVZ1pzFF0aucqszsu0rFku+N1+4JpNaOWhiTzSwqP8H9TD UcHunXuIa05jKi/F0smKwwxcIHU6jQJzrEXdUYfTt+zYr81UgRDCUOIi/88O153Wgxaf Lv6K8ZkQXTAn85Dy093XntEFbeccUyWF1eer95VygyId/mIBqHmgPsKDVcFN62Hu1fvQ s/3g== X-Gm-Message-State: APjAAAWoQxD/PXiYlyuiqkerXlk4KilGK8U6VYXu3RoDIXildkE90eFu dsGFwedtbVZP8bxzfsUa52e9veOB36R4qK3TB4nVFA== X-Google-Smtp-Source: APXvYqy2H/M3fZd3LwGlzNNHQwOpPIs6DT+to0W/UlNRfMYoOaKGSYEGA6oxqm+Z37vLxO2ncGSKzO0IpVS7dy475A8= X-Received: by 2002:ac2:430d:: with SMTP id l13mr50932029lfh.112.1578000493304; Thu, 02 Jan 2020 13:28:13 -0800 (PST) MIME-Version: 1.0 References: <157773531468.4577.5049465733732578910@ietfa.amsl.com> <168831D6-8542-4762-9400-0D6D632619FC@cisco.com> In-Reply-To: <168831D6-8542-4762-9400-0D6D632619FC@cisco.com> From: Andy Bierman Date: Thu, 2 Jan 2020 13:28:02 -0800 Message-ID: To: "Acee Lindem (acee)" Cc: "yang-doctors@ietf.org" , "idr@ietf.org" , "draft-ietf-idr-bgp-model.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dbf54e059b2ede4d" Archived-At: Subject: Re: [Idr] [yang-doctors] Yangdoctors early review of draft-ietf-idr-bgp-model-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 21:28:18 -0000 --000000000000dbf54e059b2ede4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2020 at 1:18 PM Acee Lindem (acee) wrote: > Hi Andy, et al, > > =EF=BB=BFOn 12/30/19, 2:49 PM, "yang-doctors on behalf of Andy Bierman vi= a > Datatracker" > wrote: > > Reviewer: Andy Bierman > Review result: On the Right Track > > > Major issues: > > - The ietf-bgp module uses (legal) YANG 1.1 constructs that are > not supported by available tools so it cannot be validated. > The solution options are > (A) rewrite the module so it does not place any definitions > in the main module. Instead place all definitions in > submodules. Add YANG 1.0 include-stmts as needed so pyang > can validate the module > (B) wait until the opensource tools properly support this > YANG 1.1 usage and resubmit the module at that time > > - The modules import ietf-routing-policy. Version used was > 2019-03-04. This module has a fatal error caused because > ietf-interface-common has apparently been replaced with > ietf-if-extensions@2019-11-04 > > leaf subinterface { > type leafref { > path "/if:interfaces/if:interface/if-cmn:encapsulation" > + "/if-l3-vlan:dot1q-vlan" > + "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id"; > } > > The path expression is wrong. if-cmn:encapsulation is now > if-ext:encapsulation. You need to check the XPath everywhere > when you refactor YANG modules. > > I have fixed this in the -08 version. > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model/ > > Now, if only we could get the IETF tools to include the > ieee802-dot1q-types.yang model so that ietf-if-l3-vlan.yang parses.... > > I noticed that IEEE modules are being imported into some IETF models now. I did not raise it in the ietf-bgp review but it does raise a process or tools issue. Is it possible to standardize tools based on the github YangModels repo, using standard module search path. e.g -p repo/experimental/ietf-extracted-YANG-models -p repo/standard Thanks, > Acee > Andy > > - Full review of these modules is not possible at this time without > proper opensource tools. Processing the YANG statements > by hand is extremely difficult, given the large amount > of groupings used which are spread across many modules and > submodules. > > > Minor Issues > > - The "clear" actions need to be specific about the exact set > of objects that are affected. The value of each object once it > is cleared needs to be specified in every object that is affected > by the action. Impact on operations should be explained in > each action-stmt > > - Some TODO items still remain indicating the YANG definitions > are temporary and will be replaced by more correct statements. > > - Additional reference-stmts would be useful to implementors > who are familar with the routing RFCs that the YANG objects > are based on > > Editorial Comments > > - The implementation complexity appears to be very high > for both server and client developers. The interactions between > subtrees is non-trivial and probably requires more clarifications= . > This needs to be done by implementors, not document reviewers. > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > > --000000000000dbf54e059b2ede4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 1:18 PM Acee L= indem (acee) <acee@cisco.com> w= rote:
Hi Andy, e= t al,

=EF=BB=BFOn 12/30/19, 2:49 PM, "yang-doctors on behalf of Andy Bierman= via Datatracker" <yang-doctors-bounces@ietf.org on behalf of noreply@ietf.org> wro= te:

=C2=A0 =C2=A0 Reviewer: Andy Bierman
=C2=A0 =C2=A0 Review result: On the Right Track


=C2=A0 =C2=A0 Major issues:

=C2=A0 =C2=A0 =C2=A0 - The ietf-bgp module uses (legal) YANG 1.1 constructs= that are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 not supported by available tools so it cannot b= e validated.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The solution options are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (A) rewrite the module so it does not place any= definitions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the main module.=C2=A0 Instead= place all definitions in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 submodules. Add YANG 1.0 include-= stmts as needed so pyang
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 can validate the module
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (B) wait until the opensource tools properly su= pport this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG 1.1 usage and resubmit the m= odule at that time

=C2=A0 =C2=A0 =C2=A0 - The modules import ietf-routing-policy. Version used= was
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2019-03-04.=C2=A0 This module has a fatal error= caused because
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf-interface-common has apparently been repla= ced with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf-if-extensions@2019-11-04

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf subinterface {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path "/if:interfaces/= if:interface/if-cmn:encapsulation"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ "/if-l= 3-vlan:dot1q-vlan"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ "/if-l= 3-vlan:outer-tag/if-l3-vlan:vlan-id";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The path expression is wrong. if-cmn:encapsulat= ion is now
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if-ext:encapsulation.=C2=A0 You need to check t= he XPath everywhere
=C2=A0 =C2=A0 =C2=A0 =C2=A0 when you refactor YANG modules.

I have fixed this in the -08 version.

https://datatracker.ietf.org/doc/draf= t-ietf-rtgwg-policy-model/

Now, if only we could get the IETF tools to include the ieee802-dot1q-types= .yang model so that ietf-if-l3-vlan.yang parses....


I noticed that IEEE modules are being = imported into some IETF models now.
I did not raise it in the iet= f-bgp review but it does raise a process or tools issue.

Is it possible to standardize tools based on the github YangModels r= epo,
using standard module search path. e.g

<= div>=C2=A0-p repo/experimental/ietf-extracted-YANG-models
=C2=A0-= p repo/standard


Thanks,
Acee

Andy
=C2=A0

=C2=A0 =C2=A0 =C2=A0 - Full review of these modules is not possible at this= time without
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proper opensource tools. Processing the YANG st= atements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by hand is extremely difficult, given the large= amount
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of groupings used which are spread across many = modules and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 submodules.


=C2=A0 =C2=A0 Minor Issues

=C2=A0 =C2=A0 =C2=A0 - The "clear" actions need to be specific ab= out the exact set
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of objects that are affected. The value of each= object once it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is cleared needs to be specified in every objec= t that is affected
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by the action.=C2=A0 Impact on operations shoul= d be explained in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 each action-stmt

=C2=A0 =C2=A0 =C2=A0 - Some TODO items still remain indicating the YANG def= initions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are temporary and will be replaced by more corr= ect statements.

=C2=A0 =C2=A0 =C2=A0 - Additional reference-stmts would be useful to implem= entors
=C2=A0 =C2=A0 =C2=A0 =C2=A0 who are familar with the routing RFCs that the = YANG objects
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are based on

=C2=A0 =C2=A0 Editorial Comments

=C2=A0 =C2=A0 =C2=A0 - The implementation complexity appears to be very hig= h
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for both server and client developers.=C2=A0 Th= e interactions between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 subtrees is non-trivial and probably requires m= ore clarifications.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This needs to be done by implementors, not docu= ment reviewers.


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 yang-doctors mailing list
=C2=A0 =C2=A0 ya= ng-doctors@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/yang-doctors


--000000000000dbf54e059b2ede4d-- From nobody Mon Jan 6 04:57:29 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C14120819; Mon, 6 Jan 2020 04:57:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <157831544795.8124.6834992450729105288@ietfa.amsl.com> Date: Mon, 06 Jan 2020 04:57:28 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-flex-algo-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 12:57:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Flexible Algorithm Definition Advertisement with BGP Link-State Authors : Ketan Talaulikar Peter Psenak Shawn Zandi Gaurav Dawra Filename : draft-ietf-idr-bgp-ls-flex-algo-02.txt Pages : 13 Date : 2020-01-06 Abstract: Flexible Algorithm is a solution that allows routing protocols (viz. OSPF and IS-IS) to compute paths over a network based on user-defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distribute manner using a Flex Algorithm definition. This definition provisioned on one or more routers and propagated (viz. OSPF and IS- IS flooding) through the network. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. This draft defines extensions to BGP- LS address-family to advertise the Flexible Algorithm Definition as a part of the topology information from the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-flex-algo-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-flex-algo-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-flex-algo-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 6 18:46:07 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07AC120137 for ; Mon, 6 Jan 2020 18:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 N6_Yjwlx8pgR for ; Mon, 6 Jan 2020 18:46:03 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C774D120123 for ; Mon, 6 Jan 2020 18:46:02 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9FA0045A15802B8EA0B3; Tue, 7 Jan 2020 02:45:59 +0000 (GMT) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 7 Jan 2020 02:45:57 +0000 Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 7 Jan 2020 10:45:54 +0800 Received: from nkgeml706-chm.china.huawei.com ([10.98.57.153]) by nkgeml706-chm.china.huawei.com ([10.98.57.153]) with mapi id 15.01.1713.004; Tue, 7 Jan 2020 10:45:54 +0800 From: Haoweiguo To: Donald Eastlake , "idr@ietf. org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-13.txt Thread-Index: AQHVwFuIvVlettsVQUeFGVZQZ+xKAKfVa7qAgAkcQ5A= Date: Tue, 7 Jan 2020 02:45:54 +0000 Message-ID: <3873f610b10346739007c78c5a3c345b@huawei.com> References: <157785269015.23329.2395522887141300513@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.30.193] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRy?= =?gb2312?b?LWZsb3dzcGVjLWwydnBuLTEzLnR4dA==?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 02:46:06 -0000 SGkgRG9uYWxkLA0KVGhhbmtzIGZvciB5b3VyIGdyZWF0IHdvcmsuIEkgdGhpbmsgdGhpcyBkcmFm dCBpcyBpbiBnb29kIHNoYXBlIG5vdywgZG8geW91IHRoaW5rIGl0J3MgcmVhZHkgdG8gYXNrIHRo ZSBXRyBsYXN0IGNhbGwgZm9yIGl0Pw0KDQpUaGFua3MsDQpXZWlndW8NCg0KLS0tLS3Tyrz+1K28 /i0tLS0tDQq3orz+yMs6IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSC0+rHtIERv bmFsZCBFYXN0bGFrZQ0Kt6LLzcqxvOQ6IDAxIHVNYXNpbmdhbmEgMjAyMCAxMTozNyBQTQ0KytW8 /sjLOiBpZHJAaWV0Zi4gb3JnIDxpZHJAaWV0Zi5vcmc+DQrW98ziOiBSZTogW0lkcl0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtbDJ2cG4tMTMudHh0DQoNCkEgbmV3IGRyYWZ0 IGZvciBhIG5ldyB5ZWFyLiBQbGVhc2UgdGFrZSBhIGxvb2suIEl0IHVzZXMgYSBkaWZmZXJlbnQg cmVnaXN0cnkgZm9yIEwyIEZsb3ctc3BlYyBjb21wb25lbnRzLCBqdXN0IGxpa2UgdGhlcmUgYXJl IGRpZmZlcmVudCByZWdpc3RyaWVzIGZvciBJUHY0IGFuZCBJUHY2IGNvbXBvbmVudHMsIHNvIGl0 IGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRob3V0IGFueSBuZWVkIGZvciBlYXJseSBhbGxvY2F0aW9u cy4NCg0KVGhhbmtzLA0KRG9uYWxkDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQog RG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAgICsxLTUwOC0zMzMtMjI3MCAoY2VsbCkNCiAyMzg2IFBh bm9yYW1pYyBDaXJjbGUsIEFwb3BrYSwgRkwgMzI3MDMgVVNBICBkM2UzZTNAZ21haWwuY29tDQoN Ck9uIFR1ZSwgRGVjIDMxLCAyMDE5IGF0IDExOjI1IFBNIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc+IHdyb3RlOg0KPg0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVyLURvbWFpbiBSb3V0aW5nIFdHIG9mIHRoZSBJRVRG Lg0KPg0KPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEJHUCBEaXNzZW1pbmF0aW9uIG9mIEwy IEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcw0KPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFdl aWd1byBIYW8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBEb25hbGQgRS4gRWFzdGxha2UN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICBKYW1lcyBVdHRhcm8NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICBTdGVwaGFuZSBMaXRrb3dza2kNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICBTaHVud2FuIFpodWFuZw0KPiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtaWRyLWZsb3dzcGVjLWwydnBuLTEzLnR4dA0KPiAgICAgICAgIFBhZ2VzICAgICAgICAgICA6 IDIyDQo+ICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxOS0xMi0zMQ0KPg0KPiBBYnN0cmFj dDoNCj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wg KEJHUCkgRmxvdy1zcGVjDQo+ICAgIGV4dGVuc2lvbiB0byBkaXNzZW1pbmF0ZSBFdGhlcm5ldCBM YXllciAyIChMMikgYW5kIExheWVyIDIgVmlydHVhbA0KPiAgICBQcml2YXRlIE5ldHdvcmsgKEwy VlBOKSB0cmFmZmljIGZpbHRlcmluZyBydWxlcyBlaXRoZXIgYnkgdGhlbXNlbHZlcw0KPiAgICBv ciBpbiBjb25qdW5jdGlvbiB3aXRoIEwzIEZsb3ctc3BlY3MuICBBRkkvU0FGSSA2LzEzMyBhbmQg MjUvMTM0IGFyZQ0KPiAgICB1c2VkIGZvciB0aGVzZSBwdXJwb3Nlcy4gIE5ldyBjb21wb25lbnQg dHlwZXMgYW5kIGFuIGV4dGVuZGVkDQo+ICAgIGNvbW11bml0eSBhbHNvIGFyZSBkZWZpbmVkLg0K Pg0KPg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHIt Zmxvd3NwZWMtbDJ2cG4vDQo+DQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2 YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRy LWZsb3dzcGVjLWwydnBuLTEzDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtbDJ2cG4tMTMNCj4NCj4gQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtbDJ2cG4tMTMNCj4NCj4NCj4g UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj4gSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0K SWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Tue Jan 7 00:22:45 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E671200D5 for ; Tue, 7 Jan 2020 00:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QjiEvU1o; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pJKeHqr1 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 VUUK6inULFqD for ; Tue, 7 Jan 2020 00:22:40 -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 7A01F1200E3 for ; Tue, 7 Jan 2020 00:22:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2530; q=dns/txt; s=iport; t=1578385360; x=1579594960; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ivtRNvwyFsiAkM2j9QdSzq3pzMcYXj+4rk1fBw2hl3s=; b=QjiEvU1oqOgOSmCJb9Zt1PCnaSfAmHrvdkcSJjm2rEHQVrCWvd/OtRzT 6Z5oYy7BGVt8GJrJZojXVy/rYVNafXY3wFeX/0NctZqDinh5fZve2uui5 XwJ7IH7K3v2oCW3uk2uPsHJkgza0/Q9nWSFKY1QGBOxHG6J3ov3QyxkqS 0=; IronPort-PHdr: =?us-ascii?q?9a23=3APPnvyhDpRd1vzjedN6iYUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuL/P2ZiomNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKDgBnPxRe/5tdJa1mHgELHIFxC4F?= =?us-ascii?q?UUAVsWCAECyqHTwOLA06CEZgNglIDVAkBAQEMAQEYDQgCAQGEQAKBaSQ3Bg4?= =?us-ascii?q?CAw0BAQQBAQECAQUEbYU3AQuFXgEBAQEDAQEQKAYBASwMCwQCAQgRBAEBHxA?= =?us-ascii?q?nCx0IAgQTCBMHgwGCRgMuAQ6hZAKBOIhhgieCfgEBBYE5Ag5BgnwYggwJgTa?= =?us-ascii?q?MGRqBQT+BEAFHgkw+gmQBAQIBARiBSSSDHIIsryIKgjaHNY8BgkZ2hweQG45?= =?us-ascii?q?TgUeHDI4cg28CBAIEBQIOAQEFgWgjgVhwFRohgmwJRxgNjRKDc4UUhT90gSi?= =?us-ascii?q?NVwEB?= X-IronPort-AV: E=Sophos;i="5.69,405,1571702400"; d="scan'208";a="700568742" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jan 2020 08:22:39 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0078McSX009851 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Jan 2020 08:22:39 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 02:22:38 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 02:22:37 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 7 Jan 2020 02:22:37 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=muA3rhYmGTmjLQ+5nnZloFDdMS0gCL007po5//Vtxjt8Oa6ehKlIJWuRReAd2T4llCfLS33TIvors0W7nthEDcGtx/ku3YEKKGNUAM1n37j7vkDckki6nu9Oi63H+KdHs/4XSLiyqFdzP3HxPedPdglOUKa8ZWECiNwrjjXzCj/mY/mPHJOnM03i1scMScAP2V+aROXyKthubYczsgrWWJKkzGI5csc2IU98O7/6VC1Qc9XWj0ZkxpfIGQgtyRsCwAQTZNMYpMsTQ98EJwAhgBuj9ymAr6K/IIoYywAdlsbFnOzWCaynDCgIwtpJbFdUZYuLwYRUSHhuffhMi8XBNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hCfNL0zk0wRYRAODbsp9HAfJUFPgNGeRcFgBnb6skds=; b=ep2vFlluSJz6xaar+X5w0Z6BMFp+QeWOxcifHjYlTHrUKYSDtg9JA7Me1pB6LTqIzy0Hqk1GFq/GGJ3lRghxsllRfHhVgKTwxEN+AFMO12/eoS8GGRRHWT8Ye+olhpCDAbzBw6V8fNyBHGUjsXmD9heBQEYdmgOd1J2XTiLo78p1yTY/fIcvHW6575wOGKeJvHZLYtJgwuK2x3hyAwgpVwBWqZAV+bJRz/qD6ejJynG1XZi+D1aY8CeaUExMEHqfJGaKfXKsyfpSDnADDEPFDM6KIeYJOtW7ayDQpM8oSGThwQfe/UDEFJglkxSGfhu109KFkfMTTppMviPtOcd8EQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hCfNL0zk0wRYRAODbsp9HAfJUFPgNGeRcFgBnb6skds=; b=pJKeHqr1hxmn9+ehA+5JEYufoFEiYil6mPzxDlEqsTu0yrEZ/OHKwDiMpPSNS63lHEw9B0gzWbF8H0fVI7r4fc0cATpS50q2y9IkvNaD8VOGE9n8BkRicaK1s3yqajAI3X2670HJhc2Heag2e0gaZCLyzssBYtMFxWngp6cTKwg= Received: from MWHPR11MB1600.namprd11.prod.outlook.com (10.172.53.142) by MWHPR11MB1328.namprd11.prod.outlook.com (10.169.237.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Tue, 7 Jan 2020 08:22:36 +0000 Received: from MWHPR11MB1600.namprd11.prod.outlook.com ([fe80::884c:b80e:f787:2098]) by MWHPR11MB1600.namprd11.prod.outlook.com ([fe80::884c:b80e:f787:2098%12]) with mapi id 15.20.2602.015; Tue, 7 Jan 2020 08:22:36 +0000 From: "Ketan Talaulikar (ketant)" To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-ls-flex-algo-02.txt Thread-Index: AQHVxJFcBJD5+PJ+4UGamQ0MqxK/NKfe3ctw Date: Tue, 7 Jan 2020 08:22:36 +0000 Message-ID: References: <157831544795.8124.6834992450729105288@ietfa.amsl.com> In-Reply-To: <157831544795.8124.6834992450729105288@ietfa.amsl.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=ketant@cisco.com; x-originating-ip: [2405:201:1800:c466:d08a:ac10:587d:3173] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8874ec7d-24c2-4bac-62ad-08d7934ac0ba x-ms-traffictypediagnostic: MWHPR11MB1328: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(136003)(376002)(396003)(39860400002)(13464003)(189003)(53754006)(199004)(316002)(7696005)(966005)(186003)(53546011)(6506007)(64756008)(76116006)(66476007)(66574012)(66446008)(33656002)(66556008)(71200400001)(6916009)(52536014)(66946007)(5660300002)(86362001)(2906002)(8676002)(81156014)(81166006)(8936002)(478600001)(55016002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1328; H:MWHPR11MB1600.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OBXSg//z9u4ID+2stuCFAoiL9vSNOwxItFFeVLjgeUUo5UZq9MPg+/4yq3BSP16CqitXmvA2M1Wziu2LXjk8YiPShMbBtJ6BFj6EWDnoRb4NVKmpwynNjLFWmBQRv+O9zyz//UkhYK7gCeuSAV5G2RtOSGVr9yoDFhuLMgDTeifdyX205dE4Vyz59rd/KFDrFX4C5Zo4MBR4i7Ox/LBhXzEqyXD3rAvdb7b/feaE1LQ4houowDcVctARHz260FTR786HKEWFz+7DU09SddE6+C4HkQfBrdpHdkORfoEQ10WMX0FjMf0zL/4J5CyfsEseJYKOIvE6z21vn5hoZVUKqgF61TNdeZzdP/jn3tHpXysx8nVzYgeBOcklE4qWlkm3vEBnAWzryj9s72ckkRCnoXcNPN8aJYBBWtQye/8Kt7b+FSugpJMsCUxIM3BOzaymlYiGJkOsHhQae50raBPaPehmothmXIwP9fkE0wCyIFzWr7c07+RsKuVqvU2tpRW8GxT5R6X6fkXT19gPmLWF6cRJpBa7o+JEswMAOlnoITFyrcdF5LMtZyOJ0DjxoVHQ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8874ec7d-24c2-4bac-62ad-08d7934ac0ba X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 08:22:36.5308 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0fbbTp7yVGgcBuvDWkgN86okdO62cSL83BjVhvRS6wzrRDMDdxdqdidFpmPUEl4dd7/lVqOGn9e1riliKNZaWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1328 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-ls-flex-algo-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 08:22:44 -0000 Hi All, This is just a refresh of the draft and includes the update for the IANA ea= rly allocations done since the previous version. Thanks, Ketan (on behalf of co-authors) -----Original Message----- From: Idr On Behalf Of internet-drafts@ietf.org Sent: 06 January 2020 18:27 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-flex-algo-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Flexible Algorithm Definition Advertisement with = BGP Link-State Authors : Ketan Talaulikar Peter Psenak Shawn Zandi Gaurav Dawra Filename : draft-ietf-idr-bgp-ls-flex-algo-02.txt Pages : 13 Date : 2020-01-06 Abstract: Flexible Algorithm is a solution that allows routing protocols (viz. OSPF and IS-IS) to compute paths over a network based on user-defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distribute manner using a Flex Algorithm definition. This definition provisioned on one or more routers and propagated (viz. OSPF and IS- IS flooding) through the network. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. This draft defines extensions to BGP- LS address-family to advertise the Flexible Algorithm Definition as a part of the topology information from the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-flex-algo-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-flex-algo-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-ls-flex-algo-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jan 7 03:13:53 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11802120026; Tue, 7 Jan 2020 03:13:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <157839562696.20884.1445434174505866717@ietfa.amsl.com> Date: Tue, 07 Jan 2020 03:13:47 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-ext-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 11:13:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP Link State Extensions for SRv6 Authors : Gaurav Dawra Clarence Filsfils Ketan Talaulikar Mach Chen Daniel Bernier Bruno Decraene Filename : draft-ietf-idr-bgpls-srv6-ext-02.txt Pages : 24 Date : 2020-01-07 Abstract: Segment Routing IPv6 (SRv6) allows for a flexible definition of end- to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by the various protocols such as BGP, ISIS and OSPFv3. BGP Link-state (BGP-LS) address-family solution for SRv6 is similar to BGP-LS for SR for MPLS dataplane. This draft defines extensions to the BGP-LS to advertise SRv6 Segments along with their behaviors and other attributes via BGP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-srv6-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-srv6-ext-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-srv6-ext-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 7 03:18:28 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD67120047 for ; Tue, 7 Jan 2020 03:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OxknVixI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hXCLKGK5 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 fplfInpPaG58 for ; Tue, 7 Jan 2020 03:18:22 -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 08863120026 for ; Tue, 7 Jan 2020 03:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2493; q=dns/txt; s=iport; t=1578395902; x=1579605502; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mTglSmgdHtfeEBaeph8R6SuyhRBsJV9DLE+NFHdXnKI=; b=OxknVixI19wuPMSvueDrFolz1juoAfVdinYWSzsVroYPGLt6bAikkjRh 97o8zmitZp6gTCB2cYkUAip+VafviB6WbwJ6bduUY+/OcO7tI0jqmnlB6 /cCyn1OmFIR3BuUUWuUty6N42F23XgewC5FoPBj1BSYcTDdYvmFKNAzhg Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AP6PC4RH0cZtAzGWP2gXto51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+ef3ncyU8AOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTFgAnaBRe/4cNJK1mHgFDDIFUgVQ?= =?us-ascii?q?kLAVsWCAECyqHTwOLAk6CEZgNgS6BJANUCQEBAQwBARgLCgIBAYRAAoFpJDY?= =?us-ascii?q?HDgIDDQEBBAEBAQIBBQRthTcBC4VeAQEBAQMBARAoBgEBLAwLBAIBCBEEAQE?= =?us-ascii?q?fECcLHQgCBBMIEweDAYJGAy4BDqEtAoE4iGGCJ4J+AQEFgTkCDkGCeRiCDAm?= =?us-ascii?q?BNowZGoFBP4ERR4JMPoJkAQECAQEYgUmDQIIsryMKgjaHNY8Cgkd2hweQG45?= =?us-ascii?q?TiFSOHoNvAgQCBAUCDgEBBYFZAjCBWHAVGiGCbAlHGA2RBYUUhT90gSiNRAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.69,406,1571702400"; d="scan'208";a="418932466" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jan 2020 11:18:21 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 007BILI5009806 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Jan 2020 11:18:21 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 05:18:20 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 05:18:20 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 7 Jan 2020 05:18:20 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W1BVZLBI1cKsBpekOuYTdoekYvnMUybo3TjUkLRb9Hb0dFK+EIgUEh/sX7m743yRjyX1vKHS0/r+4tIJBAzv+kuQ0YcvTtuEC19nLMjcGswzVw8pU+sFGT0hEZgMMI6a7UqK1FVrYtxMB95UWesMHpOqvlDLBphfsQ5tVf6NLZ649SRUY+ywdKvbS8hgBXqiyuEzpKWAvV0BVp6SXh0FAT4ATftH/KJ+eCUQ5veEKUDAaWDCPSszu87BEfb/GKaSR7WJwjZfV6hRvvfn8UAcR81ikx0tC8X5mNDXat5AVA3oEUraGqyk1H+Raov2F1Nq+cBJJr8g+NO4/P38sNAg7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xOewFE8p7v94cmyp1Hjuj0qVN8t7zI1mM+RYw6pnSNA=; b=jKNMxKmBuNbr8dVSzLZS1aobg4c8vp9uOvR9X2gesPMDQIjbmQUs2K/R/0B+gIkoDGRkG3aEJQmzEvfmagcq51owBuz1FxBgh6xh5FZ8zXfb+4RN1U5gYr0JFZBmkF5DWCe5pk47Sj5OvuNlW3XMcQXEMn8t0qp8XIjxHJCIB7ll/uyY975ERIHE+VCFCQb8G+qdd9VRL2TChbI6GP7yiszmM24QxbA16EQ4Vz1LD+vhJ9HY9VK+my35GSl2/D8ksmX58xRY/pc0r3P2woMdd1/DazbyUfWruITl/tOf8smyCdDHUYuVjZIP3gZa12n7+t7//nYU1rc3a9dhODTCug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xOewFE8p7v94cmyp1Hjuj0qVN8t7zI1mM+RYw6pnSNA=; b=hXCLKGK5ZWouuzQ6/zil0rp6cgqV40nErbcTrXTCxuosJZ0EbHh1pujcsGOfiLfYIJ3OSN94CZSyBnCPp6guxqqATmdD/9287KPBLtH65R+He4/EU8Gn8Sicm6+7sUYz+PCOtNmvrAX1zm73sWuoXpE9+kWjaLZM5QKLko9ujVY= Received: from MWHPR11MB1600.namprd11.prod.outlook.com (10.172.53.142) by MWHPR11MB1408.namprd11.prod.outlook.com (10.169.234.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Tue, 7 Jan 2020 11:18:19 +0000 Received: from MWHPR11MB1600.namprd11.prod.outlook.com ([fe80::884c:b80e:f787:2098]) by MWHPR11MB1600.namprd11.prod.outlook.com ([fe80::884c:b80e:f787:2098%12]) with mapi id 15.20.2602.015; Tue, 7 Jan 2020 11:18:19 +0000 From: "Ketan Talaulikar (ketant)" To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-ext-02.txt Thread-Index: AQHVxUuxJuYQRCENTECmEZ00sq2cOaffDN9g Date: Tue, 7 Jan 2020 11:18:19 +0000 Message-ID: References: <157839562696.20884.1445434174505866717@ietfa.amsl.com> In-Reply-To: <157839562696.20884.1445434174505866717@ietfa.amsl.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=ketant@cisco.com; x-originating-ip: [2405:201:1800:c466:d08a:ac10:587d:3173] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aae3ac1d-c367-4e76-12bd-08d793634c8f x-ms-traffictypediagnostic: MWHPR11MB1408: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(376002)(346002)(396003)(199004)(189003)(13464003)(53754006)(52536014)(66574012)(5660300002)(478600001)(966005)(2906002)(9686003)(55016002)(316002)(186003)(8936002)(8676002)(81166006)(81156014)(6916009)(33656002)(66946007)(71200400001)(6506007)(53546011)(66446008)(64756008)(86362001)(66476007)(76116006)(66556008)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1408; H:MWHPR11MB1600.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5m/RrkmAdXSUnBMHUBw301QXnGBKUVz3/Bl2QqkvcXW6wR5rUTYFuADOL6kxORpJXlvWmbYxuMGCES4PCmNrWJy/WOT4QCtwfObpYa/BQYWmBYiQvHqu2vzMerR6zZ0Ik5kwM/62i9ZpBB75NBOIpJtG+kDQEukqKcgy3R7W3mYeKgGs2hkiqXTUh+kUP6OrXNrAmNkVpFCV2a4a2MWDyrpiUMRczywtwNHHGZvsYFWWnb1qENPdoMoexj45lOgJubJDj2oQ9Bx40ENBBiq5OV8go0KKP4VAt4ZvIrZJKEpGo7QTfZ+T+f4hb14ge+RRtQjpqpJSpMCYr9n4TFcN9pGmDIsaU5oPL1RZ1F2odwRtfDl1KKz0IFGEfU7XbnaZmTvIqQz+D8RfZ06DwQMwfHFfu9t3HfmO9Klpo9PL5BdBmYzUgEKEveuOubhag0LHIKYPBqiz+ZC3az1Z5KJ0gNf4OKA+HoXPxpnVByfy/MOb1dbk7ID5a6jso7Q5N52zKutlTQfkl1bVMQI6Z5NKFKjvS0OZUeKCADFCiTquGI/9gBxt+ZK+nbDEenGRVkQzOEHW6u3Me6V5Hzj5KSPjnw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aae3ac1d-c367-4e76-12bd-08d793634c8f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 11:18:19.0395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wr4q971r2WzpdF3C2SOaBUSSDt3lRT8zoaVi5ddaHLUOvxeaVDbzr/Mcs1cu6pSMs6wTi3XNpNp+Qut3wJ1w+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1408 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-ext-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 11:18:26 -0000 Hi All, This is a refresh of the draft and it also includes editorial changes to al= ign with the updated version of draft-ietf-spring-srv6-network-programming = as well as the codepoints allocated by IANA via the early allocation proce= ss. Thanks, Ketan (on behalf of co-authors) -----Original Message----- From: Idr On Behalf Of internet-drafts@ietf.org Sent: 07 January 2020 16:44 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-ext-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP Link State Extensions for SRv6 Authors : Gaurav Dawra Clarence Filsfils Ketan Talaulikar Mach Chen Daniel Bernier Bruno Decraene Filename : draft-ietf-idr-bgpls-srv6-ext-02.txt Pages : 24 Date : 2020-01-07 Abstract: Segment Routing IPv6 (SRv6) allows for a flexible definition of end- to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by the various protocols such as BGP, ISIS and OSPFv3. BGP Link-state (BGP-LS) address-family solution for SRv6 is similar to BGP-LS for SR for MPLS dataplane. This draft defines extensions to the BGP-LS to advertise SRv6 Segments along with their behaviors and other attributes via BGP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-srv6-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-srv6-ext-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgpls-srv6-ext-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jan 7 08:35:09 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B90B120848 for ; Tue, 7 Jan 2020 08:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 xK-LNoO_1Ewu for ; Tue, 7 Jan 2020 08:35:06 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D32612084D for ; Tue, 7 Jan 2020 08:35:06 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id k24so22903776ioc.4 for ; Tue, 07 Jan 2020 08:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4k+PZQ2z9gVAbpi11ypYyWCaA9CspKEmzIjJQXbYFV4=; b=S0dbnwVoQTcQDl1iGs9nLUu4o91QUOPhWJnBg6mk8kDwtPJOJxVd3JnYup3+dmf058 6xwvipr0ih7GK/xXr6sJm8LK+Wkr3oeMdRpK0gEhxWeOqmcnCKSioGt2E6rgvUdQId69 uNbXRxrpA0MNtrX9qomZszXwTBTrHijbGydXSQa9dBa3yv+2m5s7R3BWlRpmFzwtDd4n Vd5R+dVHBAMrAA6+s4LhykRjzGlCi5Aq2y/dX1lguuNaQ4MTuMyLIGmYXU4OhArWCbUR isgwHgIa7aJIM+bIcbusrdDbTrabH4vEbDybv+H3L8FS2kQjseSjoEDcPvkdSmJXBBEw 2uiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4k+PZQ2z9gVAbpi11ypYyWCaA9CspKEmzIjJQXbYFV4=; b=YMfnWR7JEEWSbC8nMXUU8/fDwoyujjHDgBio2js3x2doANS2vCk/Mn6DCP54ggqk8U DLrTOpcT7+eCeIw+MxQosfzdq3agXv3eK9X9N4UXaawH4j99GXOTVvaWhLxOrdgmmXKb ynnXa8ICJd63+a4kq+zrNxwMZtaTZXnGzKBX4W76NGgttqgZ36CX4HuBMvTFK4FWdkbQ Dl95YUEE+kn9vJBGzszczCoVwitCB6beUrb7BvhPaV7qwL2w3XVKw3BybvVV1ZIIDbXG TFKBynQPR5msxzZpaRQVCvYOPFHLPew4J5eq4jkMtcWw0Nej86JXF+J2Y4NtQqjdkZXo iBng== X-Gm-Message-State: APjAAAUKNQ6fqd8gKOTOa30rI2PYENvwtKHNhwINFyf4j41WhEQAku8j unrJkhBYedtZyGHEq2wMtzm6bxaeqoktfwggy20= X-Google-Smtp-Source: APXvYqzxFyB56XNXFRzm18dI357lg0BvDVPL5e/BtERx6byQWxzch5OBYl39a4XUznKJfQ8AZ9iRr3dSlykg3R1qipU= X-Received: by 2002:a5d:844d:: with SMTP id w13mr75229957ior.83.1578414905644; Tue, 07 Jan 2020 08:35:05 -0800 (PST) MIME-Version: 1.0 References: <157785269015.23329.2395522887141300513@ietfa.amsl.com> <3873f610b10346739007c78c5a3c345b@huawei.com> In-Reply-To: <3873f610b10346739007c78c5a3c345b@huawei.com> From: Donald Eastlake Date: Tue, 7 Jan 2020 11:34:54 -0500 Message-ID: To: Haoweiguo Cc: "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:35:09 -0000 Hi Weiguo, On Mon, Jan 6, 2020 at 9:46 PM Haoweiguo wrote: > > Hi Donald, > Thanks for your great work. I think this draft is in good shape now, do y= ou think it's ready to ask the WG last call for it? Thanks for the compliment. I guess I think it is ready but it would probably be good for their to be more review/comments on this mailing list first. Also, I plan to update draft-ietf-idr-flowspec-nvo3 fairly soon to correspond to the revised draft-ietf-idr-flowspec-l2vpn and people might want to look at that as well... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > Thanks, > Weiguo > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Idr [mailto:idr-bounces@ietf.org] =E4=BB=A3= =E8=A1=A8 Donald Eastlake > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 01 uMasingana 2020 11:37 PM > =E6=94=B6=E4=BB=B6=E4=BA=BA: idr@ietf. org > =E4=B8=BB=E9=A2=98: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-1= 3.txt > > A new draft for a new year. Please take a look. It uses a different regis= try for L2 Flow-spec components, just like there are different registries f= or IPv4 and IPv6 components, so it can be implemented without any need for = early allocations. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > > On Tue, Dec 31, 2019 at 11:25 PM wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Inter-Domain Routing WG of the IETF. > > > > Title : BGP Dissemination of L2 Flow Specification Ru= les > > Authors : Weiguo Hao > > Donald E. Eastlake > > James Uttaro > > Stephane Litkowski > > Shunwan Zhuang > > Filename : draft-ietf-idr-flowspec-l2vpn-13.txt > > Pages : 22 > > Date : 2019-12-31 > > > > Abstract: > > This document defines a Border Gateway Protocol (BGP) Flow-spec > > extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual > > Private Network (L2VPN) traffic filtering rules either by themselves > > or in conjunction with L3 Flow-specs. AFI/SAFI 6/133 and 25/134 are > > used for these purposes. New component types and an extended > > community also are defined. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13 > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-13 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowspec-l2vpn-13 > > > > > > 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.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 Tue Jan 7 14:56:45 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D20D51200FD; Tue, 7 Jan 2020 14:56:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: idr-chairs@ietf.org, aretana.ietf@gmail.com, skh@ndzh.com, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157843780279.21009.9434387494511118784.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 14:56:42 -0800 Archived-At: Subject: [Idr] idr - New Meeting Session Request for IETF 107 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 22:56:43 -0000 A new meeting session request has just been submitted by Susan Hares, a Chair of the idr working group. --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: Chair Conflict: i2rs grow lsvr bess Technology Overlap: rtgwg spring lsr People who must be present: Susan Hares John Scudder Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 8 11:00:40 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9FD12003E; Wed, 8 Jan 2020 11:00:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: idr-chairs@ietf.org, aretana.ietf@gmail.com, jgs@bgp.nu, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157851003758.22567.17370927740194837648.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2020 11:00:37 -0800 Archived-At: Subject: [Idr] idr - Update to a Meeting Session Request for IETF 107 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 19:00:38 -0000 An update to a meeting session request has just been submitted by John Scudder, a Chair of the idr working group. --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: John Scudder Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: Chair Conflict: i2rs grow lsvr bess Technology Overlap: rtgwg spring lsr sidrops People who must be present: Susan Hares John Scudder Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 8 13:47:07 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E7B12003E; Wed, 8 Jan 2020 13:47:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <157852002151.22603.14918421926118100651@ietfa.amsl.com> Date: Wed, 08 Jan 2020 13:47:01 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-20.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 21:47:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP Optimal Route Reflection (BGP-ORR) Authors : Robert Raszuk Christian Cassar Erik Aman Bruno Decraene Kevin Wang Filename : draft-ietf-idr-bgp-optimal-route-reflection-20.txt Pages : 14 Date : 2020-01-08 Abstract: This document proposes a solution for BGP route reflectors to allow them to choose the best path for their clients that the clients themselves would have chosen under the same conditions, without requiring further state or any new features to be placed on the clients. This facilitates, for example, best exit point policy (hot potato routing). This solution is primarily applicable in deployments using centralized route reflectors. The solution relies upon all route reflectors learning all paths which are eligible for consideration. Best path selection is performed in each route reflector based on a configured virtual location in the IGP. The location can be the same for all clients or different per peer/update group or per peer. Best path selection can also be performed based on user configured policies in each route reflector. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-20 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-optimal-route-reflection-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 9 04:00:31 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943A6120869 for ; Thu, 9 Jan 2020 04:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 W_uhotUL0gjX for ; Thu, 9 Jan 2020 04:00:27 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 276E5120104 for ; Thu, 9 Jan 2020 04:00:27 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CBC57E73FEF1799B1474; Thu, 9 Jan 2020 12:00:24 +0000 (GMT) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 9 Jan 2020 12:00:20 +0000 Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 9 Jan 2020 20:00:17 +0800 Received: from nkgeml706-chm.china.huawei.com ([10.98.57.153]) by nkgeml706-chm.china.huawei.com ([10.98.57.153]) with mapi id 15.01.1713.004; Thu, 9 Jan 2020 20:00:17 +0800 From: Haoweiguo To: Donald Eastlake CC: "idr@ietf. org" , Zhuangshunwan Thread-Topic: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-13.txt Thread-Index: AQHVwFuIvVlettsVQUeFGVZQZ+xKAKfVa7qAgAkcQ5CAAGH3AIADXbUg Date: Thu, 9 Jan 2020 12:00:17 +0000 Message-ID: <8c57eb9cfd1e4c1c9538b843c5e3dde9@huawei.com> References: <157785269015.23329.2395522887141300513@ietfa.amsl.com> <3873f610b10346739007c78c5a3c345b@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.30.193] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] =?utf-8?b?562U5aSNOiAgSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pZHIt?= =?utf-8?q?flowspec-l2vpn-13=2Etxt?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 12:00:29 -0000 SGkgRG9uYWxkLA0KWWVzLCBtb3JlIGNvbW1lbnRzIGFuZCByZXZpZXcgZnJvbSB0aGlzIG1haWxp bmcgbGlzdCBhcmUgYmV0dGVyIGFuZCBhcHByZWNpYXRlZC4NCg0KVGhhbmtzLA0KV2VpZ3VvDQoN Ci0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogRG9uYWxkIEVhc3RsYWtlIFttYWls dG86ZDNlM2UzQGdtYWlsLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDA4IHVNYXNpbmdhbmEgMjAyMCAx MjozNSBBTQ0K5pS25Lu25Lq6OiBIYW93ZWlndW8gPGhhb3dlaWd1b0BodWF3ZWkuY29tPg0K5oqE 6YCBOiBpZHJAaWV0Zi4gb3JnIDxpZHJAaWV0Zi5vcmc+DQrkuLvpopg6IFJlOiBbSWRyXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1sMnZwbi0xMy50eHQNCg0KSGkgV2VpZ3Vv LA0KDQpPbiBNb24sIEphbiA2LCAyMDIwIGF0IDk6NDYgUE0gSGFvd2VpZ3VvIDxoYW93ZWlndW9A aHVhd2VpLmNvbT4gd3JvdGU6DQo+DQo+IEhpIERvbmFsZCwNCj4gVGhhbmtzIGZvciB5b3VyIGdy ZWF0IHdvcmsuIEkgdGhpbmsgdGhpcyBkcmFmdCBpcyBpbiBnb29kIHNoYXBlIG5vdywgZG8geW91 IHRoaW5rIGl0J3MgcmVhZHkgdG8gYXNrIHRoZSBXRyBsYXN0IGNhbGwgZm9yIGl0Pw0KDQpUaGFu a3MgZm9yIHRoZSBjb21wbGltZW50LiBJIGd1ZXNzIEkgdGhpbmsgaXQgaXMgcmVhZHkgYnV0IGl0 IHdvdWxkIHByb2JhYmx5IGJlIGdvb2QgZm9yIHRoZWlyIHRvIGJlIG1vcmUgcmV2aWV3L2NvbW1l bnRzIG9uIHRoaXMgbWFpbGluZyBsaXN0IGZpcnN0LiBBbHNvLCBJIHBsYW4gdG8gdXBkYXRlIGRy YWZ0LWlldGYtaWRyLWZsb3dzcGVjLW52bzMgZmFpcmx5IHNvb24gdG8gY29ycmVzcG9uZCB0byB0 aGUgcmV2aXNlZCBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1sMnZwbiBhbmQgcGVvcGxlIG1pZ2h0 IHdhbnQgdG8gbG9vayBhdCB0aGF0IGFzIHdlbGwuLi4NCg0KVGhhbmtzLA0KRG9uYWxkDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogRG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAgICsx LTUwOC0zMzMtMjI3MCAoY2VsbCkNCiAyMzg2IFBhbm9yYW1pYyBDaXJjbGUsIEFwb3BrYSwgRkwg MzI3MDMgVVNBICBkM2UzZTNAZ21haWwuY29tDQoNCj4gVGhhbmtzLA0KPiBXZWlndW8NCj4NCj4g LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IElkciBbbWFpbHRvOmlkci1ib3Vu Y2VzQGlldGYub3JnXSDku6PooaggRG9uYWxkIEVhc3RsYWtlDQo+IOWPkemAgeaXtumXtDogMDEg dU1hc2luZ2FuYSAyMDIwIDExOjM3IFBNDQo+IOaUtuS7tuS6ujogaWRyQGlldGYuIG9yZyA8aWRy QGlldGYub3JnPg0KPiDkuLvpopg6IFJlOiBbSWRyXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlk ci1mbG93c3BlYy1sMnZwbi0xMy50eHQNCj4NCj4gQSBuZXcgZHJhZnQgZm9yIGEgbmV3IHllYXIu IFBsZWFzZSB0YWtlIGEgbG9vay4gSXQgdXNlcyBhIGRpZmZlcmVudCByZWdpc3RyeSBmb3IgTDIg Rmxvdy1zcGVjIGNvbXBvbmVudHMsIGp1c3QgbGlrZSB0aGVyZSBhcmUgZGlmZmVyZW50IHJlZ2lz dHJpZXMgZm9yIElQdjQgYW5kIElQdjYgY29tcG9uZW50cywgc28gaXQgY2FuIGJlIGltcGxlbWVu dGVkIHdpdGhvdXQgYW55IG5lZWQgZm9yIGVhcmx5IGFsbG9jYXRpb25zLg0KPg0KPiBUaGFua3Ms DQo+IERvbmFsZA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ICBEb25hbGQg RS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMzMy0yMjcwIChjZWxsKQ0KPiAgMjM4NiBQYW5vcmFt aWMgQ2lyY2xlLCBBcG9wa2EsIEZMIDMyNzAzIFVTQSAgZDNlM2UzQGdtYWlsLmNvbQ0KPg0KPiBP biBUdWUsIERlYyAzMSwgMjAxOSBhdCAxMToyNSBQTSA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PiB3cm90ZToNCj4gPg0KPiA+DQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiA+IFRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVyLURvbWFpbiBSb3V0aW5nIFdHIG9mIHRo ZSBJRVRGLg0KPiA+DQo+ID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBCR1AgRGlzc2VtaW5h dGlvbiBvZiBMMiBGbG93IFNwZWNpZmljYXRpb24gUnVsZXMNCj4gPiAgICAgICAgIEF1dGhvcnMg ICAgICAgICA6IFdlaWd1byBIYW8NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIERvbmFs ZCBFLiBFYXN0bGFrZQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSmFtZXMgVXR0YXJv DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVwaGFuZSBMaXRrb3dza2kNCj4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNodW53YW4gWmh1YW5nDQo+ID4gICAgICAgICBGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1sMnZwbi0xMy50eHQNCj4gPiAg ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDIyDQo+ID4gICAgICAgICBEYXRlICAgICAgICAgICAg OiAyMDE5LTEyLTMxDQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYSBCb3JkZXIgR2F0ZXdheSBQcm90b2NvbCAoQkdQKSBGbG93LXNwZWMNCj4gPiAgICBl eHRlbnNpb24gdG8gZGlzc2VtaW5hdGUgRXRoZXJuZXQgTGF5ZXIgMiAoTDIpIGFuZCBMYXllciAy IFZpcnR1YWwNCj4gPiAgICBQcml2YXRlIE5ldHdvcmsgKEwyVlBOKSB0cmFmZmljIGZpbHRlcmlu ZyBydWxlcyBlaXRoZXIgYnkgdGhlbXNlbHZlcw0KPiA+ICAgIG9yIGluIGNvbmp1bmN0aW9uIHdp dGggTDMgRmxvdy1zcGVjcy4gIEFGSS9TQUZJIDYvMTMzIGFuZCAyNS8xMzQgYXJlDQo+ID4gICAg dXNlZCBmb3IgdGhlc2UgcHVycG9zZXMuICBOZXcgY29tcG9uZW50IHR5cGVzIGFuZCBhbiBleHRl bmRlZA0KPiA+ICAgIGNvbW11bml0eSBhbHNvIGFyZSBkZWZpbmVkLg0KPiA+DQo+ID4NCj4gPg0K PiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K PiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWZsb3dz cGVjLWwydnBuLw0KPiA+DQo+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZh aWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlk ci1mbG93c3BlYy1sMnZwbi0xMw0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtbDJ2cG4tDQo+ID4gMTMNCj4gPg0KPiA+IEEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtbDJ2 cG4tMTMNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KPiA+DQo+ID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IElkciBtYWlsaW5nIGxpc3QNCj4gPiBJZHJAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Thu Jan 9 08:47:21 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CC1120019; Thu, 9 Jan 2020 08:47:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <157858843394.11730.16809468474337679522@ietfa.amsl.com> Date: Thu, 09 Jan 2020 08:47:14 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-open-policy-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 16:47:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Route Leak Prevention using Roles in Update and Open messages Authors : Alexander Azimov Eugene Bogomazov Randy Bush Keyur Patel Kotikalapudi Sriram Filename : draft-ietf-idr-bgp-open-policy-07.txt Pages : 10 Date : 2020-01-09 Abstract: Route leaks are the propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one peer to another peer or to a transit provider, passing a route learned from one transit provider to another transit provider or to a peer. Today, approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the BGP neighbor, or enforcement that the two BGP speakers agree on the relationship. This document enhances BGP OPEN to establish agreement of the (peer, customer, provider, Route Server, Route Server client) relationship of two neighboring BGP speakers to enforce appropriate configuration on both sides. Propagated routes are then marked with an OTC attribute according to the agreed relationship, allowing both prevention and detection of route leaks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-07 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-open-policy-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 9 12:43:43 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B84120853; Thu, 9 Jan 2020 12:43:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 PvNufFqjdJnN; Thu, 9 Jan 2020 12:43:38 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EDA12082E; Thu, 9 Jan 2020 12:43:35 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id e10so6799989edv.9; Thu, 09 Jan 2020 12:43:35 -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:content-transfer-encoding; bh=V7Z/1bvUgL+0d/pTAHvCvwNgYl01hBMdM1D6C95q5VY=; b=Orc+LiXeOWRThRLgHKeo/fEyhSRqwPuN4hpxdtMUjauhtIv4OgsVCMmyLpgOxXnhVS ZJ/JPxHmQwDiMet1f2RDGmJdK8w+zQpGZR/RAFzVnH7jDKIsbPE/F8JeHoAILBXqdeFN 0xwgKsrPya15TbnPiy+m4wqmdUjigR6/uXnqLuC6FnJqQRhWj0zmIEknaCqU18VKQch/ b5JT2Y5W8i5ZSGlV1Dw00RDFxn0qdNZFnF8VWm452ngu/Igc7KO+2TK94SmB5LGuOafP IDJ8MsTBVBvGmmFgJKEKZ5DUbmMSWOJCYhKZzoA6wtd6qf3w3oQtMu7OynYzkGME3xig OzeQ== 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:content-transfer-encoding; bh=V7Z/1bvUgL+0d/pTAHvCvwNgYl01hBMdM1D6C95q5VY=; b=sZbyGpjhFvnP9ktf9ae2apBq9nxLKInscaEQzFN+l8ul+rjcSNn30qhz9WjFvMkBfI PisqE+NFCFfuRbqjvsmyhBJeQV2XaS+Q9xdd2kpCEf44wlWVXpbj0/CfK3QRkzk02gEf erR5nlo5N8hnvTX9nchD/86M2zMbMn+jmZ9BrFsvxVdedxxZZnpFMo0E1y7xELAbr8z+ 6xeJYh5OVkEG4v9+UuHQ9B3x9RE87nV7pqRzensqy2r2nGFCcS7Wj5wmbJ8OPYrPxuqI gSsHz70Sip9Xw0EkU7U9Zz4EwVIPuT2g5XraVhDVwzrfIn1HayEgRyjJRbAfP+zG9BJm +jnQ== X-Gm-Message-State: APjAAAWP6KJ0CmgIAJp7k1bJ9f4nhXb3QKzGz4uRkbILMvWFe9Cn2CYU VCnl7mFHWL3K4c3GEWydvOz7cwKRYSKYd5yY3Hi6hQ== X-Google-Smtp-Source: APXvYqyh5ckeyPAJSPc6IIqeHYiQ4T2FLkSwdBYii3FVfMbkIXGfhWAiTJhGnhzkfuy9YtmlY8ubzP7O3iDRguKMwGU= X-Received: by 2002:a50:ef1a:: with SMTP id m26mr13100328eds.289.1578602613384; Thu, 09 Jan 2020 12:43:33 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 9 Jan 2020 12:43:32 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 9 Jan 2020 12:43:32 -0800 Message-ID: To: idr-chairs@ietf.org, "idr@ietf. org" Cc: Susan Hares , draft-ietf-idr-bgp-bestpath-selection-criteria@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:43:41 -0000 Dear Chairs/WG: Happy New Year! I am returning this document to the WG for further discussion. Rajiv, Sue and I had a very fruitful conversation while in Singapore at the last IETF. =C2=A0We agree on the technical issues, but (as explained in my review -- I left the header below [*]) my concerns go beyond the content and into the Status of the document and the general interest from the WG in this work. Sue/John: =C2=A0I need you to explicitly collect feedback from the WG and reevaluate support for the document's content and status. Specifically, we need a *discussion* about the first two points mentioned below. Thank you!! Alvaro. [*] The full review is here: https://mailarchive.ietf.org/arch/msg/idr/85qTCgN4k6oAbSlKmpyi8stxZz0 On July 17, 2019 at 4:15:57 PM, Alvaro Retana wrote: > Rajiv: > > Hi! How are you? I just finished reading this document. > > First of all, thank you for your patience and perseverance in sticking wi= th > this document for so long! > > Having said that, I have significant issues with the document. I have > specific in-line comments below, but I want to highlight some of the bigg= er > issues now -- please note that while you are the Author, the issues calle= d > out here are directed at the WG/Chairs/Shepherd as well. > > (1) What is the Update to rfc4271? > > The document presents two amendments to the Route Resolvability Condition > (=C2=A79.1.2.1/rfc4271). The first one is straight forward and obvious: r= esolve > the next-hop using the correct Routing Table. > > The second one is to check the "path availability" to the next-hop. While= a > good thing to do, and optional, it introduces in the BGP Decision Process > unspecified functionality that depends on external mechanisms...which, in= my > opinion, should be used to maintain the Routing Table and not be specific= ally > a part of BGP. > > Both the policy to drive Amendment 1 and the expectations of the check in > Amendment 2 are not specified and declared out of scope. IOW, the > specification is to do something that is not specified. Back to my questi= on: > what is the Update to rfc4271? > > I didn't find a discussion on the list about the Update: either about > formally Updating rfc4271, *or* what the Update would be. I did find a no= te > [1] that says "our AD requested we move the document from Informational t= o > Standards track, and add 'Updates: RFC 4271'"...but there was no discussi= on; > in fact, no reply at all. > > [Disclaimer: I was not the AD in 2011.] > > Related to this point, and specifically to the "path availability" > functionality... In the Implementation Report [2], one of the implementer= s > reports support for "path availability check in several variations, but n= ot > all. For example, BFD may be used to protect MPLS generated nexthops for = LDP > and RSVP. For IP nexthops distributed via an IGP, the IGP may be protecte= d > using BFD." Because the "path availability" functionality is not specifie= d in > this document, then I'm not sure whether either of these satisfies this > document...but both mechanisms described are about protecting the next-ho= ps > (and presumably triggering FRR, for example), and not specifically about > providing BGP with an indication of availability to forward traffic (whic= h is > my interpretation of "path availability"). > > To be clear: I mention this text from the Implementation Report not to > criticize the implementation...but to support the points that (1) the > specification in this document is incomplete, and (2) that the OAM mechan= isms > should be used to maintain the Routing Table (and not just interact direc= tly > with BGP). IOW, I believe that the implementation is doing the right > thing...but that is not what is described in the document. > > [See more related comments in =C2=A73, after Amendment 2.] > > > (2) WG Discussion (...or lack of...) > > As I mentioned above, there was no discussion of the Update in the WG. In > fact, the only significant discussion was during adoption [3] -- at that > point the draft was Informational and it didn't Update anything. > > The WGLCs [4][5] show only 1 comment, and no other explicit show of suppo= rt. > Not even the usual "support...+1...+1...". > > I went back and looked at the minutes from IETF 73 [6], which is where th= e > draft was presented for the first time, but there was no feedback there. > > draft-asati-bgp-mpls-blackhole-avoidance, which was presented at IETF 68,= was > the precursor of this document. The minutes from that meeting [7] show no= t a > lot of excitement and minor support for perhaps an Informational one-page > document saying "please be careful about selecting a next hop". > > One last note on this point. The Shepherd's writeup [8] reads: > > =C2=A0 =C2=A0(9) How solid is the WG consensus behind this document? Does= it > =C2=A0 =C2=A0represent the strong concurrence of a few individuals, with = others > =C2=A0 =C2=A0being silent, or does the WG as a whole understand and agree= with it? > > =C2=A0 =C2=A0Solid in 2009. As time goes on waiting for implementation re= ports, > =C2=A0 =C2=A0the memory of those days weakens. However, since 2 major ven= dors > =C2=A0 =C2=A0have implemented and deployed this RFC - the solid WG > =C2=A0 =C2=A0support from 2009 has been validated. > > The draft was adopted with rough consensus [3], so I don't interpret > implementations in this case as strong validation mainly because I don't = see > a clear specification. > > All this leads me to ask: Is this work (many years later!) still somethin= g > the WG wants to progress? Or has it been taken over by events? Is the > document in it's current form what the WG thought it was adopting? > > I am looking for discussion and specific opinions (not +1s!). I would be = very > happy if someone pointed me to discussions I missed in my search. > > > (3) Terminology > > In general, I think that most idr participants would clearly understand t= he > terminology used in this document. However, the audience is wider than th= at, > and the terminology used doesn't correspond to that in other work. > > For example, the first sentence in the Abstract reads: > > =C2=A0 =C2=A0BGP specification (RFC4271) prescribes 'BGP next-hop reachab= ility' > =C2=A0 =C2=A0as one of the key 'Route Resolvability Condition' that must = be > =C2=A0 =C2=A0satisfied before the BGP bestpath candidate selection. > > rfc4271 doesn't talk anywhere about reachability or a bestpath. > > Please be consistent with the terminology in other RFCs, specially rfc427= 1. > Introducing new terms is fine, if they are needed and properly explained. > > > Given the points above, I am inclined to return this document to the WG f= or > further discussion. I really don't want to do that given its long history= , so > perhaps we can use some time next week in Montreal to talk face-to-face. > > Thanks! > > Alvaro. > > > [1] https://mailarchive.ietf.org/arch/msg/idr/jWNhfTvHbaY3rEk5nTYahS5w6_Q > [2] https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selec= tion-criteria > [3] https://mailarchive.ietf.org/arch/msg/idr/Yr9u6V2HKrHEuQLtFw7aDstMPzg > [4] https://mailarchive.ietf.org/arch/msg/idr/kiTwL6ApC_k9QFrfhaMA_qC8BcA > [5] https://mailarchive.ietf.org/arch/msg/idr/OqsCexPPmtvKjHNJzf4EcpwPhtQ > [6] https://mailarchive.ietf.org/arch/msg/idr/OVg6Cfr3EUwIRcQS6cIkwq_dUtI > [7] https://mailarchive.ietf.org/arch/msg/idr/lezFHSGaOzvL2h16M883beeHcjI > [8] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bestpath-selectio= n-criteria/shepherdwriteup/ From nobody Thu Jan 16 20:19:05 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FA9120058; Thu, 16 Jan 2020 20:19:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <157923474407.28062.14457751605685444477@ietfa.amsl.com> Date: Thu, 16 Jan 2020 20:19:04 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-nvo3-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 04:19:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP Dissemination of Flow Specification Rules for Tunneled Traffic Authors : Donald Eastlake Weiguo Hao Shunwan Zhuang Zhenbin Li Rong Gu Filename : draft-ietf-idr-flowspec-nvo3-08.txt Pages : 18 Date : 2020-01-16 Abstract: This draft specifies a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format for flow specifications (RFC 5575bis) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-nvo3/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-08 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-nvo3-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-nvo3-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 16 20:49:53 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FF21200D6 for ; Thu, 16 Jan 2020 20:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wu6LVBl1uE_a for ; Thu, 16 Jan 2020 20:49:51 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 2CAFD120099 for ; Thu, 16 Jan 2020 20:49:51 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id t26so24625970ioi.13 for ; Thu, 16 Jan 2020 20:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7VUgjBkaGal3HUrQXD8RNMb1BtSEojHRoVexpFts2ps=; b=TrM7P0uQihrZy5G7hbPTcTLSx1u55HPDoaZR9d2Hf/BRKthcQ+emdwRooaUk55iIhz pFUpV8t+8X1lD5Ebhijb4QGkxtZm7+kcSRqjeogzLa8S8/HLvMbgs7fiR5V3gLXxTpX+ bSxnujzjxwWKmEFm/JkQGlS13+ZhUKnYD58Ik/zJIoTQCwQewvf8K7qLEbI4RcMHJL5Z uV//Cya+67rbBZYxWY2XoMm7LIoIIu23O7Ue99/Y1ci41a8HD/ruHBFHfcsQre/8CSjc vusMtdqleqvVkkZLktnkqJaLBgq1WckDN7T9Oy7ffvdvipDg4szT5B4zLhaZWp797Qi9 PyGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7VUgjBkaGal3HUrQXD8RNMb1BtSEojHRoVexpFts2ps=; b=Sk5kuc0Su7sEJH0cMORDpUr0SCpNNHt0JZ9qUsED/DUXEuSm0dA8W0EUmjJaftNUCy oeLAdLR46lMjjDwgnvh7uK8LBttlkGI0P7O9tiHWVAOTidoY7pffaNxA+nIddhdqcnN3 9iTr47BuRNzETMDsVl6AIQPReoROIeuG2NTsQpMGGfMy0IU5rEhF5+vGALcL/GVG+Y+D qSuk4ZIRu/MFEqerJq4YMGwrRwxkPXgTgzJVOt2hkloa7h8HPNER80QtP2HdqK7R4jvQ 6XV+7YxjlQs1qHNEz2tbDvRC1lfLV9Somii9D91GrKcttOecsjsOqJqm7JuAg9OHrqjW e8sQ== X-Gm-Message-State: APjAAAXqlyitMw86a1MZgJ+UmBlDFYx07GGrLE05IjHN+O9upv2Nva9B XsicvtxbbLMeUXfE6aM0VnkrbCSWUeXXRElmOzBvnpzn X-Google-Smtp-Source: APXvYqyAWANpGLvpdw4ff3EfsvE/P4nWJSKesy376H2B3nGjU4+AAzC8DDyX0K26zPAQHfk4QsIxNSZXHGO/e9bO+Ak= X-Received: by 2002:a02:2404:: with SMTP id f4mr31150449jaa.50.1579236587250; Thu, 16 Jan 2020 20:49:47 -0800 (PST) MIME-Version: 1.0 References: <157923474407.28062.14457751605685444477@ietfa.amsl.com> In-Reply-To: <157923474407.28062.14457751605685444477@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 16 Jan 2020 23:49:35 -0500 Message-ID: To: "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-nvo3-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 04:49:52 -0000 Hi, This is the revised Flow-spec draft for tunneled traffic. It has been updated in ways corresponding to the updates that produced https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13 Comments welcome. We also request an early allocation SAFI for use in this flowspec-nvo3-08. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Thu, Jan 16, 2020 at 11:19 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing WG of the IETF. > > Title : BGP Dissemination of Flow Specification Rules for Tunneled Traffic > Authors : Donald Eastlake > Weiguo Hao > Shunwan Zhuang > Zhenbin Li > Rong Gu > Filename : draft-ietf-idr-flowspec-nvo3-08.txt > Pages : 18 > Date : 2020-01-16 > > Abstract: > This draft specifies a Border Gateway Protocol Network Layer > Reachability Information (BGP NLRI) encoding format for flow > specifications (RFC 5575bis) that can match on a variety of tunneled > traffic. In addition, flow specification components are specified for > certain tunneling header fields. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-nvo3/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-08 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-nvo3-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-nvo3-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jan 17 00:26:38 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06244120236; Fri, 17 Jan 2020 00:26:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <157924959596.20257.10412457723414349272@ietfa.amsl.com> Date: Fri, 17 Jan 2020 00:26:36 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-19.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 08:26:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Dissemination of Flow Specification Rules Authors : Christoph Loibl Susan Hares Robert Raszuk Danny McPherson Martin Bacher Filename : draft-ietf-idr-rfc5575bis-19.txt Pages : 38 Date : 2020-01-17 Abstract: This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, that can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. Other applications (ie. centralized control of traffic in a SDN or NFV context) are also possible. Other documents may specify Flow Specification extensions. The information is carried via BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. This document obsoletes both RFC5575 and RFC7674. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-19 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc5575bis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 17 00:55:24 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA81C120273; Fri, 17 Jan 2020 00:55:21 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): X-Spam-Report: ....ietf@gmail.com> wrote: [\342\200\246] [...] \n\tCon[...] 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJQ5vnFoa7JU; Fri, 17 Jan 2020 00:55:16 -0800 (PST) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3EF120236; Fri, 17 Jan 2020 00:55:15 -0800 (PST) Received: from 80-110-104-164.cgn.dynamic.surfer.at ([80.110.104.164] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1isNPK-0006Sy-HJ; Fri, 17 Jan 2020 09:55:12 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Christoph Loibl In-Reply-To: Date: Fri, 17 Jan 2020 09:55:09 +0100 Cc: idr-chairs@ietf.org, "idr@ietf. org" , draft-ietf-idr-rfc5575bis@ietf.org, "Dongjie (Jimmy)" Content-Transfer-Encoding: quoted-printable Message-Id: <188DFC4F-7A19-433F-AD3A-A2CC961774B0@tix.at> References: To: Alvaro Retana X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 -> Updated Version -18 and Flowspec v6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 08:55:22 -0000 Hi Alvaro and IDR, > On 12.12.2019, at 20:38, Alvaro Retana wrote: [=E2=80=A6] Thank you very much for your review. I promised to followup in January. = As I did this with the previous review, on behalf of the Authors I = opened Github issues for all the comments and worked thru them so that = changes (if any) can be tracked easier. The repository can be found here = (issues #140 and following): https://github.com/stoffi92/rfc5575bis The resulting document can be found on datatracker (-19): https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ I kindly ask you and IDR to review this new version. The changes from = -18 to -19 are rather small. This time I recommend to use rfcdiff for a = quick overview. However, I still added comments to all the major issues = that you pointed out on Github and in this Email below. >=20 > There is only one significant item remaining that we should resolve > before moving the document forward: the handling of unknown > components; take a look at the comments in =C2=A711 (of -18). >=20 > Thanks! This issue has been discussed before Christmas on the mailinglist. The = main points in that discussion were that we do not want to propagate any = garbage, while allowing a certain degree of extensibility of the NLRI = (given the zoo of FS drafts and expected AFI/SAFI pollution out there = this seems to be reasonable - extension Authors may still choose how = they extend the NLRI this is not specified in this draft) and keep = backwards compatibility. In this context Alvaro pointed out that the behaviour explained in the = draft fits closely RFC7606 Section 5.4 (Typed NLRI) and Jeffrey = explained that walking NLRIs may lead to synchronisation issues between = a buggy FS sender and a receiver.=20 The document that we now uploaded clearly references RFC7606 Typed NLRI = as the mechanism to treat unknown FS components and to allow the = receiver to skip over (and discard) a single NLRI if it hits an unknown = component type (previously the very same behaviour was explained in the = draft without referencing RFC7606). We also added a paragraph to the = security considerations section to explain that RFC7606 Section 5.4 = allows to skip (and discard) *unknown* octets and carefully = crafted/misbehaving BGP speakers may exploit that fact. The remaining Email contains the responses and links to the -17 = "review-review" and the -18 review.=20 Please review the document. I hope that we can proceed with this = document.=20 Cheers Christoph (I just noticed that something/one (me?) messed up the IANA = Considerations tables (some columns look to be centred or = right-aligned). Nothing to worry, I will fix this soon.) ********** THE SECTION BELOW RELATES TO THE -17 REVIEW ************* > ... > 227 2. Definitions of Terms Used in This Memo > ... > 233 Loc-RIB - Local RIB. >=20 > [major] This simple definition doesn't match the one in =C2=A71.1/rfc427= 1. >=20 > <-- *** Authors *** > Tracked via issue #11: = https://github.com/stoffi92/rfc5575bis/issues/11 > Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/b4950ef76c347a67a8e31e0eff4d= 1433a00e34b8 >=20 > Added the definition to to match RFC4271 > --> >=20 > [minor] Please add a reference to rfc4271 there too. >=20 <-- AUTHORS Tracked via issue #131: = https://github.com/stoffi92/rfc5575bis/issues/131 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/98e2f95f13a39a1fd434be2fe5d7= 0fd5d5e4c28b --> >=20 > ... > 281 4. Dissemination of IPv4 FLow Specification Information > ... > 287 This NLRI information is encoded using MP_REACH_NLRI and > 288 MP_UNREACH_NLRI attributes as defined in [RFC4760]. Whenever the > 289 corresponding application does not require Next-Hop information, = this > 290 shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI > 291 attribute and ignored on receipt. >=20 [..] > [major] This is the new text from -18: >=20 > 255 This NLRI information is encoded using MP_REACH_NLRI and > 256 MP_UNREACH_NLRI attributes as defined in [RFC4760]. Whenever = the > 257 corresponding application does not require Next Hop = information, this > 258 shall be encoded as a 0-octet length Next Hop in the = MP_REACH_NLRI > 259 attribute (if a non 0-octet Next Hop is present it should be = ignored > 260 on receipt). >=20 > I think I get it: the Next Hop is not needed -- so it is either not > present (0-octet length) or ignored. Is that it? >=20 > What is confusing me is the part about "Whenever the corresponding > application does not require Next Hop information", because it sounds > as if there are cases when the Next Hop is needed...but then it is > ignored anyway. >=20 > I looked in rfc4760/rfc4271, but they both talk about forwarding to > the Next Hop, and not about cases where it is not needed (or at least > I didn't find that). IOW, the use defined here is specific to the FS > AFI/SAFI pair. The specification of the use (or not) or the Next Hop > should then be a lot clearer, and Normative. >=20 > SUGGESTION> > This NLRI information is encoded using MP_REACH_NLRI and = MP_UNREACH_NLRI > attributes as defined in [RFC4760]. When advertising Flow = Specifications, > the Length of Next Hop Network Address SHOULD be set to 0. The = Network > Address of Next Hop field MUST be ignored. >=20 <-- AUTHORS Tracked via issue #132: = https://github.com/stoffi92/rfc5575bis/issues/132 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/3fd408f1fd6ac04c4a4cb3e39521= e7efc335fe5c --> >=20 > ... > 325 4.2. NLRI Value Encoding > ... > 338 Flow Specification components must follow strict type ordering by > 339 increasing numerical order. A given component type may (exactly > 340 once) or may not be present in the specification. If present, it > 341 MUST precede any component of higher numeric type value. >=20 > [major] What should happen if a component appears more than once? >=20 > [major] What should happen if the order is not maintained? >=20 > <-- *** Authors *** > Tracked via issue #19: = https://github.com/stoffi92/rfc5575bis/issues/19 >=20 > Basically if the NLRI is not encoded to specification we have a = malformed > NLRI (most probably the BGP NLRI parser will throw an exception on the > implementation). I am not sure if this needs to be made explicit. - = But I can > make this explicit. > --> >=20 > The question is: what should the implementation do in response to the > exception? Should it reset the session? Should it ignore the Update? > Should it disable the AFI/SAFI? Should it only consider the first > component (if it appears more than once)? Something else? >=20 > I looked at rfc4760/rfc7606, but didn't find anything that looked to > me explicitly as corresponding to a Malformed NLRI...but rfc4760 does > specify "AFI/SAFI disable": >=20 > If a BGP speaker receives from a neighbor an UPDATE message that > contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and if the > speaker determines that the attribute is incorrect, the speaker MUST > delete all the BGP routes received from that neighbor whose AFI/SAFI > is the same as the one carried in the incorrect MP_REACH_NLRI or > MP_UNREACH_NLRI attribute. For the duration of the BGP session over > which the UPDATE message was received, the speaker then SHOULD ignore > all the subsequent routes with that AFI/SAFI received over that > session. >=20 > The result is then that FS (including the rules/actions already > received) would now not be used. Personal opinion: Disabling the > AFI/SAFI can be worse than resetting the session because there's no > indication to the sender that anything is wrong. >=20 > If AFI/SAFI disable is the expected behavior for both out-of-order and > duplicate components, then nothing else is needed. A note in =C2=A710 > would be nice but not necessary. >=20 <-- AUTHORS Tracked via issue #133: = https://github.com/stoffi92/rfc5575bis/issues/133 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/b268bc69b1afd18fb471cf3bb1ae= 23216624faae Related issue mentioned: = https://github.com/stoffi92/rfc5575bis/issues/155 If the FS NLRI is not encoded according to specification it is = considered Malformed and should be treated according to rfc7606 = (malformed in rfc7606 still bounces the session as Alvaro pointed out). See also the above comment on rfc7606 based typed-nlri. =20 --> >=20 > ... > 542 4.2.12. Type 12 - Fragment > ... > 548 0 1 2 3 4 5 6 7 > 549 +---+---+---+---+---+---+---+---+ > 550 | 0 | 0 | 0 | 0 |LF |FF |IsF|DF | > 551 +---+---+---+---+---+---+---+---+ > ... > [major] The operation is not specified. Is this also an = (operator,bitmask) > pair, or just 8 bits indicating the values? Can multiple bits be set = at the > same time? What fields in the IP header do these map to? >=20 > <-- *** Authors *** > Tracked via issue #40: = https://github.com/stoffi92/rfc5575bis/issues/40 > Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/f078e919842330d670bc195276ea= d7bdc05a3351 >=20 > Added the text to the bit-descriptions and IP-header fields - And an = example > using the bitmask operator. > --> >=20 > The example is for a "matching packet with DF bit set or First > Fragments", which answers the question above about whether multiple > bits can be set -- yes. What is still not specified is that in the > case of multiple bits set, an OR operation is expected. >=20 <-- AUTHORS Tracked via issue #134: = https://github.com/stoffi92/rfc5575bis/issues/134 The OR operation that is expected is defined in the bitmask-operator the = m-bit. If set, this is a bitwise match operation defined as "(data AND value) =3D=3D value"; if unset, (data AND value) = evaluates to TRUE if any of the bits in the value mask are set in the data As Jeffrey already pointed out, there are certain combinations that make = no sense and will never match a packet. Especially if you have the m-bit = set in the operator and some combinations of the "LF FF IsF DF" bits = set. For example having all of them set you would require a packet to = have the following flag/offset combinations: (DF=3D1) AND (Fragment-offset !=3D 0) AND (Fragment-offset =3D=3D 0 and = MF=3D=3D1) AND (Fragment-offset !=3D 0 and MF=3D=3D0) --> >=20 > ... > 742 6. Validation Procedure > ... > 760 A Flow Specification NLRI must be validated such that it is > 761 considered feasible if and only if all of the below is true: >=20 > [major] There is no Normative language above, but I think there is a > contradiction of sorts with the new text below ("Rule a) MAY be = relaxed..."). > The introductory text to the rules is "must be...considered feasible = if and > only if all of the below is true", which sounds very strict and > specific...but then the Normative exception comes in ("MAY be = relaxed...rules > b) and c)...MUST be disregarded") saying that it doesn't matter. = Please > reword...perhaps something like: "If a destination is present...a Flow > Specification MUST be validated this way...otherwise..." >=20 > <-- *** Authors *** > Tracked via issue #56: = https://github.com/stoffi92/rfc5575bis/issues/56 > Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/d96a496295021f2aab0332bd2120= 920547f71c56 >=20 > Changed the text to refer to the default behaviour of the = implementation > (MUST validate). However this MAY be relaxed by configuration. > --> >=20 > I'm still not happy with the contradiction: MUST means "an absolute > requirement" (no exceptions!), but then we say MAY, which makes the > MUST optional...even with the "by default"... Please s/MUST/SHOULD > The MAY will then explain the "valid reason" to not... >=20 <-- AUTHORS Tracked via issue #135: = https://github.com/stoffi92/rfc5575bis/issues/135 The point to stress out is that the "default" behaviour MUST be = "validate" according to the spec. Not the default can be changed but the = "validation" MAY be relaxed by configuration. --> >=20 > ... > 783 BGP implementations MUST also enforce that the AS_PATH attribute = of a > 784 route received via the External Border Gateway Protocol (eBGP) > 785 contains the neighboring AS in the left-most position of the = AS_PATH > 786 attribute. While this rule is optional in the BGP specification, = it > 787 becomes necessary to enforce it for security reasons. > ... > [major] In the case of receiving Flow Specifications from a neighbor = in an > IXP, it may not be possible to enforce the rule above if a = "transparent ASN" > is being used. Please include some text/guidance about that type of = case. > Include it either here or in the Security Considerations. > ... > <-- *** Authors *** > Tracked via issue #60: = https://github.com/stoffi92/rfc5575bis/issues/60 >=20 > ... > In the case of IXP indeed this sometime may break in the cases where = RS is > used. If you even in the IX (which is L2 typically) use direct EBGP = session > it all works ok. If you use session to RS and such RS by design is > transparent in order to not extend the AS_PATH length that enforce = first AS > should be disabled. I think we could say that use of flow spec when = peering > with RS in IXP env is much less secure as ASN spoofing in the AS-PATH = can > occur. It is advised to apply strict inbound route policy in such = scenarios. > --> >=20 > Please add some text in =C2=A713 about it -- something similar to the > explanation above would be great. >=20 <-- AUTHORS Tracked via issue #136: = https://github.com/stoffi92/rfc5575bis/issues/136 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/96f539d178e301ccbc38c9c29ac6= ec59b7774174 --> >=20 > ... > 904 7.3. Traffic-action (traffic-action) sub-type 0x07 > ... > 917 o T: Terminal Action (bit 47): When this bit is set, the traffic > 918 filtering engine will apply any subsequent filtering rules (as > 919 defined by the ordering procedure). If not set, the evaluation of > 920 the traffic filter stops when this rule is applied. >=20 > [minor] According to the processing order and the values from Table 2, = not > setting the bit would effectively cause only the traffic-rate-bytes = (0x8006) > to ever be applied. Is that the correct interpretation? > ... > <-- *** Authors *** > Tracked via issue #72: = https://github.com/stoffi92/rfc5575bis/issues/72 >=20 > Minor1: > The terminal action applies to filter rules only, not to the filter = actions > (extended communties). Given we have 3 FS filters that match the = traffic > (they are sorted first): > FS1) The first has T=3D0 and a traffic-rate-bytes action > FS2) The second has only a redirect-action > FS3) The third has only a traffic-rate-packets action >=20 > Evaluation takes place according to the sorted filters FS1 first, then > FS2(because of T=3D0 in FS1). However, because FS2 has no T=3D0 set = evaluation > stops here and the resulting action is: traffic-rate-bytes and = redirect. >=20 > Right...rules vs actions... Please add a reference to =C2=A75.1 = (Ordering > of Flow Specifications) to make it clearer for others. >=20 > The example helps, but it is wrong. The definition says that when the > "bit is set, the traffic filtering engine will apply any subsequent > filtering rules"...so the action should result in only > traffic-rate-bytes. >=20 <-- AUTHORS Tracked via issue #137: = https://github.com/stoffi92/rfc5575bis/issues/137 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/a096cfa26367bf49b00d6c087e08= e0b69dad1e99 You are correct it should be T=3D1 not T=3D0. We also added a reference = to the Ordering of Flow Specifications section. =E2=80=94> [..] > The reason/history doesn't matter anymore, but the current use does. = The > mechanism described in this document is clearly not experimental. = Given that > changing the Type values is not an option because of the deployed = base, > etc.., then I think we should clean up the Registry and move 0x80-0x82 = from > the Experimental Use range to the FCFS range. This change would mean = an > Update to rfc7153. [..] > <-- *** Authors *** > Tracked via issue #99: = https://github.com/stoffi92/rfc5575bis/issues/99 >=20 > This is not to be solved within this document. I note that I should = propose a > update to RFC7153 to cleanup the registry independently. - As noticed = moving > the values around is not an option. > --> >=20 > So, are you working on this already? ;-) >=20 <-- AUTHORS Tracked via issue #138: = https://github.com/stoffi92/rfc5575bis/issues/138 Seriously. IF the only thing that is needed here is a IANA = considerations draft I will look into this later. If this can be done = easier. I think after the 5575bis changes have been made in the = registry. There is a good chance to have this cleaned up. --> > ... > 1308 13. Security Considerations >=20 [..] >=20 > All this is moot anyway because ROAs are only defined for the > IPv4/IPv6 AFs (rfc6482). >=20 > In any case, if I look really close, the text says that "the security > characteristics of this proposal are equivalent to the existing > security properties of BGP unicast routing" -- equivalent, not the > same. I'll let this go. :-) >=20 <-- AUTHORS Tracked via issue #139: = https://github.com/stoffi92/rfc5575bis/issues/139 Nothing to do. =E2=80=94> ********** THE SECTION BELOW RELATES TO THE -18 REVIEW ************* > [Part II: Review of -18.] >=20 > [Line numbers from id-nits.] >=20 > ... > 17 Abstract >=20 > 19 This document obsoletes both RFC5575 and RFC7674. >=20 > [style nit] Usually this statement is placed at the end of the > Abstract/Introduction. Personally, I think it makes it easier to > read... >=20 > [minor] The Abstract shouldn't have references. In the xml: s/ target=3D"RFC5575" /> and /RFC 5575 and RFC > 7674 >=20 <-- AUTHORS Tracked via issue #140: = https://github.com/stoffi92/rfc5575bis/issues/140 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/f3db0073a086179cbc7bf8216884= 3206f68a62d0 --> >=20 >=20 > 21 This document defines a Border Gateway Protocol Network Layer > 22 Reachability Information (BGP NLRI) encoding format, that can = be used > 23 to distribute traffic Flow Specifications. This allows the = routing > 24 system to propagate information regarding more specific = components of > 25 the traffic aggregate defined by an IP destination prefix. >=20 > [nit] No comma before "that". s/encoding format, that/encoding = format that >=20 <-- AUTHORS Tracked via issue #141: = https://github.com/stoffi92/rfc5575bis/issues/141 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/2bd77ff28d1a401d10c9432a0286= 8897cdd62d85 --> >=20 > ... > 32 Additionally, it defines two applications of that encoding = format: > 33 one that can be used to automate inter-domain coordination of = traffic > 34 filtering, such as what is required in order to mitigate > 35 (distributed) denial-of-service attacks, and a second = application to > 36 provide traffic filtering in the context of a BGP/MPLS VPN = service. > 37 Other applications (ie. centralized control of traffic in a = SDN or > 38 NFV context) are also possible. Other drafts specify IPv6, = MPLS > 39 addresses, L2VPN addresses, and NV03 encapsulation of IP = addresses as > 40 Flow Specification extensions. >=20 > [minor] (Related to the last sentence.) As I mentioned before, the > Introduction only points at the IPv6 draft, but it could benefit from > pointers to the other drafts mentioned here. Given the recent > discussion about extensibility, it may be better to simply not be > specific about what other drafts may specify: >=20 > SUGGESTION> > Other documents may specify Flow Specification extensions. >=20 <-- AUTHORS Tracked via issue #142: = https://github.com/stoffi92/rfc5575bis/issues/142 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/c77d7729ba25ba1d55580366d51c= ba246bd3ac3f --> >=20 > 42 The information is carried via the BGP, thereby reusing = protocol > 43 algorithms, operational experience, and administrative = processes such > 44 as inter-provider peering agreements. >=20 > [nit] s/carried via the BGP/carried via BGP >=20 <-- AUTHORS Tracked via issue #143: = https://github.com/stoffi92/rfc5575bis/issues/143 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/3590435e4eb82e86333156f68314= 22d5d52c0821 --> >=20 > ... > 120 1. Introduction > ... > 154 A Flow Specification received from an external autonomous = system will > 155 need to be validated against unicast routing before being = accepted > 156 (Section 6). The flow specification received from an internal = BGP > 157 peer within the same autonomous system (per [RFC4271]) is = assumed to > 158 have been validated prior to transmission within the iBGP mesh = of an > 159 autonomous system. If the aggregate traffic flow defined by = the > 160 unicast destination prefix is forwarded to a given BGP peer, = then the > 161 local system can install more specific Flow Specifications = that may > 162 result in different forwarding behavior, as requested by this = system. >=20 > [nit] s/flow specification (and other case variations)/Flow = Specification/g >=20 > [nit] s/(per [RFC4271])/[RFC4271] >=20 <-- AUTHORS Tracked via issue #144: = https://github.com/stoffi92/rfc5575bis/issues/144 Commits mentions: = https://github.com/stoffi92/rfc5575bis/commit/39ca5251d300906c519929373ecb= 568807ceb461 = https://github.com/stoffi92/rfc5575bis/commit/46c337286cdff56a1cf39c1aaa49= 3aefb3a102ee --> >=20 > ... > 249 4. Dissemination of IPv4 FLow Specification Information >=20 > [nit] s/FLow/Flow >=20 <-- AUTHORS Tracked via issue #145: = https://github.com/stoffi92/rfc5575bis/issues/145 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/27479f12bedaad66f23f8df5d961= 939e052e09bb --> >=20 > ... > 295 4.2. NLRI Value Encoding > ... > 311 All combinations of components within a single Flow = Specification are > 312 allowed. However, some combinations cannot match any packets = (ie. > 313 "ICMP Type AND Port" will never match any packets), and thus = SHOULD > 314 NOT be propagated by BGP. >=20 > [nit] s/ie./e.g. >=20 <-- AUTHORS Tracked via issue #146: = https://github.com/stoffi92/rfc5575bis/issues/146 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/2c567cb5307d8810161dbc862df2= 4dcc6c67aeb0 --> >=20 > ... > 607 4.3.1. Example 1 > ... > 620 +-------+------------+------------------------------+ > 621 | Value | | | > 622 +-------+------------+------------------------------+ > 623 | 0x0b | length | 11 octets (len<240 1-octet) | > 624 | 0x01 | type | Type 1 - Destination Prefix | > 625 | 0x18 | length | 24 bit | > 626 | 0xc0 | prefix | 192 | > 627 | 0x00 | prefix | 0 | > 628 | 0x02 | prefix | 2 | > 629 | 0x03 | type | Type 3 - IP Protocol | > 630 | 0x81 | numeric_op | end-of-list, value size=3D1, =3D = | > 631 | 0x06 | value | IP Protocol 6 =3D TCP | > 632 | 0x04 | type | Type 4 - Port | > 633 | 0x81 | numeric_op | end-of-list, value size=3D1, =3D = | > 634 | 0x19 | value | 25 | > 635 +-------+------------+------------------------------+ >=20 > [minor] Table 1 defines equal as "=3D=3D (equal)" -- just to be > consistent. s/=3D/=3D=3D/g >=20 <-- AUTHORS Tracked via issue #147: = https://github.com/stoffi92/rfc5575bis/issues/147 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/27e2b06bf895e73abbffd7999f53= a4b83ad34de7 --> >=20 > ... > 959 7.3. Traffic-action (traffic-action) sub-type 0x07 > ... > 986 o Traffic Action Field: Other Traffic Action Field (see = Section 12) > 987 bits unused in this specification. >=20 > [major] How should unknown bits be treated? In the last version, the > text read: "should always be set to 0 by the originator and not be > evaluated by the receiving BGP speaker." Please add something like > that. >=20 <-- AUTHORS Tracked via issue #148: = https://github.com/stoffi92/rfc5575bis/issues/148 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/1b8029dff11415abb8fd1a3a158c= aa57481321bd --> >=20 > ... > 1047 7.6. Interaction with other Filtering Mechanisms in Routers >=20 > [minor] Perhaps: s/other Filtering/Custom Filtering >=20 <-- AUTHORS Tracked via issue #149: = https://github.com/stoffi92/rfc5575bis/issues/149 I think it is fine as it is. --> >=20 > 1049 Implementations SHOULD provide mechanisms that map an = arbitrary BGP > 1050 community value (normal or extended) to Traffic Filtering = Actions > 1051 that require different mappings in different systems in the = network. > 1052 For instance, providing packets with a worse-than-best-effort, = per- > 1053 hop behavior is a functionality that is likely to be = implemented > 1054 differently in different systems and for which no standard = behavior > 1055 is currently known. Rather than attempting to define it here, = this > 1056 can be accomplished by mapping a user-defined community value = to > 1057 platform-/network-specific behavior via user configuration. >=20 > [] Moving this paragraph to its own section is an improvement. >=20 > [major] However, the Normative specification still bothers me because > the text is not specific enough for implementations to > interoperate...which I know is precisely the point (no standard > behavior), so Normative language should not be used. Please > s/SHOULD/should (to take the text back to what rfc5575 says) >=20 <-- AUTHORS Tracked via issue #150: = https://github.com/stoffi92/rfc5575bis/issues/150 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/38e60a0ee0062c43a0e1d392a5c7= 8b99dc8e82b3 Resolved as suggested.=20 --> >=20 > ... > 1080 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks > ... > 1092 The NLRI format for this address family consists of a = fixed-length > 1093 Route Distinguisher field (8 bytes) followed by the Flow > 1094 Specification NLRI value Section 4.2. The NLRI length field = shall > 1095 include both the 8 bytes of the Route Distinguisher as well as = the > 1096 subsequent Flow Specification NLRI value. The resulting = encoding is > 1097 shown in Figure 7. >=20 > [minor] s/Flow Specification NLRI value Section 4.2./Flow > Specification NLRI value (Section 4.2). >=20 <-- AUTHORS Tracked via issue #151: = https://github.com/stoffi92/rfc5575bis/issues/151 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/2acf66c58590fd7ecb525f9d6bb1= fd21d249cfc7 --> >=20 > ... > 1137 10. Error-Handling >=20 > [nit] s/Error-Handling/Error Handling >=20 <-- AUTHORS Tracked via issue #152: = https://github.com/stoffi92/rfc5575bis/issues/152 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/526d5dfe8ad05f58001335dfdf70= e16e893cee8d --> >=20 > 1139 Error handling according to [RFC7606] SHOULD apply to this > 1140 specification. >=20 > [major] rfc7606 already applies...there's no need to Normatively say > it here. And, BTW, then wound it not apply? IOW, why is that > "SHOULD" not a "MUST"? >=20 > NEW (suggestion): Error handling according to [RFC7606] and [RFC4760] > applies to this specification. >=20 <-- AUTHORS Tracked via issue #153: = https://github.com/stoffi92/rfc5575bis/issues/153 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/dc00addc1ae9349a4f07a5136646= c13797005bf4 Changed according to suggestion. However the text may need additional = changes later. --> >=20 > 1142 This document introduces Traffic Filtering Action Extended > 1143 Communities. Malformed Traffic Filtering Action Extended = Communities > 1144 in the sense of [RFC7606] Section 7.14. are Extended Community = values > 1145 that cannot be decoded according to Section 7 of this = document. >=20 > [] Please see my comment (above) in reply to your comments related to > =C2=A74.2 (NLRI Value Encoding). >=20 <-- AUTHORS Tracked via issue #154: = https://github.com/stoffi92/rfc5575bis/issues/154 Related issues mentioned: https://github.com/stoffi92/rfc5575bis/issues/133 https://github.com/stoffi92/rfc5575bis/issues/155 https://github.com/stoffi92/rfc5575bis/issues/153 This seems to be resolved in #133 and #155, #153 --> >=20 > 1147 11. Future NLRI Extensions >=20 > 1149 Future Flow Specification extensions may introduce new Flow > 1150 Specification components. In order to facilitate such = extensions of > 1151 the Flow Specification NLRI, in addition to the cases = described in > 1152 [RFC7606], if BGP encounters an unknown Flow Specification = component > 1153 in an UPDATE message, it SHOULD also treat this message as = Treat-as- > 1154 withdraw as specified in [RFC7606] Section 2. >=20 > [minor] This paragraph describes an error condition, so maybe it = belongs in =C2=A710. >=20 > [major] rfc7606/=C2=A73 reads: >=20 > j. Finally, we observe that in order to use the approach of "treat- > as-withdraw", the entire NLRI field and/or the MP_REACH_NLRI and > MP_UNREACH_NLRI attributes need to be successfully parsed -- what > this entails is discussed in more detail in Section 5. If this > is not possible, the procedures of [RFC4271] and/or [RFC4760] > continue to apply, meaning that the "session reset" approach (or > the "AFI/SAFI disable" approach) MUST be followed. >=20 > If an unknown Flow Specification component exists, then the entire > NLRI cannot be "successfully parsed"...which results in not being able > to use treat-as-withdraw. The text above leaves us with AFI/SAFI > disable, which is not extension-friendly. >=20 >=20 > rfc7606/=C2=A75.4 talks about Typed NLRIs, such as in mVPN/EVPN, and > concludes by saying: >=20 > A BGP speaker advertising support for such a typed address family > MUST handle routes with unrecognized NLRI types within that address > family by discarding them, unless the relevant specification for that > address family specifies otherwise. >=20 > The FS NLRI is not a Typed NLRI in the same sense that the examples > from rfc7606 are: the NLRI encoding starts with "Route Type". But, > because the NLRI is basically a set of components, *with Types*, I > think we could make the case that the FS NLRI is a Typed NLRI and that > the paragraph above applies to it...which would result in being able > to ignore/discard an UPDATE with an unknown component (vs AFI/SAFI > disable). Note that treat-as-withdraw is still not an option. >=20 > To be clear: all this is my personal interpretation/proposal. If you > (authors) want to go with this approach (resulting in the ability to > discard), then we should explicitly bounce it by the WG. If not, then > we can only reset the session or disable FS... >=20 > NEW (suggestion)> > An advertisement containing an unknown Flow Specification component > should be discarded as specified in Section 5.4 of [RFC7606]. >=20 > Additional text would be needed in =C2=A74.2 identifying the FS NLRI = as Typed. >=20 <-- AUTHORS Tracked via issue #155: = https://github.com/stoffi92/rfc5575bis/issues/155 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/b268bc69b1afd18fb471cf3bb1ae= 23216624faae Defining the FS NLRI as "Typed NLRI" according to rfc7606. When decoding = an unknown component type the implementation should discard the NLRI and = skip over to the next NLRI according to section 5.4 rfc7606. Everything = else is Malformed and treated as such. Explained in the beginning of the = Email. --> >=20 > 1156 The specification of a new Flow Specification Component Type = SHOULD > 1157 clearly identify what the criteria used to match packets = forwarded by > 1158 the router is. This criteria should be meaningful across = router hops > 1159 and not depend on values that change hop-by-hop such as TTL or = Layer > 1160 2 encapsulation. >=20 > [major] Only "SHOULD"? I can't imagine a case where it would be ok to > not identify the criteria clearly. s/SHOULD/MUST >=20 <-- AUTHORS Tracked via issue #156: = https://github.com/stoffi92/rfc5575bis/issues/156 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/69fb9dfad2280195395f74034426= 2c58e755e090 Resolved as suggested. --> >=20 > ... > 1192 12.2. Flow Component Definitions > ... > 1222 In order to manage the limited number space and accommodate = several > 1223 usages, the following policies defined by [RFC8126] are used: >=20 > 1225 +--------------+-------------------------------+ > 1226 | Type Values | Policy | > 1227 +--------------+-------------------------------+ > 1228 | 0 | Specification required | > 1229 | [1 .. 12] | Defined by this specification | > 1230 | [13 .. 127] | Specification required | > 1231 | [128 .. 255] | First Come First Served | > 1232 +--------------+-------------------------------+ >=20 > [minor] Consider simply reserving 0. >=20 <-- AUTHORS Tracked via issue #157: = https://github.com/stoffi92/rfc5575bis/issues/157 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/7b4a941c9db69b247c4243126cba= fcb8019c7307 Reserved is fine as well.=20 --> >=20 > ... > 1343 13. Security Considerations > ... > 1357 Deployment of specific relaxations of the validation within an > 1358 administrative boundary of a network, defined by an AS or an = AS- > 1359 Confederation boundary, may be useful in some networks for = quickly > 1360 distributing filters to prevent denial-of-service attacks. = For a > 1361 network to utilize this relaxation, the BGP policies must = support > 1362 additional filtering since the origin AS field is empty. > 1363 Specifications relaxing the validation restrictions SHOULD = contain > 1364 security considerations that provide details on the required > 1365 additional filtering. For example, the use of [RFC6811] to = enhance > 1366 filtering within an AS confederation. >=20 > [major] When would it be ok for a specification to not provide > details? IOW, why is "SHOULD" used and not "MUST"? >=20 <-- AUTHORS Tracked via issue #158: = https://github.com/stoffi92/rfc5575bis/issues/158 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/6df85c513787fba664549a47be93= 922ce4a36237 Resolved as suggested. --> >=20 > ... > 1418 14. Contributors >=20 > 1420 Barry Greene, Pedro Marques, Jared Mauch, Danny McPherson, and > 1421 Nischal Sheth were authors on [RFC5575], and therefore are > 1422 contributing authors on this document. >=20 > [minor] Danny is listed both as a Contributor and as an author of this = document. >=20 <-- AUTHORS Tracked via issue #159: = https://github.com/stoffi92/rfc5575bis/issues/159 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/77b1f01477a1609b3f99ccd2943b= b1c28e54a511 -->= From nobody Mon Jan 20 18:06:14 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD612085F for ; Mon, 20 Jan 2020 18:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxpjQ6fvlsdN for ; Mon, 20 Jan 2020 18:06:06 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3929812004D for ; Mon, 20 Jan 2020 18:06:06 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2B51FF4072C; Mon, 20 Jan 2020 18:05:58 -0800 (PST) To: Jon.Mitchell@microsoft.com, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, jgs@juniper.net, shares@ndzh.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: roufique@rtat.net, idr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200121020558.2B51FF4072C@rfc-editor.org> Date: Mon, 20 Jan 2020 18:05:58 -0800 (PST) Archived-At: Subject: [Idr] [Technical Errata Reported] RFC6996 (5960) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 02:06:11 -0000 The following errata report has been submitted for RFC6996, "Autonomous System (AS) Reservation for Private Use". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5960 -------------------------------------- Type: Technical Reported by: Roufique Hossain Section: RFC6335 Original Text ------------- Corrected Text -------------- Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6996 (draft-ietf-idr-as-private-reservation-05) -------------------------------------- Title : Autonomous System (AS) Reservation for Private Use Publication Date : July 2013 Author(s) : J. Mitchell Category : BEST CURRENT PRACTICE Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jan 20 19:51:48 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6210E120045 for ; Mon, 20 Jan 2020 19:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6WuWMliqp8B for ; Mon, 20 Jan 2020 19:51:40 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFEE12001E for ; Mon, 20 Jan 2020 19:51:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 1028120348A; Mon, 20 Jan 2020 19:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O6sIJ3lqmoA; Mon, 20 Jan 2020 19:49:57 -0800 (PST) Received: from [172.31.98.188] (unknown [96.229.48.220]) by c8a.amsl.com (Postfix) with ESMTPA id B710F203489; Mon, 20 Jan 2020 19:49:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20200121020558.2B51FF4072C@rfc-editor.org> Date: Mon, 20 Jan 2020 19:51:39 -0800 Cc: Jon.Mitchell@microsoft.com, "BRUNGARD, DEBORAH A (ATTLABS)" , Alvaro Retana , "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" , "John G. Scudder" , Susan Hares , idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200121020558.2B51FF4072C@rfc-editor.org> To: RFC System X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Idr] [Technical Errata Reported] RFC6996 (5960) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 03:51:46 -0000 Greetings, FYI - this empty report has been deleted. Thank you. RFC Editor/mf On Jan 20, 2020, at 6:05 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6996, > "Autonomous System (AS) Reservation for Private Use". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5960 >=20 > -------------------------------------- > Type: Technical > Reported by: Roufique Hossain >=20 > Section: RFC6335 >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6996 (draft-ietf-idr-as-private-reservation-05) > -------------------------------------- > Title : Autonomous System (AS) Reservation for Private = Use > Publication Date : July 2013 > Author(s) : J. Mitchell > Category : BEST CURRENT PRACTICE > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 From nobody Tue Jan 21 19:53:09 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017ED12006B for ; Tue, 21 Jan 2020 19:53:08 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arista.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 RXpaX00wnFj0 for ; Tue, 21 Jan 2020 19:53:05 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D622C120044 for ; Tue, 21 Jan 2020 19:53:05 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id l9so4844882oii.5 for ; Tue, 21 Jan 2020 19:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:from:date:message-id:subject:to:cc; bh=440EnO+Rz/QGkPUS39gY8dFdPDx3piTVf5GbXZMShpU=; b=hNyA77x6uU/d78A5N34wTXFpxdjS1ybeyOIBGzAcxLtSBTBe9i+HjHgzHWcti0ATxM YEF6ZGxugLfeegtjaej3iYOyRu5uTsO33TJvWRNvoG/EcKVZp8CuxXKw7hnz9b1YcY+X hjdGCNjICFwYSaT6Hs4yfEhnw/MVbUwekBC5JWmi9JE9OdjymOJEhRJHDN3HdaTPFRcv PbjdeqBUr7TGoLi0LEMTZheoMe65iOnrVr3/VCPOSvBy83udCV99EXLK7QCxBJtcCIGT NRpQyjoMwsjmgqX9BB1O9mubwmKkzKUCRtTNfXUIEqj9EUc391Dbs5bWrFbFe+TNVJDr CetA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=440EnO+Rz/QGkPUS39gY8dFdPDx3piTVf5GbXZMShpU=; b=qUA7B/MliWithgGlQTmY+NtnpUjVBbOaURZXXuII+5qabBqMr1IezYRlEmv8j1C5Y/ 5ZksIqB1aw3cxlLxF4AOnJzrrIuexFZ5dUWjw5q4DhIrIv/0FiQjY/bqK29eSW3nbYRQ RwSELry5mnStufK38JqPADQK1dD8ytQTEt3gbhpMWpssO5QuPvrfZortI7In02MeoWaP VVuijnh+Sj4ol4sfOCQvZ5dGPMzqrkaoPAYnQc7FW2pzr799jd56njV4oZ5RqPfiW6Pk Cx0uxlUb8pnQLJS2qkOGiLV4ZIW+eSSHPLNfBLJzYOAtmcF8tdfjVyAoEixcOXwqSxFd R3EA== X-Gm-Message-State: APjAAAXoAMJknJy5kN6FNtE2vWHw4/zbaEu23sYXN1oIkaS5HVIbXl5d bO237+wWd8/UZ0MempFck7XHAAJz7frk+VkLzwsDFMOeAe/70D1d X-Google-Smtp-Source: APXvYqxpJ0/3hV74+5MXwpDXLKIV2VNMtjaNSiiQebhbsyYCcjV3rTJ/8NhOPSzGR1IK2lC64dj55ieiOJuRegN/Tao= X-Received: by 2002:aca:d507:: with SMTP id m7mr5218776oig.48.1579665184856; Tue, 21 Jan 2020 19:53:04 -0800 (PST) MIME-Version: 1.0 From: Nandan Saha Date: Wed, 22 Jan 2020 09:22:53 +0530 Message-ID: To: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org Cc: Kumaran Narayanan , Hui Qu Content-Type: multipart/alternative; boundary="00000000000035425f059cb27654" Archived-At: Subject: [Idr] Clarifications on Error handling for malformed sub-tlvs in draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 03:53:08 -0000 --00000000000035425f059cb27654 Content-Type: text/plain; charset="UTF-8" Hi folks, In the following quoted text, >>> If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that is not recognized by a particular BGP speaker, the BGP speaker MUST process that TLV as if the unrecognized sub-TLV had not been present. If the route carrying the Tunnel Encapsulation attribute is propagated with the attribute, the unrecognized TLV MUST remain in the attribute <<< instead of "unrecognized TLV MUST remain" in the last part of the sentence, shouldn't it be "unrecognized sub-TLV" (sub-TLV instead of TLV), since the context is how to handle unrecognized sub-TLVs? (or something like "unrecognized sub-TLV MUST remain in the TLV") The same text is referred to for how to deal with malformed sub-TLVs, ie. >>> In general, if a TLV contains a sub-TLV that is malformed (e.g., contains a length field whose value is not legal for that sub-TLV), the sub-TLV should be treated as if it were an unrecognized sub-TLV <<< Just want to confirm that the intention is to propagate the malformed sub-TLV(s). I'm not entirely sure how that's useful though (as opposed to stripping away just the malformed sub-TLV(s) from the TLV before propagation) Thanks, Nandan --00000000000035425f059cb27654 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

In the followi= ng quoted text,
>>>
If a TLV of = a Tunnel Encapsulation attribute contains a sub-TLV that
=C2=A0 =C2=A0= is not recognized by a particular BGP speaker, the BGP speaker MUST
=C2= =A0 =C2=A0process that TLV as if the unrecognized sub-TLV had not been pres= ent.
=C2=A0 =C2=A0If the route carrying the Tunnel Encapsulation attribu= te is
=C2=A0 =C2=A0propagated with the attribute, the unrecognized TLV M= UST remain in
=C2=A0 =C2=A0the attribute
<<<

instead of "unrecognized TLV MUST remain&q= uot; in the last part of the sentence, shouldn't it be "unrecogniz= ed sub-TLV" (sub-TLV instead of TLV), since the context is how to hand= le unrecognized sub-TLVs? (or something like "unrecognized sub-TLV MUS= T remain in the TLV")

The same text is re= ferred to for how to deal with malformed sub-TLVs, ie.
>>&g= t;
In general, if a TLV contains a sub-TLV that is malformed = (e.g.,
=C2=A0 =C2=A0contains a length field whose value is not legal for= that sub-TLV),
=C2=A0 =C2=A0the sub-TLV should be treated as if it were= an unrecognized sub-TLV
<<<

Just want to confirm that the intention is to propagate the malformed sub= -TLV(s). I'm not entirely sure how that's useful though (as opposed= to stripping away just the malformed sub-TLV(s) from the TLV before propag= ation)

Thanks,
Nandan
--00000000000035425f059cb27654-- From nobody Thu Jan 23 06:52:42 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2B91200DE; Thu, 23 Jan 2020 06:52:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 kWwCCNg0Nj6r; Thu, 23 Jan 2020 06:52:38 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 C032112004D; Thu, 23 Jan 2020 06:52:37 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id m8so3506426edi.13; Thu, 23 Jan 2020 06:52:37 -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:content-transfer-encoding; bh=TYdinNzlrNHsKi4wxiyrZQSyb7QidNiFjNiSDoOqxVQ=; b=UmlxR2MOcg7XvEgPJMfzmeU8FQYP8QDhqBA7pIcSM+oEZ5HoXymaJmUXd3qYiFcFzM danD8JuSnAdGKlPUp8CL9s3QpTkIe4XcgflzcSPQ9uhZDNa7u2/XB1+w+ILeXojhOdNl KTxwZO1kdvaL4zjHpYvwpq5JOByjbeH3C9sGPXQdQVZnsVoJ+wW5Kp32r317RzGZz+vT xmptyajr2GK44NkToEyCj1Sc8/QLtDIpsBN0rinT0TuFYLQ6ZV+CxUuhp4mSsFe3iMqC /6OW1KAEpJtbut7LoSgFuMSTQaUKWTCXEkgAlDMhJiWGYGi8CeXGL4qnIg7Fv9YAM2dn XKCA== 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:content-transfer-encoding; bh=TYdinNzlrNHsKi4wxiyrZQSyb7QidNiFjNiSDoOqxVQ=; b=YKh+rAOCXhcPInUj1aClO13LHXZPk3HZBFlybBNcMotvpxEbWPzM5/hOe6qKgizSUu uPRU1e6auGq+36ILCajf3noJVsSg/cGJrELhTCX1bvTF+RmObNWurpyzxoVXuEMyUevW wKFwygjG6dnhlYMnltv2RjlGqrJRY173197rBC8RG2Ra9syGlyOyF3s66W383fDA8KQJ MEl3MsJ3j3K0W6yJ6xcTqvosUqxbkUxS/yaW1HlQ+1ZeU3oin+ZSo730264iMFwwBFVY oz6dBkivnrVHjCc/ZQQXFOhb2RHKimnp2FwgfSR2jBEda/nHxr1Z1gfqka3aL4IN6gQw MU8g== X-Gm-Message-State: APjAAAXxp7Sl7iy9HEOZuH4OpOjtGiKT3430+bxA/N49MyFypbeoK5eS U0iqN+8g7YMPAxjf87bl4hTRShcZn4gRryas1Sw= X-Google-Smtp-Source: APXvYqyj+QVO46PGXhuOn2aoP2Dhm/AhfM/KsC2By/2T4661UaicUDQzOIC5Jn6Ko6xpKqndTJBp2+FbuJcWYVFqKgk= X-Received: by 2002:a17:906:b855:: with SMTP id ga21mr6962467ejb.186.1579791156167; Thu, 23 Jan 2020 06:52:36 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 23 Jan 2020 15:52:35 +0100 From: Alvaro Retana In-Reply-To: <188DFC4F-7A19-433F-AD3A-A2CC961774B0@tix.at> References: <188DFC4F-7A19-433F-AD3A-A2CC961774B0@tix.at> MIME-Version: 1.0 Date: Thu, 23 Jan 2020 15:52:35 +0100 Message-ID: To: Christoph Loibl , John Scudder Cc: idr-chairs@ietf.org, draft-ietf-idr-rfc5575bis@ietf.org, "Dongjie (Jimmy)" , "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 -> Updated Version -18 and Flowspec v6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 14:52:40 -0000 On January 17, 2020 at 3:55:14 AM, Christoph Loibl wrote: Christoph: Hi! > > On 12.12.2019, at 20:38, Alvaro Retana wrote: ... > > There is only one significant item remaining that we should resolve > > before moving the document forward: the handling of unknown > > components; take a look at the comments in =C2=A711 (of -18). > > > > Thanks! > > This issue has been discussed before Christmas on the mailinglist. The ma= in > points in that discussion were that we do not want to propagate any garba= ge, > while allowing a certain degree of extensibility of the NLRI (given the z= oo > of FS drafts and expected AFI/SAFI pollution out there this seems to be > reasonable - extension Authors may still choose how they extend the NLRI = this > is not specified in this draft) and keep backwards compatibility. > > In this context Alvaro pointed out that the behaviour explained in the dr= aft > fits closely RFC7606 Section 5.4 (Typed NLRI) and Jeffrey explained that > walking NLRIs may lead to synchronisation issues between a buggy FS sende= r > and a receiver. > > The document that we now uploaded clearly references RFC7606 Typed NLRI a= s > the mechanism to treat unknown FS components and to allow the receiver to > skip over (and discard) a single NLRI if it hits an unknown component typ= e > (previously the very same behaviour was explained in the draft without > referencing RFC7606). We also added a paragraph to the security > considerations section to explain that RFC7606 Section 5.4 allows to skip > (and discard) *unknown* octets and carefully crafted/misbehaving BGP spea= kers > may exploit that fact. I think I was advocating for discarding the whole UPDATE, not a single NLRI. =C2=A0But, re-reading what I wrote, maybe I was not clear. I don't think Jeff liked the Typed NLRI approach. I am ok with the current text -- I think I understand the risks that Jeff is pointing out. However, I cannot call consensus on my own suggestion, specially based on having only 3 people speaking up, with 2-3 different approaches. WG Chairs (John): Please start a separate thread (not everyone reads "AD reviews") to poll the WG on this item. =C2=A0This shouldn't be a long discussion (1 week should be enough), but if should also be long enough to get some thoughts/discussion. Note that the result also affects the treatment of out of order or duplicate components. Once the Chairs call consensus we'll be ready to go. =C2=A0I put a couple of no-action-needed comments below just to close loops. Thanks!! Alvaro. ... > > > > 742 6. Validation Procedure ... > > I'm still not happy with the contradiction: MUST means "an absolute > > requirement" (no exceptions!), but then we say MAY, which makes the > > MUST optional...even with the "by default"... Please s/MUST/SHOULD > > The MAY will then explain the "valid reason" to not... > > > > <-- AUTHORS > Tracked via issue #135: https://github.com/stoffi92/rfc5575bis/issues/135 > > The point to stress out is that the "default" behaviour MUST be "validate= " > according to the spec. Not the default can be changed but the "validation= " > MAY be relaxed by configuration. > --> Needless to say, I'm still not happy as there was no change. =C2=A0But I'm ok with letting go -- and dealing with comments later in the process, if any. :-) ... > > > > The reason/history doesn't matter anymore, but the current use does= . The > > > > mechanism described in this document is clearly not experimental. G= iven > > > > that changing the Type values is not an option because of the deplo= yed > > > > base, etc.., then I think we should clean up the Registry and move > > > > 0x80-0x82 from the Experimental Use range to the FCFS range. This > > > > change would mean an Update to rfc7153. > > [..] > > > > <-- *** Authors *** > > > Tracked via issue #99: https://github.com/stoffi92/rfc5575bis/issues/= 99 > > > > > > This is not to be solved within this document. I note that I should > > > propose a update to RFC7153 to cleanup the registry independently. - = As > > > noticed moving the values around is not an option. > > > --> > > > > So, are you working on this already? ;-) > > > > <-- AUTHORS > Tracked via issue #138: https://github.com/stoffi92/rfc5575bis/issues/138 > > Seriously. IF the only thing that is needed here is a IANA considerations > draft I will look into this later. If this can be done easier. I think af= ter > the 5575bis changes have been made in the registry. There is a good chanc= e to > have this cleaned up. > > --> Independent of this document... =C2=A0Yes, all we need is an IANA considerations draft. =C2=A0If you will look into it, that would be great. If not, then let me know and I'll take care of it. ;-) From nobody Tue Jan 28 03:38:12 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83A3120018; Tue, 28 Jan 2020 03:38:09 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=CMMXZb1h; dkim=pass (1024-bit key) header.d=juniper.net header.b=Dd7JHVxn 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 X4lXymKjGzRy; Tue, 28 Jan 2020 03:38:08 -0800 (PST) Received: from mx0b-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 459DF120013; Tue, 28 Jan 2020 03:38:08 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00SBbI1V010551; Tue, 28 Jan 2020 03:38:07 -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 : mime-version; s=PPS1017; bh=YdL3+VPkdBGHL09YlE9mZzo+QmaQUVStAI+11sgIC/o=; b=CMMXZb1hhoveFfqlMOmanbFfmYibfKvB8HZ9lT8jaHaKCDhDED8ufxsCEW4xNgoia0ej jICXajnozUEqMTXsQch5ikN2cAdP4Fq6hnacOmTFPvoQFgSHqRnIWT4uqR1IkF71Mqfg Iq7ZHt5B+1tB+IpAplqI4Gr3hbjL0sifFOjMc9LsSU+PQXlfXOLOhknMbgZCWGi6QAkW Seh2HtxgwqKvIsEzLLEhWTmoj0U8AAmpgsG1zFlysj6riEUUYU1v5YV7Wi9+rejiGMv9 cTTmLZErJAyvR5gg5bYFpB06/LQZZ/lrc/prMCuJ+Gq3xYBtyAu/Wwn54+/uVRhU6Yxh nw== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) by mx0a-00273201.pphosted.com with ESMTP id 2xrnttcuug-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jan 2020 03:38:07 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OS67nffpYtNRFukUhmIxC+CKXT9fyWAcblgCFJRjLCq+fUEv1ThVf+fZKV4pkkOBSXxGStLEwllwD7JTPBmZk2ruygEgdOAKEAX/MhYtbL+NBGaphxRaUtRK2zCaJRNIP4qsv4afjsUY0bYVU3jvlOa574xgiGdlprsLwkG3iM8OMXHs54osSHTHg8U8t6hmfe5pCFDVIqhbxEBILhqfI9fz3Fb76fwgmuKjHTlzmLGUPKK273dsn1dkkh6K+Fj6cFk8aX/YMjH0LruXqR+w37Z2mWQ/5MqUAQGB3dDxUNnC1ZcuHFMYM32/Hvm0CcwcCB6WFvSbNBXQJFKdgRFn0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YdL3+VPkdBGHL09YlE9mZzo+QmaQUVStAI+11sgIC/o=; b=D/ugAvvn+lXxdOMDSUu6GBp7fJWihtFWyNOHR93ZY6DuQP/AGuFjYSKVd9Jc2uf/qet8xYjgRWtXnKdN6rcEo7WpCXL5impDfFvkRRie3Poq3jHEGGcRal/QTnpw6q8UxstF/Fhzi2mIZjw29MNG/N5/3ah7ExaEv4XJQ5UhzNcAZLNri/xMbmZ2YSronOAI+FZeTcOndX3ic6LiYDnG6XfhsdpbFBYQkfWyHaAnsAEbZtF7TUdo6Q1rU7tm97LZmCub2vnxNafoGwoMNVnr5tz3R2FPR8C/7MXOAFdrL4QKr8zkxSr2c1R4Y5TFP4yQi1qjBy4YdDBmSXwiq+zpwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YdL3+VPkdBGHL09YlE9mZzo+QmaQUVStAI+11sgIC/o=; b=Dd7JHVxnM+FO3lS7ZgaeYJ1briCf/nXZOtkcRyohOBr6RYOnV+Hb3N/2+CJMjOSI5KU6HUswqeo1qvqB0uVRfUqeCL4YVcE3qCtQ56luume4bQd0cvjmktPR6+9js4P/VoZQuby9PRp1EWHrvuM4m7z1Nlc2+SLhDy1HOXWFhxs= Received: from BYAPR05MB6230.namprd05.prod.outlook.com (20.178.55.215) by BYAPR05MB5560.namprd05.prod.outlook.com (20.177.186.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.15; Tue, 28 Jan 2020 11:38:04 +0000 Received: from BYAPR05MB6230.namprd05.prod.outlook.com ([fe80::2817:f5de:b518:dacb]) by BYAPR05MB6230.namprd05.prod.outlook.com ([fe80::2817:f5de:b518:dacb%3]) with mapi id 15.20.2686.019; Tue, 28 Jan 2020 11:38:04 +0000 From: Srihari Sangli To: Nandan Saha , "idr@ietf.org" , "draft-ietf-idr-tunnel-encaps@ietf.org" CC: Kumaran Narayanan , Hui Qu Thread-Topic: Clarifications on Error handling for malformed sub-tlvs in draft-ietf-idr-tunnel-encaps Thread-Index: AQHV0Nd5utExhRV7HUyfftzZnXaP/6f/zSoAgACMIwA= Date: Tue, 28 Jan 2020 11:38:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Name=Juniper Business Use Only; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ContentBits=0; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Method=Standard; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ActionId=e5936776-12b5-4b3d-86e7-00000f2c70ce; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SetDate=2020-01-28T11:31:16Z; x-originating-ip: [116.197.184.13] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 25c9c23e-7524-42ca-f584-08d7a3e689da x-ms-traffictypediagnostic: BYAPR05MB5560: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:989; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(376002)(136003)(346002)(39860400002)(396003)(189003)(199004)(2616005)(71200400001)(478600001)(54906003)(86362001)(2906002)(5660300002)(36756003)(6512007)(110136005)(6486002)(91956017)(76116006)(66446008)(64756008)(66476007)(66556008)(8936002)(66946007)(4744005)(8676002)(81166006)(81156014)(316002)(6506007)(26005)(33656002)(186003)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5560; H:BYAPR05MB6230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: L4euvNOawqk0heGvNxRmkWiG0SpOA+8kcKykpKyzy2nDLxGUY4jkqaTmN4LbfxvceQKvCE4qmBnmXM+eAUm3hlg/vAXVLuqdaDGrQCfS5obTluazVp3gcbuhb72ZeEh0XzJERVPsw1u19ONDaNU8vUY6Twxq9H2iq+/oB3gLZHClzTal+SrR3sgUiB9wJFDRut7ovjKZ42xQPtdDgDiyUich3IZKsTJOoEv/L6OJ6CqTi0PaxA5ec2tTyN7JTiWrO2E4+42AFBZCs4QxcZe46BePeVSb6e9KFBKwpfLNoiG6HYJxSypcp79z/ga2XvVBLHGPSJqZZwHUdeEbkbluz+bE2V1wexm0kre0948sIeMZxGF8hqd3/OLm5qXm0oWruMCdFu4FZKc96cETzT9G6CoR3eAUJ4MAzp9qrCytnHqbCYDeG5sT+EtlrDxkQ0xd x-ms-exchange-antispam-messagedata: KglUgG5hOLTSLIgxDftJvgxg08dksjBiSFdeRW7JpZmLFMTjJXJfZ9E6cIqW+1zB+zJuvOxY6NMOn4KjiJMkJpd+phdowqhWY5TEiJJlek4KSMUMmME9ugM0Oz0qmI7dBlZNt15dQXH0q+P6xD/fkg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AD5596CBDF8241D3B0DE11B642319998junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 25c9c23e-7524-42ca-f584-08d7a3e689da X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 11:38:04.5439 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CSC8aXOf7TS0uoxCzzLHVehnD6meYp4b495ShbP+4+MV5H90Ordq/DC3LmcqDks4JufHFJFGaU1qgoBiey73BA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5560 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-28_03:2020-01-24, 2020-01-28 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 spamscore=0 clxscore=1011 suspectscore=0 impostorscore=0 mlxscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=802 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2001280094 Archived-At: Subject: Re: [Idr] Clarifications on Error handling for malformed sub-tlvs in draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 11:38:10 -0000 --_000_AD5596CBDF8241D3B0DE11B642319998junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpKdXN0IHdhbnQgdG8gY29uZmlybSB0aGF0IHRoZSBpbnRlbnRpb24gaXMgdG8gcHJvcGFnYXRl IHRoZSBtYWxmb3JtZWQgc3ViLVRMVihzKS4gSSdtIG5vdCBlbnRpcmVseSBzdXJlIGhvdyB0aGF0 J3MgdXNlZnVsIHRob3VnaCAoYXMgb3Bwb3NlZCB0byBzdHJpcHBpbmcgYXdheSBqdXN0IHRoZSBt YWxmb3JtZWQgc3ViLVRMVihzKSBmcm9tIHRoZSBUTFYgYmVmb3JlIHByb3BhZ2F0aW9uKQ0KDQpZ ZXMsIHRoZSBpbnRlbnRpb24gaXMgdG8gbWFpbnRhaW4gdGhlIGVudGlyZSBUTFYgaW50YWN0IGFu ZCBub3QgZHJvcCB0aGUgdW5yZWNvZ25pemVkIHN1Yi1UTFZzLg0KDQpzcmloYXJp4oCmDQo= --_000_AD5596CBDF8241D3B0DE11B642319998junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <80AD2809DF13BD40B145D59E4742D7D0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50 Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUlOIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 NDcuNTVwdCI+SnVzdCB3YW50IHRvIGNvbmZpcm0gdGhhdCB0aGUgaW50ZW50aW9uIGlzIHRvIHBy b3BhZ2F0ZSB0aGUgbWFsZm9ybWVkIHN1Yi1UTFYocykuIEknbSBub3QgZW50aXJlbHkgc3VyZSBo b3cgdGhhdCdzIHVzZWZ1bCB0aG91Z2ggKGFzIG9wcG9zZWQgdG8gc3RyaXBwaW5nIGF3YXkganVz dCB0aGUgbWFsZm9ybWVkIHN1Yi1UTFYocykgZnJvbSB0aGUgVExWIGJlZm9yZQ0KIHByb3BhZ2F0 aW9uKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoZSBpbnRlbnRpb24gaXMgdG8gbWFp bnRhaW4gdGhlIGVudGlyZSBUTFYgaW50YWN0IGFuZCBub3QgZHJvcCB0aGUgdW5yZWNvZ25pemVk IHN1Yi1UTFZzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNyaWhhcmnigKY8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AD5596CBDF8241D3B0DE11B642319998junipernet_-- From nobody Wed Jan 29 11:08:22 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66ED5120910 for ; Wed, 29 Jan 2020 11:08:21 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 header.b=LZt0h9rm; dkim=pass (1024-bit key) header.d=juniper.net header.b=b7sUH64Z 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 cVXQNRuOIwIz for ; Wed, 29 Jan 2020 11:08:18 -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 07E2A1208FE for ; Wed, 29 Jan 2020 11:08:17 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00TIv15U014681 for ; Wed, 29 Jan 2020 11:08:17 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=PfGkcHi3vNnlpcMvYDQNi+BhJYmpeIVrsygeYz5xXAA=; b=LZt0h9rm+Bbl+BqlqTxPhAK4w0JC723PT+5KpJcG67QJWp2zXzqXGfKVF836vI9WYe2+ g5O2ys2F4t+8oIwmca3f3pU6u3n6Qq5Noa7JT1ZMy5wtSmrgtgnsjf9tJKB8hcQKmbXY VooUvJKDVO5/ULeH8Z1i7CBVo8Yvqk9C8pHDxf5V3SmUfgqEqE35y22x3+cFjXXYCxih s+WWZD7lNvD77kiXbqGvnzGVL84zc2He69wzAtNQoeThRSrTLy8Ybr1jtktNNB2ccO56 fJkwJHYy3zABkfcOdvaj0E5HRvCv1i35nd/OTsWjt/hWj5kJ7gYYxZsJlNNBmtSsTnnu +g== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2058.outbound.protection.outlook.com [104.47.45.58]) by mx0a-00273201.pphosted.com with ESMTP id 2xrmh3yrvx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 29 Jan 2020 11:08:17 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EWbMPX7+KuGlLky2ZpvX9G/Fs+orF2i0HmmSb2W5nseqSvyLuD1L/aF95yZJAno9vycHWMyIowonuWPhazKZoHmdMq1hYtQbaNIhS/NRhv8AjSvh8X5qNPSlJxEVQjPeHBhhgbUf/9/PSd8YePc9kd9iy/T3Rvo7rNWDncT5h5SC8fS8K9C9qUIQ32xRj5JK4uUhhww4esgiXreL0xNMuSMW7fgMgvB6ySSP9+ODxuFSxt5HsAGHBKyqWT9oHQOXvyBOUSSWOG0Yoz7r+ZPuqwWvmWDcNJmaDTbWSWazeJoL/msEFNWwExx1deVDm1UcsTXn3D056J6SR+bdD1iWvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PfGkcHi3vNnlpcMvYDQNi+BhJYmpeIVrsygeYz5xXAA=; b=dc+Kqc2vjVhXlRC3FzWr+YZD81jmd/CaHNQHMdMo2qnKxr5YrJy69KJDqaiUAp/YMVHAD4Q99LxnIN1Rd7eaVdJitXpvCZW4kfcR9r8hE0JrsAvuxxJPo5S5VAg9RVpwGsjgRMDVSO/P7ciq8J+mdYpxVDgmwhin7T+pryBx7PXErdMU4xCZUpuncE/hY+LO/CC9OZwj2nVjKwyXfdcg2v3Kz+u84Xhx+TWiExyZWLf/X3NjD/OWOz14CvdZuYtu6Twn4450s+56rcpNZf9llHJQ3WM+mTkQyZqw0UEuemNSvlQs6nCGiUzMikBvs387WTns2BBUbXFGLjcNgMgFoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PfGkcHi3vNnlpcMvYDQNi+BhJYmpeIVrsygeYz5xXAA=; b=b7sUH64ZBkk5J4rW4N8ekiksIHTPT/rzawGDwFd62WbKVdwJ9gNHHq7vJaCgPgm8+39wt/qG8foBkQpTrBtuNyp9vX7an6Y2AcH5jP6S3Z5h1T+oh0bZLl/fkWZhSLO1qBLG5U8NcuGfEh+PDuxqbtCaRDscFcNlJqnw7spkot8= Received: from BL0PR05MB5076.namprd05.prod.outlook.com (20.177.240.204) by BL0PR05MB5265.namprd05.prod.outlook.com (20.177.207.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.14; Wed, 29 Jan 2020 19:08:07 +0000 Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::61df:edf5:70d1:4614]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::61df:edf5:70d1:4614%3]) with mapi id 15.20.2686.025; Wed, 29 Jan 2020 19:08:07 +0000 From: John Scudder To: "idr@ietf.org" Thread-Topic: BGP Autoconf design team Thread-Index: AQHV1tdwlyuFEfI9XkePfAQYyKr34w== Date: Wed, 29 Jan 2020 19:08:07 +0000 Message-ID: <9A90AA32-BF4C-405A-969D-A176DDDDDE72@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2600:1700:37a0:3ca0:48ff:fb52:a483:74bf] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 01c049a6-54b5-4ad8-ad52-08d7a4ee9321 x-ms-traffictypediagnostic: BL0PR05MB5265: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(346002)(39860400002)(366004)(376002)(136003)(189003)(199004)(86362001)(6506007)(6916009)(186003)(5660300002)(3480700007)(8936002)(64756008)(81166006)(71200400001)(66556008)(33656002)(81156014)(66476007)(66446008)(8676002)(91956017)(66946007)(76116006)(6512007)(6486002)(966005)(36756003)(2616005)(316002)(478600001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR05MB5265; H:BL0PR05MB5076.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vFjWU/Ya2g4zkVddZMQcwMOi2LbLuyr20kEXOpjJDkKKhQFhq29tSCYkxtrpiDEV6gS+bP1px9/bMX/fd8EiNScrN8ogebOgOufsf4DdL+qlRF8vzhfbOTXF7ah6DwdAEdrS65+0jlltamp5jPmjWFGszwlNuZj8eZ6MYB+MufPHZ4ZTO57HcWZgGJGDbAeScwpL4ippDb/p5voAGHayUS6b3t7zICZcxQIv3z9eHZMgaHR/uBE+sMw7VakUyOkyCOxnTU+Qaq03mdb/z4QqH1qDtmG2yaMvuoU+mTFNuMJaBBlg+BApwo5HxGNnQXZhTQ9tbSooCqhL3lP5oWxh2pZYi+MG8HAoDtRjXS1bL0ya0uKxUip5537C5cvYWZrVBj9YzLhZRWYsWFd1ZyDpYsU4d8rLyC25cfoUrBTl1ElUIzugvE4JgeqM2paDC5VNQAJUiWfu+JflONgXDeuKV8ixvOgNvm7ByLoZtxh9ukiUqILBjpqwy5cgG6TMRD6UNBEApy8P4dGljgvREmCH7g== x-ms-exchange-antispam-messagedata: e1Cbuev2RjWVfzreCMelp92eiHXGbsxOSseeN6frUfPM2Efy0l21nEhk0OvLsgczjmjg/EmBDRerUay9jyewUgA3p2k8ldtmTWuwWcuEExUnpqmFQQP1z3jXya8y/OPv1gq9D8sq64caOdsrVSGqbrv0DshOEwkfUFnX4jKsRvgVua8qqgKEEZJtlJzXXGgKpFrOQRUi960VCt5ESZvZ+Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 01c049a6-54b5-4ad8-ad52-08d7a4ee9321 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 19:08:07.2025 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BcuYL6uk2K4uLYbNQYGky0GtqCm1kxRHL/ugZ+E5WVcMpvQDmu2xWVo2DXkFwvHI X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5265 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-29_05:2020-01-28, 2020-01-29 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 mlxscore=0 bulkscore=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 impostorscore=0 clxscore=1031 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2001290151 Archived-At: Subject: [Idr] BGP Autoconf design team X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 19:08:21 -0000 SGkgRXZlcnlvbmUsDQoNCkFmdGVyIHNvbWUgZGVsYXkgOi0oIHdlIGhhdmUgYSBkZXNpZ24gdGVh bSB0byBhbm5vdW5jZS4gVGhlIHRlYW0gaXMgaW5pdGlhbGx5IGNoYXJ0ZXJlZCB0byBjb25zaWRl ciByZXF1aXJlbWVudHMgYW5kIHJldmlldyB0aGUgc29sdXRpb24gc3BhY2UgKG5vdGFibHkgaW5j bHVkaW5nIGV4aXN0aW5nIHByb3Bvc2FscykuIA0KDQpIZXJlIGFyZSB0aGUgSUVTRyBndWlkZWxp bmVzIG9uIGRlc2lnbiB0ZWFtczogaHR0cHM6Ly9pZXRmLm9yZy9hYm91dC9ncm91cHMvaWVzZy9z dGF0ZW1lbnRzL2Rlc2lnbi10ZWFtcy8gLiBXZSBwbGFuIHRvIHN0aWNrIHRvIHRoZXNlIGd1aWRl bGluZXMuIFRoZXnigJlyZSBzaG9ydCwgeW91IGNhbiBqdXN0IHJlYWQgdGhlbSwgYnV0IGhlcmXi gJlzIG9uZSBleGNlcnB0IHRoYXQgYWRkcmVzc2VzIHRoZSBtb3N0IGNvbW1vbiBjb25jZXJuOiAi VGhlIGtleSBwb2ludCBoZXJlIGlzIHRoYXQgdGhlIG91dHB1dCBvZiBhIGRlc2lnbiB0ZWFtIGlz IGlucHV0IHRvIGEgd29ya2luZyBncm91cCwgbm90IGEgZmluYWwgZG9jdW1lbnQuIFN1Y2ggYSBk b2N1bWVudCBtdXN0IG5vdCBiZSBjb25zaWRlcmVkIGFzIG1vcmUgaW1wb3J0YW50IHRoYW4gYW55 IG90aGVyIGlucHV0IHRvIHRoZSB3b3JraW5nIGdyb3VwLuKAnQ0KDQpXaGF0IHdlIHdvdWxkIGxp a2UgZnJvbSB0aGUgZGVzaWduIHRlYW0gaXMgcHJvcG9zZWQgcmVxdWlyZW1lbnRzIGFuZCBzb2x1 dGlvbiBzcGFjZSBvdXRsaW5lIHRvIGd1aWRlIG91ciBkaXNjdXNzaW9uIGFzIGEgV0cgaW4gcHJv ZHVjaW5nIGEgc29sdXRpb24gKHdoaWNoIHdpbGwgbGlrZWx5IGluY2x1ZGUgb25lIG9yIG1vcmUg aW50ZXJpbSBtZWV0aW5ncykuIFRoZSBkZXNpZ24gdGVhbSBpc27igJl0IGZvcmJpZGRlbiBmcm9t IHN1Z2dlc3RpbmcgYSBzb2x1dGlvbiwgYnV0IGl04oCZcyBub3Qgb25lIG9mIG91ciBzcGVjaWZp YyByZXF1ZXN0cyB0byB0aGVtLg0KDQpXZSBoYWQgbWFueSB2b2x1bnRlZXJzIGZvciB0aGUgdGVh bSwgdGhhbmtzIHRvIGFsbCBvZiB5b3UgZm9yIHZvbHVudGVlcmluZyBhbmQgaWYgeW914oCZcmUg bm90IG9uIHRoZSB0ZWFtLCBicmVhdGhlIGEgc2lnaCBvZiByZWxpZWYgOi0pIGFuZCBiZSByZWFk eSB0byBqdW1wIGluIHRvIHRoZSBuZXh0IHN0ZXAuDQoNCkppZSBEb25nIGhhcyBhZ3JlZWQgdG8g Y2hhaXIgdGhlIGdyb3VwLCB0aGFua3MgSmllLiBXZeKAmXZlIGNyZWF0ZWQgYSBtYWlsaW5nIGxp c3QsIGJncC1hdXRvY29uZiwgZm9yIHRoZSBsaXN0IG1lbWJlcnMgdG8gdXNlIGZvciBkaXNjdXNz aW9uIGFtb25nc3QgdGhlbXNlbHZlcy4gTWFpbGluZyBsaXN0IGFyY2hpdmUgY2FuIGJlIGZvdW5k IGF0IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2UvYmdwLWF1dG9jb25m Lw0KDQpHcm91cCBtZW1iZXJzIGFyZToNCg0KUmFuZHkgQnVzaA0KSmllIERvbmcNCkplZmYgSGFh cw0KV2FycmVuIEt1bWFyaQ0KQWNlZSBMaW5kZW0NCk1hbmthbWFuYSBNaXNocmENClJvYmVydCBS YXN6dWsNCkplZmYgVGFudHN1cmENClhpYW9odSBYdQ0KDQpUaGFua3MsDQoNCuKAlEpvaG4=