Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 19 March 2021 01:13 UTC

Return-Path: <jheitz@cisco.com>
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 C5E063A1146 for <idr@ietfa.amsl.com>; Thu, 18 Mar 2021 18:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.618
X-Spam-Level:
X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ck5A2CVm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wjzDS6nW
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 a2c4p0zrIitV for <idr@ietfa.amsl.com>; Thu, 18 Mar 2021 18:13:12 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB293A1145 for <idr@ietf.org>; Thu, 18 Mar 2021 18:13:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=125736; q=dns/txt; s=iport; t=1616116392; x=1617325992; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MvmcqffwVhWK+O9KS26b+fTUX3swe/yv6Hk4ISQnhvo=; b=ck5A2CVmx7kElok5xRgryNqL3D9GUr21kBZ/ouK9/uOLoHr6/GjPxT4u q2BlKZ/NpTYwIJKF6xlpgigl+ZgivywSkhsYfwcXc8A+gJXyI/G88hAyS 3teR+BoTiKSsapVZc1mxWDSptXanscASKypWSac4gGeY5n1txEGKFWFnF I=;
X-IPAS-Result: A0AKBQBB+lNgkJhdJa1QBwMeAQELEgyDMzAjBih9WjYxhEKDSAOFOYhFA4EJiSGEeIoOgUKBEQNPBQsBAQENAQEdAQwIAgQBAYRQAheBYgIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQGGCwcmDYZEAQEBBAEBGAECBgoTAQEsCwEPAgEIBwcDBAEBFgsBBgMCAgIfBgsUCQgCBA4FCAwHglUBgX5XAy8BDqBiAooed4EygwQBAQaBMwEDAg5BgnwNC4ITCYEiF4J2hAcBAYEMhTgmHIFJQoERQ4FaSTU+gh5CAQECARV/EgEHCwEDDxEVCgwJCAEIgk8XHoIrgU8JAQIOVAcGAQEFNwIkAQMYGRIOAQEFGw8ZEwIWAREMBwgiAhkBJAEDKwsEJBCQHwRTgn6HVIdxhH6QfFsKgwSJUocSTYVugjqDGYNEimWWCZMFhASHO4IPgxGNdYEzFIREAgQCBAUCDgEBBoFrITswcHAVO4IBaAlHFwINhyGGXCIHAgMNCRRtAQ6CPYRZO4VFcwI2AgYBCQEBAwl8jDyCQwEB
IronPort-PHdr: A9a23:bOX0EB8REntHv/9uWNHoyV9lXQAupqn0MwgJ65Eul7NJdOG58o//O FDEjd1iiVbIWcPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWlcDjtlehA0vBsOJSCiZZP7nZiA3B oJOAVli+XzoPk1cGcK4bFrX8TW+6DcIEUD5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3e R63tg7W8MIRhNgKFw==
IronPort-HdrOrdr: A9a23:n88MBKhi9NPGcXQPbgpY6dqlyHBQX4hx3DAbvn1ZSRFFG/Gwv/ uF2NwGyB75jysQUnk8mdaGfJKNW2/Y6IQd2+gsFJ+Ydk3DtHGzJI9vqbHjzTrpBjHk+odmu5 tIW5NVTOf9BV0St6nHySGzGdo43Z2j+Kenme/Rwx5WPH5XQotLhj0JbTqzOEtwWQVAGN4dHJ 2T+sJIq1ObCAoqR+68AWQIWPWGms3TmPvdEFA7LjMEyC3LtzOn77bmDwOVty1/bxpjyaovmF K16DDRyb6kt5iAu3rh/k/Vq69bgd7wjuZEbfb89vQ9DhXJpkKWaJ96W7uE1QpF4d2HzFoxit HDr1MBEq1ImgnsV1q4qxfsxAXsuQxGgxSJpDPo4gqAneXDSD03EMZHj45CGyGplnYIhs1206 5AwguixvxqJC7Ahyj06pzpUBxnhyOP0AIfuNMTlHBWXM8ibqZQp+UkjTpoOaoHdRiKjLwPIa 1LNoXx9fxWeVSVYzTypW902uGhWXw1A1OvXlUCktb96UkXoFlJi28jgOAPlHYJ85wwD7Ne4f 7fD6hunLZSCucLcKNGAvsbS8ffMB2PfTv8dEapZXj3HqAOPHzA77Tt5q8u2e2scJsUiLw/hY rGS1EdkWIpYUrhBYmv0fRwg1LwaVT4eQ6o5tBV5pB/tLG5bqHsKze/RFcnlNblrO4YBsHdRv avKJNbC/LuNgLVaMJ09jy7f6MXBWgVUcUTtNp+cUmJuNj3JorjsfGecPu7HsurLR8UHkfERl cTVjn6I8tNqmqxXGXjvRTXU3TxPkj2/Zd6FrnG7/EeobJ9cLFkg0wwsxCU98uLITpNvugdZ0 1lOo7qlau9uC2x5mbH72JgPxJHFUZL6LD8U3dHzDV6dn/cQPImgZGyaGpS1HyIKltUVMXNCj NSoFxx5OaqNZCK3DsjDNimK2qeiHMWqBuxPs4hs5zGwf2gVoIzD54gVqA0KB7CEAZtnx127E 1ZbhUfe0PZHjTyqKmsgZAOHtvDf91kjArDG78NlVvv8WGn4eAmXD8yQiOnW8//u3deexNkwn lKt5I5rJXFszC1Mmc7iPk/KzR3GRSqKYMDKh+EaoVSkq3sYydqQw6x9GenoiB2XHb2/EMPgW GkCiuYdZjwcwdgk0Ed9Lr2+1VpcWjYRWZMUzRRtI1wEnmugAco7caCerez32yNalEL3+EaN3 XfbSEPJx51rurHpyK9iXKME24ryY4pOfGYBLM/c6vL0nfoM4GQk7oadsUksapNJZTrsuURV/ iYdBLQJDTkC/kx0wj9nAdvBABk7H0lm+jvwhvr8Syx22M+G+PbJBBjS6sAK9+Rq2jiSPDg6u Qysfsl+e+xOH72cNiI1OXeaCNCMArapSquVP4zwKoky54apf92Bd3WQDHI3HZI0FE3K9r1jl oXROB+7KraMoFicsQOc0tijxYUvcXKKFFuvh39A+c4c11olXPdMt+T67fDqLYkACS61UPNEE ja9zcY8+bOXiOF27JfFrk5Jn5OblMgrHtl5+GPeuTreUqXXvAG+ED/NHCzcLVQEvfYXboRqw t3+NGOkauccTHi1AXZoDt8JeZP/g+cMLePKRPJHfQN9dqwfUmIiO+t5sW4iT/sUzu1a0gCn+ R+BAUtR9UGjiNnlZE91yi5V7f+rU0kmUZP+D0PrC+Z5qG2pGPAWVxcOQLXgp9KTSBeP3iBg8 PC6/WZ3h3GkU948IiGElxRcNFIE8URSYayLz4GE7ljgIKV
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,259,1610409600"; d="scan'208,217";a="662815401"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2021 01:13:10 +0000
Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 12J1DA7r026133 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 19 Mar 2021 01:13:10 GMT
Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 18 Mar 2021 20:13:10 -0500
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 18 Mar 2021 20:13:10 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 18 Mar 2021 20:13:09 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O8HVcb+skA5pD8Q0B7Leba5X0fKTZG5NI+IEKP3nDO/WPjSJDI+/KK5Z8+Xw4BSQb/7B5dTlZ6qkNnXHLwhXu3qj5a9LAOLGusLZQRuN9bF77G84H+ypSksoYmYR83AMunz3zwHIMNaUy1r5WkiLKSHOJ6/UP3jXMRgTCiDRVvc5m1gVidZHDiLhy1OMlBunyix3uLb/frKoPdtT0FM2qLVgCoulkMsp281JgvjpOVpu+CNriJ8a2hGIUPDHOY9cdkuFVLMlkruZeP0tR871TYzhg4pIsJFe2Iu7xovBfQkr08PdqLu9zpQkm057SvLVaIUx8GAby4lIbn9MPwUlMA==
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=MvmcqffwVhWK+O9KS26b+fTUX3swe/yv6Hk4ISQnhvo=; b=bxC4BloeYz5FoX9eUNEeEICPA6/O0DIqTGcu0Rx8eZnAe3TWviJt+An78xKNvODlQUmf8UxM8pStEbgfQDBVi0H22+PJxPWaYU9xUMLgMUqW+ti/1D2f+gPE1Vge2XpYXaFuVD7MnDAjXWtFpjC7gwFkBSetrxPibtaihi+oPAwvYacu+Pi8S4VODoySMknAzsaq/SqmSUyL8CGz0/dFC4YjuQsRQwEXW5LpRHsywfjI48XjyNL0KEag6XAhL3doSiMZDOzmK7ZwO5j+UfF+c9KEOApvmea+Ylx2fl/CRpEmEPYd37AaXQKVusl84xJusimEQi5UpxexzXnYXQ5i0Q==
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=MvmcqffwVhWK+O9KS26b+fTUX3swe/yv6Hk4ISQnhvo=; b=wjzDS6nWAiZqRzN9VaGSKLvMj6qA8KtFS3pieJnlYHHCd5tBlv/9nGr1yemTFE2f2WjzvJw/V859itd6bMqXBEVWylIWt/EY9+RA5kzNn6r7HFbAIWEGC5Ur9NoF5l7hSVDRAMr+BEtVBDYZNbQXIaJbJoBBKeGtHJNiOIqK8LU=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BY5PR11MB3877.namprd11.prod.outlook.com (2603:10b6:a03:186::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Fri, 19 Mar 2021 01:13:07 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e084:727e:9608:11c7]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e084:727e:9608:11c7%7]) with mapi id 15.20.3912.031; Fri, 19 Mar 2021 01:13:07 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: IETF IDR <idr@ietf.org>, "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Thread-Topic: [SUSPECTED SPAM] Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
Thread-Index: AdcUzCK9cOxVNXxlSTaYTgm0ztYk+QAlchOAAARMGvAAAPLwAAAARvIwAAM2YYAACa7m0AABveeAAFc7oAAAAOjLwAABuHEAABRZTIAAdWAxgAAGV4UwACQ8iAAAA0idYAALo5mAAIdEEDA=
Date: Fri, 19 Mar 2021 01:13:07 +0000
Message-ID: <BYAPR11MB3207F0D8480B4B8EF992406CC0689@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <BYAPR11MB3207CF86CF2FBD56CA3EAD66C0919@BYAPR11MB3207.namprd11.prod.outlook.com> <CBFDE565-E501-4344-BF6C-53A541D50391@tsinghua.org.cn> <012b01d7170f$7ec90310$7c5b0930$@tsinghua.org.cn> <BYAPR11MB3207D4E973EE9ED170687E1EC06F9@BYAPR11MB3207.namprd11.prod.outlook.com> <015601d7171a$036be470$0a43ad50$@tsinghua.org.cn> <CAH1iCiqy3uu0SF2i9TyTRwCdt2d2Ud9+nUCtRG+vc2E-gwfLPQ@mail.gmail.com> <000501d71940$e9b87420$bd295c60$@tsinghua.org.cn> <BYAPR11MB320799969ECFDA66B32F2BBBC06C9@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV1UotP6Zc-YhvbBbj0XDiH-nnu3raUH9c0agVJ6B-D32A@mail.gmail.com> <BYAPR11MB320787166ECA326B9E05B2B2C06B9@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV071G9LPV4zjDzJU=YvcTHaJ3KP4yzjEuP62mkLLy_njg@mail.gmail.com>
In-Reply-To: <CABNhwV071G9LPV4zjDzJU=YvcTHaJ3KP4yzjEuP62mkLLy_njg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:65b6:eeee:b2ff:8898]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9f1c908d-e611-42bb-4ad4-08d8ea7427bf
x-ms-traffictypediagnostic: BY5PR11MB3877:
x-microsoft-antispam-prvs: <BY5PR11MB3877D237661B364855D8BC06C0689@BY5PR11MB3877.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bkb51ShZftk4Zov6hk8rupiD9Y+qQ5/XHxwp5qJFZTMgWbaAzHDjeJvquPWMNU6YBBFdna0mXoNDrmgLUWqhphthnMfLZ1v2IZcgU4sgsDwbZu3B1T8X6u2SsWdeT2wmnLjIdbRN7oMgt7+ojf4YQu3QItjpJF+KNlzWigM2MWa7REcukl90SyyVJ0nJ8HVjSzVjxWxWIk67d1qsm2BmsrPcRZGMSoKUtlEMh0mrdOlJzWIM7UdRXIClQ3fs9XDtBy+sdaA8EV6/NR5AlHifI4JZbJ9Gn3+nGENlPCFdwleb8nYMk0pZhbdrRRqD9mjasJeX81qSajqKOV32i4fyf9zI/hjnfpJRW8wOBlA9Gm7xZaX8kyFWiHhvNLbiveGglSmWi163krMTX81mgSGamsbgFF1p1+16Tf6dDA5ZEsbK8NmEH8K83ZyPxhS0to38DaYq3Wis+XfXK/NNz1zZonNnC9dsXs5xG17CgPPcvKMtag/CRDKOu2JRD5Kikzk7a0ElfQx2HjwTIedmC0QmtTphDbzrDtL7BjLxvxiQjM3r9ZKRuuR/R3WCiqfIAv7mn5KeiTiUnoJYFSYaBXIprsqCm1N625CSFYwaVnWFw8UHtjdDgpsfp5LrdFB7MRSvE0PSvQvcoqPf74Ggd9ICUXGGS1ffm1x/Vxwu81woCWfPk0Jqm6XujGd25GE7qmZjTQRNzDuh2qY4cSGX2BQlDBWD52cXGhyi63YChhgbm8w=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(346002)(396003)(376002)(366004)(5660300002)(6916009)(66556008)(52536014)(64756008)(66446008)(66476007)(66946007)(4326008)(33656002)(166002)(66574015)(86362001)(54906003)(7696005)(76116006)(316002)(30864003)(478600001)(8936002)(53546011)(966005)(38100700001)(8676002)(55016002)(2906002)(186003)(83380400001)(6506007)(71200400001)(9686003)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: P4FxXDvleMO8s0ZlG+7sF84Y9ReBchxxDAoo4Rt5v+x7zNyHMJy49lvBw9NqnzfvBxxn3oAQHz9rdLHvQYmCj+bgmr6f1lYan9u+pql03YKrM9M4JPC32FpVwOwWSyr2d/hhxffnNPF43fOSbutA7jRx5aA6MEVuYxA0LL6miSpPOreW6OBSiYPyj2Swx3Wrbss8G/5+BoAfXIzXmzHe21o4vI36CYfI5hHmk45KP8oP39bzXG3tOhtomwIEaHN5f+g7xPkrpRELHXbJaEnX1d4WWJKEAqWJvugIyWzs/tGiwb0sN2wfei3flK2nogjgGaCPl+AYZSmL5Kjirsczwz2x+6FRIC8LrAKbdGOusUfUM2gfDUoHjF/GovR8aVORWCSOJQ/Jr8AvXNDQKAQLtZTWH4ANNlNLsGG+MrkaC6Q2yts/xyeOYOxeZwQ3jGNUOP0h9IYZ9CxWjBfKUEJQvYouMvb8kLLncIkSMSIorkStwPI5ODbE4QVbfSNa2BKIsJS1O9kiwC7Eu5ogekn6z0az1kc1yB28PZLxASEfO78DHuprZSH7Fanah1j7uWnjcUd1JCeA1Ahz8zZc/tK+41WSW8YqacBmxlpar8fiZo8WnjjWMucaE6vf5xz22exNrbye40BmDrWNNwGfXS8qWsbWrdY1kmE6U8lTr6ALZY0Xw1KQyWbSDUIBi3hL2JtwfUfhrTREIWm9UsTCvA0fEkTKj9ZEisd3tJhWJyqNyyJDUuqLvxyCfO7zD+t6/o1bPtT19LAI2dhUK5h9CpoNxKlXDST3j1NNm4dUDfDCEjKzpZ/1cZxuMonN/kwL/1IuMpkaUjGXDeS5n9PSCk9duOJMHSmvwT5fts8LTnUCC79jBIZScM0XQshTcXOSAd+4LyH7czSrc8JWxmsI/G5bB5aZPYpaRemjlAZ3u9doRoT7f7eI5dDm/1Q5hDsIlIG8slUxZUkSJvPtHaA70MYUhJfYqWUEHZq44pfUyK7/zfEzS3SH6jpqbOYdL67jN9OAOwcgMaMApcEn+hD1cFJKKir0gAAVkA1+zHGoZGj03Wiqi5tI/l0VGmWX+RrUyk2oEUP3xvwXSx45aS7njYbYDWP1EoQ+j3XxzAfqcuRiNnB+parQ9mlD9XDPVJDjmXJm2j5CVW+/Maoo1R91VtblJS8iVGRuDLWK5T/JaoFba3VAsq42pH2+t0dvOKy7Us5g3UBnbe4s+0Z3zrhtMb5aTStYSw0oUj2ldwqH+mJb+9vRs8sn1DJRoi+/3XXWqJHm0dAiadrIBfGoS42uPMPVMXTMItLWOZz2QvVoYi0X3YCrshhCS664m5++lOU7DT+6a6K2axqDUaTpHyitohhXEVkdGAaBlTYwItl7sgzHWBvGvRfBXzALvqgM2Krpkri/
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3207F0D8480B4B8EF992406CC0689BYAPR11MB3207namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f1c908d-e611-42bb-4ad4-08d8ea7427bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2021 01:13:07.5689 (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: 3Ebn3c1U8EJd9xzkcYgSnIxY7/sPu2OXUx6k52UcDmqJEaKNL2Imy3sribm8t/a9zqmBWOnMYY3blOnyPP5h1Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3877
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kwcREjricZ37BVMHWvvtRgjcPoQ>
Subject: Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Mar 2021 01:13:18 -0000

Gyan,

The Global Administrator, or the leading octets in the community are the AS
that defines the community, not the AS that sends the community.

https://tools.ietf.org/html/rfc1997 page 3<https://tools.ietf.org/html/rfc1997%20page%203>
   encoded using an
   autonomous system number in the first two octets.  The semantics of
   the final two octets may be defined by the autonomous system

Also
https://onestep.net/communities/as701/
701:80 is defined by AS701 and sent by a customer to cause AS701 to set Local Pref to 80.

RFC1997 reserves two AS numbers (0 and 0xFFFF) to allow for well known communities:
   The community attribute values ranging from 0x0000000 through
   0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.

So, we are not without precedent.

Your point about the ASN being useful for troubleshooting is a good one.
I will add to the draft the sentence:
"The definition of each WKLC should consider including the BGP identifier
and/or the ASN of the BGP speaker that originates the WKLC value in the
data fields of the WKLC for easier troubleshooting."
Let me know if you want a different text.

Regards,
Jakob.

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Monday, March 15, 2021 10:41 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: IETF IDR <idr@ietf.org>; Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org>
Subject: [SUSPECTED SPAM] Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)


Hi Jacob

In-line comments

I think we both agree that this draft should update RFC 8092 so it does not add confusion as to the standard as your are completely revamping the format of the data fields all of that needs to be properly documented.


On Mon, Mar 15, 2021 at 8:54 PM Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:
In RFC 8092, the Global Administrator defines the function
of the community, the meaning of the data fields.

https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02
does not require a Global Administrator, because the function
of the community, the meaning of the fields, will be defined
by standards action and not by an AS.
 Gyan> if this draft is updating RFC 8092 all of the changes and updates need to be part of this document as part of the specification being changed and not referencing other documents as normative or informative for the actual proposed changes.  All of that has to be included in this draft proposal.
In
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04
the ASN is not the Global Administrator of the function of the community.
It is the AS that sent the community.
 Gyan>  Historically and to date all communities both standard and extended 2 byte and 4 byte AS the ASN as it had been the GA left field in the data fields
It has always been the AS that is setting the community is the originator and Global Administrator of the community and NOT the AS that sends the community as the community is being propagated hop by hop each node can tack on an additive community or pass the string upstream with their GA value added to the community string.  So it’s the “originator AS” is the Global Administrator and that is how it had been historically from Day 1.

No flip-flop. This concept is key. ASN != GA. WKLC needs no GA.
 Gyan>  See my comments above.  I don’t agree that the ASN that sets the community is not the Global Administrator of the community.
Your suggestion to update RFC 8092 is a good one. Thanks.
Gyan> Agreed.  Thanks
Each WKLC begins with the bit pattern 111101.
If we can be sure that no Global Administrator ASN beginning with that bit
pattern exists, then the WKLC can be distinguished from the LC.
 Gyan> Ok.  Makes sense. the pieces of the puzzle are coming together.  Please explain that idea better with updated verbiage.
The data fields in a WKLC will not be defined by any Global Administrator.

    Gyan> I don’t agree with your reasoning as the main purpose of the Global Administrator for troubleshooting is knowing which AS node originator set the community.  The Global Adminstrator field is critical for troubleshooting.
They will be defined by standards action when a specific WKLC is defined.
 Gyan>  So you are saying that their will  not be an explicitly defined Global Administrator field however if the operator chooses to use one of the data fields as a Global Administrator field so be it as the data field are open and can be set to anything.  Even with today’s standard and extended communities the fields  RT types 0, 1, 2 the fields can be set by the operators to anything the operators want to use the fields for however the RFC guidelines of Global Administrator field and local field almost 99.9% of the time as always been followed.  That being said I don’t see any harm as the operators can set and do whatever we want with the 10 bytes but I think it’s a good idea to keep in sync with the historical precedence that has existed for decades with the Global Administrative and Local fields.
Most of your other questions stem from the assumption that ASN == GA.

    Gyan> Yes most have been related to the ASN==GA.
If not, please ask again.

Gyan> Will do

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Gyan Mishra
Sent: Monday, March 15, 2021 3:34 PM
To: Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>
Cc: IETF IDR <idr@ietf.org<mailto:idr@ietf.org>>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)


Hi Jacob

I have a few questions related to the draft.

Do you think it would make sense to make this an experimental draft and as it matures in testing the leak mitigation we can advance to standards track.


The WKLC format change reason as you stated to flip flop the global and local part as per GROW leak detection proposal to use the WKLC to primary goal of community usage would be for “route leak detection” and per the leak draft as you stated the reason for the global and local part flip flop is so that the field is prevent the legitimate AS from having the same AS field as the leak routes signaling and tagging.

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04

Is this draft updating RFC 8092 and if it is not it is really confusing for any reader as it does seem that it is being updated to this new format.

How would legitimate traffic use RFC 8092 format and non legitimate use this new draft format of RFC 8092 is being updated.

Also how can you maintain 2 completely different formats for large communities one for legitimate following RFC 8092 and one for leak draft using flip flopped fields.  Or is RFC 8092 being updated and this is a new format being proposed.  We should state if this draft is updating RFC 8092.

Also in Section 2 encoding the Data fields are not defined as global or local.  Are the three fields open and not defined maybe to used for global or local at the operators discretion?

It appears the leak draft defined the 10 byte 3 data fields as NN1:NN2:ASN however your draft keeps it wide open for the operator to whatever it chooses for the 10 byte field.   Would that make the RegEx match complicated and break RegEx matching as now you don’t know what field is what do you don’t know what to match on.  I can see the advantage idea of the flexibility of not defining the 3 data fields but I am not sure that work with RegEx matching.

In thread was mentioned 2 ASN fields mentioned by Brian which does seem strange.  Usually the ASN data field is set to the originator ASN that is doing the marking.

So from RFC 8092 to this proposal to account for the route leaking issue solution WKLC we go from 3 data fields and 12 bytes ASN:NN1:NN2 to 3 data fields 10 bytes NN1:NN2:ASN using the first two bytes for flags and WKLC byte.

In the draft in some spots it says the 10 bytes data field is for WKLC but can’t it be used for any large community usage.

The goal of RFC 8092 was to make the data field larger for 4 byte ASNs but does not specifically addressing WKLC.

All of these questions need to be made more clear in this draft before it can be adopted.

The leak draft proposes one format idea for WKLC format, however  I don’t understand why we are jumping from a standards perspective on this one idea to flip flop the format or make it open with no defined structure as a solution to mitigate the route leaking.

The leak detection draft lacks guidance as to why this DO format was chosen and does not propose any other ideas or options for leak mitigation.

In the leak draft section 3 of community versus attribute and I agree that a new path attribute would be the way to go but as stated that would require code upgrades and longer lead time for operators to implement.

It does seem like a rush to get something pushed out as a stop gap measure “standards bandaid” without thoroughly thinking through all the nuances and possible ramifications of this flip flop or open ended concept.

I agree that some thought was put into the solution comparing drop leak detection versus deprioritization and I agree the RFC 8092 LC is the best method for the solution at this point, but I am not convinced on the flip/flop format DO community style for route leak mitigation.  Also we stated how would RegEx match work if you don’t know which field is the global field and the high field is the local field.  I cannot see this working.

As with RegEx you can match on any digit in the RFC 8092 style AS:NN1:NN2 versus the flip/flop idea NN1:NN3:AS.

In the draft as the fields are open ended, how are we calculating that WKLC uses the number of ASNs listed below.


   The range of AS numbers currently unallocated by IANA is 399,261 to

   4,199,999,999.  The WKLC reserves 67,108,864 AS numbers.  That still

   leaves 4,132,491,874 unallocated AS numbers.  For comparison, there

   are 94,968,317 AS numbers reserved for private use.  Thus, the number

   of ASNs reserved for WKLCs is considered insignificant.


As all communities to date have always follows the AS:NN Global:Local part I am not sure  why the drastic change in format.




Kind Regards


Gyan

On Mon, Mar 15, 2021 at 1:30 AM Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:

[WAJ] Yes, there are abundant range for the 32 bit ASN space, but my main point is that your draft doesn’t state the reason to reserve 1/64 32-bit ASN space(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF)).

[JH] Aijun. I'm glad you agree that there is still abundant space to allocate ASNs.
The reason to reserve space is explained in the introduction.
It is to prevent WKLCs from having the same Global Administrator field as a legitimate AS trying to distribute its LC.

Regards,
Jakob.

From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Sent: Sunday, March 14, 2021 7:14 PM
To: 'Brian Dickson' <brian.peter.dickson@gmail.com<mailto:brian.peter.dickson@gmail.com>>
Cc: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>; 'IETF IDR' <idr@ietf.org<mailto:idr@ietf.org>>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Brian:

Based on your intention, I think you should consider to redefine the encoding of LC, not only well-known LC.
Even for the redefinition of LC encoding, you should also state clearly the potential advantages.

More detail replies are inline below.

Best Regards

Aijun Wang
China Telecom

From: Brian Dickson <brian.peter.dickson@gmail.com<mailto:brian.peter.dickson@gmail.com>>
Sent: Saturday, March 13, 2021 2:14 AM
To: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Cc: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>; IETF IDR <idr@ietf.org<mailto:idr@ietf.org>>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)



On Fri, Mar 12, 2021 at 12:31 AM Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>> wrote:
Hi, Jakob:

From: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Sent: Friday, March 12, 2021 3:45 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)


1.      It is small, not huge as explained in the draft.
[WAJ] When compared to the 22 well-known community, “67,108,864 AS numbers” is too large.  I am worrying the unnecessary reservation may prevent the allocation of the unallocated AS-number for other purposes.

The range of reserved ASNs occupies two bits of the upper 8 bits, plus the entirety of the the next 24 bits in its range.
This represents a single value from the 6-bit portion of the ASN space, or exactly 1/64 of the 32-bit ASN space.
Given that the current usage for ASNs is 2^16 for the 16-bit ASNs, plus less than 7 bits out of the upper 16 bit range, that is roughly 64/65536 or about 1/1000.
This still leaves well over 31/32 of the potential ASN space, so I believe your worry is unjustified.

[WAJ] Yes, there are abundant range for the 32 bit ASN space, but my main point is that your draft doesn’t state the reason to reserve 1/64 32-bit ASN space(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF)).

2. It got updated and I missed it when I updated my draft. Thanks for catching it.
3. I don't understand your question. Can you expand?
[WAJ] why not take the approach directly as that descried in  https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04. ?
That is to say, for each potential well-known large community, reserve one value for the “Global Administrator” part of the large community, and defined the associated data for the other two local parts. Transitive or non-transitive can be defined accordingly.
Currently, you define “WKLC ID” as the large community type. From the definition of large community(RFC8092), the “Global Administrator” part will be divided into 256 groups, each group will have 2^16 number, that is 2^16 well-known large communities?
I know you want to leave some field to the data part, but this arises some confusion when your proposed encoding is different from the original definition of RFC8092.

The logic for this is as follows:
The initial use case is to establish a structured value of TBD1:TBD2:ASN for the route-leak-detection-mitigation (as that draft explains).
The TBD2 is a single value out of a 32-bit range which will be in its own (new) registry. Having a registry allows for future uses in the context of TBD1, allowing new kinds of LC's in this bigger registered range.
[WAJ] You should state also the reason that such sub-registry under one well-known LC.  Describe some examples may be helpful.  DO community is one example, but there still also no more explanation.

However, the router implementations, for the most part, permit filtering of LCs on the basis of 3 32-bit values, where either literal values or wildcards can be used.
Having the elements be aligned on the 32-bit boundary, and having TBD1 and TBD2 be fixed values, permits LC matching using a patterns of either TBD1:TBD2:* (wild-card), or TBD1:TBD2:ASN (explicit ASN match).
In other words, this structure choice is forced by router implementations, and really not appropriate to second-guess. It isn't up for negotiation, as this is a necessary requirement for the first use case.

BTW: Both of these patterns (fixed single value and wild-card of lower 32-bit value) are required to implement the GROW draft you referenced.

Having said that, this is the first out of up to 255 WKLCs, and the maximum benefit to other potential uses for WKLC is achieved by making the maximum (reasonable) number of octets available for those other WKLCs, specifically 10 octets of undefined structure.

In particular, it is possible that other WKLCs require two ASN data values in their encoding (such as a source ASN and a destination ASN), and additional values (single bits or ranges of values) beyond that. Limiting the WKLC to having only single Global Administrator values and 8 octets of data, would be insufficient in that case.

This would require re-design of WKLCs at a later date, and it may not be possible due to existing usage or reservations of WKLCs.

By providing more octets to EACH WKLC, this problem is prevented. Making data allocations on power-of-two boundaries at the highest order is necessary up front. Attempting to expand ranges after allocations is possible, but may not be compatible with the power-of-two alignment required by future use cases of WKLC.

You cannot aggregate that which was not initially allocated in a fashion suitable for aggregation. This was one major outcome of the IP allocation strategies prior to CIDR addressing for IPv4 address space. We would do well to learn from the mistakes of others, particularly when those mistakes were effectively repeated in the ASN space already (16 bits to 32 bits, because the initial assumption was 16 bits would be sufficient).
[WAJ] If you want to accomplish this, I think you should propose to change the encoding of LC, not only the well-known LC.   And, the community is not used to packet forwarding, what’s the necessary to aggregate?

So, in summary, the reservation of the range of ASNs is specifically to permit applying structure to the LC values within that range.
The original LC definition is only applicable to "actual" ASNs as Global Administrator. RFC8092 says only "intended", and that the value "SHOULD" be an ASN.
This is a new use case, and is the reason RFCs use "SHOULD" instead of "MUST".
(What RFC8092 really says is, LCs where the Global Administrator value corresponds to an actual assigned ASN, are reserved exclusively for the operator of that ASN.)
Since this proposal sets aside a range of ASNs as a group, the structure of LCs covering that range can be redefined accordingly, as long as that redefinition is scoped to that range of ASNs.
[WAJ] This is different from the structure of LC defined in RFC8092, in which only the Local part 1/local part 2 of one Global Administrator is operator-defined.

This is EXACTLY what this WKLC proposal is doing, and nothing more.
The other draft is for the use of the first assigned WKLC values (single ID plus the Transitive Bit values).

Hope this clarifies the usage and compatibility with other RFCs.

Brian


Regards,
Jakob.

From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Sent: Thursday, March 11, 2021 11:16 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Jakob:

More questions for your draft:

1.     Do we need to reserve such huge range(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF) as you described in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-6 for the countable well-known large communities?

2.     There is some inaccurate description for the current reserved AS number space in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-4.  You can check it at https://www.iana.org/assignments/as-numbers/as-numbers.xhtml. The unallocated AS range is 401309-4199999999, not at described in your draft “The range of AS numbers currently unallocated by IANA is 399,261 to 4,199,999,999.”

3.     What’s the necessary to group such WKLC via the WKLC ID?

Best Regards

Aijun Wang
China Telecom

From: idr-bounces@ietf.org<mailto:idr-bounces@ietf.org> <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Aijun Wang
Sent: Wednesday, March 10, 2021 9:38 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Yes, if we reserve some 4-bytes AS range, then your concerns will not happen.
The well-known large community need just be allocated from this reserved range. That’s all.
Do we need other definitions in your draft then?
Aijun Wang
China Telecom

On Mar 10, 2021, at 21:18, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:

Consider if there is a real AS that uses 4,093,640,704 as its ASN.
And if this AS were to send a large community of its own.
It would put its ASN into the Global Administrator field of the LC.
This ASN is 11110100000000000000000000000000 in binary.
Then another AS sends a WKLC with WKLC ID 0, Transitivity 0 and Data 1 = 0.
This has the same bit pattern.
To avoid the clash, we need to reserve the ASNs that would clash.

Regards,
Jakob.

From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Sent: Wednesday, March 10, 2021 12:11 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>; 'Susan Hares' <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

And, what the reason to assign the “111101”value in the first 6bit your encoding? It is not conformed to general definition of large community, in which the first 4-bytes is to identify the Global Administrator.

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
Silver Spring, MD

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD