Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini Pseudowires and SR

"Christian Schmutzer (cschmutz)" <cschmutz@cisco.com> Wed, 01 June 2022 07:42 UTC

Return-Path: <cschmutz@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 7CCA6C15AAF0; Wed, 1 Jun 2022 00:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.596
X-Spam-Level:
X-Spam-Status: No, score=-9.596 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, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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=GL4/qh55; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VgFoZemm
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 Nrn6GLESiKU0; Wed, 1 Jun 2022 00:42:35 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004DDC15C614; Wed, 1 Jun 2022 00:42:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56165; q=dns/txt; s=iport; t=1654069355; x=1655278955; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tXzJuxmiAlCe4qZ/ul9/e5YWEpjGIkJNhv0mBFHX9RM=; b=GL4/qh5559ojpmQgHmUaTvHYPH/2KuOCjvPSUCs+EMuKhfcNQkkDIjY1 v9NGOmxaqW5LxwPRxKuRRFbGOSI4BvzILF50K+q86dpe46sEZBECaVI7O VwGOvUZB8zu2fZanSRaXDJs/9bOPi2aEQFQ8FsklwCVLLc4+YC6mULnkM I=;
X-IPAS-Result: A0BxAACSyZJi/4sNJK1aHQEBAQEJARIBBQUBgXsIAQsBgSAxKigHdwJZOUQDhEuDTAOEUl+FC12CJQOBE4oEkCSBLBSBEQNPAgMLAQEBDQEBLAEOBwQBAYQ9RQIWhS4CJTQJDgECBAEBAQEDAgMBAQEBAQEDAQEFAQEBAgEHBIEJE4VoDYZCAQEBAQMBARALBh0BASwLAQ0CAgEIEQMBAQEhAQYDAgICFAsGCxQJCAIEDgUUBQIHglsBgg1XAzEBDqAJAYE+AoofeoExgQGCCAEBBgQEgTcBFUGCfw0LgjgDBgWBOAGDFIJ/A4EmAQGBIzODU4EAeyccgUlEJm0BAScMEIIVGzc+giBCAQECAReBEQESASAYCQYGAQkCgx43gi5jjHk7aINagTSCTAc6AwkGBwUzNRKBIXEBCAYGBwoFMgYCDBgUBAITElMLEgITDAocDg5GGQwPAxIDEQEHAgsSCBUsCAMCAwgDAgMjCwIDGAkHCgMdCAocEhAUAgQTHwsIAxofLQkCBA4DRQgLCgMRBAMTGAsWCBAEBgMJLw0oCwMUDwEGAwYCBQUBAyADFAMFJwcDIQcLJg0NBBwHHQMDBSYDAgIbBwICAwIGFwYCAkAxCigNCAQIBBweJQ4FBQIHMQUELwIeBAUGEQkCFgIGBAUCBAQWAgISCAIIJxsHFjYZAQVdBgsJIRwpCwYFBhYDI3gFB0EPKToGIgEckyaDGIEaEFsdKSEDBBsHEBEOAgRCEgMoByUWCwoEGwcDECAEBjqRdx4KHg+CWAFGiX6OC5IWYAsKg06LG41ygQSFfQQtg3VIi3aSRIVjlmiNLYNakQRbhCQCBAIEBQIOAQEGgWE8Kz5wcBU7KgGCPT4TGQ+OIAwWgQQBAoJJhRSFSnUCATgCBgEKAQEDCY00WgEB
IronPort-PHdr: A9a23:wylhDRADiFfgQ5fPn7dPUyQVaBdPi9zP1kY95pkmjudIdaKut9TnM VfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKWkwJjMwMlFkmB8iIQUTwMP/taXk8G 8JPHF9o9n22Kw5bAsH7MlbTuXa1qzUVH0aXCA==
IronPort-Data: A9a23:oFpOoKCSreofNBVW/+7iw5YqxClBgxIJ4kV8jS/XYbTApDIjhDdTm mRMWmqFPKuCMGamf91wYI+280oO6pXXztIxOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4WGdIZuJpPljk/F3oLJ9RGQ7onVAOulYAL4EnopH1U8FX1x0UgLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdq+HQ04IYnbPMmRXhemTuMpYFx8 /sWqsnlIespFvWkdOU1Wh1cFWR1OrdLveGBKnmkusvVxErDG5fu66wxVwdtY8tBoaAuWjAmG f8wcFjhajiInOm2xa+nWMFnh98oK4/gO4Z3VnRInWyCU6l9HMGdK0nMzeJj+2wT3tFjJq/Ha dcGdjl+NVPBJBIabz/7D7p7xo9EnELXeTBDs3qUqLY5pW/Jw2RZyLHpK/LUd8CEA8JPkS6wv Xrc/mL2KhAXKNLZziCKmlq3muLQlDnnHogIBbS+6tZlhVSSwioYDxh+fV6jpeL8gU63WshEA 00Z5iRoqrI9nGSiSNXnUgL9oXOYsEtAA95RCvA75EeRx6HUywqcD3IPCD9MdNJgs9U5LRQo0 UWGkpXzDDZmvLSTYXSa9bad6zi1PEA9BGsPdSYCQQYfpefqoYcojg7CT9BLCqS/iJv+HjSY6 zOHsCE4m/MSgNIF/6q+9FHDxTmro/D0ohUd7wHTWCeu6Rl0IdDjbI2z4l+d5vFFRGqEcmS8U LE/s5D2xIgz4VulzURhnM1l8GmV2su4
IronPort-HdrOrdr: A9a23:H4BPMKyq2lge/6cOOHusKrPxh+skLtp133Aq2lEZdPULSKKlfp GV88jziyWZtN9IYgBdpTiBUJPwJU80hqQFnrX5XI3SEzUO3VHIEGgM1/qb/9SNIVydygcZ79 YcT0EcMqy/MbEZt7eA3ODQKb9Jq7PrkNHKuQ6d9QYWcegAUdAG0+4NMHfjLqQAfnghOXNWLu v42uN34x6bPVgHZMWyAXcIG8LZocfQqZ7gaRkaQzY69Qinl1qTmf/HOind+i1bfyJEwL8k/2 SAuRf+/L+fv/ayzQKZ/3PP7q5RhMDqxrJ4dYyxY4kuW3bRYzSTFcFcso65zXQISSaUmREXee z30lUd1gJImjXsly+O0ELQMkLboUgTAjfZuC6laD3Y0JTErPZQMbsauWqfGSGpsHbI9esMo5 5jziaXsYFaAgjHmzm479/UVwtynk7xunY6l/UP5kYvG7f3+Ndq3PwiFW5uYd899RjBmcsa+S hVfbbhzecTdUnfY2HSv2FpztDpVnMvHg2eSkxHvsCOyTBZkH1w0kNdnaUk7zs93YN4T4MB6/ XPM6xumr0LRsgKbbhlDONERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfgIzfDvfIZNwIo5mZ zHXl8dvWkue1j2AcnLx5FP+gClehT1Yd0s8LAp23FUgMyIeFOwC1zwdLkHqbrVn8ki
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.91,259,1647302400"; d="scan'208,217";a="853673596"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jun 2022 07:42:32 +0000
Received: from mail.cisco.com (xfe-rcd-002.cisco.com [173.37.227.250]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 2517gMar005884 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2022 07:42:22 GMT
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 1 Jun 2022 02:42:22 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) 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.986.14 via Frontend Transport; Wed, 1 Jun 2022 02:42:22 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bAdAgmdCE6wqBGsg1+u6J6znxxChx9Ymg0vPru3+MI/xWFXpxNau45jIxX+NuYpb4+HS8wuyD6QpUkufmXkxUqhpTQIfGspEbh/2vI19Ym0kaqzaFn4ugdbL0feyIuigh8cTOCJXCwa/9IBTD7yKo46VL6bGUS+a96AtzAOkZF8rCNGimSwnzM9eAJrMqoaKiYk6hdu7cRs45YRMPFqy74EjTQI5CHtQC33m8zf7FQY5rcZgSAgYK+LZQf/e6TF2oGxUSeJDLQhhzfVR+j6Z2k1yZ01JdvRqtoohC7II1IyEkvuL+jZwA/azPZ1WfRCg+AIDaLiT1pK4gS3aoBdPlA==
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=tXzJuxmiAlCe4qZ/ul9/e5YWEpjGIkJNhv0mBFHX9RM=; b=L+h/gUCeMYzD1OyfbGQyDqqTnl+Iy/LjrARyOq+nFAWW9r/D3Aq5MuvYjMnxKNHjO80g3a8BOKs5KvfpiysUhVFEn2F+jRld61L5C5gUypj9cIO8rH+HybLZn162rbPzlNH1U1RIXazZrPLF4GVE101YyhFN+2w6UUbSLsXqTYuOFYA0GqDnqpUpEuTiNRqHFTq0ZXb3Eb1l8dhT2sH+T+uJuNSiTuRZ2vcsWxHu9Vmc88OVu1eqHRzmx5Br8As/i14eA7KgyO06NxR9n3mBrH4UlqvIBwvBpnvk6PuBWWjIkxLz1apvyvaksKSwFjqF2nQlDjn/h9no+kTmZdKMJw==
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=tXzJuxmiAlCe4qZ/ul9/e5YWEpjGIkJNhv0mBFHX9RM=; b=VgFoZemm8C1vnNEFqTz24AToDdzjTjuZtdzWjae3ZIi3BX4Cy9VAVMEct3y//zWacfJ3NotLSLDSALogTiTpoWlZE8kiiOawhjRXAMqsYdzw2OosRZWKyiH760bQATC5ip3O90fD+cWXCyZAb9f6IQLbTIs3FITSaDz/JwN49Wo=
Received: from SJ0PR11MB5662.namprd11.prod.outlook.com (2603:10b6:a03:3af::7) by SA0PR11MB4638.namprd11.prod.outlook.com (2603:10b6:806:73::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5293.13; Wed, 1 Jun 2022 07:42:21 +0000
Received: from SJ0PR11MB5662.namprd11.prod.outlook.com ([fe80::8d0e:9e27:e7bf:64b9]) by SJ0PR11MB5662.namprd11.prod.outlook.com ([fe80::8d0e:9e27:e7bf:64b9%5]) with mapi id 15.20.5293.019; Wed, 1 Jun 2022 07:42:20 +0000
From: "Christian Schmutzer (cschmutz)" <cschmutz@cisco.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
CC: "Christian Schmutzer (cschmutz)" <cschmutz@cisco.com>, Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, "Rabadan, Jorge (Nokia - US/Sunnyvale)" <jorge.rabadan@nokia.com>, Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org>, mpls-chairs <mpls-chairs@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, SPRING WG <spring@ietf.org>, "pals@ietf.org" <pals@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR
Thread-Index: AQHYdOHFFnqGvAn6HUWoDUc+EWs3iq05M9OAgAD4p4A=
Date: Wed, 01 Jun 2022 07:42:20 +0000
Message-ID: <38720EC0-D677-4197-85C6-97DABB11E994@cisco.com>
References: <AM7PR03MB64514C7EA1750090FE94192CEEDD9@AM7PR03MB6451.eurprd03.prod.outlook.com> <51706C42-15E2-442D-916E-627769062F22@gmail.com> <PH0PR03MB6300D250BC9F3762D91E0337F6DD9@PH0PR03MB6300.namprd03.prod.outlook.com> <BY3PR08MB70600C3B393A3B2E4FCF0671F7DD9@BY3PR08MB7060.namprd08.prod.outlook.com> <PH0PR03MB6300E03FCF3C0307ADC9D71AF6DC9@PH0PR03MB6300.namprd03.prod.outlook.com> <CAH6gdPz1=_RkWQ0Hekh_jhiLGQP+80dExeJwRg02ScoB-6f1Jg@mail.gmail.com>
In-Reply-To: <CAH6gdPz1=_RkWQ0Hekh_jhiLGQP+80dExeJwRg02ScoB-6f1Jg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3696.100.31)
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: 6dffd39c-8b05-4841-32ae-08da43a242b9
x-ms-traffictypediagnostic: SA0PR11MB4638:EE_
x-microsoft-antispam-prvs: <SA0PR11MB463845D31673F0B0DA567698CDDF9@SA0PR11MB4638.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Ul/vsrZiCT62MIo/VeM2Z85QQ+gK4GEefH1zIbSat1H7WKFSHKM2f+da/dSuM1D/8zh5Z3rzWw77LWPeY/Gtr9E7pUYN6LF6gFuzzPBQczjf2mrTpkDZ7XnqzixZ1FBhwBt7VOPjwCkrAtMcZILVMEfC9Y4amadOpe8clOL3HwuCMo1OTTxLmkOtri7kLUFqbcJg5d9m9JRrSdnTcL7Y81C+CgpJiDehCWUhmK4A9INrqHZmnSdaExL8/U655aPgijhlGYkuY7KumDE2ydxoYLO+E5XgREmCwMK12k/CMwez3zdD0ufvi+iPpDc4RQ9kz96dTWCF7YkTVE6KOtHfwOOWkxq3ap/8gLmuT2eE/rjWqf9+QBrbQgaswUEwH3sQGPd1ZNb7Duumjd73ls57T7YuFQklrVzA008k3Pk0Io5OgclLejSBeAloly0ow9UzYa+fIKzimfhSMahWdVt1nnIcyray4OS6P8Fe6Fbjkf3pjo27uT5o8GrwOxlJqgRT+JTc/XHpW7qZ8Rjf6py6lobdV6HL/Z89NCjC0/nCjkIOIfeXoQu9FdXGBGWGYi40j7c4kSw2i9idnqhtI210CXKt9VUz7+eet5SLhdtwtMwaDLXnh0Za5JlksCVEfnT1aMesLDI0i8QLQMh2UNIT8m+c1FruTCdfhWFR2MCI2XGYHkadc/pRXq7qaKvCWcniXI+UhVCIkH7R1NLESWWWv8FHT0x0ozL1s5N8xdzpiMPkZPvXKLpW2bKDPKi10POLDcJe71sFjDisJhfTaExPeIR+S48kSe5Wne4uwjc/lCwplfhqHdX8Lx+ZoG5lLcLaQiX3ErVr2zY939iV9T6DFpiizhDzQWhJTjwXXndlvMQ=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB5662.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(86362001)(38100700002)(5660300002)(166002)(66476007)(8676002)(91956017)(64756008)(66446008)(66556008)(76116006)(8936002)(4326008)(2616005)(66946007)(186003)(508600001)(71200400001)(966005)(6486002)(33656002)(6506007)(26005)(6512007)(6916009)(54906003)(53546011)(316002)(2906002)(83380400001)(36756003)(122000001)(38070700005)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: sGyN1ErTh5yck2OYNBKwJc3hgVQR4t8VhTJdcu/Dzq5jhFhxM22/J3YtGexmcnP+byvOeToaEWOfBm6Nx490M2g7uc/n3Y332G5M6Y2C/m9BUeGYTWrYLGxRSTskiUhb0uX6WMpclFutpzUIol1gDHZyPuaov3tziPFDrzuWFjUCsEW+EbeuGUwnpm78jVtomOG6iAiv2FjU288uPBoJsCs8UXGmQ/cFQoY+13d9FCs7JrIPGWxUD/GK5OF7Zar3GsSBzByfwZmn4nMpZLW144doFejPI/EyyO4x6d3pZ4Wg8jUMCVur/lm0y62xNaoCyWb/pmcBWgVRCTpQwzp/NLkNpXUxHxp7RfQAvx8gPY5wT48AlmQQhoLSc3G5cHar0Jw7vQdSQxocyKFJ53U71CqRQ92uQqJSN7tm+j87tt3osVXKv7MUOkXiwE0LynUf6RY2JshVLdwzKZH1soR6wYkCdS1+N1XBgRuY72kudLIX0GkTpGVkZmhOUa6iJwca/znEDu/IFAUhaEbZ//rWbnJupgXfRTBYxmfrMn6qqhpX2Z+czVSYYFIpbeWE6xetIhSzFFOJY8gSOkkiCPNWI/PnkAAoO8vLHohk7x4s/4iy15/Q++F9RMXZS49sb9gcUNhNjcI6q6/9KjB1cYi1PJPwtVCgxOr/KMkWyskOHrr6HG0AleHMffR/fEbNqvPb1Ow6YHKNGuAsEL0pfxomvx+CQbZI76fozWraSKs5Jp9UPKF5UFKbJ1g+cvFUzEIwFCITWgCgh7q9YxgAxWBxM2qTtmWd7yQPRMbYkIh1xKJCRAOCVQezMwFKHL1KujfZXW2swe5R++oxjoPQmVtSDl7RmBundvZhCv0w6/abqUAcwerMucyhTqfpWZ6WVTiaFHtUJ1Po8vJQn2lRvOhWHvtVZYQB7Maq8yEM5yrkHsU7JI+JGCl02yM+1qKZl36QpPQQuh8ffIshRB8f7ZFgd8pqSonEyKYfxWV6pTrX2c03yi0y5Cp8s1p2xEgOAFNY020/eYaiJfAc+nkgs9UhfLBT83H+fC9LaAjHYNX8DxDhE9jWtUMbI8T9vQMBaZ0hPHVsj2I/xbb916f7WL+fY5HUsHAjUxvW8QgZddcndrP10ayOYT6RJ7d5NgpIcVDVaBBZA3lehHrIqxPYS9QxLRhNyzBryh998bxe9WhFjqXvN8DdnBU4FaAaifDLdpQY43C2JqncZ4fSFPz6ckL3tqnh3uzEfIrKLocvbHa7LdheIju13WfbTdZUlKtuJsaksouoSiCRZf0mKnJ6FuaI75jProRQgZ4HWUKB+RaTT1RbvjIl+muYX9rQBdOdRbfphYTzDNbrZJ40Kx8rYRTh4Cm9W8quIN7piNe2lHfRaSerI9tPjU2ldoETpEcUTbQ2sqYXRoa3nDwKdSKVyvIPGk0Pliq1Twt6lxtcLz0TabvIBX3ylIOyL979KJJmSJv9QGsawSCfgxq7vBvfSxzYysAnLB54EMSItRAR2GerLNL76jrBAYLMxeNPfZFehoegT+ZiUmv1RIaKto4/TjOnnA/sV+/q3+iH+DAtmsg43Zq68pKY8MXEhVUahrwqFHEgaumMGeoIf94Sc/saogJfBElRYVLEH3uAUDFNIDz8n7aGMNrK2BO2eR00DXerxTrE9kVjZ47F5wqvnydJVxr3v9YMJfqB/s79+7mmI7qd1FhmOs8e/y7lsq0rBlhyTpfGFwbe9SPe37es3rV1oZp9zQNyxLqGlcK/CPOq/vwCXKc=
Content-Type: multipart/alternative; boundary="_000_38720EC0D677419785C697DABB11E994ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5662.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6dffd39c-8b05-4841-32ae-08da43a242b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2022 07:42:20.9230 (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: z/bfSUD7ZWacFAbHE9si1ZaQD6wPbZ/Iu/2ScUpmp77qhGngoQzjnzmutpEmzRbqHY6qzMBCPwulUqrL7xfvzQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4638
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.227.250, xfe-rcd-002.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/qXBOfO17hYulWf-E8HBaHFuPvYU>
Subject: Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini Pseudowires and SR
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.34
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: Wed, 01 Jun 2022 07:42:39 -0000

Hi,

After the initial hype for PWE3 in the early 2000s we have seen renewed interest in circuit emulation (TDM PWE3) in 2015 as there was (and still is) a lot of PDH and SONET/SDH infrastructure out there that operators can’t get rid of fast enough while those products go end of life.

We have invested in a modern, complete (SATOP, CESOP and CEP) and high-density MPLS/PWE3 implementation and several operators and utilities have deployed our solution (based on T-LDP PWE3).

Having said that, many operators raised the question on “why not EVPN-VPWS instead of T-LDP?” as they were already looking at EVPN-VPWS for ethernet services. As we see continued interest in our circuit emulation offering and this EVPN-VPWS question is continuously coming up I believe there is merit in addressing TDM pseudowire setup via EVPN-VPWS.

Also more recently we got requests to carry high speed “pipes” such as 10GE, 100GE, OC192/STM64 and various FibreChannel variants in a transparent manner which lead to our PLE data plane proposal documented in https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple.

For PLE (being new) we looked at EVPN-VPWS to start with (instead of T-LDP) and also already started a proposal via https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple-vpws-signalling. The proposal is not re-inventing the wheel, rather aligning with the concepts defined in T-LDP. We would appreciate community review and input.

I think draft-schmutzer-bess-ple-vpws-signalling can address the “TDM’ish” features while another document or updates to RFC8214 could address the other (more generic gaps) to RFC8077 and other T-LDP RFCs.

Regards
Christian

On 31.05.2022, at 18:52, Ketan Talaulikar <ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>> wrote:

+ 1 to Sasha and Jorge

The feature gaps to be addressed in BGP EVPN VPWS should be based on operators' feedback so we add only those that are relevant.

Thanks,
Ketan


On Tue, May 31, 2022 at 4:59 PM Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>> wrote:
Jorge and all,
Here is a (admittedly incomplete) list of things that, AFAIK, today are not supported with EVPN VPWS:

  1.  All the non-Ethernet PW types (28 such types can be found in the IANA registry<https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-2>)
     *   Not sure if all these types are relevant for the industry today
     *   AFAIK, TDM and SONET over packet are still widely deployed
  2.  Differentiation between Raw and Tagged Ethernet PW types (not sure it is needed, but still)
  3.  All Interface Attributes listed in the IANA registry with the following exclusions:
     *   Interface MTU  (EVPN VPWS supports a standard way to ignore it which IMHO is one great advantage over LDP-based signaling)
     *   Flow Label (support is defined in 7432bis)
  4.  Full-blown PW status signaling
  5.  FCS retention – not sure it is used these days
  6.  PW fragmentation and reassembly - not sure it is used these days.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>

From: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>
Sent: Monday, May 30, 2022 1:02 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org<mailto:40liquid.tech@dmarc.ietf.org>>; mpls-chairs <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; pals@ietf.org<mailto:pals@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

I concur with Sasha.
We’ve been gone through a significant effort to unify the service signaling by using EVPN. If we are missing anything in EVPN VPWS compared to T-LDP based PWs, I would rather look at extending EVPN VPWS (if needed). If not an option, it would good to discuss at least why EVPN VPWS is not an option.

Thanks,
Jorge


From: Pals <pals-bounces@ietf.org<mailto:pals-bounces@ietf.org>> on behalf of Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Date: Monday, May 30, 2022 at 10:58 AM
To: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>, Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org<mailto:andrew-ietf=40liquid.tech@dmarc.ietf.org>>, mpls-chairs <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>, pals@ietf.org<mailto:pals@ietf.org> <pals@ietf.org<mailto:pals@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR
Stewart, Andrew and all,
++ Bess WG.
I fully agree that using (targeted) LDP for setup of Martini PWs in an SR-based environment is quite problematic for the operators.

One alternative is transition to setup of PWs using MP BGP based on the EVPN-VPWS mechanisms (RFC 8214<https://clicktime.symantec.com/3Qviu2KUub4f1w6MeHVbgcu6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8214>)

These mechanisms probably require some extension to support PWs that carry non-Ethernet customer traffic as well as support of some features that can be signaled via LDP for Ethernet PWs but cannot be signaled today with EVPN-VPWS (e.g., FCS retention – RFC 4720<https://clicktime.symantec.com/32Jf7wnYMxKQPc3r3RR9Cy96H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4720>)

My guess is that, once the basic EVPN-VPWS signaling is supported, migration of LDP-signaled PWs to EVPN-VPWS would be simple enough.

This work, if approved, would require intensive cooperation between PALS WG and BESS WG.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>

From: Pals <pals-bounces@ietf.org<mailto:pals-bounces@ietf.org>> On Behalf Of Stewart Bryant
Sent: Monday, May 30, 2022 11:10 AM
To: Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org<mailto:andrew-ietf=40liquid.tech@dmarc.ietf.org>>; pals@ietf.org<mailto:pals@ietf.org>; mpls-chairs <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: [EXTERNAL] Re: [Pals] [spring] Martini Pseudowires and SR

Including the PALS and MPLS WGs in the discussion.

In the case of PWs, LDP runs directly between the T-PEs to provide the control plane. If it is known that the only use of LDP is to support PW, then a lightweight profile of LDP might be implemented, ignoring unused parts, but this does not necessarily need a standard.

Before you can profile LDP, you have to also profile PWs to determine which subset of the PW system you need to support. The danger here is that you end up going through the PW development cycle again as old requirements re-emerge.

Stewart



Sent from my iPad


On 30 May 2022, at 07:22, Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org<mailto:andrew-ietf=40liquid.tech@dmarc.ietf.org>> wrote:

Hi All,

Sending this email wearing only the hat of a working group participant.

One of the things that our network uses, and is used by so many networks out there, are martini based pseudowires (which for clarity are generally setup using what is described in RFC8077).  In an SR world however, this creates a problem, because typically you don’t want to run LDP in an SR context.  This means that standard martini pseudowires no longer function.  This gets even more complicated when you want to do martini based pseudowires over an IPv6 only network, particularly considering the lack of widespread support for LDP6.

This is also relevant in cases where networks wish to run SR-MPLS in the absence of SRv6 for whatever reason.

So, my question to the working group is this:

Is it worth looking at creating a form of LDP light – both compatible with IPv4 and IPv6 – that simply exists to setup and tear down the service labels for point to point services.  A form of targeted LDP without all the other complexities involved in LDP – that could potentially run at a lower preference than LDP itself (so if LDP is there, use it, if not use this)

Before I start drafting though, I would like to hear from the working group if there are others who feel that this is worth doing and, call this a call for expressions of interest in those who may be willing to work towards something like this.  Happy to take emails on list or off list and see if we can find a solution.

Looking forward to hearing from you all

Thanks

Andrew



_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://clicktime.symantec.com/3Dg1AP6FnSDeshweMg29hXi7GS?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess