Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 22 January 2019 17:37 UTC

Return-Path: <kaduk@mit.edu>
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 A0C9C130F7C; Tue, 22 Jan 2019 09:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 q4cUrFCCcKCc; Tue, 22 Jan 2019 09:37:11 -0800 (PST)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730098.outbound.protection.outlook.com [40.107.73.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C913130F1B; Tue, 22 Jan 2019 09:37:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CjSGemLbPgHhKoCCgYVh9TA8rP2YI6gmw5gITPgmlXU=; b=XTuZ5JjqA0R5EcBWFWZFpYJ7QWSW7+EU7j5O0eHs/eKMGcuYmpzYjS2j6tB6jDHT2f/Nl39Yd8ERjKcOzawdvp6tngxpH8owWYW3P2XsQ512f8eczj8K7h3qsCNlajyuENg0iFw3ukcF6aW0lZ4v5DdJF8vywn8vyVc66b82pRk=
Received: from SN2PR01CA0029.prod.exchangelabs.com (2603:10b6:804:2::39) by DM6PR01MB4492.prod.exchangelabs.com (2603:10b6:5:78::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.24; Tue, 22 Jan 2019 17:37:06 +0000
Received: from BY2NAM03FT046.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::206) by SN2PR01CA0029.outlook.office365.com (2603:10b6:804:2::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.26 via Frontend Transport; Tue, 22 Jan 2019 17:37:06 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT046.mail.protection.outlook.com (10.152.85.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.11 via Frontend Transport; Tue, 22 Jan 2019 17:37:05 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0MHb1qP019736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Jan 2019 12:37:03 -0500
Date: Tue, 22 Jan 2019 11:37:01 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-bess-evpn-vpls-seamless-integ@ietf.org" <draft-ietf-bess-evpn-vpls-seamless-integ@ietf.org>, Matthew Bocci <matthew.bocci@nokia.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Message-ID: <20190122173701.GL81907@kduck.mit.edu>
References: <154688146371.23228.11253231358362119768.idtracker@ietfa.amsl.com> <B55A7785-E8FC-4AC0-A719-43B09041F386@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B55A7785-E8FC-4AC0-A719-43B09041F386@cisco.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(396003)(39860400002)(376002)(346002)(136003)(2980300002)(189003)(199004)(186003)(55016002)(53416004)(104016004)(6306002)(106466001)(26826003)(966005)(229853002)(478600001)(14444005)(2486003)(23676004)(7696005)(6246003)(486006)(356004)(26005)(86362001)(1076003)(76176011)(246002)(956004)(11346002)(446003)(8936002)(476003)(126002)(4326008)(8676002)(316002)(106002)(6916009)(54906003)(786003)(426003)(33656002)(336012)(305945005)(50466002)(47776003)(2906002)(36906005)(75432002)(2870700001)(88552002)(58126008)(18370500001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4492; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT046; 1:yb4BMWZ3qUH0YdBCIGRHZGw0FSvJ5nOjpYISc6HJ05B9Q0E+xSJLwn0ubqRKAS0OmTFEmtKTx8Styu0Fn1wqkIKSuJag2ZOg5y92o+0Y0xYxj6B/fdgoJKllVPCAskAPVKKZH5NQZorCldXppHnWgllcYzMSNhQMFxoSdYfwy/Y=
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5da1e685-d73f-4f65-aff9-08d680903a71
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:DM6PR01MB4492;
X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4492; 3:nu+wlQ9PcAdHeF1W24LaEhAp6kUEGql3gHW1XPq57FeV4Sda72RSPl2QqQC2qSrS9UXB8S1zYyotUE1sEPRtVRKDaLzZH8z4KBQHaAlWBAfqVBSKSmnntk4aIvgiQUdRlfQGVSxMS+G/CndQ5o49OieAQ4C/6c5xCla6Gdbjs2/ZNiXCbQTqZr8pLEqjrcDrWjtSXiqJ0a5ym7Y7oZLoq0vIfJLK9pGEgVjtVty9dQPi+c4gf0W/QHiiLMh8FKXHezqRbZYjDNbvIPIfl30jt+iTe0q/BDg9dBHUnim/lKtGGlPOl0F39JMbpLBII6lNagDARO0bgwt8RBDmmeSR0RLCOiFi683sM+bfMULa+jXaI1dFcnJqerByCKAoc+LY; 25:/SenLIUd3cRWdBiTqb0H4l0ZfJoLUUUEtN+q0anu3DyHLl1XRQA0i9NKUV8ElUcj40WXgnRS2skLOKZA6g8hKiVYoGR+4m81kobL4qIHg1DB+GyddmT7BbOYE5ouVKU3d2bchuUM9Jb8+A81dWS3JFhVhjvwl9X4b9wdJA9auPnnSNLoIDE0HITBVgsw4Obin5XbcRCnF2960KPjfP4qoyj0bLzJlxo9/789nD2tTYv+oHVhN0TElu9t6B6hGtdJ7ImZImSnwTYFR2AwCPBY0pfofdkQfouUPMW9+PjQwNcSuW+01btkLNmPXY2WnouE95fEnBL26Bq/cqq2A/znxA==
X-MS-TrafficTypeDiagnostic: DM6PR01MB4492:
X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4492; 31:HStM1vMaCxJagopnX/r3NBDSRFiRv7geHfmhisibMZzxpgd8Frx5q3Lf8mMETVu5FHwGtwSqFFB430Wxx1AEq6Aiw+FoPOQ3sC1sYmARPlmSOKBY2EPi/MBYRTifg1h/T6dMf5XiHW+LcCwn87uejXSjArX3Meof/1QpBP0tl3y1tY0phweqaqDfMB2TlmAPFMQ22eVGC6nI9ujHOhKWVoNDtHNF0EDG6+KnIxja12o=; 20:Upk8sZGPKq+RuTcWwO3y9tw/+9Z9nW6wUgejRGk2J7e+KiuneWmSb+724KzdeWmaNW4VusROc6SuL/MYY+yZBhTATn/9w85l3e8y/cdl6ma/L+kr9FhTUpYyTN7o1cQppQxQ5WkQhNdHjgunYIkuVGvI8e9bSLswkZlinUOPpK4cxsTud/R3oZlfARougz6Z1xICZns2hYFYkN9cBZ0N8Pj22ecNHPOA+0dz2W0UU/xtB9q2lz2GFuMoXnoSGG9mySmESb90P7+DTsEs7EAap0usHd+nA8dhOJGxW9MhiCryzoKXfDVkoWEX/zP06ArTrr72NhFSYDr9Ckg315+Upm7jt8MyVKIwJIBU8EocqIrBg3WbICfLcUMCJ+ZUkfwolpLwVvWnG8vL4PKW3MzpX6xktTdrfFfcP/cHAoOtzqfRzpoDNDN0+lxOQAx1MCrPZvfWiHbkS2y3H1D6pleH4L9Pf0tQGwbJqwiTEVKnIESvHfdARwOaXzqi5OFzCPo9Vh17yth4BUm4f8wAmBdexFv2vM1686W0f4SRQZ+Mml5UIXqWQagpwxRF9yvWjH7ucQcIFqlFFZsXYoY9xLF/F5F2R3YrgBlu2RhOPwOMPGQ=
X-Microsoft-Antispam-PRVS: <DM6PR01MB44925BA0690567ADF2FEAB5CA0980@DM6PR01MB4492.prod.exchangelabs.com>
X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4492; 4:hDY+27Cwa3D9a35RWL8QdjLO/6ouaLl6j9e04ZMxn17k4b8CUI++FiiDXiCJYfrZf80m7QZ5YNJPJkK6ox55P1sVsT2ISSfZPzKrpGWy9P/ffOQV7oYw1bgxyNvxKj3Ste//YM8dsQI843ZE5KzN3ce6A8KZOSWZl5Hbj8Gx79eZSjuAI42CyffnPhgDh+pyiuNHHGkyDz1i72ZgfLEpyspPDYd/tCkd2mPZzQDgJIuwSjSfHwdGegO4tu+ZGnLdaXVBnTMC4o8BjwZ5AtbCrLsWyhzRy4UbmZxJX5nGsGKmNOeU4gTnPtvEg2wFhKeG
X-Forefront-PRVS: 0925081676
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTZQUjAxTUI0NDkyOzIzOnZ2d0Eya1NRczlRbFc3MG5VODl0NExndEJ5?= =?utf-8?B?d2RGOWsyOCtkcGxkZldiZWx6Qm40Z2pyNGEzcGRkcjYzM0VqSWtRTzRFTHZx?= =?utf-8?B?NmxCbjk2am9KWmJDSmVjempnTlZBT1ZDaFlOUUkyQkRQZEYyaGpmYUdjSkxo?= =?utf-8?B?M25xTzlHZ1RMM2wvbWplSE4xTTF3N2oxWklYenlqN3ZjVjdIVW94SGZyTXRt?= =?utf-8?B?K1B3bWRmeWZDcHg2VlB4ckZtWld0M2RxTkhta254VjA3R09TS3RBNm91dXkv?= =?utf-8?B?TUxnZG1sL3hOMWFlSmErclRKUCtMZ1ZoUUdoT1kyM1M0b0JZSFJ0S1NKL3Q3?= =?utf-8?B?RWR1RTE4eGMwSzd4Ump4eFVSK3FxdDNiQ3Z5aDlyaCtsci9RQTdVRXZDTWhM?= =?utf-8?B?cC9uS0RQN2R0K2ltclYxcTZYUW54WjdhZDlkcGM5KzJPK0hXS3VxdnpjRDVE?= =?utf-8?B?WmFzZW16MFZuaUdVdVBHVWIzWGF6YWpSbER1L1Vqb05RRXdMTklwR3F3ZUFX?= =?utf-8?B?NU1FSUErZjM3ZmJkTnB4RVFWZUJ0ZkFwdzVRQUVMSTBYZzQ4S1g5MU5MaEE4?= =?utf-8?B?OVFuTVJVOWp2amtaZFFLN1BMUWhxMWlSZ0xxaUR1WjlMS3EzWm5XOWtIK2hs?= =?utf-8?B?Q0tuclFveVpiMUo2SWFDRGFLbWkxcjBvTXk2WUkrN2tlNEU3cXFHbWdNYmFY?= =?utf-8?B?MWxVcWNUYjliTEV1UnZ2TUc2QXFqb3NZb3lzZ2VuSUxxbDdzdHRLaEU2b0J2?= =?utf-8?B?UmhTeFZHUTlRWmgvc3FyTWQzY3hid253U05PUnBUYUoxeHZrMlNmKzRpY29r?= =?utf-8?B?Mkpwenh3UURXMlBQWkhGWkJuNFhFRWJKWUp0KzA2Y2ZselJHUCtNeGpJblFK?= =?utf-8?B?Y25PYng4WlQvQ21JaStHREpOYlR1VkpKRmI2cHgwUjNTOTlXQ0YvSGR0U0F6?= =?utf-8?B?Q2k1cm1PbEJ1cjBlVk1PTzRUc2ZIYlRwQkhqak5OY21HUTFFWnpkWXAyTTZv?= =?utf-8?B?RUNQampGYm9Ic1ZseTFzMTBBeUdhNGFxemNsOC9oQmVLQzFZK1ErMFAwRm1i?= =?utf-8?B?a2JQbGs5bzZZZlNRbENXNWZqQTNYUjk4VXRFTUI4M0x4YnQrRDhqNVlwYmNn?= =?utf-8?B?c2piUm50cXhrdGlRL25BUkU2ZWtKK1U3cGp0TElCY2NYdVNNN1hFNWZ4VHdy?= =?utf-8?B?L3F4YVBjU21kZ2k1Z29EQW5rT2t5U1JWU2h1VW05TExKNjVIZ1doYVJPRm5h?= =?utf-8?B?cklGOHFkb05mY2ExSnhzVUI3SFJqOEsyVFZibTFjTWJJdEVsK2ZmYUdwTmw2?= =?utf-8?B?UnI3L3Azb055SmoxZ1lYU2hCT1RLL0ZybEp0OHI1ZTMzd05HeDVPVmtIeUdn?= =?utf-8?B?QmZ2MFR1d3FYcERkYVcvMWpaQmhjNUVkU0p6SEdUbnhadTFQMlBmU0FONFhP?= =?utf-8?B?MHlSRXhkNmF1OUJmT2tpajRSS0ZGUXF6K3BJRmRPSjJnaGhqa3ZqZ0lRUWxh?= =?utf-8?B?U1R5NjVlc2FBS0p6TEZIWTNlM1NVbzFRNjc4WDFVOUxaS1VaNGd5ZldVUmRT?= =?utf-8?B?SGNQR1NxNzJJUVdyOGdZc1dRREs5SzM1Z1l3ck5OTUk5WlMrS2E4enJZTS9s?= =?utf-8?B?M3RsWkhpWFo2VEdpdFdvUmZtZjF4VWc2c3kxdS9ROU4xdXF4S2FIbXh2LzUx?= =?utf-8?B?ajA1VVhXK1R3ZWxSTndVM0JtclQvZGo4dkdWSHBTQTVyTGJ1M1orYWt2a0tL?= =?utf-8?Q?s1Iz97PbIx7s+QgipyJCQdH+Z5kZZLU+sPXWw=3D?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: A12z5RzJXO2Jb62lfcAepTkyc6q5RXeLNsXBDR3Wog/+cDKWcNpPzg7oiThruxctLXJs7WuumLPJEUtEpZJweR8DGRcpHAznm+DIvNF42rS18tG0Y71q+vgaw02+dcuMEPH9+2JfiZBr1J/fSQpA/wqOOnmFCwpJbCoo/7PiVu/XBgG9QASWMLNpM/7Cvf/nMXJILfKDtmEHlVXpVv/xx0pP4K/75pfshsO5GLgfb4ZUVRgdwB8taiWFHdYcYKWQQsaQ73BairEOwV6kuy5KPAPdkUQ+Kt6hKptZ3oo23vMHf1t9i9k0EiVFYYSk45IEO8LWFUF4xuLKZHWWQ7hcWIt0I9D0FYtY2U9OwlI41mO6FGLfhYx/tWCPh0WysA4W/ud3RXUR1X47uLugzeAowxCR2m03nSznmmokViNmLuA=
X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4492; 6:Czj8rh+lTdSnrAyWN/MM/uPIRO8RGZxpQN9V+J4Mo7gx6CAmHWyTgyLOkXGSCG4K6HrsKdMNex/KLIU/jIZEw+KC8lGj11VwQznERS2yqQrAwiPHl/fdC74KzeIA1VbjDe+XWeoJMkr2hRcQ+0zHAc8oaPDFb9G2MKeKj1E1E51ROxVL3t5P3wl3grzMrPTAZqmGxage2sKph01uog+yQzWmAdo+XOxkPZ16xeVpYFrwpXoDWiO4++qgWd7gvFMgltlTuzgVAkKZNCmEK2j/7h8V/dyJQ+xEQG6KMHaX0OOM31gq1dDHDjEruobIF/GYHSRgG0w8BcVqFGTPaN26xrnS9/YJh6QSCi9QiFUe1sCZZj75viwHlj1F8tUiwTC+V8GZ6tMBMldYPRsSxh1BCsybX4uDMzFeIh9azL/yeDnQQCFhksrCioX2XBy8E47cLCgILnpDYBqDEmTxW9MKBg==; 5:FiGS1bI9Sn+/O1+bMYbDKAyyIx15hv0mSs/k/bUwe83I6NdYacLcchpntHWXNcDv80A+SsINVg6puW8+PaL9x91Ao8m+G1dIJIu10RaO6f9QMs9+kxuaSNbckhJpkLdrJJvV3ZddZpvEqWZVUjohBsHiWkmWzVwS0JXAxjSIacuRXFla2IyMvJZRh4Geop0ZXC9xW50mb8W6F9p6typvTA==; 7:YF4wmYvfDrDRytF6Aw7lzGgZ3W/tFd5KOv8CAW0755lLq+d2oSYiFDX1hcWwdlOK8FEV7lmQTKIYTd1y5CHtQFgOqXCS6eFERb/CuYNW+1XIbZfHZs2kuU/DNIh2oH/auQpCYSWZbgytJuDSjvJR0A==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2019 17:37:05.6647 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5da1e685-d73f-4f65-aff9-08d680903a71
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4492
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/EDECPUQOFXFAxgpZx6xk6CIfYqc>
Subject: Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 22 Jan 2019 17:37:15 -0000

On Tue, Jan 22, 2019 at 07:17:05AM +0000, Ali Sajassi (sajassi) wrote:
> 
> Benjamin,  Thanks for your review and your comments. Please refer to my comment resolution replies below marked with "AS>".
> 
> On 1/7/19, 9:17 AM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> 
>     Benjamin Kaduk has entered the following ballot position for
>     draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection
>     
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
>     
>     
>     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     for more information about IESG DISCUSS and COMMENT positions.
>     
>     
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/
>     
>     
>     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     Please be consistent about (non-)hyphenation of "VPLS A-D".
> 
> AS> Done.
>     
>     Is "MP2P" really an intended acronym (vs., e.g., P2MP)?  It does not appear
>     in https://www.rfc-editor.org/materials/abbrev.expansion.txt and is not
>     defined, even though P2MP is, and MP2P is used some 8 times in the
>     document.
> 
> AS> MP2P is the intended acronym and not P2MP. The term MP2P is used extensively in RFC 7432 which is the pre-requisite to this draft.

It seems very strange for this document to explicitly define P2MP but then
assume the reader will known MP2P via other means; I'd suggest adding the
definition here as well.

>     We probably need a definition and/or reference for "split-horizon".
> 
> AS>  Added references for it.
>     
>     Section 2
>     
>        6. The support of All-Active redundancy mode across both (PBB-)EVPN
>        PEs and (PBB-)VPLS PEs is outside the scope of this document.
>     
>     The claim (not quoted) of "seamless" integration seems to only hold if
>     All-Active redundancy mode is not in common use.  Is it?
> 
> AS>  All-Active redundancy is not applicable to VPLS and PBB-VPLS; therefore, when EVPN (or PBB-EVPN) want to seamless operate with VPLS (or PBB-VPLS), then they MUST operate in a redundancy mode that is applicable to VPLS (and PBB-VPLS). This redundancy mode is Single-Active.

Having this background stated in the document would have helped me; I'll
leave it to you whether or not it would be useful for the actual target
audience, though.

>     Section 3.1
>     
>                                                               In this case,
>        when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the
>        basis that it belongs to an unknown SAFI. [...]
>     
>     Is this "MUST" a new requirement imposed by this document, or a restatement
>     of an existing requirement from elsewhere?
> 
> AS> It is a new requirement.
>     
>     Section 3.2
>     
>     Please expand FEC on first usage (or define it in the terminology section).
>     
> AS> Added it to the terminology section.
> 
>     When we talk about "learned" C-MAC addresses from traffic on VPLS PWs and
>     injecting those MAC addresses into bridge tables, RIB/FIB tables, and
>     MAC-VRFs, are these learned C-MAC addresses coming from provider-owned
>     equipment or customer equipment?  Giving the customer the ability to inject
>     MAC addresses without verification would probably merit a closer look
>     (though I do note that the penultimate paragraph discusses the
>     non-propagation of the learned addresses over the control plane).
> 
> AS> The learned C-MAC addresses come from other Provider Edge devices (i.e., from provider-owned equipment)
>     
>     Section 3.4.2, 4.4.2
>     
>     My understanding was that P2MP (PBB-)EVPN tunnels are a well-understood thing, in
>     which case I would expect to see something more like "this document does
>     not modify the operation of multicast P2MP EVPN tunnels" than "outside the
>     scope of this document".
> 
> AS> The MAC learning procedure from P2MP tunnels and associate them with P2P PWs are more elaborate and then mixing them up with MP2P EVPN or P2MP tunnel in EVPN gets even more intricate. Furthermore, there were no such requirements from SPs. 

(To be clear, this was just a question about the wording and not the
technology.  So it is fine to leave the text as-is if you are happy with
it.)

>     Section 5
>     
>     Does the extra state that (PBB-)EVPN PEs need to maintain (i.e., both the
>     normal EVPN state and PWs to the VPLS PEs) pose any risk of DoS due to
>     resource exhaustion?
> 
> AS> The number of resources used,  is basically a function of the number of PEs in a VPN. This number can be divided between EVPN PEs and VPLS PEs without much impact (if any) on resource consumption. 

Okay, thank you.

-Benjamin