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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Thu, 22 July 2021 08:14 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 E45273A3D59; Thu, 22 Jul 2021 01:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.595
X-Spam-Level:
X-Spam-Status: No, score=-9.595 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LFUExCsH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=m+VXtJt9
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 c0FE_mPc0sPf; Thu, 22 Jul 2021 01:14:12 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE4C3A3D5E; Thu, 22 Jul 2021 01:14:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67847; q=dns/txt; s=iport; t=1626941652; x=1628151252; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oCvfzkjmZAjIB5IOANoXcIzT3sfolSKg2tUGT5ciWyA=; b=LFUExCsHmcik6dH9f8eeSxhJwjXkyoZxzFr3MgpYwv28UfvX9aEfS4R9 Wu0U+Txslmcje0LReWuYlpHi6U4DhL/YQr3U4dc5uegyKul8kRpRYz5bX CjzVntuRPm77LEpBXrHoF4tM4bYwhOEAV8X244FZer3lF3uFaykqBKAlW s=;
X-IPAS-Result: =?us-ascii?q?A0BcCgAFKPlg/4MNJK1aHgEBCxIMQIFOC4EjMFEHdw5MN?= =?us-ascii?q?zGIEAOFOYhhA4pXj1mBLhSBEQNUCwEBAQ0BAUEEAQGEVwKCdgIlNgcOAgQBA?= =?us-ascii?q?QEBAwIDAQEBAQEBAwEBBQEBAQIBBgR7E4VoDYZFAQEBAwESCBMTAQEsCwEEC?= =?us-ascii?q?wIBCBEDAQEBIQEGByERFAkIAgQOBQgMDoJQgX5XAw4hAZ0xAYE6AoofeIE0g?= =?us-ascii?q?QGCBwEBBgQEhSYNC4I0CYE6gnyEDIEZhUsnHIFJRIEUAUOCYj6CIEIEgRgRA?= =?us-ascii?q?RIBIx4GEIMXgi6CLBBbBgI8JgQyET+BBSoNGQQBLgYLIA0CkTWLdY02kH47W?= =?us-ascii?q?wqDJZhZhXoSg2OLXoY+jXuCZZR3DIMhjUuVJQIEAgQFAg4BAQaBZwMxaXBwF?= =?us-ascii?q?TuCaVAZDo4fDBaDT4pecwI2AgYLAQEDCYteAQE?=
IronPort-PHdr: A9a23:e2M4vhWYYAci6r7j2MfQJTA0PVbV8K0aAWYlg6HPw5pCd6259NLjM VDRo/J3gwyBUYba7qdCjOzb++DlVHcb6JmM+HYFbNRXVhADhMlX+m5oAMOMBUDhavK/aSs8E ZdOUVZ/9De6PFRbXsHkaA6arni79zVHHBL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5L Q69qkPascxF6bY=
IronPort-HdrOrdr: A9a23:J9K1iKDHMJZ+PvvlHej1sseALOsnbusQ8zAXPh9KKCC9I/b3qy nxppsmPEfP+UkssHFJo6HmBEDyewKjyXcV2/hQAV7GZmnbUQSTXfpfBOfZsljd8mjFh5JgPM RbAutD4b/LfCJHZK/BiWHSebtNsbr3kpxAx92uskuFJjsaDZ2Imj0JcjpzZXcGPTWua6BJcK a0145inX6NaH4XZsO0Cj0uRO7YveDGk5rgfFovGwMnwBPmt0Lr1JfKVzyjmjsOWTJGxrkvtU LflRbi26mlu/anjjfBym7o6YhMkteJ8KoHOCXMsLlQFtzfsHfvWG1TYczagNnzmpD21L8eqq iKn/7nBbUp15qeRBDunfKn4XiQ7N9n0Q6T9bbfuwq/nSQ8LwhKVPaoQuliA0fkAgMbzaNBOK 4n5RPri7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSpZ2Us4ckWUzxjIeLH47JlO21GnnKp gZMOjMoPJNNV+KZXHQuWdihNSqQ3QoBx+DBkwPoNac3TRalG1wixJw/r1Qol4QsJYmD5VU7e XNNapl0LlIU88NdKp4QOMMW9G+BGDBSQ/FdGiSPVPkHqcaPG+lke+53JwloOWxPJAYxpo7n5 rMFFteqG4pYkrrTdaD2ZVamyq9C1lVnQ6dgv22wqIJ+4EUaICbRRFreWpe2vdI+c9vd/Ezc8 zDT65rPw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.84,260,1620691200"; d="scan'208,217";a="736759407"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jul 2021 08:14:09 +0000
Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 16M8E9W0020007 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 22 Jul 2021 08:14:09 GMT
Received: from xfe-rcd-003.cisco.com (173.37.227.251) 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; Thu, 22 Jul 2021 03:14:09 -0500
Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 22 Jul 2021 03:14:09 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 22 Jul 2021 03:14:09 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BCTz5836SMcj9JWcPp/UHVLgWyMemlfBDVojLCeYfhAIeNwMu64Bqd/LjMbrZqoPEGLO+PdgQKKSr/Ubc8fBMk8DjdbuacXXGJhp1DF2Je+jRNiP0isRsYESMHQ9qcpofd1ETSwylg8QxhZWlvntQ3I/5FENo/53X4mxQXgHwuBjMWQ4D3xDcCBYU0ooe/8y1DJ5U/FfEeKv2pENJRbB3SuC0+HMaYrPeADgw7cU1saskJPW2gzyEmLDkC0b6uxj97VCzOdv+K3W+IHEO9sQ7UVDGppZjPQO0IdbD2VpcV9KYig7S0f3bZfkkdjpMfIP3L6Jz6qVBp6rFLtlDmXMeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VJba8iqlYEfmOt2414umr3CC27gEhRSEl7qhXx0bk6Q=; b=WoNd+SjDB+r3dAt3pRGj9WV/X9iwFWxb5jQWQ5gUx5/ETOXkUr3Q3/3cL6ZO3fUqZdo50U/dqwbtx5QtodC11OvjpgDcPFkjBDi6zPAovgcaS0+smnlueLR5by34R3Y7bP8cl+ulK7KpcneYrZU6okqBLmYwthPr4zCY9a6D1fTBj2siVSEindr92ulOy8UfBc/TWh+EyWQ7DunCFaBb7izbsvtu4PfJckpEF5zRQBOXK2Tp/SxmAk9PcawG8ZIoB+7jInWWmlXYzhdjss+ar47tGp7UasKvgorZNm03OZcPc6CYUFVmE0V7fkPlNRpvG/2IrGF+wDXmxxjUS4E0Aw==
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=VJba8iqlYEfmOt2414umr3CC27gEhRSEl7qhXx0bk6Q=; b=m+VXtJt98NOyeLG63du6C/m8GN0ebYrc83Us0gpNy7SYFKOZXNkqbb5avkvEyosDQFX7pHH66N8Xbkk4f4DylB783NevmsGlfE3SYNpMchBmddWA311RzzUCR2C/rK534udO6viBvjTf/qfhcQJzI1X9Rby4v9pS7bGoeREy5LM=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2175.namprd11.prod.outlook.com (2603:10b6:301:5b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.24; Thu, 22 Jul 2021 08:14:07 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::7c01:5b00:b7b8:3e87]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::7c01:5b00:b7b8:3e87%3]) with mapi id 15.20.4331.034; Thu, 22 Jul 2021 08:14:07 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-srv6-services@ietf.org" <draft-ietf-bess-srv6-services@ietf.org>
Thread-Topic: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
Thread-Index: AQHXfU2NetgcsrfYIE2eXM1SSORAM6tOoX0Q
Date: Thu, 22 Jul 2021 08:14:07 +0000
Message-ID: <MW3PR11MB4570D6D60450CC3FE7DDD420C1E49@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <BN6PR05MB36346DDD4F6824CD65D70491BE129@BN6PR05MB3634.namprd05.prod.outlook.com> <BN6PR05MB36341943DEC7D8DC5869A9E0BEE19@BN6PR05MB3634.namprd05.prod.outlook.com> <BY3PR08MB70603EB604AF65D3580E3794F7E19@BY3PR08MB7060.namprd08.prod.outlook.com> <DM6PR08MB6027C9A41B6B1DF2BB59687FE4E19@DM6PR08MB6027.namprd08.prod.outlook.com> <CY4PR05MB3576D4484BD96F6E08604AF4D5E29@CY4PR05MB3576.namprd05.prod.outlook.com> <CAOj+MMGuMG8jwEUbeUkZJc_vv+1y1cnav5rp1tL6drRr-G3sCA@mail.gmail.com> <CY4PR05MB3576F5A0BF1ECFA69808D637D5E29@CY4PR05MB3576.namprd05.prod.outlook.com> <CAOj+MME3=XPFL=qmY65nCkbL9+4kjionTRPPPjUCj3hTr8D+vg@mail.gmail.com> <CY4PR05MB357659B2C5C84B3CA9C6073ED5E29@CY4PR05MB3576.namprd05.prod.outlook.com>
In-Reply-To: <CY4PR05MB357659B2C5C84B3CA9C6073ED5E29@CY4PR05MB3576.namprd05.prod.outlook.com>
Accept-Language: en-GB, 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_SetDate=2021-07-20T09:56:09Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=8e2112b7-664f-40f6-8573-8634e7773963; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 94ea388c-e536-4730-5e7f-08d94ce8ad5f
x-ms-traffictypediagnostic: MWHPR1101MB2175:
x-microsoft-antispam-prvs: <MWHPR1101MB2175255F9F95357DDE14506BC1E49@MWHPR1101MB2175.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: P4QP9ZOmmttYYjZhlMXrxvAHCCnsyEOKTQ15LlqaqJC2He4YFOCLy1vggh+IwfVZwMDoQTdNHV7I4S4F/JD9lbp2cGwI48WNq9ollgm2o8RP8AkuW7xV/17Dt1mtqo3SrZTEfwIHbMF6XD2RWmOAsPRBy5LOWTMdBGNWoPBAea7tm0odDDbuZzKpnuX7Mazl5mEYDw/nMEGcwBTCctzljyJvH2tTeswpy3ThK/KX0xWgIy67cqbeu/+GIAesOYXVPi/QcF/qBrXuvYG9g9bAXVaYG4/kw4jI7BQiE99zGGjX6hNwuYn9a87zgh3wTlfpSZYj1uvK+ZgLhMMcRpLblPsxIIrGcNH+73KOceks4wNYgkcUkrIp4/ik2bzsPDFGdQv3ycfTLnczHmcIlD0FmkL9kYqw+TNayqacB1usyz0SOAx1X5eeq7AeiO2l7NCxsun5tCtXMO4bU5YQlbdJaz3XWu2Cqk7m+4nFkUJrlv5FMvHNPbtnRkxXcJSNNRgO3XNvq8R4p5CKed07zzeOLQ0KrzFAuimSA133pikoXa7umv9ylClONGdu61kXpu0AMt7upwIlzABFA3XArqm/jY93aIkTNWdSAaBhH3HtKuoI9r08sy45Ury/14gc+oaP/kWxFL+HbGJKormWLplrVAxHB4I02fqAH2QcKFJPnFPJ2tui9tajqJkezxkO30raI3d6NV82vtCVK2ttbC72bg==
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:(39860400002)(346002)(366004)(136003)(376002)(396003)(66556008)(86362001)(66446008)(53546011)(316002)(6506007)(122000001)(66946007)(64756008)(71200400001)(76116006)(55016002)(186003)(7696005)(26005)(83380400001)(66476007)(478600001)(30864003)(54906003)(9686003)(33656002)(8936002)(9326002)(4326008)(5660300002)(2906002)(8676002)(38100700002)(52536014)(38070700004)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?7ew+wShZiZQXcD1SRm01SgteWtbBmfPh/akKZm2pojYKPCeFO8/8H+2ZHH03?= =?us-ascii?Q?T+upsR+gWtOjHIpMYxmEfn7cbIOBtP/iY97Vj2a0JnSM4gzI98xjLCBtOjOA?= =?us-ascii?Q?bwEPKGEHkbG+W1g2tm45bzZQkGFGM495ooXbOFDEqdDQiJgdD4hQ4dBJHmIu?= =?us-ascii?Q?RRgTPHo/ORrKSOW7l1ipC6+CzJvholjz0fH7eyWEXdS8C8J+E/oOlfuokOFm?= =?us-ascii?Q?U5lmq1xXG+t/xqxKkVnP0nnn3USnJvgJkf5846QlmjPfkz52D+uWRxEEL95G?= =?us-ascii?Q?FOXW2H5Coh6noe65A/R7hTFfMSsB1AMTpPoj7rYmve+LCzvbXVMsQrbA6qqk?= =?us-ascii?Q?MmOEP5HNTNjEpM15SmeWs0ObO+ZTdys13hJxPwqCTcMZgC95MaoGYysSSEBs?= =?us-ascii?Q?MWYccdWU39r+YevQSSiRv9A67AXFNOzHdfy12zBb8H34Aapbhu+4WF/4fllu?= =?us-ascii?Q?J7aIs/asQE9zs4FVC+ehN0KhiiMyaQlQY01xPeYRAE/3SE/qtVllfAFsterD?= =?us-ascii?Q?1HoZcWE6XGUYf/yHSCQpYYbixyI+BbhZbr9jHG816GaYt+X3KZV9eS7E6/ds?= =?us-ascii?Q?19yHtslRpvsgoLReK8IdspwvE4BGCVE3SEQtxHd0QpykUD7pG54oW4QYM58b?= =?us-ascii?Q?D6xWnattBJoTd5roE4Okb4BlZM1APqss3KwR/WhbIg+qneD+34zOBD1s0hx9?= =?us-ascii?Q?RFJD76oCROKeh6NPMHtZjvyCAp8OGO2e6eITpdo9pHqYYDmIP8KIpD2XMB5J?= =?us-ascii?Q?RyZ4wo0IiKW0xyQn6yn9oBFWuTWEIcgTQFnLb5Pd5PM9+cb6ZIlSsX9q+VIN?= =?us-ascii?Q?yNHyForgvSFaJwmSMwFSWbwECrfdU2VEqNS8kSwbnONqMT/VsG4oKPLTo0Rx?= =?us-ascii?Q?iIGxiH8aI1+pKGWtRYIR8uCE/l6c3ccBLtCXZK/YBWW4EhQcif5OSd8R1V2s?= =?us-ascii?Q?hCx+QhOp9PF+5MJ3Ru2CzDoSOBBWyLZ+UmAg4FdS/5cUmptJJ4TokUZ/8vzt?= =?us-ascii?Q?t2XJM6u6gn7t8v8DIFVtqw5mGQ71re+WQYYRxTbV15+BMAca1QLRB+3cZRuP?= =?us-ascii?Q?tPyBoyVTko4JTx2tlZSPFah17Xisvj3NwBx7LJfvdEwaOzpe7eUD7T1LuBpW?= =?us-ascii?Q?z8GmxUrnoZ7SaLtJiNKbooWucEsgpBsiXUfk4gyiTKBHzuKUUnE4ADWUGnfB?= =?us-ascii?Q?igph8Jk8/lGntBfEJmGbGBN78D5ddqzdLIqanIN2NGoMsTwus2gv5v/PbIrz?= =?us-ascii?Q?b7OVGjc8qRGsQtOm1jpI1rXFuBzrZdrC58CSoYmLKlhakS7IxDg2DkGMLxq1?= =?us-ascii?Q?SB83a0zE6hq9BN+n/QNCZYDW?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570D6D60450CC3FE7DDD420C1E49MW3PR11MB4570namp_"
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: 94ea388c-e536-4730-5e7f-08d94ce8ad5f
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2021 08:14:07.3701 (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: f5A8Sk4rkVyW+1bKv3g6ms2+QswgSx9RmLhawdlKsJvL1uvRVp275XMhE0FXV1B8SNYdUpLoVlkDCg9/W0h3Sg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2175
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/S9KjkiA3RZWC5hqKwNHczB5O4Pw>
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: Thu, 22 Jul 2021 08:14:18 -0000

Hi Shraddha,

As clarified a short while ago on the same thread, the draft talks about two SRv6-based transport mechanisms. I believe your comments are not related to the SR Policy based steering mechanisms. We already have mechanisms defined for fallback in that case.

Since the draft is covering SRv6-based mechanisms, we have obviously no text in there for other forms of tunnelling between the PEs.

As has been clarified by others, there can be many different forms of reachability or tunnels setup. In the end though, it would be an implementation specific mechanism or a way to resolve the SRv6 Service SID over such a tunnel. E.g. a backup static route pointing over an IP-in-IP tunnel? Or set color extended community locally and steer over an SR Policy that uses best-effort. Or other such implementation-specific options via other forms of route-policy.

Please check inline below.

From: spring <spring-bounces@ietf.org> On Behalf Of Shraddha Hegde
Sent: 20 July 2021 15:26
To: Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the destination address.

And hence service SID should be resolvable. This is not the case when a service SID

Corresponding to flex-algo wants to fallback on best effort services. The destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





"When providing best-effort connectivity or flex-algo 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.

"

[KT] We have an edit change in the buffer on this text that we will post it once the submission window opens over the weekend. How BGP resolves is implementation specific and a local policy. E.g. it could be via a backup static route as indicated above or via some other mechanisms mentioned above. Also note that the usage is a SHOULD to allow implementation-specific mechanisms.



"In some cases a service prefix intending to use flex-algo paths may want fallback on

best effort paths when a flex-algo path isn't available. The fallback behavior

SHOULD be governed by local policies.

The destination address SHOULD contain the best-effort locator based END SID

of the egress PE and the SRH SHOULD contain the service SID. Service SID

resolvability SHOULD NOT be checked on the ingress for this case."

[KT] Why should the fallback be only over best-effort locator? Why can't it be over another Flex-Algo, or some IP-IP tunnel or even perhaps an MPLS path. Why just this mechanism and that too is suggested to be mandated as a SHOULD? All these techniques and mechanisms would be implementation and more importantly deployment specific. Therefore, I do not agree with this text proposal.



Thanks,

Ketan





Rgds

Shraddha



Juniper Business Use Only
From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Tuesday, July 20, 2021 12:04 PM
To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Shraddha,

> that authors don't intend to support any form of tunnelling for SRv6
> because it is not optimal. Is that the right read?

Quite the opposite. It is the local operator's choice (not the draft authors) to decide to fall back to best effort or to drop.

Thx,
R.



On Tue, Jul 20, 2021 at 8:15 AM Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>> wrote:
Robert,

What do you mean by SR? is it SR-MPLS or SRv6.
My question is about draft-ietf-bess-srv6-services and applies only to SRv6.

Let me repeat the question.
Do the authors intend to support the case of fallback from SRv6 flex-algo to SRv6 best effort transport for SRv6
Services or not?

>From your vague answer it appears that authors don't intend to support any form of tunnelling for SRv6
because it is not optimal. Is that the right read?

Rgds
Shraddha



Juniper Business Use Only
From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Tuesday, July 20, 2021 11:17 AM
To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Cc: Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com<mailto:mustapha.aissaoui@nokia.com>>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>; Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>; Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto: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>>; bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>; spring@ietf.org<mailto:spring@ietf.org>; bgp@ans.net<mailto:bgp@ans.net>; Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Shraddha,

In an SR network fallback to best effort will also result in encapsulated forwarding using SR. It may not be as optimal service wise as using flex-algo, but this is form of tunneling. Hence I don't think your comment applies.

Note that operator may also choose to use IP tunneling for best effort forwarding if SR best effort forwarding is not supported or enabled.

Best,
R.




On Tue, Jul 20, 2021 at 7:20 AM Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>> wrote:
Hi Authors,

There is a possibility of a usecase that wants to use flex-algo paths if available and if flex-algo paths
Are not available use best effort paths.


"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.
"

The current text says for best effort tunnels Srv6 service SID resolution SHOULD be checked and
I am told that (from previous mailing list exchanges) authors intend to update the text to make it applicable for flex-algo connectivity  as well.

It is not possible to support fallback on best effort tunnels if flex-algo SRv6 service SIDs have to be resolved.
It is possible to support fallback to best effort in SRv6 if packets can be tunneled to egress PE  (destination address being PE's best effort END SID and service SID in the SRH)and
then do a service SID lookup on egress, in which case there is no need to resolve the SRv6 service SIDs on the ingress.

It is not clear whether the authors intend to support these kind of tunnelling to egress cases for
Best effort and flex-algo transport. If it not going to be supported, pls add text indicating clearly
Tunnelling is not required to be supported and hence Fallback to best effort  is also not supported.

If that is not the intention, Its reasonable to update the text to indicate SRv6 service SIDs need not be resolved
If the ingress is tunneling the packet.

Rgds
Shraddha


Juniper Business Use Only
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Aissaoui, Mustapha (Nokia - CA/Ottawa)
Sent: Monday, July 19, 2021 7:34 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>>; Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto: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>; Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Rajesh,
Also you can change the service SID for a subset of prefixes using a policy, to apply a flex-algo for example, but you do not want to change the next-hop for each new service SID.

Mustapha.

From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View)
Sent: Monday, July 19, 2021 9:47 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>>; 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>; 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,

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