Re: [Idr] draft-chen-bgp-redist-01.txt

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 02 July 2021 20:25 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 285F83A0522 for <idr@ietfa.amsl.com>; Fri, 2 Jul 2021 13:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.596
X-Spam-Level:
X-Spam-Status: No, score=-9.596 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=KsZOASqH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qhb1dsTa
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 3fcQueBtuuJO for <idr@ietfa.amsl.com>; Fri, 2 Jul 2021 13:25:30 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8883A048D for <idr@ietf.org>; Fri, 2 Jul 2021 13:25:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14589; q=dns/txt; s=iport; t=1625257530; x=1626467130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HqvgB/ajYgINzxaH2VXIzrT7nrTLRoEJpgwG8CuzJi0=; b=KsZOASqHJsAsTrlMju21DeHWkjTE0MyHaPKx3x7n1hPYWPMMT367pen9 qYlcVnjFX6HnHFTBXauiLeL8WLycZ2652o+1i6x5V66nUxgLtpUp9YGYA tqWrc6EnYeHu8FJrjB9gFh5BSsoy5zjFciJEwop7//nCfVv0MDXz5KzW0 k=;
X-IPAS-Result: =?us-ascii?q?A0AmAgD5dd9gl5tdJa1XAx4BAQsSDECBTguBUyMuflo3M?= =?us-ascii?q?QKIDgOFOYhTA4pShRKKQ4EuFIERA1QLAQEBDQEBKg8GAgQBAYQORAKCbQIlN?= =?us-ascii?q?AkOAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVoDYZFAQEBA?= =?us-ascii?q?wEBARAoBgEBLAsBBAcEAgEIBwoEAQEfCQchBgsUCQgCBAENBQgTB4JPAYJVA?= =?us-ascii?q?w4hAQ6bIwGBOgKJUBo1eIE0gQGCBwEBBgQEgTQBARM/AoNODQuCMgmBOoJ7h?= =?us-ascii?q?SWBUIN6JxyBSUSBFAFDgmI+giBCAQEBAQGBFwgJARIBCBsfBQwVgwaCLoIpA?= =?us-ascii?q?modKSIGQw4BAQUPDA8sIAUYLQgNBCUBDwMnAg8ZEJFUA5hfkHc7WwqDIYolh?= =?us-ascii?q?zZThheFeRKFJ6EAlXaMK4Mvj24thQECAgICBAUCDgEBBoInOWtwcBU7gjUBM?= =?us-ascii?q?wlHFwIOjh8MBQgJg06EWTuFSnMCAQQxAgYKAQEDCXyJcwEB?=
IronPort-PHdr: A9a23:okxDFRV1+VUxNp1cxRjqnJrmDePV8K0YAWYlg6HPw5pEbq+k+ZLvN 1CZ7vJo3xfFXoTevvRDjeee86XtQncJ7pvJtnceOIdNWBkIhYRz/UQgDceJBFe9IKvsaCo3T 85eX1hj+XywLQ5eH8OtL1HXq2e5uDgVHBi3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJ xLwpgLU5aEr
IronPort-HdrOrdr: A9a23:c8XAsaDphoF6Wu3lHegQsceALOsnbusQ8zAXPh9KKCC9I/b3qy nxppsmPEfP+UkssHFJo6HmBEDyewKjyXcT2/hQAV7CZnimhILMFuFfBOTZskbd8kHFh4tgPO JbAtRD4b7LfBtHZKTBkXOF+r8bqbHtms3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJba Z0iPA3wwaISDAyVICWF3MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWnb4j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrazMdZDsDksLlRFtyssHftWG1SYczFgNkHmpD31L/sqq iVn/4UBbU115oWRBDvnfKi4Xi77N9k0Q6S9bbRuwqSnSW+fkNmNyKE7rgpLScwLCEbzY1BOe twrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfJsRKEkjQho+a07bWjHAUEcYZ 9TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFhPDRkQZoMSa3zVfgXg8liIjtYMit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJOmOPJlbsEr0BJhv22tLKCXUOlamXkbkzvdUPcb j6ISdlXF8JCgvT4Je1reh2Gzj2MRKAtBrWu7Nj26Q=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.83,319,1616457600"; d="scan'208";a="718966997"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Jul 2021 20:25:10 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 162KP6YM014487 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Jul 2021 20:25:09 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 2 Jul 2021 15:25:08 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Fri, 2 Jul 2021 15:25:07 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Fri, 2 Jul 2021 16:25:07 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tact3SsWSSs7i68kknODPvnFURJDhJ9kfUiJyCEmFZ5/FtdVPlEzTnOZQjvs8gw5Es8P9nGjDdDii2xYJfHHKXo+EKj0eUBjBK0LGr3Qulp9jQfdi9TkJWQ7BLwv3nF7zYjhfASt+TefqfLv4/84ZRBcffFxQPVTNXSfqIWk2hIXF+G3NiyLEJXudqTT9B/3JK5ejgWohl/C/ikkHsisLwgiPHVLvps35tIzXRoySLvnpVWGFEV6JUNgdM1nnv8quiH6KFAKxr5bK5yX/qzxkeD29bNkfY71Crj32V8nf1zqC72QZdYe5Ckk7t+zac6LqX/+wV5ocZSk1iIppF2aLQ==
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=UF3yfM/Y+zpYueZI1WfqDDotmjRDydSuBwS5uM4MKgU=; b=VJAlGuQ+KpBRDEZtMmrVPUFoh2DFs2duCiXRYfGn/Ic9p1Dn+xYsaOezFgaegKarGQa3sEvRmfbcWF4cOjI1L+ODtTOw6e7UXgn48oK0mIZwptks/Qu7NwvXYGHTuZw15Qh2IqPqjSAPhw1UfYOuN+LNuhfocGIhlWf+02nvXf0js7l12iK+T38ksGzQAWw+Zg3s6x1GotBqYGmqC6b4Rgi+PhPLc1wUJq79JjI4eVcIZpkvvqOZlKpv5V6lUY+fCe87DteAM/fgNTls/S8dYtkVkSBGCGj98iU83ZCZe6qxnHdU1UYJ2PaVHY9WP3uOUslhL78XB1dmgCDHMxjCeg==
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=UF3yfM/Y+zpYueZI1WfqDDotmjRDydSuBwS5uM4MKgU=; b=qhb1dsTa8Mj72S29LpFD6C02XKDs4c0suoInkRtuaJfMsyK1uqLZU5AJ8nBXxhtgITtRsh8Ka1he5RXJ8goNtvYj+gxs6Qp2DV0Ip5+ujGsMmJow+BSC5i1/3JADcERGCy55Hb1HcNblxIcoIzn+TikZ9yKYvaZtN4a6n6U5Hp0=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB2854.namprd11.prod.outlook.com (2603:10b6:a02:c9::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.27; Fri, 2 Jul 2021 20:25:06 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::5c60:81c3:b049:887f]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::5c60:81c3:b049:887f%6]) with mapi id 15.20.4287.028; Fri, 2 Jul 2021 20:25:06 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: tom petch <ietfc@btconnect.com>, Gyan Mishra <hayabusagsm@gmail.com>, Robert Raszuk <robert@raszuk.net>
CC: "idr@ietf. org" <idr@ietf.org>, Jenny Yuan <jyuan@paloaltonetworks.com>
Thread-Topic: [Idr] draft-chen-bgp-redist-01.txt
Thread-Index: AQHXbQo/o8jtDe7ZgkW8Zce3qNBqsKsrajOAgAC8HwCAAkYXgIAADpUAgABb94CAAAkRAIAABfuAgABOYECAADijAIAAuIuQ
Date: Fri, 2 Jul 2021 20:25:05 +0000
Message-ID: <BYAPR11MB3207B35CA69BD68E144D1878C01F9@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <CANJ8pZ_2yk666tSca818-e0YdziKjK3dMqhopOtYAP3vKXTEmQ@mail.gmail.com> <CAOj+MME5zZeZDnhpfivbdKj00JwBzi9rjMmzBXxE_fFqkxEVpA@mail.gmail.com> <CANJ8pZ9Und3fF324tzTAkhrMFV0MZfhHYfZussiYSCNUx-n_Hw@mail.gmail.com> <CABNhwV3BXk=+fuxVSg_9j+u+5Ffr+NQGE9P75NCPpTaUr5LqYQ@mail.gmail.com> <CAOj+MMFxM_yvrPDEyQ+dpO7ZxoiQKa0DE4ZQf763Cuidj76QXg@mail.gmail.com> <CABNhwV1q-H1pSypWCvA9VKXBZZTfM3nQNPktjbmbN0D=VSXpBw@mail.gmail.com> <CABNhwV29-t-N6EMmJQzOairgTB5jsPX1h6Q0e+akEgiA2cUpQg@mail.gmail.com> <CABNhwV1QAR8qHdP+rSTOk3eRU5A5tMAfWFFyqXYPQteHtoNyBg@mail.gmail.com>, <BYAPR11MB3207B8AE524F71ED25590B94C01F9@BYAPR11MB3207.namprd11.prod.outlook.com> <AM7PR07MB6248B0D69C861D1898EBE921A01F9@AM7PR07MB6248.eurprd07.prod.outlook.com>
In-Reply-To: <AM7PR07MB6248B0D69C861D1898EBE921A01F9@AM7PR07MB6248.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:4a3:1f38:ea7d:9e8c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5eeaf58e-7ff9-4680-b27f-08d93d977ae1
x-ms-traffictypediagnostic: BYAPR11MB2854:
x-microsoft-antispam-prvs: <BYAPR11MB2854969702850AC176DBDBBFC01F9@BYAPR11MB2854.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ZhQ8u1/jrB3KDeTl5vMNkEwCt+hdH22BucnG+yAws9HGxR4Biw784A89I3q080XvL57RjBZ1tPVefPjSmy1PIWIpArQZTVOhUzh5EsurbGm5PycqrPRW8l3FyfzmVudwdIXTlSsVBHKX4Csfp14JvlyOebsZfgF/CvCVgpbLDxXd1xrAPCea/hTw+HQgoDEm5Mrf5rQGtxfKqAebTbgB5J2Hs2CU3QNWHv74h+PlWFyHsQU9YfNEIp9jjTclVzQsM1hO8wfX+ASdHMAdGHuK196rcY6m6LnzSeFDLOf5UnZSW0M/rzCaquCfEmumJ9hFYcZvnNiACfNavZ2WV6c5YUMmJSSu0+f9Qi1AFSNEj82V9gSdJR9UiBacbMh9SV2XmofLWBZj2U7TihxIVRKPnnHpBXJuB82bfcff+QgMBWOPalxor8n4XBk1SldOd4zbaCqacVOwAnr2fWjaCWYv+lrRFeIT/zibFOMpMqEym56JGPWB7Hislee3JSTrr7OAGWxRdjdj+o0Apu6ak/tXeWvgdKDykPMZ7Pu88jHVkXZmS1oHL7myyeyPRL6Wi3t2rbVsGxuEfcqi3OxIGkOg1d+uImrQtm4pFaBhUZUftB5YbvNMZlj0Z2RbhaAE6rDEmLRRl2LFQG/SISLi4Z9VkuyM7J6UH9gsYuuSN3hiySxljhCZuVT9rpcuPw4LCLH3UL2q30atzMEMqnIgKJVP3Y4NQrA5NiVkXrpLG6Dv1vSBsvlMxFvXgn9Fpz9uTRibjNibJM33PGDvHUzZiAD4bA==
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:(396003)(366004)(346002)(136003)(376002)(39860400002)(53546011)(83380400001)(6506007)(66574015)(966005)(110136005)(478600001)(7696005)(122000001)(316002)(38100700002)(186003)(33656002)(71200400001)(54906003)(4326008)(55016002)(296002)(5660300002)(9686003)(8676002)(52536014)(2906002)(8936002)(76116006)(66476007)(64756008)(86362001)(30864003)(66556008)(66446008)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?vlcM3BvpolQHez+blLUG1Ra409LoBPNzFwpLc1TzTTYFyeZu/TtKxlrlIFTj?= =?us-ascii?Q?lmHnnVhr12Y8C9m9WCdMzoB+qZJCNa3N2/9jWMNWheLg3X96Z0PAeHoBqdqY?= =?us-ascii?Q?GkCsFmKMxOS6UWS5HsDZypQWOJTGGS/8l1UI8iUTpR8agm9x7gD9NXAAUJ1b?= =?us-ascii?Q?oijBUErRlEb5PjUkxJ592utA/cCcTGJN94AKMznf9e4erJ6RRnBnfMgT3HZO?= =?us-ascii?Q?rerVBskeSZy9FQLqUzsikPo/8hzmG4b359/e8N/L9xU4Dnm1oRZryR7qLXHZ?= =?us-ascii?Q?ujGhir5klvw6CKBnf5fELBZvUstdRFn3PurDAB+dCgo8D/01KmXBzfb/A2s8?= =?us-ascii?Q?fOL7uOjnc2CrXb+hBsT/aA/gr4viQwYIL0IxPI1ED5J6993z+GkKh4ejlM6e?= =?us-ascii?Q?ngcLkTE3VmAQQKSUK+LCENxZFTbfX29YLD3/61cCatsQowJx2BIwcEn9Aa6b?= =?us-ascii?Q?d3V3mV6K7koIR05IsWPI2HfJxkCO5+9IFaZa07BvQyA+sMVY1YtPEHaHelrp?= =?us-ascii?Q?28v293KhKQOG3zHpF+AwKe5vpzEjbFnBEeos5Efuhz2gWkFrTUUYX4bq4VQY?= =?us-ascii?Q?nM4q+ffpOqwGV1kyR7OWQgQ/MpnuEoxDRmJYa6wBWvvLqC/dSi7vdOnTVXxB?= =?us-ascii?Q?PaAnz4AXjV9t1Tf4DdcWh2kjyH8meHSXVgyFC4uYvoVEVben0iBkBwCCMglk?= =?us-ascii?Q?X/+u/VxPTrTvNfjA0QeMDuyDevmG+iHym1MEiWZD2wjMqjK58XHLtOAVB5Wk?= =?us-ascii?Q?8bxRXb4AoHFHPqW7Tzxkv01n0TPYE6aTdhPEGeDhNo2OTd5dZwNbcjeOCTtx?= =?us-ascii?Q?Uis167LOA5TEhLDUSdybwbN63RinbkvdCte1mAIRKeCx2MpS5T5gvvD5VOCP?= =?us-ascii?Q?y0N2DOtgDBi+kNmsk1g/4QvJhbR6olPZ1NvU7le62Qx8uDgRPvEqyhiE251t?= =?us-ascii?Q?lmdcg/7q5VuBKCS3EiNsAkld4PWAcZZLbn4q9jEBcJTsmNUVY165mzaSgDvq?= =?us-ascii?Q?vxpXogTtEsMjbnuUZwVj+yJLCgNDELf3NJGBoFPlNvXRbd40GPxNWGdNuOJL?= =?us-ascii?Q?ygpd0r6Wfyn3j0ks2gdyiIZb/zq0UysUQjU7f/niojOe5kykdqxFceJWAzGB?= =?us-ascii?Q?TlydFFo1YW3YJIadwtPHlAkI1bOdkdQLvwrztH+nmB3C+0eUXaW4PH0uaUoK?= =?us-ascii?Q?YxEfdNkwCf1oC1ASK4f+INDmz4KxSMV/gKHxrUdXdZCvb59Q21xD8pLYHSXj?= =?us-ascii?Q?fJTdfsE9FkAyppweB9KMQP31fXmfuhkxsiyc8RGdg3+gKGtVEbv/rioVEOrW?= =?us-ascii?Q?4OLnvWD/LnXajtZqKN1q9hPQ0XPNUuuvKf3In8/EP4eTQ2x7wH1suYriWeJU?= =?us-ascii?Q?JrQavrJwHu1VDVm7FaQFmfSVPwOD?=
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5eeaf58e-7ff9-4680-b27f-08d93d977ae1
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2021 20:25:05.9374 (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: Q99L4EGCNXmg2ErjXB5K3mn2GC5xfgfkTdaYVFspqGXl/jF9cfXhSbibzYS+FFlVMAsNEHs4Dsuwk2u4NOsm5w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2854
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DlC7kzxqOOLxDLSVMQTANHGxSfg>
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt
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, 02 Jul 2021 20:25:35 -0000

Thanks Tom. You complete my search.

Regards,
Jakob.

-----Original Message-----
From: tom petch <ietfc@btconnect.com> 
Sent: Friday, July 2, 2021 2:21 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>om>; Gyan Mishra <hayabusagsm@gmail.com>om>; Robert Raszuk <robert@raszuk.net>
Cc: idr@ietf. org <idr@ietf.org>rg>; Jenny Yuan <jyuan@paloaltonetworks.com>
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt



________________________________________
From: Idr <idr-bounces@ietf.org> on behalf of Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org>
Sent: 02 July 2021 07:33
To: Gyan Mishra; Robert Raszuk
Cc: idr@ietf. org; Jenny Yuan
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt

Admin-distance is not defined in any RFCs. It is a vendor only concept.

<tp>

I encounter it in (at least)

RFC8349
RFC8022
ospf-yang

Tom Petch


I can speak about it from the Cisco IOS-XR and Redback perspective.
In both of these implementations, RIB and BGP are separate processes
with separate memory spaces and their own routing tables.
Routes are passed between them using inter-process communication messages.
They cannot access each other's routing tables. Other routing protoclos,
such as OSPF, ISIS and static are also separate processes. Each of the routing
protocols downloads their valid routes to RIB. If the same IP prefix is
sent to RIB by multiple routing protocols, RIB will select one to be used
for forwarding and resolving nexthops. RIB uses admin-distance to decide.
Routing protocols get their local routes from RIB.

A static route has admin-distance of 1 by default.
However, a static route can be configured with a different admin-distance.
It is possible to configure a backup static route by configuring a high
admin-distance for it.
In that case, if another route is found for the given prefix by another
routing protocol, say an ISIS route, then the ISIS route will be used
for forwarding. Only if the ISIS route disappears will the backup static
route be used.

Now, suppose we want to advertise that prefix in BGP. We can do that
with a "redistribute" statement or with a "network" statement.
They work a little bit differently, but either command will import
the route from the RIB into BGP.
Once the route is in BGP, it loses its admin-distance.
BGP has no knowledge of the admin-distance that this route had in RIB.
There is no admin-distance in section 9.1 of RFC 4271.
This is the root of the problem that Enke and Jenny are trying to solve.

The problem occurs if the same prefix can be learnt by BGP from
a BGP peer. BGP may download it into RIB. The draft addresses the
different outcome if BGP learns the route first from it peer or learns
it first from the local RIB.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: Thursday, July 1, 2021 6:18 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: idr@ietf. org <idr@ietf.org>rg>; Jenny Yuan <jyuan@paloaltonetworks.com>
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt


>From a network design POV, in general within a an IP transit AS their is no need to redistribute BGP into IGP unless their are non BGP speaking routers within the network.

As for sourcing routes into BGP advertisement from a customer edge best practice is to originate the advertisement as close to the source routers as possible, and if it's a summary then use a network statement and if LPM routes are required then redistribution of IGP into BGP via policy is the best way but also as close to the source of the prefixes.

>From a core perspective IP or MPLS it is common to redistribute connected or IGP into BGP global table still separate from customer traffic in SP operator core where MPLS any-any VPN VRF is used to carry Internet traffic and in that case the NOC may sit in the Internet VRF and NMS systems need telemetry access back to the global table.


Kind Regards

Gyan

On Thu, Jul 1, 2021 at 8:56 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

Hi Enke

I am still trying to understand the need for this draft.


Their are two main methods to locally originate routes into BGP done at the customer edge which is via redistribution or network statement.  When you redistribute routes into BGP the origin flag is set to incomplete.  When you use a network statement with exact match of prefix installed in the RIB, the route origin changes to IGP origin.   The pecking order for Orgin is EGP, IGP, Incomplete so if the routes is also advertised via network statement and redistribution by two different ASBR the best path selection will converge on the best path IGP origin via network statement over redistribution.  Maybe that is the intention of the draft to prefer incomplete over IGP origin and that can be set via policy as well so that both are equal so load balancing can occur.

At the bottom of page 2 below is stated as the premise for this draft.


Currently the admin-distance does not play any role in BGP route

selection.



I disagree.  Indeed AD plays an important role in redistribution or locally sourcing of prefixes into BGP advertisement.  All vendor implementations do this the same way and that is that only the lowest AD source

Of a particular prefix is what is installed onto the RIB and FIB.  So when doing either a redistribution or using network statement exact match to source local routes into a BGP advertisement only the prefixes installed in the RIB that match exactly via network statement or if you have a redistribution policy matches the prefix and source protocol for the route being redistributed.



Let's say you have a redistributing OSPF into BGP however their is a static route exact match for the prefix you want to redistribute that matches your redistribution prefix list

however as OSPF has AD 110 and static had AD 1 default and if you are trying to redistribute ospf into BGP the redistribution will not work since the RIB has the static route as the source for the prefix installed in the RIB.



Example of how AD plays an important role in how redistribution can or may not occur properly due to AD of the protocol sourcing the prefix

And the protocol being redistributed must match or the redistribution will fail.



I have noticed one issue with both redistribution and network statement which is problematic is that the IGP metric is passed into BGP as MED which is higher in the BGP best path selection which can result in sub optimal routing.  The workaround is to reset MED to 0 with a policy.





Kind Regards



Gyan

On Thu, Jul 1, 2021 at 8:23 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

The main protocols are BGP, OSPF, ISIS, Static

Juniper

https://www.juniper.net/documentation/en_US/junose15.1/topics/task/configuration/ip-route-administrative-distance-configuration.html


Route Source

Default Distance

Connected interface

0

Static route

1

Internal access route

2

Access route

3

External BGP

20

OSPF

110

IS-IS

115

RIP

120

Internal BGP

200

Unknown

255


Cisco

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html


Route Source
Default Distance Values
Connected interface
0
Static route
1
Enhanced Interior Gateway Routing Protocol (EIGRP) summary route
5
External Border Gateway Protocol (BGP)
20
Internal EIGRP
90
IGRP
100
OSPF
110
Intermediate System-to-Intermediate System (IS-IS)
115
Routing Information Protocol (RIP)
120
Exterior Gateway Protocol (EGP)
140
On Demand Routing (ODR)
160
External EIGRP
170
Internal BGP
200
Unknown*
255



On Thu, Jul 1, 2021 at 2:54 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
Gyan,

> My understanding is by default most all implementations that I know of for example Cisco & Juniper which have use identical default AD

Can you provide source(s) of your above information ?

To the best of my knowledge they are quite different ...

Cisco:

[cid:image001.png@01D76ECC.FA73DD40]

Juniper:

[cid:image002.png@01D76ECC.FA73DD40]

Except connected I do not see much of "identical default AD"

And that is as the draft says especially important when your intention is to control active - backup paths for a given net.

Thx,
R.


On Thu, Jul 1, 2021 at 8:02 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

Hi Enke

My understanding is by default most all implementations that I know of for example Cisco & Juniper which have use identical default AD, redistribution of the route only occurs from the source protocol that is being redistributed for example static versus OSPF or ISIS based on AD.

So if you have multiple protocols redistribution into BGP, the source protocol with the lowest AD is what is inserted into the default RIB/FIB and its that specific route from the source protocol that is redistributed into BGP.   All implementations that I know of work that way.

I don't see any issue with deterministic redistribution as exists today with implementations.

Normally you are only running one IGP but let's say you are running OSPF and ISIS and you have a Juniper and Cisco ASBR redistribution into BGP, as OSPF has default AD 110, the OSPF prefix would be inserted into the Default RIB and redistributed into BGP.  Let's say you set AD for ISIS down to 90 and now the ISIS route is inserted into the RIB and now both Juniper and Cisco ASBR Will redistribute the ISIS route into BGP.

I am not seeing the issue that you are trying to solve.

Kind Regards

Gyan

On Wed, Jun 30, 2021 at 3:19 AM Enke Chen <enchen@paloaltonetworks.com<mailto:enchen@paloaltonetworks.com>> wrote:
Hi, Robert:

1) Usually the default admin-distance is configurable. Having the same admin-distance across implementations would certainly make things simpler, but that is not required. What matters is the local_pref value for the redistribute backup route:

            local_pref = default_local_pref - delta;

It needs to be in the right order (relatively) for the "role" the route is supposed to play.

It's a good question. We will try to clarify it in the next revision.

2) Certainly it would work if we define the "delta" (or "local_pref") for the redistributed route based on its role (e.g., primary, secondary, tertiary). But extra config would be needed for specifying the "role".  The algorithm described in the draft does not require additional config other than the existing "admin-distance".  When more than two paths are involved in a multi-vendor environment, the admin-distance needs to be carefully assigned in order to get the desired local_pref value.

Thanks.   -- Enke

On Tue, Jun 29, 2021 at 1:05 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
Hi Enke,

How do you assure that admin distance is the same or delta would be the same across implementations ?

Looking at say junos I see quite different values then when comparing with other implementations ...

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-default-route-preference-values.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junos_topics_reference_general_routing-2Dprotocols-2Ddefault-2Droute-2Dpreference-2Dvalues.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=GOhXjwEf1z0GAfIQVgVAc4sHvcAog6czTO30VhKwzQk&e=>

Would it be simpler to define here verbatim what the local pref should be for redistributed routes ? Then at least those could be used as default local pref values unless overwritten by operator's policy during redistribution.

Thx,
Robert


On Tue, Jun 29, 2021 at 7:14 PM Enke Chen <enchen@paloaltonetworks.com<mailto:enchen@paloaltonetworks.com>> wrote:
Hi, Folks:

Apologies for the very long delay in updating the draft:

       https://datatracker.ietf.org/doc/draft-chen-bgp-redist/01/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dchen-2Dbgp-2Dredist_01_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=IBn3kTJmGrWISvSq8L3M9GLLamXIqw7t2PvEdtvhmos&e=>

The issue still exists, and shows up from time to time. The revised version provides a complete solution that covers the use cases involving a single router as well as multiple routers in a network.

Your review and comments are welcome.

Thanks.   -- Enke


_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=O1wpTf7XmDmE4-mQGDJ9YNEx2UVZW-k1meY3fd-tQrE&e=>
_______________________________________________
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

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

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

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

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

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

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

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347