[bess] Comments on draft-dawra-idr-srv6-vpn-03

Eric C Rosen <erosen@juniper.net> Thu, 28 December 2017 16:45 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4959A12D775; Thu, 28 Dec 2017 08:45:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 pgNAo36H6mKa; Thu, 28 Dec 2017 08:45:00 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 CA05E1270B4; Thu, 28 Dec 2017 08:44:57 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBSGilRs023573; Thu, 28 Dec 2017 08:44:56 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : from : subject : message-id : date : mime-version : content-type : content-transfer-encoding; s=PPS1017; bh=yzFSzjBfZPXeYEPWu4uCn61ud9IDdAplfj6MrRs3sWs=; b=fNE0LM6pEd9o29NhX2IAd1I2JM2nkKCzumKJovtN/o0whoEiP4AoTW1ODVr3z8hdpnqv zCwC/Q2XUaQgKbuQzmbwTsrufG9o7bYNgBqQklNZ1Aqhiu0Rcs/ffAszUQLEiPeu9ww+ 8WkADtuL8Vxk3mQnD9Ua44JKYXdm89gplicVr0mTwk2I8If/IkMv+tGOVyvDhJzswNoW ReO1tFljkbiMTVDNwlK4FLRd2ekpj0A3kQUMs3hRU1SseAdYJR5lrmxLTRI0rXLxyhtS igLBrxturd1AB7ni60hdLCNlozJLi13MWS7HZhpQYXbHQyIl3Bm/PauFPIJT9Zw2UDn5 2w==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0088.outbound.protection.outlook.com [207.46.163.88]) by mx0a-00273201.pphosted.com with ESMTP id 2f523w09pb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 28 Dec 2017 08:44:56 -0800
Received: from [172.29.37.99] (66.129.241.12) by CY1PR05MB2298.namprd05.prod.outlook.com (10.166.192.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.3; Thu, 28 Dec 2017 16:44:52 +0000
To: "bess@ietf.org" <bess@ietf.org>
Cc: draft-dawra-idr-srv6-vpn.authors@ietf.org
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <afb80dad-4f6a-332f-bb3a-4641a3c61a77@juniper.net>
Date: Thu, 28 Dec 2017 11:44:49 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: MWHPR17CA0081.namprd17.prod.outlook.com (10.173.237.147) To CY1PR05MB2298.namprd05.prod.outlook.com (10.166.192.144)
X-MS-Office365-Filtering-Correlation-Id: 7737e986-1e0c-447d-e319-08d54e12520c
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(48565401081)(2017052603307)(7153060); SRVR:CY1PR05MB2298;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2298; 3:b1gjhbziWZfpMDERPMkkWCU8aq+0XUAyzvw+hunLZMGECTSHhy450/Kv9Bk+jIrh6t3kLXJoFu5oK4OQ/CQGeVQ5ca9jD+dtrKRkEhvR8qipIipx+mj3ogK503DcupIiV/JL6gnGVRmEStwjXbkzUHU+Aw+E7vjvic/LRuoHQ4cMMo14tipFq82Al5QFJGJGq9wdgs9DeOiq4RClrRRN7wZFA1jBFM8n1BUxwVSRvcGjPMsxtCi7DJ9o4RyDH9+l; 25:HUKHba/4ZzVmJX1/G35Ak3bOcBRt+5nNPrZiwThJbhEcPmOU1KRMEamKa12CsEWgn2Bk/IbN4/QwuKTBFCv1oWX+gUC87I74/G57UWYJUbuPWBtFkX0lg3gaPcDj6QKMoS/0ZQyQctJ2hd5rn6g7Zdbc0uoJRpZq00FaEGeT6bIItIMFY6RjXeTel4/iw3uWFnyq/vlOIfvPYwMJWDoPPuSMstj2ZSPIwMzlUx+pGg7XKyQyZeTwnxzRVpgXPiCVZbezl/Spj6slpYy06l2QskWDt707b7oG8sFvfp9YtvkBzwx+mEup6Tus6e3wLbFvDXewjwefMuT5IHrnLwDmjQ==; 31:kO/HqutqKaH+SkCumx+GWwRfJjiApIk9o00xoMiUox+an5OU2n1uN/jbiAYSufBfPpylw72NYnwZKk4w8kp30tduKizEA23nb472Lwy8keHccz+JBlUf0Fx2AoUkpL7+4Z0ii5G0x/MXx5XUmV0ei5th/Syk8agQzOUO5ITkGQmpSRCZ4pKb6lpsl1pKhsWO4d31ksRtmIEkJwRm8kdfb+pf8i2U759kHlbSk2xl2QU=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY1PR05MB2298:
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2298; 20:WibpfTxjK5Zh1bReyi6SVMBmu0UdMGm+9zVKSN/8SxJp8t0MClk9aTdsthRl92hojz0G81S229PkB//J21pBx7mVkmp2ZvPglwiEg6L03JuuzqiL5ZD+j9uOeIclY+RJNnv0qEOY/SBkltDELVdiDt2N30U4mqobKQ1nhtGro8BCmj1Jh2ULkYE9z8bgAXgCqj2d/3CxEgC8mrKcNKhQnm1ljwhP4k6lthsI6sNh9zjmhnacRxLsxq9SjQTf1ncXyJQhWTKNYYQIbmPr56xIKGuZ6G09+TsuQRauf/RxvczZyZENfhUn1aZwlDwssGlTez1Vt1hCYnE09asWGDY3xC8zL32wwXbGieKT2j+kjRGBIJL5FE6N20BhMFQTWmjrkDdJDfRbgAIsxD0kFSTcagdfJQRgorEiix3fHHhqtyxawj9PcB7XvQo7N8iGxu1WtCY2G2bZKE+izhsjpwM1bXBPDmpjUCVb72hzP5Vx1n8Cy/+cl7iPao3/SY1VGCC5THr2jNcCvuu67b9VDb6zZXlHz9zLPC8CQKcFFkczIP6/FT/fv8TIthCGkVF/C25mThCmAvy6Wf1v5bx8vz2mQ1ESC4KVeGNKB84sB36gn5o=; 4:M0vDMibcqHpfOG05LsCRCteUWxEwVGgpULML+3KmDYW8ux2oiuuDzmYD9JEUHyoctV/kKbU5bIJpKzcPl9/MLVTmVNNUhw73KUf1jTXoX0EA7gZKq2HXkoDAfj1t9SRHe/G15FAC7W8AkjvCc+T6Z5jCQCPqIBAdT05dkIFfFVAAjsLim/aYJq63vT7+Gjfi+2xdLymM4QOakyb8GZEyP/wiKbjh8Qjxz3aIQ9vpnvRKO01q7qTjveeo8KMA96Stk0FKFaG9zQA8RfOBZvX+ZrgbYAuECppXFvBoECq9Tjl9r2RxBMHR2JfEggKY7Phn
X-Microsoft-Antispam-PRVS: <CY1PR05MB2298B5B80CCDDD0AFBFEEF09D4040@CY1PR05MB2298.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(192374486261705);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231023)(944501075)(6055026)(6041268)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY1PR05MB2298; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR05MB2298;
X-Forefront-PRVS: 05352A48BE
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(39380400002)(346002)(396003)(39860400002)(366004)(376002)(199004)(189003)(52314003)(51444003)(59450400001)(105586002)(2486003)(386003)(2351001)(16526018)(31686004)(36756003)(97736004)(47776003)(5640700003)(52116002)(23676004)(52146003)(478600001)(2870700001)(2906002)(6916009)(68736007)(4326008)(3260700006)(25786009)(450100002)(6666003)(65826007)(6486002)(77096006)(5660300001)(53936002)(64126003)(86362001)(8936002)(31696002)(67846002)(106356001)(5890100001)(90366009)(2501003)(66066001)(58126008)(1730700003)(16576012)(83506002)(65956001)(65806001)(316002)(3846002)(7736002)(6116002)(50466002)(305945005)(81166006)(81156014)(8676002)(230783001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2298; H:[172.29.37.99]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyMjk4OzIzOndPQTJQZ0VCbzJyME91QSsrdnNlOFg3TnZx?= =?utf-8?B?MWsxVmd2bWFzM2YrNE9kOGRVYlVmUHpGNkJjZG81bkswb3BWdmtvVkwvbW95?= =?utf-8?B?T3VhL2ZJTlBzWXVjTkgyRzJ0cnZ4ajM1aGZ3cDdVUDU4aGh0VWJGUG1wTXRW?= =?utf-8?B?NGtSOTB2ZWNWcTA3QlZvTHBscEQrazFkd3QwZmZveDBweEZSOEpDWEh3YXhW?= =?utf-8?B?MjNkRkJFcjN4KzFYZ1E5UW4rTEFtSFVlVDZJaDNCb0pVZ3hqR1ZQMWJUTWN1?= =?utf-8?B?by9WOFFJNUlpSi9ZZEF1dGZaR0ZreFBtMFN6Zi94ZCt1eUFhcUNyN3ZqTDN0?= =?utf-8?B?WUp2YUtmMHB4ZGVrTWtiNi9GYzllRi8vakIyWHpwNnFhbnVORUJkNXFvT1Vx?= =?utf-8?B?bFRoQm9pdjJSeUNGZHhESXJJTjlYZUFkSndEdFp0a1RMTjNib0x1MlJPeFNu?= =?utf-8?B?aTlDTGNkU09KeC9sUWh5OHBEQ1J4V0s1R2ozOUhML3ZMbW03eC9tSk9oQXlu?= =?utf-8?B?Q2c1VG11L0xDaXd6ODF0RWNrekl2aXp4VXpZWkdpQVoyT2xCVjNGN2QrY1ly?= =?utf-8?B?VnJGenZmaUkxZHE1eG1ONHA2a3d6a0dBdVBvWkgzUnNSVVVSTDRwVm5iV3F4?= =?utf-8?B?RWwyaTB2VGFKQ3p4M3VLY3lwU1JXWS94ZTVPaXRpSzlJRy8wdUQ1RkVKc05J?= =?utf-8?B?WEpSTXhQRGhtSElMK2poVFgraGgzTjVNVkRMVW1xNktrSlJxQlplREVZOExZ?= =?utf-8?B?VVhtNjZCZktENTYvQVN1UEluSkF3SnBWcUFtWXU1a3orNFg1Z2wyT1hBTms0?= =?utf-8?B?WkUrWGUwaHptRWdaTW9GK21UM1lkbHFpZTh4WTZxMTdOYS9tNGlFNzE0QnMr?= =?utf-8?B?bmd2VEpRUDVTaTY3Y2VDY2c3bklhKzZ4ckVOMnQzY0VWSUVJallVQVVsUmFs?= =?utf-8?B?S0xZM0lzNEpDRS9zUkVYRFZYRExmOXp1TjhQK1ZiaEdncWIvaVh2QWtnL2kv?= =?utf-8?B?QzdjQzRHY0JuMEFZeklMUXVRV1lMTlo2WnoxMGVscEQ5d2FPQ291TmZvbHph?= =?utf-8?B?RjgxTWs0YTYxOHJ5WlRRbXluR1pVUHNSbHBjYTFjdW9SQ1d0VDYxWVNBYVJ2?= =?utf-8?B?MmNQODVMUEtaQmtWTytxUEEyMy9GUU5pZk5qajN5cGVPb2k3UHJuWlV3UXZo?= =?utf-8?B?U2E0MGtqSEdIajZ1ZkQ1d1lVWTJHUkZYNVdqM1o3cGw0Y1lmaTkrRUxySCtP?= =?utf-8?B?VldCU01QaW8ycFArVzJuMEdyMjc4WXVXVnB1SjhPMW5UN0NWWWtobFQ0ekZj?= =?utf-8?B?dTkrUGF1UFNzWnRVSG9Vekx4Qm5ZTk03TFRlY3NtekdpREk4ZERUVkpqV3Fy?= =?utf-8?B?UU5hYnY0VTFHYVRtdFNPdDlCMG5NODVpSHBsQlRQMzZmajlNdjhvTWVKTGk5?= =?utf-8?B?UHlyL1JaalpBQ0NtQmpUTDlydkhDYWZENmUwTGhleHl6bmpBeGFXZDRxdmZC?= =?utf-8?B?US9iKzhSU0oxYUtzZXlqdXFaajRCd3lJUTZsYUlmaEUxM3d2aEJGZFJiaSty?= =?utf-8?B?OHcvZFdnQ29tbHhpSmRCVkx5Q0JKNU55VlpSSjhIZUlXTWZxa2RTQzFodldU?= =?utf-8?B?aUpmbFJ0SEZ3bVo4bGdEU3d1eExmSVZGMjd1akY4d3pXb3RMakRiZjhZdzY1?= =?utf-8?B?dWZnbHJoSW5GUEJ4eThjSFpCQTZ1SmVKOG9DU3BQaUdvUzNKaU41cktmcVFo?= =?utf-8?B?VTBKb05PZFRnbVdDdTRrSzVtRE5uTXFiSjhsSzQ1TG90UG1mY2MvNHBCM2hq?= =?utf-8?B?YmVmWEV0bGs2a2VvUEk0ZjVyUklRK1Myam0wclRFdVYzR01qbWhkYWp4Sjcy?= =?utf-8?B?UVEya25OaXRlY0tzUEZSSDdJUUJtcU5IRkk0QmtVRmtiRnVYcjFZblNwVlNN?= =?utf-8?B?aVlmUGJJNm5KeWlXSXVoZnpQNVh0SkxBVmtkVTZqb2czd2NYVXZtZkNVVHI3?= =?utf-8?B?d002SW40SFd5ZG42Rm9sOHJVTnkreVBxTVBVd1h2VzBYdlc3M0RuR3UwQWlD?= =?utf-8?B?MFlPS0phdmk4NzQ2dnZYWlpmcGQ1a3JINUdONDFHOXAxaG4wTkpDVEc3eHB2?= =?utf-8?B?OFE9PQ==?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2298; 6:zj3JPf+mtbQZ5iSrwkZcrZcRBrCZO0bgRJ70ZQDzSz3sU2F05a3Hz25nYBvpwc0BNZ1hZH7M75GBJ9+MH3g9cPMLEWHkfEvyhyNq844+tZ7aD56jW8adrxGnlKYAXqIqP90xvjWWh6lgZYuJ3N2+4+cflOKRiwbl4TpjVpFyRgXUVEpo/E1wNRk5cA1+D6Tg21hqdlocyXXUaCxFVT8eJfFndgChce7SdqNMdLtp3bCz57RomhuMUWu4OWMaKXfEPN3zuZmzkKWFXRQIzM7ZUCeYga/0vpKAJshZGuG3y1NppBFCZ9+XHARYXnlh2wau6jcXsbbBnCflsZVstY1PzXS2ne7j/iHc28T9BBe6pSo=; 5:FSxI87vldZpR5L1ED64h8+Pqo4jrbNbMoQV5U+JM42Zp7QJGAPo9SQ6v8i+G2Trx8P5q9HWzj2OZu5S+Vzr+M/OW8Klgh4BC2ffMtZpXx5WbTCe/0BkvYAupTGRklp19g6/cWtSg5LkWt6pMYELbu+dbSrynSOqlXkx3M3E9y9Y=; 24:KsUWXYNNVRXBaPJ1gic5LlYudMriYSZg5lAbKdvdiOFhSID8ppzf3n7m5Q3eYAKcusB09XbA1Aa0KHwtOR1asDZRgLJ4BcWe200aat3DJo8=; 7:sWND1i4la6vq17WtMrkC4FQYLbNO4xlw8kdID9YRI1eQntpVxivsWUERxQVr8AnW5+uAoXPkbpFnsw1gcVXGcvAZPSpw63NXuhWgyX2uTGMjjX14cBAbSWFNe8oo0bji9GCNGvD+DLrjFNcRi1sLg7X3xEE8tEgwZZ+iAPENTN21sg2vBR+WTyEUSkOEAvySLcm7hB/ks3q30ODpwS+Vt0puSv4wmvu/Fraz5H1GfbEPvrVFvs2r5P7tIyLAEKw4
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Dec 2017 16:44:52.8402 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7737e986-1e0c-447d-e319-08d54e12520c
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2298
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-28_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712280234
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/aAtM2qJLbpm_sPLnbdnO4sXiXsE>
Subject: [bess] Comments on draft-dawra-idr-srv6-vpn-03
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Dec 2017 16:45:04 -0000

Following are a few comments (look for lines beginning ****) on 
draft-dawra-idr-srv6-vpn-03.  The name of the draft notwithstanding, I 
think this is clearly a draft that falls within the scope of BESS, so 
I've sent my comments to the BESS list. (Also copying the 12 "authors" ;-))

Section 1

...

    To provide SRv6-VPN service with best-effort connectivity, the egress
    PE signals an SRv6-VPN SID with the VPN route.  The ingress PE
    encapsulates the VPN packet in an outer IPv6 header where the
    destination address is the SRv6-VPN SID provided by the egress PE.
    The underlay between the PE's only need to support plain IPv6
    forwarding [RFC2460].

**** This suggests that an IPv6 address has to be assigned to each VRF (for
**** per-VRF "labeling"), or even to each CE (for per-CE labeling).
**** Presumably these would be taken from an IPv6 prefix owned by the
**** advertising PE?  Or not?

**** If those addresses are routable, doesn't this create a security issue
**** as discussed in RFC 4023 Section 8.2?

Section 3

...

    For egress-PEs which supports SRv6-VPN advertises an SRv6-VPN SID
    with VPN routes.  This SRv6-VPN SID only has local significance at
    the egress-PE where it is allocated or configured on a per-CE or per-
    VRF basis.

**** The phrase "only has local significance" suggests that these SIDs are
**** not routable. But later on there is a suggestion that they are
**** routable, or at least that they might be.

...

    In practice, the SID encodes a cross-connect to a
    specific Address Family table (END.DT) or next-hop/interface (END.DX)
    as defined in the SRv6 Network Programming Document
    [I-D.filsfils-spring-srv6-network-programming]

**** I'm not sure what is meant by "in practice".  Aren't these semantics
**** NECESSSARY in order to provide the L3VPN service?

    The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
    serves the dual purpose of providing reachability between ingress-PE
    and egress-PE while also encoding the VPN identifier.

**** Did you mean:

    The SRv6 VPN SID MAY be routable all along the path from the ingress-PE
    to the egress-PE, and if so, MAY serve the dual purpose of providing
    reachability between ingress-PE and egress-PE while also encoding 
the VPN
    identifier.

**** Though I guess if the SID is routable only in the egress AS, one could
**** tunnel to an entry point of that AS and then route within the AS based
**** on the SID.  (Of course this amplifies the spoofing problem discussed
**** in Section 8.2 of RFC 4023.)

**** So there are a number of options:
**** - not routable
**** - globally routable
**** - routable only within egress AS

**** If the intention is to allow all those options, please explain the
**** signaling that lets the ingress PE know which option to use.  Or is the
**** intention that this is known a priori (i.e., via provisioning)?

    To support SRv6 based L3VPN overlay, a SID is advertised with BGP
    MPLS L3VPN route update[RFC4364].  SID is encoded in a SRv6-VPN SID
    TLV, which is optional transitive BGP Prefix SID
    attribute[I-D.ietf-idr-bgp-prefix-sid].  This attribute serves two
    purposes; first it indicates that the BGP egress device is reachable
    via an SRv6 underlay

**** Whether the egress PE is reachable via an SRv6 underlay has nothing to
**** do with the presence or absence of the SRv6-VPN SID TLV.  The presence
**** of that TLV really only means that the egress PE can handle the SRv6
**** encapsulation for L3VPN.

    and the BGP ingress device receiving this route
    MAY choose to encapsulate or insert an SRv6 SRH, second it indicates
    the value of the SID to include in the SRH encapsulation.  For L3VPN,
    only a single SRv6-VPN SID MAY be necessary.

**** I don't understand the phrase "only a single SRv6-VPN SID MAY be
**** necessary".

    A BGP speaker supporting an SRv6 underlay MAY distribute SID per route
    via the BGP SRv6-VPN Attribute.

**** I think you mean "If a PE supports an SRv6 underlay, it may attach the
**** BGP SRv6-VPN attribute to the VPN-IP routes that it originates".

    If the BGP speaker supports MPLS based
    L3VPN simultaneously, it MAY also populate the Label values in L3VPN
    route types and allow the BGP ingress device to decide which
    encapsulation to use.  If the BGP speaker does not support MPLS based
    L3VPN services the MPLS Labels in L3VPN route types MUST be set to
    IMPLICIT-NULL.

**** Please provide a reference that specifies how you set the Label field
**** of a SAFI-4 or SAFI-128 route to "implicit null".  I don't recall any
**** such thing existing in RFC 3107, 4364, or 8277.

**** If you mean "set to zero", I think that will generally be interpreted
**** in a SAFI-4 or SAFI-128 route as "push on label 0 (explicit null)".

**** If you mean "set to three" (the value defined in RFC 3032 to represent
**** "implicit null"), I don't think the SAFI-4/SAFI-128 implementations
**** generally interpret the value three in that manner.

**** I'm not really sure what you're trying to do here. There are at least
**** four cases to consider:

**** 1. For the case where the backbone doesn't have MPLS, there is no harm
**** in saying "set the label to zero".

**** 2. For the case where the backbone supports both MPLS and SRv6, and
**** some PEs support L3VPN both ways, while others support only MPLS-based
**** L3VPN, then a real label needs to be put in.

**** 3. For the case where the backbone supports both MPLS and SRv6, but a
**** particular egress PE only supports SRv6, there needs to be some way to
**** instruct the ingress PEs to use SRv6 and not MPLS. Perhaps the
**** presence of the prefix-SID attribute with VPN-SID TLV is sufficient.

**** 4. For the case where the backbone supports both MPLS and SRv6, the
**** egress PE supports both for transit, but the egress PE only supports
**** SRv6 for L3VPN, the label in the SAFI-1/SAFI-128 routes should be a
**** value that will cause the egress PE to discard the packet.  If there
**** happens to be an ingress PE that only supports the MPLS style of L3VPN,
**** this will prevent the egress PE from misrouting MPLS packets that
**** arrive from that ingress PE.  (This would be an odd, probably
**** transitional, deployment.  But the draft isn't very explicit about just
**** what combinations of MPLS and SRv6 it is supposed to support.)

**** In any event, the draft would be better off specifying the actual 
label value
**** to be included rather than saying "implicit null". This occurs several
**** times in the draft.

Section 3.1

...

    SRv6-VPN SID is encoded as part of the SRv6-VPN SID TLV defined in
    Section 2.  The function of the SRv6 SID is entirely up to the
    originator of the advertisement.  In practice, the function may
    likely be End.DX4 or End.DT4.

**** Obviously, the behavior is not up to the originator, it MUST provide
**** the functionality necessary to provide the behavior that would have 
been
**** provided by the MPLS label(s).  Statements like this occur several
**** times in the draft and should all be fixed.

Section 4

...

    Ethernet VPN(EVPN), as defined in [RFC7432] provides an extendable
    method of building an EVPN overlay.  It primarily focuses on MPLS
    based EVPNs but calls out the extensibility to IP based EVPN
    overlays.  It defines 4 route-types which carry prefixes and MPLS
    Label attributes, the Labels each have specific use for MPLS
    encapsulation of EVPN traffic.  The fifth route-type carrying MPLS
    label information (and thus encapsulation information) for EVPN is
    defined in[I-D.ietf-bess-evpn-prefix-advertisement].

    The Route Types discussed below are:

**** After carefully counting up to five route types, the document then 
proceeds to identify eight route types ;-)

**** And there are lots more on the way!

Section 4.1.1

...

    SRv6-VPN TLV MAY be advertised along with the route advertisement and
    the behavior of the SRv6-VPN SID is entirely up to the originator of
    the advertisement.  In practice, the behavior would likely be
    Arg.FE2.

**** This seems to require that a unique IPv6 address be assigned to each
**** ES.  Is that the intention?  If so, then probably those addresses
**** should not be routable.

...

Section 4.3

...

    An Inclusive Multicast Ethernet Tag route type specific EVPN NLRI
    consists of the following [RFC7432] where:

    o  BGP next-hop: IPv6 address of egress PE

**** I don't think there is any reason for this document to specify the
**** contents of the NH field of the IMET route.  The above doesn't make
**** much sense anyway, as the term "egress PE" doesn't really make sense in
**** the context of the IMET route, and the next hop can change as the route
**** is propagated.

    o  SRv6-VPN TLV MAY encode END.DX2/END.DT2M function.

    o  BGP Attribute: PMSI Tunnel Attribute[RFC6514] MAY contain MPLS
       implicit-null label and Tunnel Type would be similar to defined in
       EVPN Type-6 i.e. Ingress replication route.

**** Is the intention to prohibit the use of either P2MP tunnels or assisted
**** replication in an SRv6 overlay?  That seems to be a consequence of the
**** above.  If that's the intention, please say so explicitly and do not
**** leave it as an inference.  If that's not the intention, then do not say
**** what the tunnel type should be.

    The format of PMSI Tunnel Attribute attribute is encoded as follows
    for an SRv6 Core:

                   +---------------------------------------+
                   |  Flag (1 octet)                       |
                   +---------------------------------------+
                   |  Tunnel Type (1 octet)                |
                   +---------------------------------------+
                   |  MPLS label (3 octet)                 |
                   +---------------------------------------+
                   |  Tunnel Identifier (variable)         |
                   +---------------------------------------+

    o  Flag: zero value defined per [RFC7432]

**** The EVPN specs (of which RFC 7432 is not the only one) use five or six
**** of the PMSI tunnel attribute flags.  This spec should not say to set
**** the flags to zero, unless it is meant to prohibit the use of any
**** function requiring the flags.

    o  Tunnel Type: defined per [RFC6514]

    o  MPLS label: Implicit-Null

**** MPLS label should be zero; in the PMSI Tunnel attribute, it is clear
**** that zero means "no label is specified".

    o  Tunnel Identifier: IP address of egress PE

**** This makes no sense when P2MP tunnels are used.

**** For IR, the tunnel identifier is the identifier of the PE originating
**** the route, per RFC 7432 section 11.2.

**** Note that this will require that a unique IPv6 address be assigned to
**** each Broadcast Domain; that should be stated explicitly.

**** In a draft entitled " BGP Signaling of IPv6-Segment-Routing-based VPN
**** Networks", it would be nice if the following little details were
**** mentioned explicitly:

**** - In L3VPN, an IPv6 address must be assigned to each VRF (or to each
****   VRF interface)

**** - In EVPN, an IPv6 address must be assigned to each ES.

**** - In EVPN, an IPv6 address must be assigned to each BD.

**** It would also be nice if multicast were covered in both MVPN and EVPN.

...

6.  Implementation Status

    The SRv6-VPN is available for SRv6 on various Cisco hardware and
    other software platforms.

**** Does it provide the full set of L3VPN/EVPN features? If not,
**** what subset of features are supported?  Does it support
**** transitional scenarios without relying on non-standard
**** behaviors?

...

7.  Error Handling of BGP SRv6 SID Updates

    When a BGP Speaker receives a BGP Update message containing a
    malformed SRv6-VPN SID TLV, it MUST ignore the received BGP
    attributes and not pass it to other BGP peers.  This is equivalent to
    the -attribute discard- action specified in [RFC7606].  When
    discarding an attribute, a BGP speaker MAY log an error for further
    analysis.

**** If the attribute is discarded, and there is no label (or the backbone)
**** doesn't support MPLS, what will happen to the VPN traffic? Can it be
**** misdelivered outside the VPN?  That wouldn't be very good.