Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 12 March 2020 13:51 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12753A093E; Thu, 12 Mar 2020 06:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.954
X-Spam-Level:
X-Spam-Status: No, score=-2.954 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, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H2=-1.463, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecitele.com header.b=WMWDwe+P; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com header.b=VOX+pkYn
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 eGPX5hIXvbPg; Thu, 12 Mar 2020 06:51:34 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0B33A0881; Thu, 12 Mar 2020 06:51:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecitele.com; s=eciselector10072019; t=1584021092; i=@ecitele.com; bh=5QyW3Kh8zAaw6X/IbIaAeoW++46nL077HFX0mqm9CnY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=WMWDwe+Pfm/HPHwzO967OnILqv/fiof65k0QzpaXcIYhL6gGPC2PQYcamtEvJpaf6 7cF9C7QA6pXlpKnnIHeJXCOlVqFQL24DAFWeLHMg3Dyrgid1jdYK2hcKLtnr70y/7+ YE0dXxGQHmGWKxiYvw0BkVXfuxn/lIi9lrtNkOj8=
Received: from [100.112.194.245] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-west-1.aws.symcld.net id 41/04-38240-36E3A6E5; Thu, 12 Mar 2020 13:51:31 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa0xTZxjmO+eUHpGyjxbsK5dFS1zmsKXVsZQ wFwnbZNl0yxa2zEXcAc7aMiisLQK6DNiFBbwxkQ1Qwp1MHCkXpRqJINPihSECkSCCI8M5iggD J1aG2zk91bkf583zPs/zPe+bL9+hSel+cQDNZlpYk5FJVnh6UdLpvS3K+FeS4tQlt7H26I+jh Dbv6hlC2zZaJtJWFJ0QaR80nRVru/sW0SbPmEOLzaKYU2Wj4phGWyUVU1vrJN6htokMxvjUzI 9F+uu9pWTa2Fdk5oGlAiIHfdtLFCAvGuE6EhYv91FCY6eg0vm7u2lFcKH7oJhvKNxIwqHOTs8 CtIyW4iICvr9sFPA4goNdL/HYE2+ElmOjLo8fVsHNjiURf5jEuQQMnalBvCDDO8HW00wJpgzI c9whBJwK+e3TLp7Ca6Bv8D43maYlmAH7kA+fI8W1IrD/nCPmPctwHExOTbswwitg4dJPrhwSy +H6RIULA8ZQ236FFLA/TP72SCT44+HmrSok8KvhQOU5tz8Y+iv2IH4u4BA4/sd2gd4CbSPXPA W8Duw9DkrAaeDobRIJ+DmoGTzt5oPAUTfrukXApyhwFne5Ly4BLhyZd5uehYZ941QhUpc9tXY ZN5rERmhvW87TEuwLF0snKMGihpneClLAoVBfNeXGYdB87xf0NF+JxA1IG28y6PSWFMaQrNSo 1UqNZr1SE7GB+yJUzC4lo2LTlRms2aLUqJgMs8qclZKQnKgyspYWxD2+xLSz3SdRfeOMqgutp AmFvyR/1hAn9YlPTczSM2b9DlN6MmvuQkE0rQDJjcikOKmvidWxmZ8Ykrkn/FgG2lvhJ9mwkZ Ml5jQmxWzQCdIl9CZdOFleTdJ3nTVc/bOhlqv3XHXBVVvL66pJKWVMNbIBckkQH4H5CH268cm Ax79JPwoOkEmQh4eH1DuNNaUYLP/XHUhOI4VMMvQyl+JtMFqe7OHgViS4FffadfyKFuY/KSCH +PK+JWLrpqojO8pfHAvE859n+83kjndat8U6UOinc4kPAj87GmjLPl+2avPxddF3IkvGqau7Y uGZpfDNo88Xj4zY3te2+uyrWNy7JMs7F2XPKP7LsNt6+i2fuQWNbSzp8G5rdKy8dDYcqr6ICn O0zodbdaqxjz68VrAi8NVfDzNN71kfrhwcXjsQu2p5T5E8ZCB7686URtjzNysLfn3Jmb/Fqcl 67YPO7NXfBA2/XajQdrDUwD+2huD6K4WJs37bH9aV1rwRtXZqaDpUzaZOqL/299XJHvX9kK2V fOfXvz53ruF8R8ixsH555Alx9cnw4Za4W9a70TeKB95tXdNyca7kdkKMl4Iy6xnNC6TJzPwLX h4DuKEEAAA=
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-2.tower-267.messagelabs.com!1584021068!662452!1
X-Originating-IP: [18.237.140.178]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.50.1; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 11971 invoked from network); 12 Mar 2020 13:51:10 -0000
Received: from p01c.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.178) by server-2.tower-267.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 12 Mar 2020 13:51:10 -0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DRrHOFX5LlZamq1HAEeBaw3KuUVacHKK53aSLpy4evdrmGD3g3Gw7u4TxfTP62?= =?utf-8?q?gFm7ohlRSJG5aiLG7wjsLI8j6Px4yZmP7q097BskP0VfCPbZH484JtM3LFR/417c9?= =?utf-8?q?F3KBrIEA5+bsyVULKmvdrWrQmC4kXiwNv5eQ1ZhIMuVoqhXdNeNMd/48WVflJVxFy?= =?utf-8?q?jkp2dxCVb8wwHHdzuTzXXdP9j2e4nBjwpTkr/Q3T73pKq3S7IzbrM4EWQEYlNqfR9?= =?utf-8?q?tlaxyAs0Eqide1n/bXt0iibF3rW/vFr+DYtvTUBA898dTbrzpbrD+p3F7zn+kxJ1g?= =?utf-8?q?h4BzgB2b7fH+Ugce+DPyQ=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DIU0Is3AmdA3WC/cFwLJMAR/sLjpMx2S0nrfrQxC6slU=3D=3B_b=3DUPwT/3?= =?utf-8?q?ABrJhBkt6Dce01Q2DdLWxuU62AFRxF6Kwb1yJZEHYMO0WaH9uBHH75xHQItsu6fOB?= =?utf-8?q?ywoCCWntTT+AJHyvHrXUbJMdrIM/BuxwNk7mnHAEOO5MBCteFdyCGhC7/E19D8XZ/?= =?utf-8?q?lCFmYGu4fMjBls74Hc3rlLiHutNMngXt7K4zpgcOfYuysbTgH9Fwg/h8CvUD1rCQu?= =?utf-8?q?sFvLqMjD0diXAMQ7SZJIkrEbf6w/QFMqIp4t2ywhACLCFrprOB/MCgMbo1VRdZV7H?= =?utf-8?q?KQkJ3y4grPZnuPx8FFp232p9s7lBz+f1amJmopISYJxoSIk701CFKwHGMXDhMKH3X?= =?utf-8?q?kGByATqMmxA=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ecitele.com; dmarc=pass action=none header.from=ecitele.com; dkim=pass header.d=ecitele.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector2-ECI365-onmicrosoft-com; =?utf-8?q?h?= =?utf-8?q?=3DFrom=3ADate=3ASubject=3AMessage-ID=3AContent-Type=3AMIME-Versi?= =?utf-8?q?on=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DIU0Is3AmdA3WC/cFwLJMAR/sLjpMx2S0nrfrQxC6slU=3D=3B_b=3DVOX+pk?= =?utf-8?q?YnJt86l20bAPMmhM6do7uv0DHWUxUa31aWPAGTpPNUML05I7ajUyV2BNSzfz+Bo6P?= =?utf-8?q?PSg/sWvC36u06Fk9Z9iTkSu9N9lPD1Cu4WE9pkED7WdZp/ubv4+FZP8BQyyRX+Zzp?= =?utf-8?q?GrvGEZTZXVxndjCXfmttWOaOnHcYMoW023E=3D?=
Received: from AM0PR0302MB3217.eurprd03.prod.outlook.com (52.133.33.12) by AM0PR0302MB3474.eurprd03.prod.outlook.com (52.133.37.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Thu, 12 Mar 2020 13:51:05 +0000
Received: from AM0PR0302MB3217.eurprd03.prod.outlook.com ([fe80::aca8:db6e:97b:c780]) by AM0PR0302MB3217.eurprd03.prod.outlook.com ([fe80::aca8:db6e:97b:c780%7]) with mapi id 15.20.2793.013; Thu, 12 Mar 2020 13:51:05 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Darren Dukes (ddukes)" <ddukes@cisco.com>
CC: draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>, "6man@ietf.org" <6man@ietf.org>, SPRING WG List <spring@ietf.org>, Fernando Gont <fernando@gont.com.ar>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Topic: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: =?utf-8?q?AdXtUHCBczz/925MQSaI7w9wOHJRdgACBA6AAAGG3AAAA/RiAAAA?= =?utf-8?q?HJfwApEqIgAAAZ7QEAAHxyEAABnrCUAACif/mQACpfZA?=
Date: Thu, 12 Mar 2020 13:51:05 +0000
Message-ID: =?utf-8?q?=3CAM0PR0302MB321754A483B2D635FB4F5CC89DFD0=40AM0PR030?= =?utf-8?q?2MB3217=2Eeurprd03=2Eprod=2Eoutlook=2Ecom=3E?=
References: <6B803B308679F94FBD953ABEA5CCCCD701089509@dggema524-mbx.china.huawei.com> <6E7A3022-DEC7-4E35-9A56-0F708CD41180@fugue.com> <58c706f7-2370-2b63-37df-0b5daf1ad8a5@gont.com.ar> <9E058FE7-22DB-4267-A796-88301885F269@fugue.com> =?utf-8?q?=3CDB3PR0302MB32?= =?utf-8?q?28A52782E01BEA74C105F79DEB0=40DB3PR0302MB3228=2Eeurprd03=2Eprod?= =?utf-8?q?=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CFCA51487-D859-4A22-8B66-744E72A4B3F7=40cisco=2Ecom=3E_=3CAM0PR?= =?utf-8?q?0302MB32176C376B261592901708369DFC0=40AM0PR0302MB3217=2Eeurprd03?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3C9a3619e2-cf22-fdf8-6ea4-924ebe7775f8=40gmail=2Ecom=3E=2C_=3CAM?= =?utf-8?q?0PR0302MB32177CFAA0DE9E9C0E397C8F9DFD0=40AM0PR0302MB3217=2Eeurprd?= =?utf-8?q?03=2Eprod=2Eoutlook=2Ecom=3E=2C_=3CDM5PR11MB181892A07220C2AF3A0A6?= =?utf-8?q?732C8FD0=40DM5PR11MB1818=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CDM5PR11MB181892A07220C2AF3A0A6732C8FD0=40DM5PR11MB?= =?utf-8?q?1818=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [79.177.103.60]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 498eb3fc-7132-4d23-57cb-08d7c68c6911
x-ms-traffictypediagnostic: AM0PR0302MB3474:
x-microsoft-antispam-prvs: =?utf-8?q?=3CAM0PR0302MB3474765EC3D4F0F3E44240B99?= =?utf-8?q?DFD0=40AM0PR0302MB3474=2Eeurprd03=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0340850FCD
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810019020=29=283760?= =?utf-8?b?MDIpKDM2NjAwNCkoMzk2MDAzKSgzNDYwMDIpKDEzNjAwMykoMzk4NjA0MDAwMDIp?= =?utf-8?q?=28199004=29=2853546011=29=2871200400001=29=2864756008=29=2896600?= =?utf-8?b?NSkoNjY0NzYwMDcpKDQ3ODYwMDAwMSkoODYzNjIwMDEpKDQzMjYwMDgpKDY1?= =?utf-8?q?06007=29=2866556008=29=2881156014=29=2866446008=29=288936002=29?= =?utf-8?b?KDg2NzYwMDIpKDI2MDA1KSg4MTE2NjAwNikoMTg2MDAzKSg3NjExNjAwNikoOTE5?= =?utf-8?q?56017=29=286916009=29=2866946007=29=2833656002=29=2854906003=29?= =?utf-8?q?=28316002=29=285660300002=29=2830864003=29=289686003=29=285501600?= =?utf-8?b?MikoNTI1MzYwMTQpKDQ1MDgwNDAwMDAyKSgyOTA2MDAyKSg3Njk2MDA1KSg2?= =?utf-8?q?6574012=29=3B?= DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3474; H:AM0PR0302MB3217.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?BIdrzQdTJZdY0NssIoY7fIe8KZJI5IL?= =?utf-8?q?05I+dcauKw6Nd5G2FWftnlAvxup806F3Qgc6nK5cSfOtXZqpt2B3BBaOp658fc77c?= =?utf-8?q?YvxCE7qelGIk/hfcyGcINaYmk3OMoR2nLmrOM8TI14K+Db77E8uPYbIajn44LyC5q?= =?utf-8?q?Sxz7tbbXVL9Ph7MAQvPHHhtSR8tpAGiVkokD+KFCIB+4PlcPXdQLawQm1w7sTxU6v?= =?utf-8?q?XyE7LBiznv0nWq3Pv2MmQPnHIO8U2rl0YYKwh/HI7z1wZfwi17nWjmUseC1CR3y8H?= =?utf-8?q?2Ww9bjm7xrlvvVwDZ+v0jQORitI/AUGn7zYNLRRFiKo12/DCEUEGQyi1xz80d7TgM?= =?utf-8?q?hm+YRiuQW7K3ZaNgYl1nyIj93n5vvqZxhrFJpOQL1UIzklNxazqugS8vLNW+GxqLY?= =?utf-8?q?0RqyfYJAmbyB4rwzO/4ZUtZGRPVVWZmeQX43arnfg85PvrkTWPCrMQU1AsAgxG6FI?= =?utf-8?q?9pKwIiv8Tb1GOzy+F/EfWq1njpW3xCkSOeLiDq+0UFkFZ6uw=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?EKlCltjQCrMZHELSfPGS9jOeKZbf5F?= =?utf-8?q?c2DWoaKx6dgg0Sj8veg61WL7+hUgWzjKzz0F0oZe9fjZTFXa8Rtl/XRLPZyjIGlT5?= =?utf-8?q?Sk9UARML2wHENsAj/RXU3W83x9P3cfpPzEoTxFRPmcEwwvnAO+RaX+Q=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR0302MB321754A483B2D635FB4F5CC89DFD0AM0PR0302MB3217_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 498eb3fc-7132-4d23-57cb-08d7c68c6911
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 13:51:05.5150 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?+6tzbzsqu0oNJqOGTlUPm?= =?utf-8?q?NMX4O8fIe1EJ5lKzOBphrXjAPlWLtqaJh02ywyHKo2M+mapl/r7/cUjpZEXxlw4QQ?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3474
X-CFilter-Loop: Reflected
X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IqrJ6CFrEgqwgJWAFgtVv5CRXm0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 13:51:38 -0000

Darren,
Lots of thanks for a prompt response.
My reading of your response is that in order to perform PSP, the penultimate route must advertise an SID it instanciates as PSP-flavored.  Until now I have always assumed that PSP flavor is used with some SID that is substantiated by the ultimate node similar to a node that adveririses its Node SID with PHP flag in SR-MPLS.

To me the latter model makes sense because it allows the node that cannot process both the SRH and the Next Header to indicate that. The former model looks strange to me.

My 2c.


Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Darren Dukes (ddukes) <ddukes@cisco.com>
Sent: Thursday, March 12, 2020, 15:17
To: Alexander Vainshtein; Brian E Carpenter
Cc: SPRING WG List; 6man@ietf.org; Fernando Gont; draft-ietf-spring-srv6-network-programming
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Yes thanks Brian for that response.

Sasha I want to correct one technical error in your email so your understanding is clear. You say “But PSP-flavored SIDs are NOT locally instantiated in the penultimate node, they are instantiated in the ultimate node of the path. “

That is incorrect. A SID that is PSP flavor only performs the PSP operation when it is in the penultimate position in the segment list, and a SID is only processed on the node that instantiates it. See the definition of penultimate segment in the segment list definition here. https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-2<https://clicktime.symantec.com/3AYVE1JJACQpvGS2xF9K2CY6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6man-segment-routing-header-26%23section-2>

Thanks
  Darren

________________________________
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Sent: Thursday, March 12, 2020 3:36 AM
To: Brian E Carpenter
Cc: SPRING WG List; 6man@ietf.org; Fernando Gont; draft-ietf-spring-srv6-network-programming; Darren Dukes (ddukes)
Subject: RE: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Brian,
Lots of thanks for a prompt and unambiguous response.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Sent: Wednesday, March 11, 2020 9:13 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>; Darren Dukes (ddukes) <ddukes@cisco.com>
Cc: SPRING WG List <spring@ietf.org>rg>; 6man@ietf.org; Fernando Gont <fernando@gont.com.ar>ar>; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

On 12-Mar-20 05:06, Alexander Vainshtein wrote:
> Darren,
>
> Lots of thanks for the clarification.
>
>
>
> However, I have several issues with your response:
>
> 1.       The SRH draft is a 6MAN document. I am not sure if the
> provision for new documents defining new SID types and their handling
> means that such definitions can be done in the documents handled by
> other WGs,

They certainly can, because the decision point in the IETF is not the WG; it's the IESG, following an IETF Last Call. It's very common for one WG to build on the output of another.

> especially since we see strong opposition to these changes from
> several participants of the 6MAN WG. (To make it clear, I am not a
> 6MAN WG member, and personally  neutral about PSP - but I am worried
> about the IETF process)
>
> 2.       The SRv6 Network  Programming draft has a Normative reference to the SRH draft, but it does not ever mentions that it updates it (not in the text and not in the Metadata).

An extension is not necessarily an "update". This is a weakness in our vocabulary, and there is a current proposal to change it: https://clicktime.symantec.com/32AasVXnTQLbLb4xyAqqxWy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-kuehlewind-update-tag

>
> 3.       Section 4.3.1 of the SRH draft defines the behavior associated with the SRv6 SID that */is locally instantiated/*, and explains that other SID types may be defined. But PSP-flavored SIDs are NOT locally instantiated in the penultimate node, they are instantiated in the ultimate node of the path. Therefore (and I may be too literal in my interpretation of the SRH draft), I think that the provision for new documents defining new SID types */only applies to locally instantiated SIDs of the handling node/*  and does not cover the PSP case.

I think this is governed by RFC8402, as I mentioned yesterday.

> In my original email I have suggested to the PSP/USP proponents to post a draft that updates the SRH one (or the RFC that hopefully soon will be published) - and to run it thru the 6MAN WG in the usual manner. I understand that his will take time, but I still think that this would be the most appropriate way to resolve the current conflict that has already gone too far.

I don't see how that would help, since the argument is about the interpretation of RFC8200 (and RFC4291), not about the SRH spec.

Regards
    Brian
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
>
> *From:*Darren Dukes (ddukes) <ddukes@cisco.com>
> *Sent:* Wednesday, March 11, 2020 4:44 PM
> *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> *Cc:* Ted Lemon <mellon@fugue.com>om>; Fernando Gont
> <fernando@gont.com.ar>ar>; SPRING WG List <spring@ietf.org>rg>;
> 6man@ietf.org; draft-ietf-spring-srv6-network-programming
> <draft-ietf-spring-srv6-network-programming@ietf.org>
> *Subject:* Re: [spring] Request to close the LC and move forward//RE:
> WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
> Hi Sasha,
>
>
>
> I think this question got lost in the other emails around this time.  Thanks for asking though and, let me clarify.
>
>
>
> The SRH doc was built with section 4.3.1 <https://clicktime.symantec.com/3LLGD1Uzfhu26ZSxmbnqzXQ6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6man-segment-routing-header-26%23section-4.3.1> stating:
>
> "Future documents may define additional SRv6 SIDs.  In which case, the
> entire
>
>    content of this section will be defined in that document.”
>
>
>
>
>
> So draft-ietf-6man-segment-routing header explicitly gives other
> documents the ability to fully define new SIDs.
>
> In those documents the behavior of those SIDs would be fully defined, regardless of the text in section 4.3.1.
>
>
>
> draft-ietf-spring-srv6-network-programming is one of those documents, there are others that are and will be written defining new SID behaviors and their processing, this was expected and is necessary for the definition of new SIDs and their behaviors.
>
>
>
> Thanks,
>
>   Darren
>
>
>
>
>
>
>
>
>
>     On Feb 27, 2020, at 8:27 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com <mailto:Alexander.Vainshtein@ecitele.com>> wrote:
>
>
>
>     Hi all,
>
>     I cannot say whether PSP is allowed or disallowed by RFC 8200.
>
>
>
>     But, to the best of my understanding,  format of SRH and its handling are specified by the IPv6 Segment Routing Header <https://clicktime.symantec.com/3UnfQgAfW5ZSe3uASGKwXGq6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6man-segment-routing-header-26> draft that is owned by the 6MAN WG and */is already in the RFC Editor queue/*. Specifically, handling of the SRH by the Segment End Point ((of which PSP is a special use case) is defined in Section 4.3.1.1 and says:
>
>
>
>        S01. When an SRH is processed {
>
>        S02.   If Segments Left is equal to zero {
>
>        S03.     Proceed to process the next header in the packet,
>
>                 whose type is identified by the Next Header field in
>
>                 the Routing header.
>
>        S04.   }
>
>        S05.   Else {
>
>        S06.     If local configuration requires TLV processing {
>
>        S07.       Perform TLV processing (see TLV Processing)
>
>        S08.     }
>
>        S09.     max_last_entry  =  ( Hdr Ext Len /  2 ) - 1
>
>        S10.     If  ((Last Entry > max_last_entry) or
>
>        S11.          (Segments Left is greater than (Last Entry+1)) {
>
>        S12.       Send an ICMP Parameter Problem, Code 0, message to
>
>                   the Source Address, pointing to the Segments Left
>
>                   field, and discard the packet.
>
>        S13.     }
>
>        S14.     Else {
>
>        S15.       Decrement Segments Left by 1.
>
>        S16.       Copy Segment List[Segments Left] from the SRH to the
>
>                   destination address of the IPv6 header.
>
>        S17.       If the IPv6 Hop Limit is less than or equal to 1 {
>
>        S18.         Send an ICMP Time Exceeded -- Hop Limit Exceeded
> in
>
>                     Transit message to the Source Address and discard
>
>                     the packet.
>
>        S19.       }
>
>        S20.       Else {
>
>        S21.         Decrement the Hop Limit by 1
>
>        S22.         Resubmit the packet to the IPv6 module for
> transmission
>
>                     to the new destination.
>
>        S23.       }
>
>        S24.     }
>
>        S25.   }
>
>        S26. }
>
>
>
>     I.e., 6MAN WG did not define any special processing of the SRH by the penultimate segment endpoint. And the processing it has defined in the ultimate segment endpoint  does not mention removal of the SRH either.
>
>
>
>     I do not think that SPRING WG can change these definitions by and of itself.  If PSP is so important, a new individual draft updating the (yet unpublished) RFC defining the SRH has to be submitted and discussed in the 6MAN WG in accordance with the normal IETF process.
>
>
>
>     My 2c,
>
>     Sasha
>
>
>
>     Office: +972-39266302
>
>     Cell:      +972-549266302
>
>     Email:   Alexander.Vainshtein@ecitele.com
> <mailto:Alexander.Vainshtein@ecitele.com>
>
>
>
>     -----Original Message-----
>     From: spring <spring-bounces@ietf.org <mailto:spring-bounces@ietf.org>> On Behalf Of Ted Lemon
>     Sent: Thursday, February 27, 2020 3:04 PM
>     To: Fernando Gont <fernando@gont.com.ar <mailto:fernando@gont.com.ar>>
>     Cc: 6man@ietf.org <mailto:6man@ietf.org>; SPRING WG List <spring@ietf.org <mailto:spring@ietf.org>>; Maojianwei (Mao) <maojianwei@huawei.com <mailto:maojianwei@huawei.com>>; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>
>     Subject: Re: [spring] Request to close the LC and move
> forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
>     This is really not helpful, Fernando, and goes some way toward explaining why communication isn’t happening.
>
>
>
>     What I reacted to in Brian’s message is that he asked a really simple question that could be readily answered with a pointer to the text in the document where the answer is given.  Since the response was instead to explain in email, that tells me that the spec is incomplete.
>
>
>
>     Separately, Brian mentioned that there is an issue with RFC8200 that would require an update, that discussions had occurred around this, but then the work never happened.   It’s reasonable to raise an objection to proceeding with work that depends on other work that hasn’t been done.
>
>
>
>     What I objected to in Maojianwei’s comment is the notion that the document should pass last call to support the industry.  No, the working group should do the work to address the objections that have been raised.   If you find yourself explaining some concept that’s mentioned in the document using text that is not in the document and not in another document referenced by the document, the fix is not to just publish anyway, because it supports the industry.   The fix is to update the document.   A dozen or so +1s should not be taken seriously if the work has not been done and nobody wants to do it.
>
>
>
>     > On Feb 27, 2020, at 6:11 AM, Fernando Gont <fernando@gont.com.ar <mailto:fernando@gont.com.ar>> wrote:
>
>     >
>
>     > On 27/2/20 07:27, Ted Lemon wrote:
>
>     >> The IETF serves users, not “industry”.  The IETF does not promote. Our job is to make the internet work interoperably. Brian has raised an objection that could be answered, but has not been. It is inappropriate to say that this document has passed last call.
>
>     >> In my experience, when it is hard to get consensus in situations like this it is because there is a wish to not address a concern that has been raised, not because the concern could not be addressed or should not have been raised. It may feel unreasonable, and like an imposition, but it is not. It is part of the process.
>
>     >> Rather than trying to steamroll over the objection, why not simply answer it?
>
>     >
>
>     > As a service to the community, let me explain:
>
>     >
>
>     > Essentially, and for some reason, they seem to be meaning to circumvent specs and processes.
>
>     >
>
>     > One of their last inventions has been to pretend that IPv6 allows EH insertion/deletion en-route, based on their reading of RFC8200. Based on a curious interpretation of the text, they claim that each waypoint (intermmediate router that received the packet because its address was set as de Destination Address) can insert/remove EHs, and they claim that that's not a violation of RFC8200.
>
>     >
>
>     > However, the PSP behavour doesn't even fit in that fictional interpretation of RFC8200.
>
>     >
>
>     > What PSP does is that, given:
>
>     >
>
>     > ---- B ----- C
>
>     >
>
>     >
>
>     > routers, when B realizes, after processing the SRH and setting the Dest Addr to the last segment, SegmentsLeft==0, it removes the SRH.
>
>     >
>
>     > This case is not even covered by their fictional interpretation of RFC8200.
>
>     >
>
>     > Hence the question is avoided, u<because thye would have no option than admiting they are violating RFC8200..unless... who knows... there might be yet another curious interpretation of the spec that allows it.
>
>     >
>
>     >
>
>     > It should eb evident here that the strategy is not really to follow IETF process, gain consensus, formally update specs if/where needed, but rather push whatever they publish, at whatever cost, ignoring the issues raised in this wg, and circumventing IETF process.
>
>     >
>
>     > The fact that this behavior is allowed seems to be unfair with participants, and a dis-service to the group.
>
>     >
>
>     > Thanks,
>
>     > --
>
>     > Fernando Gont
>
>     > e-mail: fernando@gont.com.ar <mailto:fernando@gont.com.ar> || fgont@si6networks.com <mailto:fgont@si6networks.com> PGP Fingerprint:
>
>     > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>     >
>
>     >
>
>     >
>
>
>
>     _______________________________________________
>
>     spring mailing list
>
>     spring@ietf.org <mailto:spring@ietf.org>
>
>
> https://clicktime.symantec.com/a/1/o-dBN-ZJMARHA7wJjIE7olF-RwnUUzVtRfX
> wdFqzmq0=?d=atw_kIqYFUZmbITw7iRdx05oul7SqRcF_hk-ksY2RXOVWKrcCK0_wLPVA5
> oOx3wxd3LHRWzwabnrklpMwnJcysKDzB7ZAlgkvkI_TBgMOmmWYTmUi7Cm9DeRzA9j6wTS
> FHHT2weAR7rEioVw_JRBIGcaxmodH6_sktn84eDFcI7b-TIpjSTD5gU0KWBiQuDvf1fgXA
> GOMtYb2BcOlbUxU6OvpXZ6eEmX0ugTpLkPxEZFSk2oe1Z9fA9GHFrSipsTECbnE9i46sWa
> YjDh7GATRMJrjPz08XHrqoPpRB7Hsm9rjbmV88d0ZyolqYLMiUxJbp5amhzqx_c2BeMoCN
> WWvFXQvMuI7SjxdfYP_1Gl0kSP848JuUk6nscdAGk9674LMjiQnz9vnahy-HtQGjQKqurW
> yHUm6-Tz1xtmpxiRiHJNYk2yxwQqWOUECBStdTdJLvRtWygm6L4Af-pDvPecd5eBAZ-N2Z
> NF2MODlL14q3R4Ewbq5YIX0rNIi1WDxNdv8YnDaK-qKbLgGNwUcBpswtWNGkMPNLYy0mNN
> lvCPHw%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsprin
> g
>
>
>
> ______________________________________________________________________
> _____
>
>     This e-mail message is intended for the recipient only and contains information which is
>     CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
>     transmission in error, please inform us by e-mail, phone or fax, and then delete the original
>     and all copies thereof.
>     ___________________________________________________________________________
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests: https://clicktime.symantec.com/34ZEL5KjkZccRzo9JWx5RVN6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6 <https://clicktime.symantec.com/38hWJKXwHtJe4zsy3VGGagg6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6>
>
> --------------------------------------------------------------------
>
>
>
>
> ______________________________________________________________________
> _____
>
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please
> inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
> ______________________________________________________________________
> _____
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests:
> https://clicktime.symantec.com/34ZEL5KjkZccRzo9JWx5RVN6H2?u=https%3A%2
> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6
> --------------------------------------------------------------------
>

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________