Re: [Idr] Color domains in BGP routes with color

"Dhananjaya Rao (dhrao)" <dhrao@cisco.com> Wed, 06 July 2022 14:31 UTC

Return-Path: <dhrao@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 8CC2BC15A726 for <idr@ietfa.amsl.com>; Wed, 6 Jul 2022 07:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.623
X-Spam-Level:
X-Spam-Status: No, score=-9.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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=aXGgcJvL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pzOaPg47
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 txTCi9KKy40n for <idr@ietfa.amsl.com>; Wed, 6 Jul 2022 07:31:25 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579A1C14F720 for <idr@ietf.org>; Wed, 6 Jul 2022 07:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70747; q=dns/txt; s=iport; t=1657117885; x=1658327485; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=26vJCOhVKBnKnzPKPvcqOv7nDc4CFswi8AYcmcbWrZk=; b=aXGgcJvLc0xVZlsYns4JRqfElDVWTFFTypBnRY7TUrAGePXYMRTpy/bu aefk21LQJ44BC2LY3jZfz0QKnT0sFIi0/l481EKi1r1Vv01asVmMwuNZ7 4Le80lw2W5WEHON/u1nSo8X/QCMQODORtpVZVDaurN0QkRTwst9QSdZyS A=;
IronPort-PHdr: A9a23:9/87sRAgbCOlinVuFT0xUyQVaBdPi9zP1kY95pkmjudIdaKut9TnMVfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKWkwJjMwMlFkmB8iIQUTwMP/taXk8G8JPHF9o9n22Kw5bAsH7MlbTuXa1qzUVH0aXCA==
IronPort-Data: A9a23:QxWHvaCPjD71hhVW/7zhw5YqxClBgxIJ4kV8jS/XYbTApDkqgjAEzWdLCm/UafyMNGahfdhzPdzg/RhSvMCEy9ZlOVdlrnsFo1CmBibm6XV1Fqp7Vs+rBpWroHlPsoNPM7EsEOhuFiWG/kr0bOC4xZVB/fjgqoTUWbas1h9ZHWeIeA954f5Ss7ZRbrxA2LBVMCvV0T/GmPAzDXf+s9JC3s343IrYwP9nlKyaVDr1JTXSb9gT1LPVvyF94J7yuciMw3XErol8RoZWRs7Zx72/u2je5RpoVpWuk63wdQsBRbu60Qqm0yUNHfP9xEkZ4HVvj87XN9JEAatTozmJhdl24N5Mrpe3DwwuO8UgncxCDEQCSnsmYfMuFLjvZCLXXdao51fBeXb23910BVokII5e/OtraUlP+eYwKT0RYFaEne3e6LSyVvc52pwhMc/qJI4F/Hdt0RnVCP88StbCTrnEo9hC018YisBUFPGLO5ISaCFka1LLZBhnNlIeEpl4neq0iD/4aTIwgFGcoast6mqGkFRzzb7sKNfPPNqHWe1Zm0+CrSTH8nj3RBYAO7SiJZCtmp63rvXEkSW+U4UIGfjksPVrm1aUgGcUDXUruZKAiaHRoiaDtxh3ciT4IhYTkJU=
IronPort-HdrOrdr: A9a23:WukN06yvzVjF5fL6sHL4KrPxgOskLtp133Aq2lEZdPULSKKlfpGV88jziyWZtN9IYgBdpTiBUJPwJU80hqQFnrX5XI3SEzUO3VHIEGgM1/qb/9SNIVydygcZ79YcT0EcMqy/MbEZt7eA3ODQKb9Jq7PrkNHKuQ6d9QYWcegAUdAG0+4NMHfjLqQAfnghOXNWLuv42uN34x6bPVgHZMWyAXcIG8LZocfQqZ7gaRkaQzY69Qinl1qTmf/HOind+i1bfyJEwL8k/2SAuRf+/L+fv/ayzQKZ/3PP7q5RhMDqxrJ4dYyxY4kuW3bRYzSTFcFcso65zXQISSaUmREXeez30lUd1gJImjXsly+O0ELQMkLboUgTAjfZuC6laD3Y0JTErPZQMbsauWqfGSGpsHbI9esMop6i0w+ixulq5VmrplWM2/HYEx5tjUa6unwkjKoaiGFeS5IXbPtLoZUY5149KuZLIMvW0vFuLABVNrCW2N9GNVeBK3zJtGhmx9KhGnw1AxedW0AH/siYySJfknx1x1YRgJV3pAZNyLstD51fo+jUOKVhk79DCscQcKJmHe8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR52Mi6PJgTiJcikpXIV11V8WY0ZkL1EMWLmIZG9xjcKV/NFAgFCvsukaSRloeMMIYDaxfzPWzGu/HQ1MkiPg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CNBgBDbIJi/5tdJa1QCh4BAQsSDIIEC4EhMVIHdQJYOUOEToNMA4UxhQmDAgObOIEsFIERA1QLAQEBDQEBMhAEAQGCDoJ0AhaFKAIlNAkOAQIEAQEBEgEBBQEBAQIBBwSBCROFaA2GQgEBAQEDEggJHQEBJRIBDwIBCBEDAQIWCwEJAgICMB0IAgQBDQUUBweCWwGCDFcDMQEOn2cBgT4Cih96gTGBAYIIAQEGBASBOwIQAw8vgn8YgjgDBoE8gxSEJwEBhyMnHIFJRIEUASccgjcwPoJiAQEBAQGBFhIBBwsBQQYHEoMXN4IujWeHegc6Axw4gQUSgSFxAQgGBgcKBTIGAgwYFAQCExJTHgITBQcKHA4UHCQZDA8DEgMRAQcCCxIIFSwIAwIDCAMCAyMLAgMYCQcKAx0IChwSEBQCBBMfCwgDGh8tCQIEDgNDCAsKAxEEAxMYCxYIEAQGAwkvDSgLAxQPAQYDBgIFBQEDIAMUAwUnBwMhBwsmDQ0EHAcdAwMFJgMCAhsHAgIDAgYXBgICcQooDQgECAQcHiUTBQIHMQUELwIeBAUGEQkCFgIGBAUCBAQWAgISCAIIJxsHFhkdGQEFXQYLCSMcHBALBgUGFgMmUgYiAR2SPIMdCIEPDwEcEC4IBjgBJzIZBgIgAlEIYyozAjqSFwctgx+JeY4IkUuBMAqDTIE+iVyUcAQtg3WMPpUTgxGWZiCNB5RMARmEcQIEAgQFAg4BAQaBYTxpWBEHcBVlAYI9URkPjiAMFoNQhFk7hUp1AjkCBgEKAQEDCZEaAQE
X-IronPort-AV: E=Sophos;i="5.91,230,1647302400"; d="scan'208,217";a="775212046"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jul 2022 14:31:23 +0000
Received: from mail.cisco.com (xfe-aln-005.cisco.com [173.37.135.125]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 266EVNwN007755 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2022 14:31:23 GMT
Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 6 Jul 2022 09:31:23 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 6 Jul 2022 10:31:23 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nFctxznIdCMfN0AZEFN/PeOoLST/m70T0arGMLC3+QpAZEniq3OAhozWyVCJ/Ju/kw+fjWPzPLgYJ3AD7pejszxX3aZdyj7WFxZALsvtP9ATRFMvrYXouNk9r5NRPkXRhnRWTYrs0KdsBsD3oG30GkJxeg+QLX3SdkvNYOlvYAoW1eu3T1PBfPFdWlsrJHmV3emaBWWqPMknd4qlEhmGA6H6f3FEpOCUHbyVE0JAgz0lrBqtpwWfaxMy8/T5QbmLC2m4Ax8Fk6L5kC1ym6hxHSriYj8CaaIPke5Dqr33fyyyNiBP18ps0OrlrzmiJhPEXt4pURplhJHj4dHkwgJsxg==
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=26vJCOhVKBnKnzPKPvcqOv7nDc4CFswi8AYcmcbWrZk=; b=K9OyIwN1/QXh6bKCJvjxg8AUbBpHaZ52AvZabhWdlHiX4aUaH/INK68umPFV5UWdQsbZN0wBN1VWucdvv7tba3yyvqEjpYyFLRVQ5+s6pZB+M9WRqC0Ky4OVPVwsqUup/qUdbZqmxu/L/g9E0NW6XgteCZhigksxr6ccijzsKyffDzFiDrAaVn8M1gwwRojdlHEDN1zYoBLKnIBP2ohiNoEVo1B6fN76ChMehDe7XBmqFrx87hpWr0NeyoiWPI6XZUGbCEqcNwMO/hIKylYbvqJwb1o5zWjrYe08qwU60dSe38iHVAJYTIJOVRCfHz1vVnuo1zzCnotFfKXsxge/Pg==
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=26vJCOhVKBnKnzPKPvcqOv7nDc4CFswi8AYcmcbWrZk=; b=pzOaPg47h970T69vFNlZUES5EBtGu2nHM2rkIWvyslcfYoMM8cjVFRrFmDr4vlBY+Q41ZuHi1PirHciJwg/3sq/n8s92VhbBKCWkxwrBLaavNuCdkz41npErtRxyuEo6YGqEP/9ToVu0OQL1tL2Qk6fidB9evQtRrz7AzbOtQ8s=
Received: from BY5PR11MB4273.namprd11.prod.outlook.com (2603:10b6:a03:1c9::32) by SJ0PR11MB5662.namprd11.prod.outlook.com (2603:10b6:a03:3af::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5395.15; Wed, 6 Jul 2022 14:31:21 +0000
Received: from BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::b9fc:bfd:5462:a8c2]) by BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::b9fc:bfd:5462:a8c2%7]) with mapi id 15.20.5395.022; Wed, 6 Jul 2022 14:31:21 +0000
From: "Dhananjaya Rao (dhrao)" <dhrao@cisco.com>
To: Kaliraj Vairavakkalai <kaliraj=40juniper.net@dmarc.ietf.org>, "Dhananjaya Rao (dhrao)" <dhrao=40cisco.com@dmarc.ietf.org>, Natrajan Venkataraman <natv=40juniper.net@dmarc.ietf.org>
CC: "idr@ietf.org" <idr@ietf.org>, 'Robert Raszuk' <robert@raszuk.net>
Thread-Topic: [Idr] Color domains in BGP routes with color
Thread-Index: AQHYPiLLqSkvWS/Ds0uUJ4f+tF9oLqzMk9qAgAAmywCAACzlgIAAqsyAgBKpKYCAYdISAIAwXHmA
Date: Wed, 06 Jul 2022 14:31:21 +0000
Message-ID: <2175A4BA-964A-4E5A-A66E-E007428D3D2F@cisco.com>
References: <20220322192622.GV4905@pfrc.org> <202203231531514641635@zte.com.cn> <20220323095042.GZ4905@pfrc.org> <CAOj+MMGneu65yqgw85hPgQRQKRUha7gt3viRmYbJW+2F4vrT8A@mail.gmail.com> <BY3PR05MB8050E0F006D80952F55B8A3BD9189@BY3PR05MB8050.namprd05.prod.outlook.com> <360907B1-D044-4703-A621-2951105C5F04@cisco.com> <SJ0PR05MB8632C7B9421E945826FCB8A3A2A29@SJ0PR05MB8632.namprd05.prod.outlook.com>
In-Reply-To: <SJ0PR05MB8632C7B9421E945826FCB8A3A2A29@SJ0PR05MB8632.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.62.22061100
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=2022-03-23T19:35:59.1440769Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 453c6348-fccc-4973-0052-08da5f5c324c
x-ms-traffictypediagnostic: SJ0PR11MB5662:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UAhi0WBQefPE2qjeQRLkgkFCLNCmz+Gf7sG3OwWBQYKYTCYXqKlmcdMOKl9Nckkw8wD8mVdCFLV8yuhGs3PqsizB0SGuM1O7uTJlP2fHL1fTroQLVAzlvhqlQhjbbo9F9jKoMPGPCQTgsAFczYWtTfqGRfKT1vEKXc/bAWmSiXX1f9635+7+/bB45pleSeFwGUXSgGjEWQWY3MK3bJgQkwd5uPpXVP6ltbwKNuOaA9xD9VvaXVT5dJXVVvkD+5rVSeJJs9skAwrrmDPLZJm9sgrdh/QOlvPYiYEVj5QHCcU0iKO58SAhIIfcoO7KT744p0Xq1ICuZ1tQawtG+iIAMEmTMwNiIqdo5oolKzlzZG9dchcDxRMxeVbX/P7ajM/nP5uft9GR5jVPFyeRAbQbF9KcuiCqn1n9zygUDE27s83mRIj30h9Fc9Mwd4y2MvcKWyH1GkSyHJnA0t1k4eV+uD/rqjJre39eQjgXQjekp4+PGJyBOL6mtBRMUifIReI7tpCobsGzd/x871Pnjib6n+0zfyOnhK08JuoOVylcjM7viZ+pvqjqizsrEm29QObOqD7rpOe86kl8afi3EfgV7BEscuUCCqR5JVpIfyYfK0YhruJ8/I5J0tOguGDigKNBYNmzSUOirTJMGwiZVTYQ03HPuti/7WP/soauMk7YYp/oHnSOgQKZ7sWpp27UXCkUvyJCb8birc6NMW/0VIj8IuO0QFAcru7vdG+J0J7WeTWwMYcGq6Bg5/ki13vqfFHHk8rrs1hjzXjqDPPcapzPeIziAuBU2a2cIuAzj61cspaDwu686npFeIo25GSNZg7O0LY5uiqB5QTRkGJInWVJ1r22IfyfG86enYb9Yw8JJnotcyQGy01YHHdcbDOppt31ezU7/GdrqeM5nLeA0ITYvXFqLdQsnjCwaxaI2Ff987g=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4273.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(396003)(366004)(346002)(39860400002)(376002)(136003)(66946007)(64756008)(2906002)(83380400001)(76116006)(166002)(91956017)(8676002)(54906003)(33656002)(66556008)(66476007)(6506007)(71200400001)(66446008)(4326008)(2616005)(186003)(36756003)(38100700002)(38070700005)(21615005)(316002)(6486002)(30864003)(6512007)(110136005)(966005)(122000001)(478600001)(41300700001)(9326002)(8936002)(86362001)(53546011)(5660300002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 33FtVzX3Um0XU3tesoJUsH9/LNk4hdeGqP45p/E3ltz75Fand85O7Y0DWOsX16fBcZ5kFMcx68mDHZLyGq4pTUH2DNQkudPyjEZMyWxvG9cndLoTnKi21sG3LvoD5Qr04RnuyTHxAqcKdpbsmONv/NiMjuLG55g8cQBDOKv9g3YmD6GGO+WcNbSdI51DAynUkgKoLTziGNZY+YPS13zPIKUYe2ZUWQaC/QyAdTPe96I3FY57jkwE54Ha2R/S4x7L1rJB0rp2+XAlY7KcjxAyjXDSSCAVQyT2iXqom+DNPV8tVNgYb7OLat+cQ9emFSD2z7aZdOYnSYsW49B5/0jFXgLY8HBzV64akVcXbwewj3HwkGmJERYNFB5ezbrd8YFjY0goTaE8YIXVfaqdYV+/w1/HIYIv/Gz6AFtsg4QTQOh05UWMjTGBg7jjBhtzbODVUpHeI4bqgScneQpq8pKNmP8wzhpM/yE3tNb0MIdR0ybR/YGC3ON795ADnpQn3tpn7lboE2DrmTf5eaptnLdKR9aMnLTKb8qiNr+d0mJRCBc+qAbQ0K26BYFxjjB2Ob4PcwzbN71UrfUARhNoUz5vjUcCy00xA3yX9ZAUL22cSTZmPNdY3Yck4z1js3q6dMY6YqrWPx7MZpqLTBdhYSBXamWu6f3xz+vjT3r0N9UjJkv8n5tfPHSBwzvb29N00Ea5Kebs+vd94uImZpC2m2uBHXd6Yo8epAF8gNf50iSUKwUx3PuADEH2o39HcJc/cabg5aHyAqkPUEt/gbpJevYCqBo/aaxcBm9G02zNw/o+9U8e59ADyieSTOY51PNEcyqhUHfdMH9g5X6+u9bo8gokj0wgjyet69VCyW5dRQg15US/HNy+/ITtUVib+Miw4yj0g3QYC09pR4iNAwdICiCgCOneoMqWSzcK1oDgN6IDsauo9Xv4b5v/ZywmEKLZMqItIe6sK0/QV6kJDFIAxUzg8BJs9FacVOkgo4py0vBNXzGBh+/t4T60pTcviQrP6yo7ORGcyVU1QYuhOeS0jE5hyZko77/drwisrfoIwU3x7lLtWXauwV1Ti0ZVd5ga0NSUvPBhZIsnSfQGVo+t1IY1dXRSdvwG2qnJUdbg8cCiZwU+qnxd6lZARxVOJ5txYYmgWr0l3oMjCjmWc0nWJhHl139nW8qEDSSXDxIKdufoR+F+jgTjSpESobp2Y7z71ORLiiPPETbC/edzFj5M1n+o7xAeudxSF0YutLAdcj9AoKuMXWHbg+Z+ZAgOTNqu/WqGzxbMErfAnzcmhGpBZYIidZuNdRGG+YNiwI7UtCbq2JfYmO0aN9yYenLWfeijvmMfSmG892Hf4c4Ib08b/VBUc7W5q48FrdjQw1PRBYuksPi6pbMYe52gvdFO+DHlZeA0cwxeytoGKuJ2SXo/PMlQgCfc/tLrc3WuNVwz4o4Whi1P3dO9CymeP9SvFEL/fciINySWdnpsvic1M31kkNR1AVEH76KQEHAgA6CjcQxYIs58zGx83jLyVgrwh8cLBtG4wp/PAyGwTEnNkvj8tSiBd+DX9YeQW6vVqnXKGnSy856Rkcvl8VDjxPLLDWXhiDv7Mr8O/QDknDBKde/E0xpslxxQFwBbgVsi229NnzyLEp3ww13oR37IiN7TsZ1LxwJi
Content-Type: multipart/alternative; boundary="_000_2175A4BA964A4E5AA66EE007428D3D2Fciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4273.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 453c6348-fccc-4973-0052-08da5f5c324c
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2022 14:31:21.1349 (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: t4u9IRNOO9wGvV6FkyuVFnk7pBL2/zJO9TDSFPucCGbiWdA1c37vJUvTfCpUqyNu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5662
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.135.125, xfe-aln-005.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4Sffm_AR-wW9_jEEn3UfPGBbG4U>
Subject: Re: [Idr] Color domains in BGP routes with color
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: Wed, 06 Jul 2022 14:31:29 -0000

Hi Kaliraj,

I’m afraid you missed the point I made. The per-flow steering was an example to illustrate how the color construct is flexible to allow indirection and mapping to multiple colors.

As an example, C100 on a service route can map to an array of forwarding-class entries with different colors for the purposes of steering different classes of flows on paths of different colors. This example is also illustrated in the CAR draft.
https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-05#appendix-A.6

Now, the same concept can also be used to steer two different colored service routes via transport CAR routes of the same primary color but different fallback colors.

For example,
R1 can be colored with C101 ;
R2 can be colored with C102 ;
C101 maps to C1 primary, BE fallback ;
C102 maps to C1 primary, C2 fallback
Etc.

Regards,
-Dhananjaya


From: Idr <idr-bounces@ietf.org> on behalf of Kaliraj Vairavakkalai <kaliraj=40juniper.net@dmarc.ietf.org>
Date: Monday, June 6, 2022 at 7:01 AM
To: "Dhananjaya Rao (dhrao)" <dhrao=40cisco.com@dmarc.ietf.org>, Natrajan Venkataraman <natv=40juniper.net@dmarc.ietf.org>
Cc: "idr@ietf.org" <idr@ietf.org>, 'Robert Raszuk' <robert@raszuk.net>
Subject: Re: [Idr] Color domains in BGP routes with color

Dhananjaya,

The ‘per-flow steering’ you mention below talks about DSCP/Forwarding-Class Based Forwarding over SR-policies.

Here, the question was about Fallback between different Colors for ‘per-destination’ steering. They are obviously two different things.

Say, the following routes:

  *   R1 wants the intent : C1 primary, fallback to best-effort
  *   R2 wants the intent : C1 primary, fallback to C2
  *   R3 wants the intent : C1 primary, fallback to C3

Which is a use case where all three routes want color C1 as primary but have different fallback requirements.

Note here, it can be a “RSVP only” network too.

How is this achieved?

Thanks
Kaliraj
From: Idr <idr-bounces@ietf.org> on behalf of Dhananjaya Rao (dhrao) <dhrao=40cisco.com@dmarc.ietf.org>
Date: Monday, April 4, 2022 at 7:11 AM
To: Natrajan Venkataraman <natv=40juniper.net@dmarc.ietf.org>
Cc: idr@ietf.org <idr@ietf.org>, 'Robert Raszuk' <robert@raszuk.net>
Subject: Re: [Idr] Color domains in BGP routes with color
[External Email. Be cautious of content]

A few specific comments, just to clarify some incorrect assumptions stated below about CAR.

To restate, CAR creates color-aware paths in the transport and the intent/characteristics provided by them is represented by color. A service is steered over these CAR paths based on the intent requested/expressed in the service route using a Color Ext-Comm.

For the typical case of automated steering of traffic for a service route, the Color in the Color Ext-Comm maps to the Color in the CAR route NLRI (similar to the way it mapped to an SR-Policy in the SR-TE solution (https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22)).

However, this is not hard-coded nor the only option. The Color construct is flexible and expressive enough to support different requirements.

For instance, the Color in the service route Ext-Comm may map to multiple other colors via a local policy. This is already described in the SR-Policy draft, one example being support of per-flow steering.

There isn’t a compelling reason to add new constructs such as mapping communities or transport classes at different levels of the hierarchy to achieve the necessary flexibility.

The “mapping community” appears to be a distinction without a difference, and the claim in the thread below incorrect. The community values also either needs to be coordinated if the service routes goes across different domains that may reuse the values, or needs to be rewritten at the boundary. The same can be done with Color.

Regards,
-Dhananjaya


From: Idr <idr-bounces@ietf.org> on behalf of Natrajan Venkataraman <natv=40juniper.net@dmarc.ietf.org>
Date: Thursday, March 24, 2022 at 4:13 AM
To: Robert Raszuk <robert@raszuk.net>, Jeffrey Haas <jhaas@pfrc.org>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] Color domains in BGP routes with color

Hi Robert,

Please check replies highlighted with NV> inline.

Regards,
-Nats-


From: Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <robert@raszuk.net>
Date: Wednesday, March 23, 2022 at 5:32 AM
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: idr@ietf. org <idr@ietf.org>
Subject: Re: [Idr] Color domains in BGP routes with color
[External Email. Be cautious of content]

All,

My intention is to illustrate that for each of the two proposals below
that as routes go from one domain to another that there are situations where
remapping may have issues.

Practically speaking I am not so sure about the value of complexity introduced by the notion of remapping colors at domain boundaries. That goes against the KISS principle.

NV> ------------{ Start…
I agree with you practically. However, “actual” customer use cases are not always practical or ideal. There have been known features that customers (predominantly DC) have requested for end to end connectivity between multiple color domains. One such requirement was MPLS RSVP LSPs with Abstract-hop ERO where the LSP have to navigate end to end through more than one color domains where each abstract hop provides the color to go forward. Here, the customer has specifically defined different color domains within their administrative domain(where the color domains are intra-as). Therefore, what is practical might not be what the customer “actually” wants. This is not a disagreement but purely factual based on the deployments that we see where community rewrites happen even today with any color constructs at the AS boundaries.

https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/ref/statement/abstract-hop-edit-protocols-mpls.html
https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/lsp-labels.html#id-example-configuring-abstract-hops-for-mpls-lsps

NV> ---------End.}

Instead of remapping I would simply propagate tuples (ASN-Color). Now the meaning of color in each domain has to be known via some form of publishing it. Be it a web page or pub-sub or xyz is a different topic.

Why do we need to keep colors flat ? Moreover colors signalled by BGP interdomain may not be the same as intradomain colors as build by some constrained protocol.

NV> ------------{ Start…

For Service routes mapping to CT transport routes, such an agreement is possible. I will try to explain how.

Can a color uniquely identify the overall end-to-end service intent? This is where the proposals CAR and CT differ w.r.t expressing intent to multiple color domains. IMHO, color is a function of the transport and intent is a function of the end-to-end service realized as a sequential ordering of colors (, a Color Scheme). Color does not fully represent the service intent.


  1.  In CAR, Color is the Intent. Therefore, the service route carries the exact color in the CAR NLRI is encoded in the form of a color community as part of the Service Route which resolves to the CAR route. However, the fallback decision is strictly local to the ingress domain ingress PE. The Ingress PE needs specific policy (per-service / per-prefix) as to what color the Ingress PE needs to fallback when the EP:Color tunnel is down. i.e, the fallback order needs to be policed.
  2.  In CT, Color (Transport Class) is a collection of transport properties that contributes to the overall intent of the service. This is where the “extended mapping community” comes in. The CT transport routes as well as service routes carry extended mapping community. This maps not just to a color but a “resolution scheme” which can be configured and there is no need for local policy at each service/border node but a re-representation of a “globally unique color resolution scheme” that represents the color sequence and its corresponding fallback order, uniquely identified and shared via the extended mapping community. For example,

     *   MapCOM - Color:0:C1 resolve strictly over Transport Class C1 (used by CT transport routes for Color C1)
     *   MapCOM - Color:0:C2 resolve strictly over Transport Class C2 (used by CT transport routes for Color C2)
     *   MapCOM – Color:0:C1BE resolve to Transport Class C1 fallback resolve to Best Effort (Used by Service routes)  <<<
     *   MapCOM – Color:0:C1C2 resolve to Transport Class C1 fallback resolve to Transport Class C2 (Used by Service routes) <<<

In CT,

the extended mapping community helps in creating the same resolution schemes across color domains identified by the mapping community values C1,C2,C1BE,C1C2. CT Transport routes are attached with extended mapping community values C1 or C2 (depending on the transport class). Service routes are attached either with extended mapping community C1BE or C1C2 (uniquely identifiable values that do not represent individual colors)

CT Transport routes:
Rewriting of the mapping community “has to happen” to transit a different color domain since colors are uniquely identified by C1 and C2 values which represent individual colors. This is also where CAR brings in the Local Color Mapping (LCM) community.

Service routes:
Rewrites to Service route mapping communites are not needed as they are uniquely identifying a resolution scheme (sequential ordering of colors) and not the individual color. That being said, different administrative domains can actually come to an agreement on uniquely identifying resolution schemes than uniquely identifying colors easily.

For example.

Color domain A:- Low-Delay: Gold(100), CBR: Silver(200)
Color domain B:- Low-Delay: Blue(400), CBR: Green(500)

Now, the resolution scheme for color C1 falling back to C2 is identified by value Color:0:C1C2 extended mapping community that the service route maps in Color Domain,

  1.  {Resolve to Gold, Fallback resolve to Silver}
  2.  {Resolve to Blue, Fallback resolve to Green}

As we could see, the service intent is achieved irrespective of the differences in color across color domains under same or different administrative domains where in, the abstract value of the resolution scheme (or the sequential order of colors that the service wants) can be easily agreed upon.

NV> ------------End. }


Here is why I posting the above doubt:

* if things are under same admin control we could presume there is no issue. When you build policy which takes into account each domain's color mapped to some anchor points (on the edge or within a domain) and therefor end to end path will likely be formed and work as expected

* if things are not under same administration each color/class may mean completely separate thing unless we define in stone what it should mean. And if we do that there is no need to remap anything any longer.

NV> ------------{ Start… Example describing how color is different from intent

This is from one of the CT slides for IETF IDR. With CT, the following differential treatment for the different service prefixes of the SAME service at the SAME Service Node or Border Nodes is possible.

Say,

  *   R1 wants the intent : C1 primary, fallback to best-effort
  *   R2 wants the intent : C1 primary, fallback to C2
  *   R3 wants the intent : C1 primary, fallback to C3

Which is an use case where all service prefixes want C1 as primary but have different fallback order.

This is achieved using Mapping Communities, as below:

  *   R1 advertised with M1 (Color:0:<C1BE>),

     *   maps to Resolution-Scheme1: Transport classes {C1, best-effort}

  *   R2 advertised with M2, (Color:0:<C1C2>) -

     *   maps to Resolution-Scheme2: Transport classes {C1, C2}

  *   R3 advertised with M3, (Color:0:<C1C3>) – Abstract value

     *   maps to Resolution-Scheme3: Transport classes {C1, C3}

Here C1BE, C1C2, C1C3 are abstract values and do not represent C1, C2 or C3 that can be easily agreed between different administrative domains.

NV> ------------End. }


Thx a lot,
R.




Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only