Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT)

"Acee Lindem (acee)" <acee@cisco.com> Fri, 07 April 2017 22:58 UTC

Return-Path: <acee@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 4CBD7129469; Fri, 7 Apr 2017 15:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 sNV8Jy_1RBiJ; Fri, 7 Apr 2017 15:58:32 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F847129490; Fri, 7 Apr 2017 15:57:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3648; q=dns/txt; s=iport; t=1491605872; x=1492815472; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=spHySaT9dfOTQd+ddDMpf6uRIM0vipJCrB+W4bDjo4U=; b=GQzen/a/zWQaNC0LCfCI3Juz7pu8vE/TsNpUR89NiqZ0oLCpOp6opNoB gN6R2Xzqg/7DDQpbZYM4yaOoX/52R85sN3Mvq4v87rZrFLLzAWlZceveh HGOxumsXWqXEbfvuV+DngDme24JxMfjg00i7H8kpOGaqvkaPpocXllyXo o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAQAGGehY/5pdJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1NhgQsHjXKZXo09gg8fC4V4AoNePxgBAgEBAQEBAQFrKIUWAgEDAQE4NAsQAgEINhAhBgslAgQBDQWJdwMVDqx7hzENgy0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYs+glGBVxEBToUzBYklBZMTOwGGf4cchDyBfoUuihSLAIh+AR84fQhbFUGEWx0ZgUp1AYcKgSGBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.37,168,1488844800"; d="scan'208";a="408546456"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 22:57:51 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v37MvpoG031349 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 22:57:51 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Apr 2017 18:57:50 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 7 Apr 2017 18:57:50 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "zzhang@juniper.net" <zzhang@juniper.net>, "draft-ietf-bess-evpn-vpws@ietf.org" <draft-ietf-bess-evpn-vpws@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>
Thread-Topic: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT)
Thread-Index: AQHSr+iG6cNaUXQKF0uToizt/aKp+qG6hOyA
Date: Fri, 07 Apr 2017 22:57:50 +0000
Message-ID: <D50D912F.A7E71%acee@cisco.com>
References: <149160161083.11232.11409617444161707051.idtracker@ietfa.amsl.com>
In-Reply-To: <149160161083.11232.11409617444161707051.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.197]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CB1BB79AB3E7A34CA7A5442BE1A8432A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/3EVj5NTIDX5NBVb0Xtou7VCEUJA>
Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT)
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: Fri, 07 Apr 2017 22:58:36 -0000

Hi Spencer, 

On 4/7/17, 5:46 PM, "BESS on behalf of Spencer Dawkins"
<bess-bounces@ietf.org on behalf of spencerdawkins.ietf@gmail.com> wrote:

>Spencer Dawkins has entered the following ballot position for
>draft-ietf-bess-evpn-vpws-11: 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-vpws/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>I did have some non-Discuss questions that you might wish to think about
>before the document is approved ...
>
>In the Abstract
>
>   This document describes how EVPN can be used to support Virtual
>   Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the
>   following characteristics for VPWS: single-active as well as all-
>   active multi-homing with flow-based load-balancing, eliminates the
>   need for traditional way of Pseudowire (PW) signaling, and provides
>   fast protection convergence upon node or link failure.
>
>everything is exceptionally clear, except that I don't know what the
>"traditional way" of signaling means.
>
>The same phrase appears in Section 1  Introduction
>
>   This document describes how EVPN can be used to support Virtual
>   Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN
>   mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to P2P
>   services. These benefits include single-active redundancy as well as
>   all-active redundancy with flow-based load-balancing. Furthermore,
>   the use of EVPN for VPWS eliminates the need for traditional way of
>   PW signaling for P2P Ethernet services, as described in section 4.
>
>with the addition of "as described in section 4", but I didn't see an
>explicit statement in Section 4 that explained what was replacing the
>"traditional way". Even a clear reference to an RFC where the
>"traditional way" was defined would be helpful.
>
>It would probably be helpful to expand acronums like "P2P" on first use.
>I immediately thought "peer to peer?" but I bet you didn't mean that.
>Yes, there's a terminology section, but it's three and a half pages into
>the document.
>
>In this text, 
>
>   For EVPL service,
>   the Ethernet frames transported over an MPLS/IP network SHOULD
>remain
>                                                           ^^^^^^
>   tagged with the originating VLAN-ID (VID) and any VID translation
>   MUST be performed at the disposition PE.
>
>why is this a SHOULD? I guess my first question should be "does this
>still work if you don't?"
>
>In this text,
>
>   In multihoming scenarios, both B and P flags MUST NOT be both set.


> 
>
>the double both(s) made this difficult to parse. Is it saying
>
>   In multihoming scenarios, the B and P flags MUST be cleared.
>
>or something else? But I'm guessing, and the rest of that paragraph made
>me doubt my guesses.

I think it is clear that it means they are mutually exclusive.

Thanks,
Acee (Routing Directorate Reviewer of this draft)
>
>
>_______________________________________________
>BESS mailing list
>BESS@ietf.org
>https://www.ietf.org/mailman/listinfo/bess