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

[Yu Tianpeng <[e-mail]>]

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

##########################

ethernet-segment yang

1. the key of "container ethernet-segments" is "name", should not it be
ESI?
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
interface...

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
string.....
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.


evpn.yang
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
for?

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