[cmaster-next] Technical Meeting Agenda
1) Status 2) Branching Discussion 3) CAP-N-PROTO email 3) RD/RT 4) EVPN Is there anything else that people would like to discuss? donald
Yes, 5) handling changes in coding conventions - yes this is prompted by the guarded debug logging discussion. Lou On 12/5/2016 8:21 AM, Donald Sharp wrote:
1) Status 2) Branching Discussion 3) CAP-N-PROTO email 3) RD/RT 4) EVPN
Is there anything else that people would like to discuss?
donald
_______________________________________________ cmaster-next mailing list cmaster-next@lists.nox.tf https://lists.nox.tf/listinfo/cmaster-next
Hello, I added in point 3) Capnproto, 3)RD/RT and 4)EVPN some precisions. On Mon, Dec 5, 2016 at 2:34 PM, Lou Berger <lberger@labn.net> wrote:
Yes,
5) handling changes in coding conventions - yes this is prompted by the guarded debug logging discussion.
Lou
On 12/5/2016 8:21 AM, Donald Sharp wrote:
1) Status 2) Branching Discussion 3) CAP-N-PROTO email
https://lists.quagga.net/pipermail/quagga-dev/2016-December/016510.html
3) RD/RT
o RD/RT config impementation review https://lists.quagga.net/pipermail/quagga-dev/2016-December/016504.html o I had a question about network command under bgp vrf subnode. It does the same as if I was using network under address-family subnode. I mean it creates an entry in global RIB. Right ? If yes, then I suppose that the BGP daemon can be configured with 2 addresses families. Let's suppose EVPN and VPNv4. So, does that mean that the command is applied to both families ?
4) EVPN
By looking deeper at EVPN implementation from Cumulus. I have some remarks: - about the way to configure the VNI. I think it could be possible to append vni configuiration into bgp vrf subnode. Like that, it should be possible to have automatic values configured ( by vni value), or setting the wished values. This would permit from benefiting from current vrf implementation ( multiple import export communities instead of one). Whatever, the automatic mecanism to get import RT and RD is good to keep. - about prefix impact, I see that the vni ID is kept in prefix.h. If we want to have an EVPN implementation that works for MPLs and VXLan, it should be better to use eth_tag instead ( defined by rfc7432). - about the creation of entries, all MAC-only entries are derived from information retrieved by Zebra. Unless unnoticed, is there a way to configure an entry by using vty command. Based on this assumption, what about following proposal of adding a RT2 set command EVPN RT2 support + RouterMAC BGP extended community network A.B.C.D rd ASN:nn_or_IP-address:nn ethtag WORD mac WORD esi WORD l2label WORD l3label WORD routermac WORD Best Regards, Philippe
1) Status - Still working towards 2.0. We believe we are at a point where bug fixes are only allowed( caveat a couple of fixes for Martin's Snaproute I believe ) 2) Branching Discussion master is the branch new development should be worked on. The real discussion about how to handle auto-merging is being delayed till next weeks meeting. 3) CAP-N-PROTO Yes we would welcome this change in the code. 4) RD/RT Vivek counter-proposed a new option #7 and a modified #6. Have been placed in the document. Additionally Vivek or Donald will send email with details of proposal to alias 5) EVPN Some discussion between Vivek and Philippe about approach. Further discussion needed on alias 6) Changes in Coding Conventions Donald to modify hacking doc to discuss debug guards Lou to provide patch to bgp/rfapi code to guard debugs. donald On Mon, Dec 5, 2016 at 8:21 AM, Donald Sharp <sharpd@cumulusnetworks.com> wrote:
1) Status 2) Branching Discussion 3) CAP-N-PROTO email 3) RD/RT 4) EVPN
Is there anything else that people would like to discuss?
donald
participants (3)
-
Donald Sharp -
Lou Berger -
Philippe Guibert