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

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Tue, 22 January 2019 07:17 UTC

Return-Path: <sajassi@cisco.com>
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 2BDBC12D84C; Mon, 21 Jan 2019 23:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.053
X-Spam-Level:
X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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
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 hWu74X6VQc_I; Mon, 21 Jan 2019 23:17:08 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB16128D52; Mon, 21 Jan 2019 23:17:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6052; q=dns/txt; s=iport; t=1548141428; x=1549351028; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CSFEOegZQ043CWfBLLEAImFETY5n3B+gaUWf8T/BcOI=; b=FtIJbceArXTOMlEfRzSlVIy4INVJc7TazPZzd5sHSrP21WPKo7b62UFh peJ4/K4SwqU4q+skSfT9p0W0GRbmPeLRUQSG/rT4TI5gEZGan7XMcb1SD p+KUxnp5Z8uA3VRFP8HUiyAk+kkKpLPERWHQgdvYxRfkgF0G7jIGMV33u Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACDwkZc/5BdJa1kDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYFVLmaBAicKg3eIGotnmg4UgWcLAQE?= =?us-ascii?q?lhEcCF4JMIjQJDQEDAQECAQECbRwMhUsGIxE5DBACAQgaAiYCAgIwFRACBAE?= =?us-ascii?q?NBYMiAYIBD6w1gS+EQkGFHgWBC4s2F4F/gRABJx+CTIMeAgECAYEqARIBgyg?= =?us-ascii?q?xgiYCiWWXZlUJAociincYgWaFLosAigSFHItWAhEUgScfOGVYEQhwFWUBgkG?= =?us-ascii?q?CLBITiEyFBDtBMQEBiEmBH4EfAQE?=
X-IronPort-AV: E=Sophos;i="5.56,505,1539648000"; d="scan'208";a="228928950"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2019 07:17:06 +0000
Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x0M7H6ue021198 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Jan 2019 07:17:06 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 22 Jan 2019 02:17:05 -0500
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1395.000; Tue, 22 Jan 2019 02:17:05 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "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>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)
Thread-Index: AQHUpqzucqDThd8FvE2qpZr/pGZFxqW6xU4A
Date: Tue, 22 Jan 2019 07:17:05 +0000
Message-ID: <B55A7785-E8FC-4AC0-A719-43B09041F386@cisco.com>
References: <154688146371.23228.11253231358362119768.idtracker@ietfa.amsl.com>
In-Reply-To: <154688146371.23228.11253231358362119768.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.6.190114
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.87.48]
Content-Type: text/plain; charset="utf-8"
Content-ID: <DC6896E51ED4DE43B8BFC4FEA034A3A2@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.143, xch-rtp-003.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/zQrVuP22yb8v8ZY5cT4C55pc6t0>
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 07:17:10 -0000

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.
    
    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.
    
    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. 
    
    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. 
    
   
Regards,
Ali