Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/24/2023)
Susan Hares <shares@ndzh.com> Fri, 10 November 2023 02:28 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 6B476C0A8592 for <idr@ietfa.amsl.com>; Thu, 9 Nov 2023 18:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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_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 nIwMWREK11e5 for <idr@ietfa.amsl.com>; Thu, 9 Nov 2023 18:28:38 -0800 (PST)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2059.outbound.protection.outlook.com [40.107.92.59]) (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 43F44C0A8590 for <idr@ietf.org>; Thu, 9 Nov 2023 18:28:17 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V6tYGE7OY0SbjuGM0kqgOykt+9ildztigqvDd0RjJPu0487JXLglYpkxlYNXk4eenZU/3o8dDU7tqN24iNGwgzZf137+86R48lbIQY1p/LQ9ZbKYgscDFnYWfquWB3s3fqcsmASYy2ZtYuu4eG85cvQ5wHaHZnlzNyQUqM0p4Tfp2YJ/llHHGBoWFotw5PYsXertXGYjOhCK7U5JhMNns+nJPFG6D+GGDudrkXiDHyukfxGHJWCS8Nl31jNJIByoYUxkGt17qivPqcZOJnYSp+FgUnSHgMyA8RPdWKLx+CRhyE4OPcEXuyLzNvnlFU9NxwMSQZ44sNxbsFusmO0dIA==
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=zdPILp8Jal10X/TAqWcu56snx+1rp5Vf83gd1I+H5v0=; b=C19sask+RTa3poCNiax9KZMYq6qMeATZnod43Hk13QkKUYyqVaduF4JYjaZA3PpNoF0IKi5WO5Skk3rjizRwGnQAL2GhPpg95s0XRa7Klvv0mPs48beIOBoBC3uIN6YAn7UuP4Zc4eyIFAUXpbkB934Vm5HBjVJEC8UGjbPap0Gs1mxb+FwtWKYsegey1NYdOIFPlt+BzYao44KzshSqVjoEuu+OsHsujp1rfSKRZD0303p1DvT1MEul7HuRSelJKE2VItz6I6bWHnqr5j6DBWj2Boxjg1ZAKg/TMgibP6SAcmHo5CJRpM7EIAYW96FlxGXg3PwFXn85P5dBJAFI1w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 104.47.70.101) 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 MW4PR04CA0225.namprd04.prod.outlook.com (2603:10b6:303:87::20) by DS0PR08MB9112.namprd08.prod.outlook.com (2603:10b6:8:1b9::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.29; Fri, 10 Nov 2023 02:28:12 +0000
Received: from MW2NAM12FT005.eop-nam12.prod.protection.outlook.com (2603:10b6:303:87:cafe::f8) by MW4PR04CA0225.outlook.office365.com (2603:10b6:303:87::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.19 via Frontend Transport; Fri, 10 Nov 2023 02:28:12 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 104.47.70.101) 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.70.101 as permitted sender) receiver=protection.outlook.com; client-ip=104.47.70.101; helo=NAM10-BN7-obe.outbound.protection.outlook.com; pr=C
Received: from obx-outbound.inkyphishfence.com (35.166.188.152) by MW2NAM12FT005.mail.protection.outlook.com (10.13.180.72) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7002.4 via Frontend Transport; Fri, 10 Nov 2023 02:28:11 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) by obx-inbound.inkyphishfence.com (Postfix) with ESMTPS id 4BBA010618D; Fri, 10 Nov 2023 02:28:10 +0000 (UTC)
Received: from BYAPR08MB4872.namprd08.prod.outlook.com (2603:10b6:a03:70::17) by DM4PR08MB8224.namprd08.prod.outlook.com (2603:10b6:8:47::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.29; Fri, 10 Nov 2023 02:28:04 +0000
Received: from BYAPR08MB4872.namprd08.prod.outlook.com ([fe80::4e94:fb94:b53b:f0e9]) by BYAPR08MB4872.namprd08.prod.outlook.com ([fe80::4e94:fb94:b53b:f0e9%4]) with mapi id 15.20.6977.018; Fri, 10 Nov 2023 02:28:04 +0000
From: Susan Hares <shares@ndzh.com>
To: Natrajan Venkataraman <natv@juniper.net>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/24/2023)
Thread-Index: AQHaEq/nHWLXnfecS0S5shIuGTn2krBy1YYg
Date: Fri, 10 Nov 2023 02:28:03 +0000
Message-ID: <BYAPR08MB4872854D21AEA71294F36C34B3AEA@BYAPR08MB4872.namprd08.prod.outlook.com>
References: <BYAPR08MB487246E024BD1BD1B3993E74B337A@BYAPR08MB4872.namprd08.prod.outlook.com> <BY3PR05MB8050A43BA165CD0B23A8BEA8D9AFA@BY3PR05MB8050.namprd05.prod.outlook.com>
In-Reply-To: <BY3PR05MB8050A43BA165CD0B23A8BEA8D9AFA@BY3PR05MB8050.namprd05.prod.outlook.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-11-09T01:51:29.6448914Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard
x-ms-traffictypediagnostic: BYAPR08MB4872:EE_|DM4PR08MB8224:EE_|MW2NAM12FT005:EE_|DS0PR08MB9112:EE_
X-MS-Office365-Filtering-Correlation-Id: b3922542-163d-4568-7413-08dbe194af82
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: cAwO1y4TjrF5qeGUwhRkVh/cg2qeaXA5c/91MKYvwJo2kJTa22k7Wpuy+ERi+xvDcd5+kL6jf2yolROydB84hLQkkpd23oAn/4uGuu4DTFLn2iUM1GN7UB3+3gjQI1erXvZ/BNnlKAwUqPVuiJxyK9XJFGO0784y1ghQ16YbPh/LxcIy7bxZzZBIMFb3vMQVw0Knlc5qsHYo6HDDWfUBrD4ImFdpdwWPBqEUuJe8sw7iromqWlpmeOPk+5Ddks6RYDLK7OZbAl3NTnndmAKef61Wstie04PKNYkU+Ouj6DB2ZPOpX9bgdHq4LvEmh7/BUsx6bKUrOcfuafFJIMfCpygYbjpuXRWwYfBEhiT9XYKBQP0V6ryToxST7wwJMlPflljEUtmJj+8TmiRZMsP2zgW2mcLGkRTT6IGZa2Oe7igMMb1SBwfXtJjiPxdLSErfx1MDOkVHZ2Edc7iRO8S0uGvRELVjB2q0j1EQfsZfFtn1jgYGfdkOdDdwaTVXppuzCYraVuN6vUQUeVmh+8p+Wz7zo0EoYLBTf7yhN3Lfvk9ujVbJqRQP4psz5GXDCU7UKrNLOUg5XUBiHLDtF+MiUjh89vBhCyTqBhHLuX36hVgFMlWbfbai9Fbn5JCvz1ejyGsWo7mhU4C8OK3qwjMhMg==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR08MB4872.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(136003)(366004)(396003)(346002)(376002)(39830400003)(230922051799003)(230173577357003)(230273577357003)(451199024)(186009)(64100799003)(1800799009)(4326008)(66556008)(64756008)(41300700001)(66446008)(38100700002)(8676002)(166002)(66476007)(110136005)(52536014)(66946007)(86362001)(76116006)(122000001)(33656002)(7696005)(2906002)(5660300002)(478600001)(966005)(53546011)(316002)(9686003)(30864003)(6506007)(8936002)(71200400001)(38070700009)(83380400001)(55016003)(559001)(579004); DIR:OUT; SFP:1101;
Content-Type: multipart/alternative; boundary="_000_BYAPR08MB4872854D21AEA71294F36C34B3AEABYAPR08MB4872namp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR08MB8224
X-Inky-Outbound-Processed: True
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender: ip=[104.47.70.101]; domain=NAM10-BN7-obe.outbound.protection.outlook.com
X-MS-Exchange-ExternalOriginalInternetSender: ip=[104.47.70.101]; domain=NAM10-BN7-obe.outbound.protection.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped: MW2NAM12FT005.eop-nam12.prod.protection.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs: ead939a6-877b-4254-45db-08dbe194aab8
X-IPW-GroupMember: False
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: n5BypfKfGmCBNfPoRQTXdtief5qEzGyXYcXgOOgXhprdSzs1k/FKFeAEMkPv1wmnr9BPetmNYRDP/PKlbTKTeeqJc/zwTdHEcsTnzbBkkUICBb22ctILhGq6osjM2JmfxbHhC5jtHaCSUhc+Xn8F1EL2EFpPX05iKUyZ+HQ+m6OEDRgZ5tMKnsiUU1DauI+lLPRCRMf8yaQDw36P/L50RdKuHiWUaFraaybHYJXUZKcRMrLTapYyyR6kVft/hfB54caBssbYE8VtiUOlptRzeomCHQnnWCA306zNd2liVyiePamab/Pj961QiSCLrQC5lHhVyL0H4a9IIoZacfmlE5zwZboTCtUJYqWATc3rALrBwuVLye/vvDBKC8oA8AEi5UGM3dU+HDKoFd5H8q2dt9ttBMpy3MOb4cjOI2V7T/PAEoxT3awBk9zF7bp9Jcg6h/6HIkCCme19520rhdp8+To0lBFH8QGTjEF8Aa061dmwHlndSiwLK08LbBA3RbgtAqGcS01SSB2j8+ZhyOHy+2KUNp27fFiaOK/skO5mhfFGukuVKjDJMztbMgHgK1NGJUHJ1OoJXHqxEDIpTrWKhC6S+f2hcF++db9R6H+JWIiCa7n8nneXoI/+tACXfg7YcGKEUOTM3y+w6CSBQiexNvrdSsqzpy4gw7/J8kc1tiLvWX6n6XD3VJo2LbzIzfdzmlE/lf0m4VYeJAyw6Ki9Vt5+K4fwpgl7rYZOhGhWHyUBp+aSz7obkRuZIElk05rOmCuvFI36lOVT/OkTWkkznhSBO+IbpeqqHuTL0Ysi9WPB784i5Oh+rRbJQMC8AwR5eVyWAy9DgJ+H1NZ3i2Kneak+w8rqklV1XU0dV34YrMzHTdWBE0tg0UietAfh49lbFGKZxnGOC2CGDBpC5xIB8y8s5URH6xEu91Bp/XBb44hEGokJPQUQUE0Z0R335eU7
X-Forefront-Antispam-Report: CIP:35.166.188.152; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:NAM10-BN7-obe.outbound.protection.outlook.com; PTR:mail-bn7nam10lp2101.outbound.protection.outlook.com; CAT:NONE; SFS:(13230031)(346002)(39830400003)(376002)(396003)(136003)(230273577357003)(230922051799003)(230173577357003)(186009)(451199024)(82310400011)(1800799009)(64100799003)(36840700001)(46966006)(6506007)(53546011)(7696005)(86362001)(70206006)(70586007)(55016003)(52536014)(8936002)(156005)(478600001)(32850700003)(966005)(8676002)(4326008)(45080400002)(30864003)(9686003)(316002)(33656002)(40480700001)(5660300002)(110136005)(2906002)(26005)(336012)(83380400001)(47076005)(36860700001)(41300700001)(7636003)(166002)(579004)(559001); DIR:OUT; SFP:1101;
X-OriginatorOrg: ndzh.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2023 02:28:11.8403 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b3922542-163d-4568-7413-08dbe194af82
X-MS-Exchange-CrossTenant-Id: d6c573f1-34ce-4e5a-8411-94cc752db3e5
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d6c573f1-34ce-4e5a-8411-94cc752db3e5; Ip=[35.166.188.152]; Helo=[obx-outbound.inkyphishfence.com]
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT005.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR08MB9112
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_LE4xyHryhvgYXBoe_iQa9UgmvE>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/24/2023)
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, 10 Nov 2023 02:28:43 -0000
Nats: Thank you for this review. I look forward to the CAR author's feedback. Sue From: Natrajan Venkataraman <natv@juniper.net> Sent: Wednesday, November 8, 2023 8:56 PM To: Susan Hares <shares@ndzh.com>; idr@ietf.org Cc: Reshma Das <dreshma@juniper.net> Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/24/2023) Hi Susan and WG members, The following review is for - BGP-CAR-03 (draft-ietf-idr-bgp-car-03) with respect to the intent-driven service mapping problem and how it addresses provider network deployment External (natv@juniper.net<mailto:natv@juniper.net>) Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzVjNzdjMDQwZjRjMmEwM2ExY2EzMWViZTYzM2VkMzgwLzE2OTk0OTQ5NjEuMTY=#key=ed9ef0d94f5315b2af2eadf07bed8abc> 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 Susan and WG members, The following review is for - BGP-CAR-03 (draft-ietf-idr-bgp-car-03) with respect to the intent-driven service mapping problem and how it addresses provider network deployment scenarios that are seen today, while mainly focusing on the issues raised in IDR GitHub by the CT team. - https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxNjcsOgyAURH_FsC4CovhY-SsIV6APNDzapE3_veKqmdXMSc58UA53NFXIprTHiRDjks1LrbYHcZBW_DLY6UB0kGvC53JUvJgdKxmIizFDRJcK3YrEQ9qCYbQbxMgaEq0MEGev3_YUdqrvFW3p2qpGUi6ZkpzBAoJz0HyghIlxbI8IVjNRrHBaZXrO1-zdDqE-LgrQBfxv3x_qtT8P.MEUCIQCoAlQWkHk4bWHwHAgl-DPvjIh2WvpU5uWBJ9CudW7VQwIgfC3fk_dTKu0NH4GWfIXEwWAJ-6J6m6uQk_eQUuF4nD0> 1) F3-CAR-Issue-1: BGP-CAR Appendix A.7 - Anycast EP Scenario: 2) F3-CAR-Issue-2: BGP-CAR - Consensus on the need for resolution-schemes 3) F3-CAR-Issue-3: CAR-Q3 - Handling [of] LCM and Color-EC 4) F3-CAR-Q4: Mis-Routing in Non-agreeing color-domains for Anycast EPs 5) F3-CAR-Q5: Update Packing Observations Having spent considerable amount of time for this review, I hope it helps operators/vendors to, - Get closer to this problem space - Understand how CAR achieves different aspects of service mapping - Get implementation insights for CAR based service mapping - How different deployment scenarios are handled by this draft Verdict: Has Issues =================== Setting up Key Aspects: ======================= Quoting from RFC 1925: Twelve Networking Truths: (4) Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network. Before we begin, Intent-driven service mapping using BGP is a substantial effort. It applies to "all" BGP Service Families whose nexthop is reachable via transport tunnels. These tunnels belong to various forwarding architectures such as MPLS (RSVP-TE, SRTE), IPv6 (SRv6), IPinIP or MPLSoverUDP. It introduces new constructs that allow for an operator to be able to specify the service intent. Therefore, this is a substantial upgrade for existing provider network deployment scenarios such as MPLS-VPN Options, CsC, Multi-Homed CE and Anycast scenarios that are prevalent today. Therefore, this review will evaluate BGP-CAR based on certain key aspects and operational criteria. Intent-Driven Service Mapping Key Aspects: ------------------------------------------ To better understand the nature of issues raised, it is important to consider the basic intent-driven service mapping aspects. A) Classification & Grouping: Construct to group underlay tunnels with sufficiently similar TE characteristics - CAR: Classification: Color Grouping: None (Not clear from the draft if any construct is used) B) Resolution & Steering: Construct for overlay routes with a Mapping Community e.g. Color-EC, to resolve next hop reachability to the underlay path with the same "effective color" arrived from the following - CAR: Resolution for CAR routes & SR policy based steering/automatic-steering for Service routes > Color-EC on Service Route (Mapping Community) > CAR Type-1: IP:Color as key in NRLI > CAR Type-2: Colored IP Prefix > Color-EC on CAR route for Anycast > LCM-EC for non-agreeing color-domains and download service routes to FIB when its path is reachable C) BGP Extensions: (AFI/SAFI Encoding/Decoding) A BGP family to extend the above constructs to adjacent domains (AS/IGP) - CAR NLRIs: (New NLRI formats for CAR and VPN-CAR) > Type-1: Color as key in NRLI > Type-2: IP Prefix as Color > Color-EC attr (for Anycast) > LCM-EC attr (for non-agreeing color domains) > IP prefix for CAR types and RD:IP prefix for VPN-CAR types D) Path Availability & Selection: This is the final and most important aspect which has two important steps for selecting transport routes for nexthop reachability: i) Avoid path hiding - - CAR route: Type-1: Unique "IP:Color" key in NLRI Type-2: Unique "Color IP Prefix" per color-locator ii) Path selection and Resolution should use the same "effective color" - CAR route: Type-1: Path Selection key Prefix: IP and Type-1-NLRI-Color Resolution key Prefix: IP and "Effective Color" (Type-1-NLRI-Color or Color-EC on CAR route or LCM-EC on CAR route) Type-2: Path Selection key Prefix: IP color prefix Resolution key Prefix: Not needed as it is routed Review: ======= Switching back to the open issues and scenarios, this review will focus on evaluating CAR on the above set of aspects and criteria. MAJOR: "Where is my color?" - From CAR-00, as a draft that addresses this "new" problem space of using "Color" to achieve "Intent driven service mapping", CAR introduces the "Where is my color?" ambiguity in procedures for any node receiving and processing a CAR route. These are arrived from the following procedures: PROCEDURE I: CAR Route validation --------------------------------- Quoting from section 2.4: BGP CAR Route Validation "A BGP CAR path (E, C) from N with encapsulation T is valid if color- aware path (N, C) exists with encapsulation T available in dataplane." " A local policy may customize the validation process: * the color constraint in the first check may be relaxed: instead N is reachable via alternate color(s) or in the default routing table" ... "A path that is not valid MUST NOT be considered for BGP best path selection." PROCEDURE II: Path Selection and Availibility --------------------------------------------- Quoting from section 2.7: Path Availibility "The (E, C) route inherently provides availability of redundant paths at every hop, identical to BGP-LU or BGP IP." PROCEDURE III: CAR Route resolution ----------------------------------- Quoting from section 2.5: BGP CAR Route Resolution "For a CAR route, Color-EC color takes precedence over route NLRI color." "A BGP CAR route may recursively resolve over a BGP route carrying Tunnel Encapsulation attribute. Procedures of section 8 of [RFC9012] apply in presence of BGP Color EC in the CAR route. They are extended to use LCM EC and Color in CAR route NLRI as per above and Section 2.9.4 in absence of BGP Color EC." Quoting from section 2.9.4: LCM-EC "When a CAR route crosses the originator's color domain boundary, LCM- EC is added." "An implementation SHOULD NOT send more than one instance of the LCM- EC. However, if more than one instance is received, an implementation MUST disregard all instances other than the one with the numerically highest value" "If present, LCM-EC is the effective intent of a BGP CAR route." "LCM-EC Color is used instead of the Color in CAR route NLRI for procedures described in earlier sections such as route validation, resolution, AIGP calculation and steering." Quoting from section 2.10: LCM and BGP Color Extended Community usage "Default order of processing for resolution in presence of LCM-EC is local policy, then BGP Color-EC color, and finally LCM-EC color" This CAR route will have one or more of the following depending on the NLRI type and the Scenario being addressed. ----------------------------------------------------------------------- | CAR color variable | Scenario ----------------------------------------------------------------------- A.| Color-EC color | Anycast, Single Domain N:M color B.| LCM-EC color | Multiple color domains C.| CAR-NLRI-Type-1 'color' | Default, used for path availability and | | selection additonally D.| CAR-NLRI-Type-2 'IP Prefix'| Defined in Section 2.9.3, 8, 9 and 10.2 ------------------------------------------------------------------------- Quoting from RFC 1925: Twelve Networking Truths: (3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. Issue-1.1: As mentioned in key aspects, the path selection key and the resolution key can be different depending on the scenario. This will cause misrouting issues such as the ones mentioned in F3-CAR-Q4 below. Specific text needs to be added to address this scenario. Issue-1.2: CAR-NLRI-Type-1 'color' is overloaded for path selection, path availability as well as intent. While this solves path hiding for Unicast EPs, there is path hiding @ ABR/ASBRs in anycast and multihomed EP scenarios, and as a result, all paths are not visible to the ingress domain and thus end-to-end, as both Prefix and Color are same in all paths. Therefore, overloading CAR-NLRI-Type-1 'color' as both the distinguisher (RD) as well as "Intent" needs to be explicitly called out for each scenario. Moreover, using EBGP add-path at ASBR to get around this will use AddPath-ID as the distinguisher which is again, not well deployed and limits the distinguisher to the scope of the EBGP session and not end-to-end (e.g. RD) Issue 1.3: Migration from unicast to anycast is not seamless for E2E path availability use-cases. This can happen when a CE is multihomed to another PE in the egress domain. Operators should expect path hiding and will have to use A.7 workaround to have an additional variable, Color-EC which is attached to the CAR route, and is preferred over CAR-NLRI-Type-1 'color' as the effective intent even in single color domains. This is further discussed in F3-CAR-Q1 below. Issue 1.4: Colorless Transport Tunnels with varied intents like RSVP-TE, MPLSoUDP and IPinIP are quite prevalent in existing brownfield and customers do foresee these deployments continuing into the next decade as well. However, there still needs to be construct to achive the aspect of classification and grouping in such deployments. How can local policy achieve this in the absence of 'transport color' and 'TEA'? F3-CAR-Q1: Status = Unresolved ------------------------------ BGP-CAR Appendix A.7 - Anycast EP Scenario: https://mailarchive.ietf.org/arch/msg/idr/nAj25sX0x_lp09VEqUDSCxmDR_w/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxNjUEOgjAURK9iujb9LYUirDTqBTQad6aWD1QBsa1KNN5d6srM7k3mzZvcbUPyCam9710O0CrTKKtr80Bq0Jf0aisIAFpXgSksdItzlLgDG45Nz7L9-rZbbZdDu9ocn0CmE3IJug79OOQsmcmMR-BqZdHNu-JVU31tIdFpqlnMylhHignFtRIcTyiFwELMGHCZZfEYySmXwYo_q_KP-fnemR4tHS9CUYTin32-VldBvw.MEUCIQCGI-vtBdV3eAlbX2xsxlPWm2yCMM1rj26tBataDBluPQIgFh_FUFJuogS0_WCilMyz4lJ_QVZ8Fnk21b78YF-t014> Note: This is not a solution but just a work around. While bug fixes in code are common, it is painful to see bug fixes and work arounds in new and evolutionary technology drafts. F3-CAR-Issue-1.1: To work around Issue-1.2 and Issue-1.3, each anycast end-point is configured with a different CAR-NLRI-Type-1 'Color' to avoid path hiding and attaching the same Color-EC to all EPs additionally. Does this sound familiar? Of course, Prefix remains the same, CAR-NLRI-Type-1 'Color' now becomes the RD and Color-EC becomes the intent. In CAR, this comes with a lot of local policy overhead @ PE/ASBRs to STOP automatic resolution using CAR-NLRI-Type 'color' as intent and replace it with Color-EC as "intent". This is the reason for the first two quotes mentioned in procedure (III.) and quotes in procedure (I.). This issue still exists and the draft needs to call out policy overhead required in PE/ASBRs. F3-CAR-Issue-1.2: Considering the second quote in procedure III. and an Administrative domain with ColorSRTE based transport tunnels, a CAR route can resolve over a Color SRTE route with TEA. This means that for N anycast EPs, there are N colors assigned and hence N color SRTE paths per AS domain for each Color-EC. This multiplies the Color SRTE forwarding state by a factor of N. This needs to be called out in the draft. F3-CAR-Issue-1.3: Quoting from section A.7 "Both E2 (in egress domain 2) and E3 (in egress domain 3) advertise Anycast (shared) IP (IP1, C1) with same label L1" Labels are dynamic. If the same label has to be sent on both, there needs some static configuration to coordinate this. This should translate to a SHOULD clause in the procedures. If an implementation is unable to do static labels, then recommendations need to be provided to address the same. F3-CAR-Issue-1.4: How does ECMP and protection work here? Based on procedure (I.), a local policy can be used to discard CAR-NLRI-Type-1 'Color' and use alternate colors, say in Color-EC to resolve the CAR route. However, the question that still remains is how the route needs to be maintained in the RIB? Should the route be installed as IP:C1, IP:C2? Since these prefixes are unique, path selection cannot act on them. This is another example of C1 and C2 used as "distinguisher" rather than "intent" and hence the ambiguity due to overloading. If they are installed as just IP, which RIB they are installed to? This needs to be explained in the draft. F3-CAR-Issue-1.5: Section B.2 - N:M distribution In Figure 12: N:M illustration, attaches atleast two Color-ECs on the CAR route while overloading the CAR-NLRI-Type-1 'color' as both distinguisher as well as intent for unicast EPs. There are no procedures as to which Color-EC should take precedence in which AS/ABR domain. This needs to be clarified. It should also note that there needs to be one additional Color-EC on the CAR route for each M (M1, M2, ...). F3-CAR-Issue-1.6: Section B.2 - N:M distribution and Anycast In Figure 12: N:M illustration, now with Anycast in play and as per F3-CAR-Issue-1.1, there will be atleast "three" Color-ECs, where Color-EC-Anycast represents Anycast plus the "two" Color-ECs for the N:M distribution. As per A.7, CAR-NLRI-Type-1 'color' now becomes the distinguisher and Color-EC-Anycast becomes the intent. This is a "critical" issue because there is no clear precedence in picking the Color-EC assigned for Anycast. This needs to be clarified as part of the draft. F3-CAR-Q2: Status = Unresolved ------------------------------ BGP-CAR - Consensus on the need for resolution-schemes https://mailarchive.ietf.org/arch/msg/idr/g6ZCJYzWwgRsilWlZY74MTv9Fqk/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxNjcsKwjAURH9FspbcxNTUdlUQXAhuRCi6i-ltG-3LJFao-O82rmR2Z5gzb_K0DUkXpPZ-cClAq0yjrK7NiNSgL2lvKwgAWleBKSxU8rLdn6f8VR2dafLmco6jw2lMdo87kOWC3IOuQz8POVtvZMJX4Gpl0WVdMdVU9y2sdRxrFrEy0ivFhOJaCY5XlEJgITYMuEySaI7klMtgxZ9V-TG7PTszoKXzRSiKUPyzzxeLG0IV.MEYCIQD3qd2QkTT0Rfb_J6_bKPDV9_P2edYNjOhm6qTBtSOMDwIhANVaBDUJGPZgZzIwrUz8E_A8_No8fFQQ4Uul4KO_LFPg> F3-CAR-Issue-2.1: Based on the above issue list, especially Issue-1.1, Issue-1.4, F3-CAR-Issue-1.1, 1.4, 1.5 and 1.6, it is indeed important for CAR to have a clear scheme for resolution that handles all the of these issues. The nature of this scheme needs to be explained as part of this draft specifically, that vendors can use to incorporate during implementation. Offloading this to a local policy blob is prone to make implementations incompatible due to configuration ambiguity. F3-CAR-Q3: Status = Unresolved ------------------------------ CAR-Q3 - Handling [of] LCM and Color Extended Communities https://mailarchive.ietf.org/arch/msg/idr/w5ROKVQPtVcI_BTBXfnKpKB4h4k/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxNjcsKwjAURH9FspbcxKTRdiXdSRc-EHEnMb010b5Io4Liv9u4ktmdYc68yd3XJJsQG0I_ZACNdrX2xroHUoehop2_QATQDBdwpYdnslsXh-0mHMzqlO_zY9UWfZFLK29AphNyi7oWwzjkLFmolM9gsNrjsGzLl6WmayAx87lhklXSzDQTmhstOJ5RCYGlWDDgKk3lGMUpV9GKP6sOj-X13roePR0vYlHG4p99vjlcQYc.MEQCICcuowWgAS2I8f9-9QmcDr9P5t0856H4--xbwhAj30iFAiB_RXxSy_qz0BVM4PE_G7Ovd8Sp_4vbIrg8_y3O14HGyg> F3-CAR-Issue-3.1: Considering quotes from section 2.10 in Procedure (III.), F3-CAR-Issue-1.1 to 1.6 apply. Additionally, LCM-EC needs to be factored into F3-CAR-Issue-2.1. F3-CAR-Issue-3.2: Considering the following quotes from section 2.5, 2.9.4 and 2.10 in Procedure (III.) respectively, "For a CAR route, Color-EC color takes precedence over route NLRI color." "When a CAR route crosses the originator's color domain boundary, LCM-EC is added." "If present, LCM-EC is the effective intent of a BGP CAR route." "Default order of processing for resolution in presence of LCM-EC is local policy, then BGP Color-EC color, and finally LCM-EC color" These normative text contradict each other. If Color-EC takes precedence over CAR-NLRI-Type-1 'color', then Color-EC becomes the "intent" and CAR-NLRI-Type-1 'color' becomes purely the distinguisher and not overloaded with intent. In such cases, it is not very clear whether Color-EC value should be the effective intent instead of NLRI color and which one should be copied into LCM-EC since, CAR-NLRI-Type-1 'color' is just a distinguisher. This needs to be clarified as part of draft text. F3-CAR-Q4: Status = Unresolved ------------------------------ BGP-CAR - Mis-Routing in Non-agreeing color-domains for Anycast EPs https://mailarchive.ietf.org/arch/msg/idr/OOZOBSyjdAYBar8NxvOqo6-5fAc/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxNjbsSgjAURH_FSa25iYEAVuoHSGGlXUwuJCqgITA-xn-XWDnbnZ09-yaDv5LVjNgQbv0KoFHuqry2bkTqMFS08zVEAE1fgzMeyvJYbvfPs9kctsrnu8dY3ju5SKuNBjKfkUvUtRimIWdpLgu-hN4qj_26NS9LdddAqrNMs4RViV4qJhTXSnA8oRQCjcgZcFkUyRTJKZfRij-rCuP6PLTuhp5OF7Ewsfhnny9TMEGz.MEYCIQCXgKP6zTDh_w0SbpRBmMSZdkYshz8voiugmXJqWZ__8gIhAKqXrB3BNlwXAzpYnppY3wKYDfQ4jHu4kJVwTdoWirdp> F3-CAR-Issue-4.1: Quoting from section 2.9.4 "If two BGP paths for a route have different LCM values, it is considered an error and the route is not considered for bestpath selection." The above text still does not address the mis-routing problems that might arise in Anycast with Non-Agreeing color domains as indicated in the above issue link. However, this seems to have been "worked around" using Color-EC as the intent, CAR-NLRI-Type-1 'color' now acting solely as a distinguisher and hence its derived LCM-CE also acts as a distinguisher in the receiving non-agreeing domain. The local policy operations for this scenario needs to be clearly specified to avoid ambiguity in the draft. It is also important to note that a portion of colors from "intent namespace" is being used purely as distinguishers and others being overloaded with intent as well. This needs to be clarified in the draft as to how the intent namespace(s) are managed so that local policy schemes can derive how this namespace is used. F3-CAR-Q5: Status = Resolved ---------------------------- Update Packing Observations are considered resolved. No additional text is needed. Pending Review: (Part II) =============== - CAR-NLRI-Type-2 - CAR-NLRI-Type-1/2 interoperability - VPN-CAR and VPN-CAR IP-Prefix - Service family support - Route target constraints and Scaling Thanks, -Nats- Juniper Business Use Only From: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> Date: Wednesday, July 12, 2023 at 6:34 PM To: idr@ietf.org<mailto:idr@ietf.org> <idr@ietf.org<mailto:idr@ietf.org>> Cc: Natrajan Venkataraman <natv@juniper.net<mailto:natv@juniper.net>> Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/24/2023) [External Email. Be cautious of content] Greetings: I mentioned in the original call WG LC on Monday the following: In parallel with this WG LC, I have asked Jeff Haas (idr co-chair), Jie Dong (idr secretary), authors of issues during adoption to review this version of the draft. Directorate reviews have also been requested. I would like to ask Natrajan (Nats) to provide feedback for the from Forum 3 of the adoption call which are specific CAR indicate Whether their technical concerns have been resolved In draft-ietf-idr-bgp-car-02? 1) F3-CAR-Issue-01: BGP-CAR Appendix A.7 - Anycast EP Scenario: Author: Natrajan Venkataraman natv@juniper.net<mailto:natv@juniper.net> 2) F3-CAR-Issue-2: BGP-CAR - Consensus on the need for resolution-schemes Author: Natrajan Venkataraman natv@juniper.net<mailto:natv@juniper.net> 3) F3-CAR-Issue-3: CAR-Q3- Handling [of] LCM and Color Extended Communities Author: Natrajan Venkataraman natv@juniper.net<mailto:natv@juniper.net> 4) F3-CAR-Q4: BGP-CAR - Mis-Routing in Non-agreeing color-domains for Anycast EPs Author: Natrajan Venkataraman natv@juniper.net<mailto:natv@juniper.net> 5) F3-CAR-Q5: Update Packing Observations Author: Natrajan Venkataraman natv@juniper.net<mailto:natv@juniper.net> Nats - please suggest any technical issues or changes In text that may help this issue. Cheerily, Sue Hares
- [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Dhananjaya Rao (dhrao)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Swadesh Agrawal (swaagraw)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… James Guichard
- [Idr] 回复: WG LC for draft-ietf-idr-bgp-car-02 (7/… 蒋治春(若弈)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Mahesh Jethanandani
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Jorge Rabadan (Nokia)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Satya Mohanty (satyamoh)
- [Idr] FW: RE: WG LC for draft-ietf-idr-bgp-car-02… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Wen, Bin
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Natrajan Venkataraman
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Jingrong Xie
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Swadesh Agrawal (swaagraw)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… bruno.decraene
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… David Smith (djsmith)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Jakub Horn (jakuhorn)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… bruno.decraene
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Miya Kohno
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… 易昕昕(联通集团本部)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Luay Jalil
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… James Uttaro
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Wim Henderickx (Nokia)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Gyan Mishra
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Gunter van de Velde (Nokia)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Jose Liste
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Satoru Matsushima
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Kalyani Rajaraman
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Brent Foster (brfoster)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Ketan Talaulikar
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… MEANS, ISRAEL L
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… MEANS, ISRAEL L
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Wanghaibo (Rainsword)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Dongjie (Jimmy)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Liyan Gong
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Stefano Salsano
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Krishnaswamy Ananthamurthy (kriswamy)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Ali Sajassi (sajassi)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Julian Klaiber
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Severin Dellsperger
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Clarence Filsfils (cfilsfil)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Neeraj Malhotra
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Gaurav Dawra
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… chen.ran
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Jingrong Xie
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Zhuangshunwan
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Adam 1. Simpson (Nokia)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… James Uttaro
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Natrajan Venkataraman
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Xing James Jiang (jamjiang)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Dirk Steinberg
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Antonio Cianfrani
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Dhananjaya Rao (dhrao)
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Susan Hares
- Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/… Voyer, Daniel