[Idr] FW: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list
Susan Hares <shares@ndzh.com> Fri, 12 January 2024 14:24 UTC
Return-Path: <shares@ndzh.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 20A94C14CE30 for <idr@ietfa.amsl.com>; Fri, 12 Jan 2024 06:24:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy-L6py_2o7D for <idr@ietfa.amsl.com>; Fri, 12 Jan 2024 06:23:55 -0800 (PST)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2045.outbound.protection.outlook.com [40.107.237.45]) (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 44463C14CE5D for <idr@ietf.org>; Fri, 12 Jan 2024 06:23:54 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d2olAGRyIQzho1NRc54Sndjm/09kUjGesUyQt2aDQZk5Xq510v0/jb7TWkvY4yO2jRwNsPuMWvf3EeS1MBn+uSbBPq/VJ7SwZz6v1HOO2lpV2oPuuQYRZJUpmKRIDGBPTKt1XwH8EIT3wbPzBolDf0GgoaRjrBLFQuJVhf8CsEPq048CQ4MBGM/snfYC18PV9KOWKbR/3DqvC0FZWAAs5ki4MfRvhqX7Bym+p7/22qWzm/0ED7NieQqEiKTuHqYTbhRbOazA62RjZNDw58KZ8QUe+GUoP7GSVLsehRpoahJ6qacHg9XaWsQx0bzgawhJ6wd9yf0696jsAjg0/xG0ag==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aBhyMbDoEmOap7oz4xLtX1NSFipT00hmt3CrRaO0zqQ=; b=mffnhibyr5U7yes0EK+wnkAo1Wny9hX7eiuT7S5Ef4Lx0M9dK4N1rPy/ILm3w36IZXaS9B12FsZ0wzV36AL3hCzIscuyaPX+84OnhEajDX1MV1rbMpSorWSBCxRjBt90Lp56+sDKG9842Qi1TW8JJXC3dnXPb1/e16/fiNCO4I9asTxi3VA1YaLRk2wjiwqzjbhxzJ8s2w96yl8KBOt4KCBWaiBeqgcqp/ietgq/tj5idSrPXdeGbp6SlElJmFL/2PWqmsifaPWZTtfNxQwDtumrNRXJTQQ2EfkOU/yQHWjBObQDRbbwVeavWTN4bq1B6XTrgD7nrrd8bBq7ASr6KA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 104.47.59.168) smtp.rcpttodomain=ietf.org smtp.mailfrom=ndzh.com; dmarc=bestguesspass action=none header.from=ndzh.com; dkim=none (message not signed); arc=none (0)
Received: from BYAPR03CA0020.namprd03.prod.outlook.com (2603:10b6:a02:a8::33) by CO1PR08MB6676.namprd08.prod.outlook.com (2603:10b6:303:99::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.21; Fri, 12 Jan 2024 14:23:49 +0000
Received: from SJ1PEPF00001CDE.namprd05.prod.outlook.com (2603:10b6:a02:a8:cafe::4d) by BYAPR03CA0020.outlook.office365.com (2603:10b6:a02:a8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.23 via Frontend Transport; Fri, 12 Jan 2024 14:23:49 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 104.47.59.168) smtp.mailfrom=ndzh.com; dkim=none (message not signed) header.d=none;dmarc=bestguesspass action=none header.from=ndzh.com;
Received-SPF: Pass (protection.outlook.com: domain of ndzh.com designates 104.47.59.168 as permitted sender) receiver=protection.outlook.com; client-ip=104.47.59.168; helo=NAM12-DM6-obe.outbound.protection.outlook.com; pr=C
Received: from obx-outbound.inkyphishfence.com (52.4.92.69) by SJ1PEPF00001CDE.mail.protection.outlook.com (10.167.242.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.14 via Frontend Transport; Fri, 12 Jan 2024 14:23:48 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2168.outbound.protection.outlook.com [104.47.59.168]) by obx-inbound.inkyphishfence.com (Postfix) with ESMTPS id 61E2D102FE2 for <idr@ietf.org>; Fri, 12 Jan 2024 14:23:47 +0000 (UTC)
Received: from DM6PR08MB4857.namprd08.prod.outlook.com (2603:10b6:5:44::25) by CO1PR08MB6675.namprd08.prod.outlook.com (2603:10b6:303:6d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7202.13; Fri, 12 Jan 2024 14:23:44 +0000
Received: from DM6PR08MB4857.namprd08.prod.outlook.com ([fe80::572a:654:1f3a:59b4]) by DM6PR08MB4857.namprd08.prod.outlook.com ([fe80::572a:654:1f3a:59b4%6]) with mapi id 15.20.7181.015; Fri, 12 Jan 2024 14:23:43 +0000
From: Susan Hares <shares@ndzh.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list
Thread-Index: AQHaLo/WqRu7pFKlYUme4CZhI5Rp47Cpbl0AgAJFYQCAKTjZgIABfBDg
Date: Fri, 12 Jan 2024 14:23:43 +0000
Message-ID: <DM6PR08MB4857378F5081CD790D1BAEC7B36F2@DM6PR08MB4857.namprd08.prod.outlook.com>
References: <B1EC9C75-9B89-47EF-BABE-ECB085C406B7@arrcus.com> <2B7F7884-0BCE-4DD3-9D91-048A3C7C4B6F@arrcus.com> <561C2A38-1AB6-457A-9212-20D0A6208151@arrcus.com> <BYAPR08MB4872CA57601615F2A062083DB38CA@BYAPR08MB4872.namprd08.prod.outlook.com> <BYAPR08MB48722A3A096C20C57EB247E4B38CA@BYAPR08MB4872.namprd08.prod.outlook.com> <SJ0PR05MB863243535D743ADA045F97C9A292A@SJ0PR05MB8632.namprd05.prod.outlook.com> <9C1835B1-36FB-4153-9323-223604115DB1@arrcus.com>
In-Reply-To: <9C1835B1-36FB-4153-9323-223604115DB1@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2023-12-16T07:51:35.6218172Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard
x-ms-traffictypediagnostic: DM6PR08MB4857:EE_|CO1PR08MB6675:EE_|SJ1PEPF00001CDE:EE_|CO1PR08MB6676:EE_
X-MS-Office365-Filtering-Correlation-Id: 3999f827-99f9-4d24-7467-08dc137a1808
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: 1IRoM95XwNJOU1lVZ9H0IJcLrpCzxeHY92tu7AykX79cyBNU0z7CKfJLsWHepf3DGXhsdzwLFNds6ooqBncawDbF13UkuE+6oPgrC10Z+W0b2fnm+bbWCIP8un5gJuxEO5Dji5Xc3VFFQfcQYeB6Y89HxqFs7cBZ0+FL0ajxJfU2leHHc2oN1PJdw/lXJ32seOjbymHmFi5y42kZwGR8qfpGTTng4fP4Wp5LIzEx47T2AEwEpqNG2sspBGDWSBs4e5lzXtdb8PT/IEuJGIxSFJKA8WDimG9V1R/4apq8Kq1LcJhIAYP5tbuzk/SQvPVWheXalRwlIufwfBdvKi3vuwTyCLYTHijel1ySqIfDUc6xjJZ74hq0Puucfk06GNlHQztGWyfujOWSuhf96B++5Rfkxs57plXk1oVR3ubNung8eamvamGXKU6ik5Mi8MT8Aotf/4lbAZ5507lTlmf+hTe/hueAG1zUPl5HwDHsRBa9h0EPM3szJNIA+RKb5Rz2CmvNHDE5xV7+AbiRQF6DzF1+ZK8MUr6btyfqPc+kgd+mAvQihhQluLAVAb9uNRLSJKo3ZtxOCV7JaLWcl93h8I8NtAynFqoXQtUrM5jGz/nFG6ITUxszkwug69JVWhl6M6dTv+gMlYbopiu3+3sREg==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB4857.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(346002)(136003)(39830400003)(396003)(376002)(230273577357003)(230922051799003)(230173577357003)(64100799003)(451199024)(186009)(1800799012)(55016003)(71200400001)(6506007)(7696005)(66574015)(478600001)(9686003)(53546011)(26005)(38070700009)(122000001)(166002)(33656002)(38100700002)(86362001)(41300700001)(2906002)(76116006)(5660300002)(30864003)(83380400001)(66446008)(8936002)(52536014)(66946007)(8676002)(64756008)(66476007)(66556008)(316002)(6916009)(579004)(559001); DIR:OUT; SFP:1101;
Content-Type: multipart/alternative; boundary="_000_DM6PR08MB4857378F5081CD790D1BAEC7B36F2DM6PR08MB4857namp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR08MB6675
X-Inky-Outbound-Processed: True
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender: ip=[104.47.59.168]; domain=NAM12-DM6-obe.outbound.protection.outlook.com
X-MS-Exchange-ExternalOriginalInternetSender: ip=[104.47.59.168]; domain=NAM12-DM6-obe.outbound.protection.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped: SJ1PEPF00001CDE.namprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs: 49baea0f-efb6-4f32-3413-08dc137a1506
X-IPW-GroupMember: False
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: lw8Lo207E9/hLRdjV95ygVP9wYTWPyO8JAYOUP5UlD2zBM4HUP/v2XkRhrN/spleGoejmfLt7/uTyoNeDel181QK2V2kNCm5jDb6JpDOlupPAOi7fHaUPFapQIHf+7YwvvD9M0ZDm803ConBFrj9DROHTyx9SeGCQ33YrNTpC7djsDhcaLJlgpfH1TV4F25F81bdGm4DSRm+4uFHT8lGl/sbstCaq/VyakzuJuNFCUuRGlpUIxUwAG5GbT/AqCuPiICK2EmsfJRL7Xc3oniDysPsH0nIkMgOqa1bkHKAQKPK3g95AFs9qPC5nGz4kSLHtCUPloEQaDB+lPlLPrxaFu48XvWls6CKDRCnC9nXVBtGGY9nt64RGj9JYneMQPD6lxgaL01NmXJuHG2lCKNB+ObyUNe5uWO9LMf0Jen+wZIBRLJlBd3QFghaU6LOIZr96b0xlD5/3l8LhHN3PWfGOUJ+fzCizc0EqHPUP6Gyy5fAYh1+6agjSeBqiJFPqUiJt+AYf4ITmDaGQfnXQZB3utV3sg7BWtDN3tmq7blr/PrFMi/5AUpsvr0xON2lRTI3wKj0eUl5oukl3hF/K2OGPTJDJlw+ik2/rImpfUjHZBRiaANcdkrnsIaQOC56z9gdQopZnuk8DtN4ecAKgml/YKdTACUFNxPDllvPM5AO9HHH9YqWgw6lDU5l/Oe9Qqzo8kMHNdFgp4nRibByOJ3iByzNvWWHwh0cNah8vgdL5VUHFLbxRsFlF5PWKIONH0OhA2Kry1Kj0khAxjM7F5j60g8Xfkkutwk0vmVQV/amBa7VzB8xMuzV7MZqS1/UA+O65Q2qKujs7DqK32KGJSn7qhJjJmJAWO2oK5/h4j36NR/PydolWH0VLaFJnY6I3ElayP2M/j2sc3n04VThGaRtAj+v8+0lM1ACCQ6/W9V/9rg=
X-Forefront-Antispam-Report: CIP:52.4.92.69; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:NAM12-DM6-obe.outbound.protection.outlook.com; PTR:mail-dm6nam12lp2168.outbound.protection.outlook.com; CAT:NONE; SFS:(13230031)(346002)(136003)(39830400003)(396003)(376002)(230273577357003)(230922051799003)(230173577357003)(64100799003)(451199024)(186009)(82310400011)(1800799012)(46966006)(36840700001)(40480700001)(55016003)(336012)(6506007)(7696005)(66574015)(478600001)(9686003)(53546011)(26005)(33964004)(166002)(33656002)(7636003)(86362001)(41300700001)(2906002)(36860700001)(47076005)(5660300002)(32850700003)(30864003)(83380400001)(70586007)(8936002)(52536014)(70206006)(45080400002)(8676002)(156005)(316002)(6916009)(579004)(559001); DIR:OUT; SFP:1101;
X-OriginatorOrg: ndzh.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2024 14:23:48.8037 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3999f827-99f9-4d24-7467-08dc137a1808
X-MS-Exchange-CrossTenant-Id: d6c573f1-34ce-4e5a-8411-94cc752db3e5
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d6c573f1-34ce-4e5a-8411-94cc752db3e5; Ip=[52.4.92.69]; Helo=[obx-outbound.inkyphishfence.com]
X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00001CDE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR08MB6676
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/W1nip0dzudxSbw_F9sHxCRfsUlI>
Subject: [Idr] FW: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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, 12 Jan 2024 14:24:00 -0000
Keyur’s response for the discussion From: Keyur Patel <keyur@arrcus.com> Sent: Thursday, January 11, 2024 6:43 PM To: Kaliraj Vairavakkalai <kaliraj@juniper.net>; Susan Hares <shares@ndzh.com>; Natrajan Venkataraman <natv@juniper.net>; Reshma Das <dreshma@juniper.net> Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Jeffrey Haas <jhaas@pfrc.org>; Jeff Haas <jhaas@juniper.net> Subject: Re: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list Hi Kaliraj, HNY! Thanks for the note and apologies for the delayed response. My responses are inlined #Keyur External (keyur@arrcus.com<mailto:keyur@arrcus.com>) Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2U2NTMwNDk3Y2NkMGNlNGQ2ZWYxNzkwN2E0MzQxOTE0LzE3MDUwMTY1OTMuNTk=#key=a4addfdeb1dd17b92e37f6b4745ad3ec> FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813> GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky> Hi Kaliraj, HNY! Thanks for the note and apologies for the delayed response. My responses are inlined #Keyur From: Kaliraj Vairavakkalai <kaliraj@juniper.net<mailto:kaliraj@juniper.net>> Date: Saturday, December 16, 2023 at 2:13 AM To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>, Natrajan Venkataraman <natv@juniper.net<mailto:natv@juniper.net>>, Reshma Das <dreshma@juniper.net<mailto:dreshma@juniper.net>> Cc: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>, "Dongjie (Jimmy)" <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, Jeff Haas <jhaas@juniper.net<mailto:jhaas@juniper.net>> Subject: Re: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list Hi Susan, Keyur, please see inline for responses. KV> Thanks Kaliraj Juniper Business Use Only From: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> Date: Thursday, December 14, 2023 at 3:32 PM To: Kaliraj Vairavakkalai <kaliraj@juniper.net<mailto:kaliraj@juniper.net>>, Natrajan Venkataraman <natv@juniper.net<mailto:natv@juniper.net>>, Reshma Das <dreshma@juniper.net<mailto:dreshma@juniper.net>> Cc: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>, Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, Jeff Haas <jhaas@juniper.net<mailto:jhaas@juniper.net>> Subject: FW: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list [External Email. Be cautious of content] Kaliraj, Nats, and Reshma: Here’s the review that Keyur created on 12/8/2023. Please send me comments on the review. You should also reply to Keyur’s when he sends it to IDR@ietf.org<mailto:IDR@ietf.org>. Sue From: Susan Hares Sent: Thursday, December 14, 2023 8:17 AM To: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>> Subject: FW: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list Keyur: I apologize for not sending this on Monday. Please send this to the IDR list as your review comments (chair). Cheerily, Sue From: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>> Sent: Monday, December 11, 2023 9:19 AM To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; Susan Hares <susaha1@regent.edu<mailto:susaha1@regent.edu>> Subject: Fwd: Review on - draft-ietf-idr-bgp-ct-18 Begin forwarded message: From: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>> Date: December 8, 2023 at 12:13:37 PM PST To: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org> Subject: Re: Review on - draft-ietf-idr-bgp-ct-18 Forgot to mention that I will send it to authors as well (as have been chatting with them). I haven’t told them but the draft does need serious work. From: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>> Date: Friday, December 8, 2023 at 12:12 PM To: "idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>" <idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>> Subject: Review on - draft-ietf-idr-bgp-ct-18 Comments attached. Apologies for typos and any other issues. 😊 1) Section 1. <snip> The mechanisms defined in this document are agnostic to the tunneling technologies. These can be applied homogeneously to intra-domain tunneling technologies used in brownfield networks as well as greenfield networks. E.g. MPLS Traffic Engineering (TE) or Segment Routing (SR)). <snip> #Keyur: SRv6 is not supported. GRE and Vxlan not support so really not agnostic to tunneling. Can we replace agnostic? KV> Tunnels like SRv6, GRE, VxLan etc are also supported in the architecture. The architecture supports any kind of tunnels. KV> The tunneling mechanism is made transport-class aware and they install their tunnel route in corresponding TRDB, as explained in Sec 4.1. KV> SRv6 support is specifically explained in detail in draft-ietf-idr-bgp-ct-srv6-00, referenced in Sec 7.13 in BGP-CT draft-v18. #Keyur: Can you call out in that case that the architecture supports all tunnels and has not tunnel based limitations? 2) Section 1. <snip> The constructs defined in this document are used to classify and group these intra-domain tunnels based on their TE characteristics (e.g., low latency), into identifiable classes, thus making them "intent-aware". <snip> #Keyur: Is it TE characteristics or more Services specific intent? KV> It is TE characteristics. The tunnels have specific TE characteristics. The service-intent maps to some such TE-characteristics. KV> Operators consider a set of TE characteristics to denote a certain TransportClass. The Service Intent is what TC to use as primary KV> and what TC to use as fallback.. etc. #Keyur: But the draft doesn’t list out TE characteristics. Infact your service intent could be broader than just mapping to TE-characteristics (i.e providing internet or an ipsec as a service over a common backbone). 3) Minor nit Section 2.1. <snip> BGP Community Like Attribute (CLA) <snip> #Keyur: The use of "Like" in the attribute naming is confusing. Can we choose a better name please? KV> It is used to suggest all BGP attributes that carry community/extended-community/large-community KV> This term is used in draft-zzhang-idr-bgp-rt-constrains-extension-03 KV> Please suggest a different name. “Community Carrying Attribute”? #Keyur: Ok with Community Carrying Attribute. 😊 4) Minor Nits Section 3.0. #Keyur: Please Define L1, L2, L3, L4. Please Define IP1, IP2, IP3, IP4 (BGP-LU/underlay prefixes) KV> IP1, IP2, IP3 are Service family Prefixes (e.g. AFI/SAFI: 1/1). It is shown in the figure as ‘INET Service’. I can clarify this in the text. #Keyur: Thanks. 5) Section 3.0. <snip> BGP CT family carries transport prefixes across tunnel domain boundaries (e.g., in inter-AS Option C networks), which is parallel to BGP LU (AFI/SAFIs 1/4 or 2/4). <snip> #Keyur: Please consider removing (e.g., in inter-AS Option C networks). KV> it is helpful in clarifying BGP CT is applicable to option-C networks. KV> This was added based on suggestions in some previous reviews. #Keyur: I was suggesting broader scope that includes option-C as well. 6) Section 3.0. <snip> It disseminates "Transport Class" information for the transport prefixes across the participating domains, which is not possible with BGP LU. <snip> #Keyur:This line is confusing. The confusion to me is as to why BGP LU doesn’t do it. KV> BGP LU doesn’t do it, because of Path-hiding (it doesn’t have a distinguisher in NLRI) KV> And it doesn’t carry something like a TC-RT, which plays the role of RT as-well as Mapping community. KV> we could use some community and user configured policies to achieve all that, but CT automates it. #Keyur: And that is why (community and user configured policies is one way to achieve) its confusing. Maybe consider removing the line “which is not possible with BGP LU”. 7) Section 3.0. IP1, IP2, IP3 and IP4 are BGP-LU color routes. They are typically used for creating the slice/intent based forwarding as described. KV> IP1, IP2, IP3 are AFI/SAFI:1/1 routes, as explained above. Not BGP LU. <snip> Overlay routes carry sufficient indication of the desired Transport Classes using a BGP community which assumes the role of as a "Mapping Community". A Resolution Scheme is identified by its "Mapping Community", where its configuration can either be auto-generated based on TC ID or done manually. <snip> #Keyur: This part is collapsed in the picture and so is confusing. Maybe some clarifying text can help. KV> The pic is an eye candy summary of the various pieces in the architecture. KV> And this text introduces and explains those pieces. If you have any suggestion text KV> with imrpvoed clarity, pls share. I will also try to improve it.. #Keyur: Thanks. 8) Section 3.0. #Keyur: Minor Nits- Define Tunnel Endpoint Address (EP) in the section 2 KV> OK. Will do. 9) Clarification Section 4.2. <snip> An implementation may realize the TRDB e.g., as a "Routing Table" referred in Section 9.1.2.1 of RFC4271 (https://www.rfc-<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjl1PgzAYRv_KIF4KtEJbOm9GlM2PTUwkOr0hrLwMBgNtQQTjf9caL7x8npOcnE-zl7U5n5lF172queP8zAxyaBTYoj06766TJH9sGAZb5sJKknPDuAs7Om7SyNpXxhX5CMrpOd4FShwgvXiZtmN_Gd5v8u1q1Yv1qHZRTiMWksdgvZRW-BSyCODI-7ir_WUZp_X1WxvTw83DrV9WJ-bpzKx0VANdK_cYEZ9yfOaoIpWgFk02Fb9xQImLPM6EyJAAL6OQY8YRSz3Xwxx7DmaIIEwJd23CtRW0tYKxl4tUStEr7dEg0-Df9fUNhONX7g.MEUCIQDRdz4I79PwzCg_YqFGBp9Wxk9lLHiTMD9Gz2jONCEV5wIgQs5wEv4qEy3iksiqNGQ4smV7CiWSmLijiHxQu48Rk5Q> editor.org/rfc/rfc4271#section-9.1.2.1)<https://shared.outlook.inky.com/link?domain=editor.org&t=h.eJxNjDsOwjAQRK-CTIUEtjfxB6fKVSJ781EgRmunAMTdYTuKaebNvLfY6Sa6g5hrfXRKYVpqJplpUjRGjmk8HAvGuuTtEiTIRsJJnA9i5duGv_kE2l5dgEaVeSAs_ZZes4z5rtDZVpvgY0w6okkOR_BB-8G0BgIYBV5bDc6GVtrAVmTris-d-oEo7oU9DBKDv-rzBXQ0Nrs.MEYCIQCzcEglKfoI-lbLFwHqoE70ZArI6SfDAdlFrQzjVXcRmwIhAM1NMfH8Pw7M1AWuBa2wpFSAj3YzoufKYwRwVOND5L-w> which is "only" used for resolving next hop reachability in control plane with no footprint in forwarding plane. However, an implementation may choose a different methodology to realize this logical construct while still adhering to the procedures defined in this document. <snip> #Keyur: This seems very rsvp specific? In case of pure segment routing where the control plane does carry nexthop specific information, this won’t be correct. Suggest removing everything from "with no footprint..." KV> Its not RSVP specific. Even SRTE routes in a TRDB don’t need to be installed to FIB as a FEC/destination. Only if they are resolved over by another overlay route, KV> it will be installed as nexthop. I can try to clarify this in the text. 10) Section 4.2. <snip> SNs or BNs originate routes for 'Classful Transport' address family from the TRDB. These routes have NLRI "RD:Endpoint", Transport Class RT and an MPLS label (or an identifier that represents an equivalent of a label in a different forwarding architecture). <snip> #Keyur: It could be more than an identifier (Tunnel class and tunnel parameters). Curious as to why mention the text in ()? KV> text in () refers to other encaps like SID in SR forwarding architecture. It is denote support for different forwarding architectures. #Keyur: Can we remove the text in question for better readability? 11) Major Comment Section 4.3. <snip> A BGP speaker that implements RT Constraint Route Target Constraints [RFC4684] MUST apply the RT Constraint procedures to the Transport Class Route Target Extended community as well. <snip> #Keyur: 1) This text needs to be augment to account bunch of SAFIs defined in this draft. KV> Following text mentions that: “Constrained Route Distribution mechanisms as specified in Route Target Constraints<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNzEsOwiAUheGtGJzKywItHZmYuAB3gHArTVttLtRGjXtXZk7Pn_O9yYIjaTck5jynlvN1XVkPuWN3vHKHPvYP4H3gAV2XaSm0D0gv15n6TGXDYp7G7fl0VKZRZLchQ9FukH9_KXRjrNzzFB1COtzCKzJ_nzgYXQlla--D8KCCgU7WVtROVUpaqbishRbSaFsxbYsKRR3gueDBIfolFaeEUMLf9PkCS50_wA.MEUCIHeOzI6dJkbZWSQdIs1TMBhPJ4ME7iHDeb5Sc-EmeSczAiEA_us4iunzhPLSS5ff7l6fUiI4YqQdCfnB5xGvSvrDBbo> [RFC4684<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNzEsOwiAUheGtGJzKywItHZmYuAB3gHArTVttLtRGjXtXZk7Pn_O9yYIjaTck5jynlvN1XVkPuWN3vHKHPvYP4H3gAV2XaSm0D0gv15n6TGXDYp7G7fl0VKZRZLchQ9FukH9_KXRjrNzzFB1COtzCKzJ_nzgYXQlla--D8KCCgU7WVtROVUpaqbishRbSaFsxbYsKRR3gueDBIfolFaeEUMLf9PkCS50_wA.MEUCIHeOzI6dJkbZWSQdIs1TMBhPJ4ME7iHDeb5Sc-EmeSczAiEA_us4iunzhPLSS5ff7l6fUiI4YqQdCfnB5xGvSvrDBbo>] can be applied to BGP CT routes using its Transport Class Route Target Extended community.”. KV> May be I can add SAFI 76 value specifically in it. #Keyur: Ack. 2) If these routes need to be leaked into EBGP domains.. RTC doesn’t provide multi-paths by default and so implementation should give some guidance. KV> RTC has number of external-paths config control. Which is used for CT routes also. #Keyur: You may still need text as RTC doesn’t provide multi-paths? 3) Also guidance should be provided about filtering of this community where needed (as it is defined as a transitive community). KV> Since CT follows RFC8212 by default, explicit import/export policies are needed to send/receive CT routes with this community across EBGP boundaries. KV> and the routes propagate only until the sessions where CT SAFI is negotiated, and don’t intermix with other SAFIs. I think these sections cover this aspect? #Keyur: RFC8212 doesn’t provide guidance on stripping transitive communities. You may have to provide it as part of this draft? 12) Section 5.1. #Keyur: I like the concept in section 5.1 but any reason why mapping community is not preferred to be one of color, transport target, or a RT? If the mapping community is preferred (as it seems) then some descriptive text would help. KV> Mapping community is not a IANA type, it is a role. So yes, either of these communities (color-ext-community, transport-class-RT) can be used as a Mapping-community. KV> This is what is described in Sec 5.1. Not sure what I am missing.. #Keyur: The text here is generic. What happens if multiple communities are carried in a single attribute? Any guidance on which one to be used first? 13) Section 6.2. #Keyur: What are error conditions in cases the nexthop length is other than specified? Will these routes accepted or still ignored? KV> rfc7606 Sec 7.11 talks about nexthop length error in MP_REACH. I don’t think bgp-ct draft needs to redefine that. Same logic should apply here also, since we are using the same MP_REACH attribute. #Keyur: As part of this draft you have specified behavior of 4, 16, 32, 24, 48, 12. Possible to add a line that says “anything else is an error and error handling should be done according to 7606 w treat as withdraw” ? 14) Major Comment Section 6.4. <snip> In this document, SAFI 76 (BGP CT) is used instead of reusing SAFI 128 (BGP VPN) for AFIs 1 or 2 to carry these transport routes because it is operationally advantageous to segregate transport and service prefixes into separate address families. For e.g., such an approach allows operators to safely enable "per-prefix" label allocation scheme for Classful Transport prefixes, typically with a space complexity of O(1K) to O(100K), without affecting SAFI 128 service prefixes, with a space complexity of O(1M). The "per prefix" label allocation scheme keeps the routing churn local during topology changes. <snip> #Keyur: 1) This suggest don’t use L3VPN safis. But if L3VPN SAFI is enabled, what are the implications? Some text to that point would be useful. KV> No, it doesn’t suggest not to use L3VPN SAFI. It is just explaining why a new SAFI 76 was created instead of overloading SAFI-128 for carrying Transport-layer routes. KV> SAFI 128 is indeed used with SAFI 76. #Keyur: You could try and make text a bit more clear. Also what happens if L3vpn is enabled in the network. Some text to that point would be helpful as well. 2) What about other VPN SAFIs (Layer2/EVPN)? Either it has to be out of scope or defined? KV> Yes all service families (EVPN, L2VPN, VPLS) are used with SAFI 76. Just like SAFI 4. All of this is implemented and qualified. #Keyur: Can you please change text? 128 is ONLY BGP MPLS VPN safi. 😊 EVPN is 70 😊 15) Section 7.2. <snip> this route SHOULD NOT be advertised to the IBGP core that contains the tunnel, using policy configuration. Impact of not prohibiting such advertisements is outside the scope of this document. <snip> #Keyur: I am assuming this line has an exception to a RR and Confeds? KV> No, it doesn’t exclude RR-peers/IBGP-peers-in-Confed. Basically, Tunnels in a domain need to be exported out in BGP to other adjacent domains only, not the same domain that contains the tunnel. #Keyur: I am confused. Are you suggesting that such route announcements SHOULD not be done by a RR for example? Can you clarify please? 16) Section 7.3. <snip> The resolution scheme for a Transport Class RT with Transport Class ID "C1" contains TRDB for Transport Class with same ID. In cases where Transport Class "C1" tunnels are not available in a domain, the administrator MAY customize the resolution scheme to map to a different set of transport classes available in that domain. <snip> #Keyur: How does this work with section 4.3 where RT Constrain is enabled? KV> RTC will work for both the TCs C1 and availble-TC-ID. Because both those TCs are configured, RTC membership request will be advertised for both TC-RTs. KV> Rules specified in RTC RFC apply for these cases also.. #Keyur: I didn’t see any text to that point you cited? 17) Section 7.3 <snip> RD is stripped by the ingress node from the BGP CT NLRI prefix RD:EP when a BGP CT route is added to a TRDB. So that service routes can resolve over this BGP CT tunnel route for EP. This step applies only if the Transport Class RT is received on a BGP route in address family with SAFI 76. <snip> #Keyur: Isn’t this an implementation specific text? KV> No. TRDB only contains the IP prefix without RD. And these IP routes are used to resolve BGP NHs. So RD should not be there. #Keyur: But there is no reason why an implementation has to strip RD? it can keep it if it wants? Hence my comment of being implementation specific text. 18) Section 7.4. #Keyur: What is the purpose of this paragraph. It suggests implicitly that third party nexthops shouldn’t be supported? KV> No. It just explains how label-swap happens when doing nexthop-self. BGP practices like third-party nexthop or nexthop-unchanged are not prohibited. #Keyur: Then I suggest either making it clear or removing the text. 19) Major Comment Section 7.7. & 7.7.1. #Keyur: The looping issue define in 7.7 and 7.7.1 is well understood? The solutions to these looping issues are also well understood. What is the purpose of these sections? The text in 7.7.1 is now updating a Route Reflector RFC for this SAFI? IMHO this text SHOULD be pulled out. KV> It is tribal knowledge that is not documented in any draft/RFC (I was actualy surprised), And it is very important to document this, because customers may hit it in the field when deploying CT, which uses RRs with nexthop-self. So, documenting it in this draft. #Keyur: How is the deployment of CT with nexthop-self going to be any different from other SAFI routes with nexthop-self? Btw the tribal knowledge is well understood across industry and you could write a separate draft if you feel strongly about it. 😊 20) Section 7.8. #Keyur: Does the Mapping community need to be tied with RTC? KV> No. Mapping-community doesn’t interact with RTC. Only the TC-RT interacts with RTC because it is a RT. 21) Major Comment Section 7.10. <snip> It should be noted that in such cases "Transport Class ID/Color" can exist in multiple places on the same route, and a precedence order needs to be established to determine which Transport Class the route's next hop should resolve over. This document suggests the following order of precedence, more specific scoping of Color preferred to less specific scoping: Transport Class ID SubTLV, in MultiNexthop Attribute. Color SubTLV, in Tunnel Encapsulation Attribute. Transport Target Extended community, on BGP CT route. Color Extended community, on BGP service route. <snip> #Keyur: This draft has MNH in informative section. :) KV> It is mentioned to provide comprehensive and unambiguous rules wrt deciding ‘effective color’. I think this kind of reference is OK for informative? #Keyur: Section 7.10 talks about Interaction with BGP Attributes specifying Nexthop Address and Color. As part of this section the document suggest the order of precedence which has rules. If you want multinexthop attribute there you want the draft as a normative (and not as an informative). I will let Jeff chime in here. 😊 22) Section 7.13. #Keyur: SRv6 support. Not sure what the section is trying to say from the normative pov? KV> It is pointing to the document that explains in detail the SRv6 procedures for BGP CT. #Keyur: You could simply says it is covered in a separate doc and out of scope. Instead you have a normative language for SRv6. Any reason to keep it in this section? 23) Section 7.14. #Keyur: Error handling may need more serious look. KV> I cant think of any other error-handling scenarios. Pls send suggestions or text. KV> Thanks for the detailed review!. #Keyur: Ack. Will do one more pass soon. [EXTERNAL]
- [Idr] FW: Review on - draft-ietf-idr-bgp-ct-18 - … Susan Hares
- Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - … Susan Hares
- Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - … Kaliraj Vairavakkalai
- Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - … Kaliraj Vairavakkalai
- Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - … Kaliraj Vairavakkalai