[bess] [BESS] A few comments on draft-ietf-bess-evpn-yang-07

<wang.yubao2@zte.com.cn> Wed, 15 May 2019 01:50 UTC

Return-Path: <wang.yubao2@zte.com.cn>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5C08E1201D8 for <bess@ietfa.amsl.com>; Tue, 14 May 2019 18:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6lCNXvhDjvfK for <bess@ietfa.amsl.com>; Tue, 14 May 2019 18:50:46 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn []) (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 BCE88120088 for <bess@ietf.org>; Tue, 14 May 2019 18:50:45 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown []) by Forcepoint Email with ESMTPS id 801388DD61D26559EFED; Wed, 15 May 2019 09:50:42 +0800 (CST)
Received: from njxapp04.zte.com.cn ([]) by mse-fl1.zte.com.cn with SMTP id x4F1oacI043881; Wed, 15 May 2019 09:50:36 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Wed, 15 May 2019 09:50:36 +0800 (CST)
Date: Wed, 15 May 2019 09:50:36 +0800
X-Zmail-TransId: 2afc5cdb706c6e39ad51
X-Mailer: Zmail v1.0
Message-ID: <201905150950361427390@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: bess@ietf.org, pbrisset@cisco.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn x4F1oacI043881
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/U4pJrbVyfqLdgjMpf7JYOvChFMM>
Subject: [bess] [BESS] A few comments on draft-ietf-bess-evpn-yang-07
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: Wed, 15 May 2019 01:50:49 -0000

Hi everyone,

1) I think the choice node named "ac-or-pw" gives up the probability to support vES and I-ESI

       +--rw ethernet-segments

          +--rw ethernet-segment* [name]

             +--rw (ac-or-pw)?

             |  +--:(ac)

             |  |  +--rw ac*                            if:interface-ref

             |  +--:(pw)

             |     +--rw pw*                           pw:pseudowire-ref

  So I think it will be better to rename the node to "es-forms" or something else .

  I think the "pw" case is a form of vES yet. but there are other forms of vES.

  I think it will be a bit weird to take one form of vES into consideration and ignore the other forms.

  Even if the other forms of vES would not be added in the near future, I think it will be better to name it with a neutral phrase that will not conflict with future extensions. 

2) The PBB Source B-MAC for zero-ESI is forced to be configured per-EVI-basis according to its current version,

  but RFC7623 says that "The PE may use a shared B-MAC address for all its single-homed segments and/or all its multi-homed Single-Active segments (e.g.,segments operating in per-I-SID load-balancing mode)". 

  So I think a PBB source B-MAC per PE should be added. because it is typically not necessary to assign a unique B-MAC to each EVI.

Best Regards,