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

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

Date: Wed, 15 May 2019 09:50:36 +0800
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====="
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/U4pJrbVyfqLdgjMpf7JYOvChFMM>
Subject: [bess] [BESS] A few comments on draft-ietf-bess-evpn-yang-07
Precedence: list

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,


Bob

[bess] [BESS] A few comments on draft-ietf-bess-e… wang.yubao2