Re: [bess] LxVPN and EVPN yang models

[Lizhenbin <[e-mail]>]

Hi Stephane,
These comments truly make sense. There should be more synchronization and consistency between these Yang models. And during the course of design of different Yang models,
Patrice and other team members proposed to define the common VPN Yang components shared between different Yang models as an independent draft. We will try to
synchronize the LxVPN and EVPN yang models and work out how to abstract the common modules reused across all models.


Best Regards,
Robin


From: [e-mail] [mailto:[e-mail]]
Sent: Monday, October 22, 2018 8:29 PM
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: LxVPN and EVPN yang models

Hi Authors,


Speaking as individual, after reading the last versions of your module, I still have several concerns about the consistency of the modeling across all models.
There are common components between all the models that could be shared or at least modeled in the same way:

-          Model name: L3VPN uses ietf-bgp-l3vpn while others use ietf-evpn or ietf-l2vpn

-          Route-target import/export and route-distinguisher:

o   Under bgp-parameters/common/rd-rt/ for EVPN

o   Under bgp-auto-discovery for L2VPN (that could make sense here but it is weird in term of config consistency => maybe better to have a bgp-auto-discovery Boolean or maybe the discovery-type is enough to know that bgp-auto-discovery is used ?)

o   Under ipv4 or ipv6 for l3vpn RTs but rd is at top level. That could make sense but again the configuration is slightly different from other AFI/SAFIs. Having different imp/exp for IPv4 and IPv6 is a valid use case, but you should also allow to have the same config for both without defining per AFI/SAFI config.

-          RIB route limits could also be modeled the same way

-          Modelization of route entries in the RIB could be modeled in the same way across model

-          Attachment to the NI:

o   I don't understand how EVPN is integrated in L2VPN. It seems that you add a pointer (reference) to an EVPN instance which is in a completely different tree. That looks really strange and make EVPN instance configuration completely different from an L3VPN instance or L2VPN instance. Do you plan to reuse the config parameters from L2VPN or do you prefer creating a completely different tree ? If you prefer a completely different tree why not creating an EVPN ni-type ?


Can't we have one model defining some bgp-vpn containers possibly as a separate module that could be reused across all models ?

Happy to hear your feedback.

Brgds,

Stephane


_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.