Re: [bess] LxVPN and EVPN yang models
I agree with Stephane for the following suggestion, it will be great to see these three draft can factor out common building block or all augment from Network instance model separately, without any dependency on each other? Factoring out common building block will be a good approach, one a good example is resolve dependency between TEAS topology model and TE tunnel model, to move TE topo forward, common TE type have been factored out. All Augment from Network instance model without dependency also make sense to me. I want to hear authors’ feedback on the above two proposed approaches. -Qin 发件人: BESS [mailto:bess-boun...@ietf.org] 代表 stephane.litkow...@orange.com 发送时间: 2018年10月22日 20:29 收件人: draft-ietf-bess-evpn-y...@ietf.org; draft-ietf-bess-l2vpn-y...@ietf.org; draft-ietf-bess-l3vpn-y...@ietf.org 抄送: bess@ietf.org 主题: [bess] 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. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Revew of draft-ietf-bess-evpn-yang-07
Hi, folks: Have a quick review of draft-ietf-bess-evpn-yang-07, I am confused about EVPN adding dependency to L2VPN YANG. A few quick comments as follows: 1. Section 1, last paragraph: Try to understand the relation between L2VPN YANG and EVPN YANG. Is ethernet-segment model is specific to EVPN? It looks Ethernet segment can also be used to model pseudowire which is defined in L2VPN model? Is L2VPN model a base model while EVPN model is extension to L2VPN model? If this is true, can we move etherent-segment model into L2VPN model draft and consolidate with pseudowire model? 2. Section 1, last paragraph said: "That interface can be a physical interface, a bundle interface or virtual interface. The latter includes attachment-circuit and pseudowire. " What does the latter refer to? Bundle interface or virtual interface or both 3. Section 3.3 module ietf-evpn If EVPN model is extension to L2VPN model, I believe these common attributes should be moved to L2VPN model draft? Make sense? Also It will be great to align with ietf-bgp-l3vpn, change the name into ietf-bgp-evpn 4. Section 3.3, schema tree Why bgp-parameters are repeated in both ietf-evpn or Ethernet-segment? Is there any rationale behind? Not sure vpls-constraint attribute is specific to EVPN? Why not define it in the L3VPN model draft? Confusing the relationship between L2VPN and EVPN. I would suggest both L2VPN and EVPN augment from Network Instance model and add L2VPN and EVPN specific parameters to address this confusion. -Qin ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping
Hi, We have a good amount of support. This draft is adopted as a WG document. Authors, Please republish the document with -ietf- v00. Thanks, From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.com Sent: Tuesday, May 07, 2019 09:37 To: bess@ietf.org Subject: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping Hi, This email begins a two-week poll for adoption of draft-jain-bess-evpn-lsp-ping-08[1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 21th May 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/ _ 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. _ 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. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
