[bess] Comments on draft-ietf-bess-evpn-yang-07

Yu Tianpeng <yutianpeng.ietf@gmail.com> Fri, 29 March 2019 18:47 UTC

Return-Path: <yutianpeng.ietf@gmail.com>
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 0E5DA1202E1; Fri, 29 Mar 2019 11:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E7VA8SIbtXED; Fri, 29 Mar 2019 11:47:34 -0700 (PDT)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5D3120285; Fri, 29 Mar 2019 11:47:34 -0700 (PDT)
Received: by mail-it1-x130.google.com with SMTP id y63so5462879itb.5; Fri, 29 Mar 2019 11:47:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=ygDzYs+OgqkecWLtkZHn0b7gik7MmuFuShX5Kop45zo=; b=RtwqVrZTVi+ng8mHvih5Z9VGkRdKkwvWBuRUbPg5fumbYnswz37MWpFpEqpKu9Z9CB bNNFJ7IEDbCNOBJZescpeeMtEbTTl7vFDdAdtQwkz0RGf+QZA/X1MseDVVybIsuMMjWC XdzlaH6yCaHsP7oGYsqQJBH/G7AwpcD78v3edE3TYzueK88yKT5+CXgYEwg7WbbnWqez JKugy6Ia8B00hk66AjzNlsUfmwDW26evAcFmmlhOjVCbwWdJifvaZMng13SS1BSRMs25 Y5wplnAefrcamsR3FEfdsBcRFSXkCvGBwaM+yoVhpm/B27DCWytyrEtKo/c7EvLLPvMF papQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ygDzYs+OgqkecWLtkZHn0b7gik7MmuFuShX5Kop45zo=; b=MRq3gzFdtj690aOCuwQFm/5MQ+MeNi6b0U7M/kvBYau1SNMomQKWpth7YnWcMb8pae Hjtq8g9sXvWREPKgmuMkmCkq+/PwllNuDwIhmyWhX9KTKSu2SV0mIVhLUMzIZb2erlAp +dbeMx9cU13PBxgZBe6bTM3Fu+1bJGMBlLXqZfOXQ9e5UyaQ63URxqGVKoywhpxIPhZ9 My/FZTwJbgGyCcYMLIihnGAE+pGFOaW1nv2UY36Z6Tc3WvU+sbq8qXAQAKtUbNHp0oCR +BFtWW4722iwUBActGF77gIhFq+pGWpToApnsuWadpsvlxKn0nqdKINT2Guou0G0XUoQ 8W8g==
X-Gm-Message-State: APjAAAWBWNbP2ZuMLryPSwNS33qIjgm1Sy0ZOn3dW9J6ExQ7oDnbQFRs fTXS+NDqolLGxzAAsi38RZ6xtrC58EH/FnWsW6A=
X-Google-Smtp-Source: APXvYqx/6cls0IfNPMGs4nbDW6nRR56rp3jsXXBCs9wtlGOdPG9vxceWqc7joxpOUVeoOTGHsxD71fwR8lKL7Qcj/eQ=
X-Received: by 2002:a02:c4c8:: with SMTP id h8mr37792958jaj.33.1553885253742; Fri, 29 Mar 2019 11:47:33 -0700 (PDT)
MIME-Version: 1.0
From: Yu Tianpeng <yutianpeng.ietf@gmail.com>
Date: Fri, 29 Mar 2019 18:47:22 +0000
Message-ID: <CAKFJ8epuVZYK_aC5Gf8ZUA9a=tU4Nv=h4Z6AQqF7P5xA-mCh_g@mail.gmail.com>
To: "Patrice Brissette (pbrisset)" <pbrisset@cisco.com>
Cc: draft-ietf-bess-evpn-yang@ietf.org, bess@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009237b70585401ab4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/gwhh4x5-9LVWu0VSo32ygRElMUQ>
Subject: [bess] 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: Fri, 29 Mar 2019 18:47:39 -0000

Hi authors,
Thanks a lot for the -07 version of EVPN yang, which fixes many points ever
raised in the mail list also some we did not notice. This version moves
this document a big step forward.
Thanks for the presentation and update in 104 also.

Related with the  P-tunnel been discussed before, I think there are two
points to fix:
1. Current version lacks a definition of P-tunnel type in inclusive
multicast ethernet tag route (for route query only, read only), raised by
Sasha initially.
It may be fixed in this way, Import the "typedef p-tunnel" defined in
draft-ietf-bess-mvpn-yang-01, and add a leaf called tunnel-type in
inclusive multicast ethernet tag route.
2. Related with the place to configure IR or P2MP, since P-tunnel is a
concept per EVI basis, I would suggest moving this into evpn-instances.
And this leaf is read+write.

And I had a line-by-line read again before LC starts, and there are some
comments as below (Probably a long list.. I hope most of them not issues or
can be fixed easily).

Appreciate if the authors could have a look.

Thanks in advance.


ethernet-segment yang

1. the key of "container ethernet-segments" is "name", should not it be
I have no clue how to fill the name field TBH, does it mean "interface"? If
so it should be read-only I suppose.  If no, where is the mount point to

2. service-type, what does it mean?? Does it mean vlan-based, vlan-bundle,
vlan-aware-bundle? If so why there is "vpws-vlan-aware" in evpn yang..

3. related with leaf "ac-or-pw"
I would suggest to use evc instead of ac as it is quite confusing. Also in
vES draft it is using evc.
And for ac, it is the interface that bound to the evi, right? What if the
es is not ves, can I fill in the interface with physical interface? If no,
we may need another leaf indicating the interface for ES.

4. vlan in leaf df, please add range restriction and use uint16. This is
aligned with many yang modules already standardised

5. leaf esi-label, it should have been covered by evpn route in evpn yang
right?  this is the label in ESI Label Extended Community right?
And if I look at evpn yang, the Extended community is defined to be a raw
Also, I cannot see e-tree label.. and I cannot find the bit saying this ES
is leaf of etree or not..
TBH I have concerns on if a raw string is a proper way to reflect all
extended communities

6. leaf ead-evi-route: similarly, this is Aliasing right? Is es or evpn
yang the better place to put this function?

7. In es yang: what is the meaning of member, which is an IP address?  Is
it the router-id of the device? Please add some description here.

1. Counters I would suggest to use counter64 instead of counter 32,
counter32 is too likely to get overflowed.

2. Control word function defined in 7432 is not included (VPWS one should
be fine as it is mounted to l2vpn pw yang, i suppose).

3. leaf vpws-vlan-aware looks abrupt to me in evpn yang... what is it used

4. leaf bestpath in path-detail-grp in evpn yang should use boolean instead
of empty. I suppose?

5. related with statistics, this is a sum of the counter of all interfaces
bound to the corresponding EVI right? Please add a bit description on this
if possible..

6. Related with the mount point of EVPN VPWS, only a container called
"evpn-pw" is defined? I am not sure how many functions being missed in EVPN
VPWS tbh... In my mind so far:
no EAD route query,
no statistics
rd-rt info..?
Also we may need to exclude some leaf from pw yang for evpn vpws