Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 22 October 2021 13:22 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629833A0DB8; Fri, 22 Oct 2021 06:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JlIb2hWT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mUPT4zGy
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDbgl0J0LF4m; Fri, 22 Oct 2021 06:22:43 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD813A0DBA; Fri, 22 Oct 2021 06:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65674; q=dns/txt; s=iport; t=1634908959; x=1636118559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DYTM76pNocBjmUmA3xIAqYyr/9SpH3CxJDNHhxZjQpM=; b=JlIb2hWTsXYOAXDOo1bZSI4QNvoH+XhRr8uyNIRcqetZHwbEJItpR535 iL+82rJUpxtUTVxwgYfMuhYWNoPb/W40MOr8HfXnqzTwRwlGmh00xOAPs 3MuziCmfA37Im2+WBjSJqYGpfiostf185LNkvi/f1Qva3+Vj1/sCDOtwH k=;
X-IPAS-Result: =?us-ascii?q?A0BTAACEunJh/5hdJa1aHAEBAQEBAQcBARIBAQQEAQGCB?= =?us-ascii?q?QcBAQsBgSAwIwYoB3cOTDcxhEeDRwOEWWCIDQOKdZABgS4UgREDVAsBAQENA?= =?us-ascii?q?QFBBAEBhQACgk0CJTQJDgECBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgSBEROFa?= =?us-ascii?q?A2GQgEBAQEDEggHAQsTAQE3AQ8CAQgRAwEBARARAQYCAwIhERQJCAIEAQ0FC?= =?us-ascii?q?BMHglCBflcDLwGRVo82AYE6AoofdAGBNoEBgggBAQYEBIUKDQuCNQmBOgGDB?= =?us-ascii?q?YJ3VEqBIIVbJxyBSUSBFAFDgWaBAT6BUAFQQgSBKQESASMMEgYQgl86gi6Ma?= =?us-ascii?q?BBbBgI8JgRLTi14FwIEAQokER4CD5FGGoxJjVSRRmcKgzKZDoYHFYNqi26XR?= =?us-ascii?q?JUYDGgfgiCNeJA8hQkCBAIEBQIOAQEGNYEsO2lwcBU7gmlRGQ+OIAwFEYEEA?= =?us-ascii?q?QeCRIgtgjF0AjYCBgsBAQMJkEwBAQ?=
IronPort-PHdr: A9a23:BuVw9BSdJJQDKJSQ5H3CAcgeJdpso6PLVj580XJvo7JTe7uu/tLpO 0mMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAFnpnwcUblgAtGoiJXEv8KvO5bzEzA 8lDElRi+iLzPU1cAs2rYVrUrzW75iITHROqMw1zK6z1F4fegt7x2fq1/sjYYh5Dg3y2ZrYhR Cg=
IronPort-Data: A9a23:Dw3hHaoKsUERkZBfkeSdgkivOtVeBmJkZBIvgKrLsJaIsI4StFCzt garIBmDOaqKYDP3LdF/a9vjoE0Cu8fSn9dlSQs5qC03Q3tB9ePIVI+TRqvS04x+DSFioGZPt Zh2hgzodZhsJpPkS5TE3oHJ9RGQ74nQLlbHILOCan8ZqTNMEn970Es7wbRh2OaEvPDga++zk YKqyyHgEAfNNw5cagr4PIra9XuDFNyr0N8plgRWicJj5TcypFFJZH4rHpxdGlOjKmVi8kFWc M6YpF2x1juxEx7AkbpJmJ6jGqEBaua60QRjFhO6VoD66iWuqBDe3Y4LZOMQTUZrjQ6owcxej 45jvtuXalgQa/ikdOQ1C3G0EglkNqFAvbTAO3X66IqYzlbNdD3nxPAG4EMeZNJDvL0oRzAVs 6VFcljhbTjb7w6y6LG2VuBqmuwoLdLgO8UUvXQIITTxXa98HcmYHviSjTNe9AcNms8VG+vlX swAUhpOcxCHQRRjO1hCXfrSm8/t3BETaQZws1KPrKY742H7zhF30aDgKpzTd8DibcBIhVqRv mLPuW34GQoTM8Ge4TyC8XOlwOTImEvTQ5oIFbu33v9nnFPVwXYcYDUaT1K1vby4h1KwHthSM FdR4TAw8+0p+Va1T9LwRDW5rWKK+BkGVLJ4GeAh8ymMx7bapQGDCQAsVDdAbsc5s9U6AyMj0 FChn87gGjFu9raSTBqgGqy8tzi+P20eKnUPIHZCRgoe6N6lq4Y25v7Scute/GeOpoWdMVnNL /qi9UDSW517YRY36piG
IronPort-HdrOrdr: A9a23:3ZOMZ6O6pMVO5MBcT23155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMcs1NKZPDUO11HYV72KgbGSpgEIXheOitK1tp 0QMpSWaueAd2SS5PySiGLTfrpQo6jkzEnrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HOVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5h+7Y23+4oowwfX+0KVjbdaKvq/VfcO0aeSAWMR4Z zxStEbTp1OAj3qDzmISFDWqnjdOX4Vmg/fIBmj8CDeSQiTfkNmNyKH7rgpKCcxonBQz+1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fLFuI4O5l7Zvtn+90a1wax7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm00xR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdCuWs7ayvVeIWzNV1wg1nwqUmGLEHQI/Bllu5EU+fHNcjW2AW4OSQTr/c=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.87,172,1631577600"; d="scan'208,217";a="812413550"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Oct 2021 13:22:37 +0000
Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 19MDMbNs010042 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2021 13:22:37 GMT
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 22 Oct 2021 08:22:37 -0500
Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 22 Oct 2021 08:22:36 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 22 Oct 2021 09:22:36 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lllQ6DBJSkHs45/y0nj3eH3SD4rLrDCmZYxwe/61akK2G+wX0liXoDVQXSIDDjfluc2XLgGN60CIObjm5VPwskRTCTGKAQfpqhAWSFgkGZ7zfp3woIg0tiCBH10ji/Sz4QeJClIbKpTVA5tpSUNNeBCE29NlAL5XncA7CVp6QPgP7nUS/7XCV0qwY/VYDGUVanCdwFqMjKWFGi5KQKq5tzEVMyPPoh/rHH1e77g+Ha+b/xZIquro485MsI0WbNga/aggdYAIeV2rwi41yZBBut3l9WbZGCrKE1Tsu5qvSo/5sHMSled/GFxn4pquiHkhvoEHGi6iBLHQzDQu3RXcbw==
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=oQGF3NoU4m5lo8ub9eyNmB2Hxl2IPa7mIn6PRUi97YM=; b=a6IAkpCRVvx4WDrn7LofOOnIYerceu5TjOxQvr6yvEYvaMY1fH8lTnqshELsm9OQ/BTiEVUU4v4zJt1CMmuVO+pawIeMOk9pCxK1Die0ltA1ULmo771pyDreuKkZvUV8ASzd6zajCkeRAp+IeKlDijRUyHiSK1/QQ7Y/AN3gPoCCyvcUxoUUbPkZs3Z0ByyHjBRg/qr3zwmmOT3VqI9uQOudwy3gxNCOqRYIElkYqx5Ks66lRs1ARKNC9st7gJa6q3Qz9ofRZxzk7KX4Zt4Toz5SdyPSTuCGMwtPz2m5Tob+2WqRtSHwFFtHmNYmWgQ1NZIlarTe85B7mhxBEMSeZw==
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=oQGF3NoU4m5lo8ub9eyNmB2Hxl2IPa7mIn6PRUi97YM=; b=mUPT4zGySm+BTLviXYpR1oehAdO8dFgAcw6Ecq+fIfmGqMh2XwKQfWVHmfYhjJi2gRYnof09OpqypN2XT8HJGEaQH5MqVCXdEHI0bYnbSE0P+WvOkOMlrXIHdtT+zwxam/klmPJAuUvfZQNedqv92A5ZkVMfKi4NSeTCZTZtioc=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB5092.namprd11.prod.outlook.com (2603:10b6:303:6e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Fri, 22 Oct 2021 13:22:35 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::5855:1d90:e596:d998]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::5855:1d90:e596:d998%6]) with mapi id 15.20.4628.018; Fri, 22 Oct 2021 13:22:35 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>, "bess@ietf.org" <bess@ietf.org>
CC: "draft-ietf-bess-srv6-services@ietf.org" <draft-ietf-bess-srv6-services@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <mustapha.aissaoui@nokia.com>, Shraddha Hegde <shraddha@juniper.net>
Thread-Topic: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
Thread-Index: Add5ZuxHtH2qrBhRQGK4/wpw+iW7/ADOgmjgAAC4i7gAAG45wACHp2JQAAGkXhAAP5xUIAACp5twAANe4IAKfvQKwAA9x5rgAAEGhpACXW/OgAS+a8SQ
Date: Fri, 22 Oct 2021 13:22:35 +0000
Message-ID: <MW3PR11MB4570414BEDE5659015F89733C1809@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <BN6PR05MB36346DDD4F6824CD65D70491BE129@BN6PR05MB3634.namprd05.prod.outlook.com>, <BN6PR05MB36341943DEC7D8DC5869A9E0BEE19@BN6PR05MB3634.namprd05.prod.outlook.com> <BY3PR08MB70603EB604AF65D3580E3794F7E19@BY3PR08MB7060.namprd08.prod.outlook.com> <BN6PR05MB363439BAFB0BD66C0DC53354BEE19@BN6PR05MB3634.namprd05.prod.outlook.com> <BN6PR05MB3634E1880604AC6AC11ECAD8BEE49@BN6PR05MB3634.namprd05.prod.outlook.com> <MW3PR11MB4570AFB28290F5AA0C871141C1E49@MW3PR11MB4570.namprd11.prod.outlook.com> <DM6PR08MB602757AF0FDA0B510B89923DE4E59@DM6PR08MB6027.namprd08.prod.outlook.com> <MW3PR11MB4570C5B83B5DA1022AED682FC1E59@MW3PR11MB4570.namprd11.prod.outlook.com> <DM6PR08MB60274C149331AD9D08C0ED39E4E59@DM6PR08MB6027.namprd08.prod.outlook.com> <MW3PR11MB457050C19A64BD4E2FE37735C1DB9@MW3PR11MB4570.namprd11.prod.outlook.com> <cafe3ea556a64f2bb2f65e1bd708eef9@huawei.com> <MW3PR11MB4570A71521F8BBEF2A2F1A74C1DC9@MW3PR11MB4570.namprd11.prod.outlook.com> <c215a5356578486f832ebed785aa5b9e@huawei.com>
In-Reply-To: <c215a5356578486f832ebed785aa5b9e@huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4ee56340-22c8-4422-3d0a-08d9955f02da
x-ms-traffictypediagnostic: CO1PR11MB5092:
x-microsoft-antispam-prvs: <CO1PR11MB509245D0F6D02606303FCC80C1809@CO1PR11MB5092.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CNUFgnne+7ZCy6Z8VyS4iuBESNjaga3Ypu1ElGJrc32PhCeXkkBmnep6jNvBWQxUJ0IRAz1D8f0q3zB+01peco4NQoFAcP8v0vwtISf1rhzGJcjpmiuBQMdNB+oCc0fvFma8A3XKt4txMDnEYcpe40W7OBTn5RjjOBjfTkz9NCNZMFZ0x/pfAlLLwEPvbjiVOpRyIy4YZV9/jziZFSKQeXKIaBR1KMjrf853l7XfwSWh9f59hGyYM3RuxrfuPiN4lGNqNTnOX+F+ylPhrVy2r1W/SaLMZDywzUOhPXnjfiqvYk4dJsOA7+yl8X4io3dq/G5G+2gPrImZl+d0/AxLF8UyqBMSQfIe2TKb0UrEhPoeqm/zt75AsuEW7xncRGSCc0sAZ0c8vuEJ0PR/Gdlurr7ffpnF9IQuyOhMIwEU6MFr9QZb0HX7kkbs6B0c/hmauBYmsahqQdYYiEDtJCKXPr91+mCuByyzSJpWsE1GoBCC62zopwVbTCqW25E1G5hibjqhmjd2ZObr9tl5yeyfHAxKoCickTPkFY5b63AZvk2uoNch4EsLpHR5fcvN1BdGolhZ+gdrXvK8OhZ8j3eEXrEEPKAtvf0xNjh7KQbB/dYK4a1ulzsEtYzqclv6M6FQOv5zr9Hw+Wv0Np9bp8NMH/w3/JMPHVEeTzJfE8ukvTEjEqwFxBnGXTNpHlGZs7dtEKE4G9oYa85MZqxPGgNthQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(33656002)(316002)(53546011)(6506007)(76116006)(4326008)(54906003)(38070700005)(2906002)(52536014)(55016002)(9686003)(30864003)(38100700002)(8676002)(186003)(110136005)(8936002)(9326002)(7696005)(122000001)(5660300002)(66446008)(86362001)(508600001)(66946007)(26005)(66556008)(64756008)(66476007)(83380400001)(71200400001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?NDZLd2dVT2p0VDdHTDBIU1NGYS8wckZxU09ESk4xNUlhMW1Xd3A5TWxy?= =?iso-2022-jp?B?QU4zYXBkNzk4MFRqNlF4ak05THFldFY5SUx3U1hkRUU3R21mbFUraUlI?= =?iso-2022-jp?B?SXBxWTVubDZ1M0VCUzBuNkxMZ2FBSlVsVVg3N05JWDV1SW1BM3FXWlJG?= =?iso-2022-jp?B?bnA5KzQ0NTZwVUkzNnRqTjR4bWV2cDljdUd0Y21VR2Y4N3BLYnU0M2Jq?= =?iso-2022-jp?B?UVNlWnVwempPTG1ITGhZVk4xTG0wcjlYeHJqVFlKTWFLakx6cUc2cW5r?= =?iso-2022-jp?B?b25BMTlUZHExTkhJekRGYVRvYUtnMWZ4NTVUSFVqazJlV0pGL0lob25i?= =?iso-2022-jp?B?Y3Q1ZUt1V3d6Z25Tb1lVbjhXWlEreWovRnhXRWZiTzJWOGxzbHBlQnRi?= =?iso-2022-jp?B?d3ZaME9hRFZtSE4zMU1VR1ozempOOG01RHBEbXQ2QnB1M0hMc0xudE5o?= =?iso-2022-jp?B?RUVTaUIxZHVlVDlaMXZRMWJNUDNaQ0ZTcThHMThSMytmNkhsejk3ZlpX?= =?iso-2022-jp?B?TWJ0K2hYT09xeld3T2ROY0VVTnQwV3N2M0JBalgybGJPMWRWck9aOXBH?= =?iso-2022-jp?B?eHdyM0J5a2hDcWo0ajhPVTY4SVoyRHMwNVZ0WXRJb3JiRk80UXJjaUVy?= =?iso-2022-jp?B?TkNBRmVhNHZhRWJxMUdNa1EyMVpReVJ0THQxaVk0RDR6aHBQZlV3RENt?= =?iso-2022-jp?B?cmttRFllOEYzSXJxb2tlNDJKMlk3N1RIT05BV1llbHRmSEY3b1BIZmdV?= =?iso-2022-jp?B?THMrdEpxL3d5NVRORzhwNVI2SmhjU2F0K0pRTjY1MUFOenpsWnBURkR1?= =?iso-2022-jp?B?UWMwNDBGVlFuRWJvQmhWQ0NwSHFVbVB3SjcveUdiUVk1d2I1OWNHTjdE?= =?iso-2022-jp?B?VURZU1diQjZCRnRqNnZ3a3paMSsrU2pXY2JmN2JUcjcvb0g4MDZHVEZE?= =?iso-2022-jp?B?Mnh5MEpTeTZFdU91MHVJdWEya0VYV3h0alMrV05XUG54bFI2YVFtclBZ?= =?iso-2022-jp?B?amhFRXJnTnF3T2p1cVdaZDBJY2hGWkpHM0gvQ3FWVytkOHQwR2lqazhs?= =?iso-2022-jp?B?L2o0ZlpDSnlWQnRpci9zR0tkdDBYRzdMQnZMUkFNRDYydWt0ZEtCbnJ2?= =?iso-2022-jp?B?YmpSa29ZbUltZEdXMGd4K1Y4WSt2d3lrcjlncEM0RUc2VXdpOFJPTFRa?= =?iso-2022-jp?B?VHdZbStXWjJIMkYxakhEemg5RzMyeHNHOEdDWkI1aFlKczZ0WXIxaU5r?= =?iso-2022-jp?B?eXdIVHlESXpRK1lXczEvWTREay9uYUJ2dHlHZU5EUmo0T1RrK1pDVWFT?= =?iso-2022-jp?B?cjhIQ09BZno5cmwzMEJpZy9hbFliUktENHVPS1BjYjh6SGdMaUlWY0xk?= =?iso-2022-jp?B?cVBOc2hCMEkyYWxPZEhFeGN2dWM1dllDVk1KM0FxV3M3Qit4VlVXQ1VV?= =?iso-2022-jp?B?YUhXVkJDaDlUclhXbGZ4K1JJTWJ0MHZxMTVWT0xXbXQ5MlVoUEJwaXhV?= =?iso-2022-jp?B?VWdVZ2k2ck40clVzU3FleHlablZmWlY5aFJSYXFOd21ITTBUOTlQdjVl?= =?iso-2022-jp?B?U2pWeEJYcURqMHRYQ0cwK0tFejdEM0EreGRsSHV2S3FZRTk3UDJTRldU?= =?iso-2022-jp?B?Qys5cUxHeWtJS2FoYkp4Y0tETE9UNjRDZEx1SUNDaFZZbS9HUGJGckhQ?= =?iso-2022-jp?B?V25HejJxekR5TmpjYUQ4TlM2SFBNZFRiaVcya1FjRitaM0s4WlBIQTRM?= =?iso-2022-jp?B?Z3FYWGc2Y0lZVmZxcWhISWFMQ1EvdGQ5em9qbU9OU0xFbm1ScjZtOGFi?= =?iso-2022-jp?B?eW9Qc2FreWdLaFBFOFF2OVVMSnR0VFJ4U2pMeXpOZyttM0t4R3VraDhY?= =?iso-2022-jp?B?cVlwbkV0SHhVcTV6SW1YVW1GVlZ3SlhIbnRWYTlzckkyU2JLV28yYklV?= =?iso-2022-jp?B?RE5ZbHpSdFA1dGNIY1plc2twdVNEYnB1a1QyYjRRRzN0eU0zSEwyaXhN?= =?iso-2022-jp?B?MnI4NGpUTmxIeWlSWTV2NldVYVhic1VOZThkV3VqU01sdjNOSitVU0N0?= =?iso-2022-jp?B?b3FiOGsvSnZ2R293NDFYd2NFS2ZvNkk9?=
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570414BEDE5659015F89733C1809MW3PR11MB4570namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ee56340-22c8-4422-3d0a-08d9955f02da
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2021 13:22:35.1366 (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: ketant@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5092
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/HjrTQmRSAqyU8TQORd7hctNoMZs>
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Oct 2021 13:22:52 -0000

Hi Haibo,

Thanks for your feedback and confirmation. Indeed the “alternate steering mechanism” is better. Will push this change in the next revision.

Thanks,
Ketan

From: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
Sent: 28 September 2021 15:31
To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; bess@ietf.org
Cc: draft-ietf-bess-srv6-services@ietf.org; spring@ietf.org; Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com>om>; Shraddha Hegde <shraddha@juniper.net>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

I’m sorry I have missed your reply.

For SRv6 services, we may have two choice for service. Use SRv6 SID to do best effort, or use <N,C> to steering to a SRv6 Policy。
Also we may use both of them, but most time we are priority to use the SRv6 Policy than fall-back to SRv6 best effort, while SRv6 Policy is down.
So I think maybe use “alternate steering mechanism” is better.  Or maybe I misunderstood the sentence?

Regards,
Haibo

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Thursday, September 16, 2021 4:55 PM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>; bess@ietf.org<mailto:bess@ietf.org>
Cc: draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com<mailto:mustapha.aissaoui@nokia.com>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Haibo,

Since the discussion on the list was related to fallback mechanisms, we have those words.

How about s/fallback mechanism /alternate steering mechanism ? Or please suggest if you had something else in your mind.

Thanks,
Ketan

From: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>
Sent: 16 September 2021 14:13
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; bess@ietf.org<mailto:bess@ietf.org>
Cc: draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com<mailto:mustapha.aissaoui@nokia.com>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

       I think the overall description is OK. But is it appropriate to use the word “fallback mechanism”?

Regards,
Haibo

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Wednesday, September 15, 2021 11:00 AM
To: bess@ietf.org<mailto:bess@ietf.org>
Cc: draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com<mailto:mustapha.aissaoui@nokia.com>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hello All,

Getting back on this topic with a text update proposal for sec 5 and 6 of the draft.

The objective of this change is to clarify the use of the SHOULD that is used in this text.

OLD/CURRENT
   When providing best-effort connectivity to the egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation.

NEW
   When the steering for SRv6 services is based on shortest path forwarding (e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) to the egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation.  The result of an
   SRv6 Service SID reachability (e.g. when provided via IGP Flexible
   Algorithm) can be ignored if the ingress PE has a local policy that
   allows a fallback mechanism to reach the egress PE. The details of
   such fallback mechanisms is outside the scope of this document.

Please let know your feedback. The authors will look to incorporate this change along with any other comments as part of the AD review updates.

Thanks,
Ketan

From: Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com<mailto:mustapha.aissaoui@nokia.com>>
Sent: 23 July 2021 22:10
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

That is great. Thank you.

Mustapha.

From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Sent: Friday, July 23, 2021 11:08 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com<mailto:mustapha.aissaoui@nokia.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

< trimming list to mostly mailers >

Hi Mustapha,

I agree.

Also after seeing Shraddha’s latest email, the coverage and details for the fallback mechanisms that she seems to be looking for is quite vast and better tackled in a separate document since this one has completed its WGLC. Some of those concepts are applicable for MPLS as well and not SRv6 specific.

We (authors) will work on some text proposal and get back to the WG next week.

Thanks,
Ketan

From: Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com<mailto:mustapha.aissaoui@nokia.com>>
Sent: 23 July 2021 19:20
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>; Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>; gdawra.ietf@gmail.com<mailto:gdawra.ietf@gmail.com>; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com<mailto:cfilsfil@cisco.com>>; robert@raszuk.net<mailto:robert@raszuk.net>; bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Cc: spring@ietf.org<mailto:spring@ietf.org>; bgp@ans.net<mailto:bgp@ans.net>; Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,
I believe it will be worth expanding the text in draft-ietf-bess-srv6-services to describe the two types of transport more consistently and along the lines of what you wrote below. Also, I would propose that we move away from terminology like best-effort service and instead just mention shortest path forwarding in base topology or in flex-algo topology.

Mustapha.

From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, July 22, 2021 3:43 AM
To: Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>; Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto:mrajesh=40juniper.net@dmarc.ietf.org>>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>; gdawra.ietf@gmail.com<mailto:gdawra.ietf@gmail.com>; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com<mailto:cfilsfil@cisco.com>>; robert@raszuk.net<mailto:robert@raszuk.net>; bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Cc: spring@ietf.org<mailto:spring@ietf.org>; bgp@ans.net<mailto:bgp@ans.net>; Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Rajesh,

My apologies for the delay in my response. However, some of my co-authors and other WG members have already clarified this point. Let me try to summarize.

The draft covers two SRv6 based mechanisms for the transport of services between SRv6 PEs. (1) using SR Policy based steering (i.e. for service routes with Color Extended Communities) using the H.encap construct along with a list of SRv6 segments  and the other (2) using H.encap with just the SRv6 Service SID in the IPv6 DA.

As mentioned in the draft, it is required to verify the reachability of the SRv6 Service SID before the mechanism (2) can be used. This is an explicit clarification for verification of reachability. In an MPLS-VPN scenario, if the egress PE NH’s IP route is reachable at the ingress PE but without an MPLS label, such a path cannot be used. This is semantically similar.

The mechanism (1) is different since the routing to the egress PE is via SR Policy and hence the requirement for verification of reachability of the SRv6 Service SID is not there.

There is no mandate for the setting of the NH since that is left to deployment design.

I hope this helps in addition to the various clarifications already provided by others.

Thanks,
Ketan

From: Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>
Sent: 22 July 2021 12:09
To: Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto:mrajesh=40juniper.net@dmarc.ietf.org>>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>; Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; gdawra.ietf@gmail.com<mailto:gdawra.ietf@gmail.com>; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com<mailto:cfilsfil@cisco.com>>; robert@raszuk.net<mailto:robert@raszuk.net>; bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Cc: spring@ietf.org<mailto:spring@ietf.org>; bgp@ans.net<mailto:bgp@ans.net>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>; Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Could Authors respond to this ?



Juniper Business Use Only
From: Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto:mrajesh=40juniper.net@dmarc.ietf.org>>
Sent: Monday, July 19, 2021 7:28 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>; Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>; Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; gdawra.ietf@gmail.com<mailto:gdawra.ietf@gmail.com>; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com<mailto:cfilsfil@cisco.com>>; robert@raszuk.net<mailto:robert@raszuk.net>; bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Cc: spring@ietf.org<mailto:spring@ietf.org>; bgp@ans.net<mailto:bgp@ans.net>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>; Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi All,

For best effort service, flex algo - Resolve SRv6 Service SID for forwarding.
For SR-TE, CAR/CT - Resolve BGP next hop for forwarding.

There is no unification here, it’s better to unify.
Any other solution is OK.

Thanks
Rajesh



Juniper Business Use Only
From: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>
Sent: Monday, July 19, 2021 7:17 PM
To: Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>; Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto:mrajesh=40juniper.net@dmarc.ietf.org>>; Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; gdawra.ietf@gmail.com<mailto:gdawra.ietf@gmail.com>; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com<mailto:cfilsfil@cisco.com>>; robert@raszuk.net<mailto:robert@raszuk.net>; bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Cc: spring@ietf.org<mailto:spring@ietf.org>; bgp@ans.net<mailto:bgp@ans.net>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>; Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi Rajesh,

The draft is written so that the next-hop address MAY be covered by the locator, but there are cases in which the next-hop address is not part of the locator prefix, and there are implementations already allowing that, so I don’t agree the document should mandate what you are suggesting.

Thanks.
Jorge

From: Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>
Date: Monday, July 19, 2021 at 3:24 PM
To: Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto:mrajesh=40juniper.net@dmarc.ietf.org>>, Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>, gdawra.ietf@gmail.com<mailto:gdawra.ietf@gmail.com> <gdawra.ietf@gmail.com<mailto:gdawra.ietf@gmail.com>>, Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com<mailto:cfilsfil@cisco.com>>, robert@raszuk.net<mailto:robert@raszuk.net> <robert@raszuk.net<mailto:robert@raszuk.net>>, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>, Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto:spring@ietf.org>>, bgp@ans.net<mailto:bgp@ans.net> <bgp@ans.net<mailto:bgp@ans.net>>, Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
Hi Authors,

Please respond.

Thanks
Rajesh



Juniper Business Use Only
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; gdawra.ietf@gmail.com<mailto:gdawra.ietf@gmail.com>; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com<mailto:cfilsfil@cisco.com>>; robert@raszuk.net<mailto:robert@raszuk.net>; bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>; jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>
Cc: spring@ietf.org<mailto:spring@ietf.org>; bgp@ans.net<mailto:bgp@ans.net>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>
Subject: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi All,

As per this draft, this is how resolution must work.

1)For Non Intent service Route:
if BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding.

2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):
BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfully resolves then return.
Resolve BGP next hop for forwarding (in case above is not success).


Using Service SID (overlay),for resolution is definitely not recommended.

Instead in case of srv6, we always resolve on BGP nexthop. This will be in line with BGP legacy.
In case of best effort/flex algo we must mandate user to set corresponding locator as BGP nexthop for srv6 routes.
I think this is a reasonable mandate.

Thanks
Rajesh


Juniper Business Use Only