[quagga-dev 15498] Re: Quagga Release Process Meeting Notes

[Martin Winter]

The Tools doc is set to “View” only. Please someone change to allow 
access for

(at least) comments.

- Martin

On 8 Jun 2016, at 6:02, Donald Sharp wrote:


All -

I'd like to close up feedback on the documents by Monday June 13.  
Please

take a few minutes to read the documents and provide some feedback.

thanks!

donald

On Mon, Jun 6, 2016 at 3:09 PM, Donald Sharp 


wrote:


Tools Document:


https://docs.google.com/document/d/1s_EbbXwqWPmfOg6ArgKmEMm_iv0vwGvJs-7ZG4yFKb4/edit?usp=sharing

Maintainer Document:


https://docs.google.com/document/d/19DZcT0cJUSYxVIFenHvGFhLLUmLTRFHuMNZcI7aUNGA/edit?usp=sharing

If you have feedback, please take the time to edit the documents.

thanks!

donald

On Thu, Jun 2, 2016 at 12:43 PM, Donald Sharp 


wrote:


Document is here:


https://docs.google.com/document/d/1xYrpTKYDvK23BCxXP-dbE6nOuvBxbGIilNLfVkI3j-I/edit

Meeting Notes:

Section 2:
  n == 6 months, let's start w/ 6 and adjust later

Discussion around YE and what it should be named.

Are YE and CE released at the same time?  The are released at 
separate

times.

Can we make the first release sooner than 6 months from now?  TBD, 
but

interest from multiple parties in doing so.

Section 3:

Martin - Pull requests for github should be handled this week.

How do the releases relate to each other?  Not sure if it is a 
problem.

Keep numbering disconnected since we don't currently have CE and YE
connected?

Section 4 and 9 - To be made into it's own document.  Olivier to 
head up

writing this document.

Section 5:

CE and YE maintainers separate?  No!

Need a set of Maintainers more than 3 that is 'reasonable'.  
Maintainer
Document under separate process, Martin taking lead on this 
document.


Maintainers have the vote, simple majority.  They have a week after
meeting to voice their opinion.  Meeting notes or recording must be 
made

available.

Section 6:

May need to be refined in the future.

Donald, Jafar, Martin, Olivier and Balaji recommend to move forward 
with

this document.

Lou can you express your opinion about moving forward since you had 
to

drop off a bit early?

Would anyone else like to express their opinion about moving 
forward?

I'd like to finish up this discussion by next Thursday the 9th.

thanks!

donald






___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15497] Re: Round 8

[Jafar Al-Gharaibeh]

On 6/8/2016 4:39 PM, Martin Winter wrote:

On 8 Jun 2016, at 8:10, Jafar Al-Gharaibeh wrote:

On 6/8/2016 9:13 AM, Paul Jakma wrote:

On Wed, 8 Jun 2016, Martin Winter wrote:

So even in a set of 4 patches, I would test patch 1, patch 1+2, 
patch 1+2+3 and finally patch 1+2+3+4 ?



Or test each on it’s own?


The former would be enough I think. The latter would discourage 
breaking up patches into easier to review 'stories'.


I agree. In most cases there will be dependency between a series of 
patches where each one may depend on previous patches in the series. 
This would leave the developer no choice but to lump the whole thing 
together as Paul pointed out.


Ok, if everyone agrees, I can just modify my CI system to 
automatically break the a series in these steps
and run them this way (and have an email reply sent for each of these 
combination, so a reply to 1/4 with
result of just patch 1, a reply to 2/4 with result of 1+2, reply to 
3/4 with 1+2+3 and reply to 4/4 with

result of the whole series.

Or is this borderline to spamming? (i.e. if someone sends a series of 
40, then there will be 40 replies)


Agreements? Or better suggestions?


 I'd say one summary email is probably better. If all patches pass then 
that is all we need to know. If a patch fails an email is sent for that 
specific patch, and I assume the test stops there, right?


--Jafar





Also, if we decide for me to automatically commit it to some 
“proposed” (or whatever the name is)

branch, then I would only commit it there if every test is successful?

- Martin

If you want me to try this, then suggest something (i.e. name of 
accumulating branch?) and I can give it a try.


'proposed'?

regards,


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15496] Re: Round 8

[Martin Winter]

On 8 Jun 2016, at 7:13, Paul Jakma wrote:


On Wed, 8 Jun 2016, Martin Winter wrote:

So even in a set of 4 patches, I would test patch 1, patch 1+2, patch 
1+2+3 and finally patch 1+2+3+4 ?



Or test each on it’s own?


The former would be enough I think. The latter would discourage 
breaking up patches into easier to review 'stories'.


If you want me to try this, then suggest something (i.e. name of 
accumulating branch?) and I can give it a try.


'proposed'?


Do you suggest the current proposed or a special proposed branch for the 
CI system?


If we decide with the “proposed” tree workflow, then I’m not sure 
if this should be a different branch

and let some maintainer cherry-pick commits into the current proposed.

Having a dedicated branch for this would also be preferred for me as 
less risky in case my

scripts screw up :-)  (at least for a trial phase)

- Martin



regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
It's amazing how much better you feel once you've given up hope.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15495] Re: Round 8

[Martin Winter]

On 8 Jun 2016, at 8:10, Jafar Al-Gharaibeh wrote:

On 6/8/2016 9:13 AM, Paul Jakma wrote:

On Wed, 8 Jun 2016, Martin Winter wrote:

So even in a set of 4 patches, I would test patch 1, patch 1+2, 
patch 1+2+3 and finally patch 1+2+3+4 ?



Or test each on it’s own?


The former would be enough I think. The latter would discourage 
breaking up patches into easier to review 'stories'.


I agree. In most cases there will be dependency between a series of 
patches where each one may depend on previous patches in the series. 
This would leave the developer no choice but to lump the whole thing 
together as Paul pointed out.


Ok, if everyone agrees, I can just modify my CI system to automatically 
break the a series in these steps
and run them this way (and have an email reply sent for each of these 
combination, so a reply to 1/4 with
result of just patch 1, a reply to 2/4 with result of 1+2, reply to 3/4 
with 1+2+3 and reply to 4/4 with

result of the whole series.

Or is this borderline to spamming? (i.e. if someone sends a series of 
40, then there will be 40 replies)


Agreements? Or better suggestions?

Also, if we decide for me to automatically commit it to some 
“proposed” (or whatever the name is)

branch, then I would only commit it there if every test is successful?

- Martin

If you want me to try this, then suggest something (i.e. name of 
accumulating branch?) and I can give it a try.


'proposed'?

regards,


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15494] Re: [PATCH 10/10] bgpd: add L3/L2VPN Virtual Network Control feature

[Lou Berger]

Philippe,

see below.

On 6/8/2016 1:55 PM, Philippe Guibert wrote:
> On Tue, May 17, 2016 at 1:10 PM, Lou Berger  wrote:
>
> Hi Lou,
>
>> This feature adds an L3 & L2 VPN application that makes use of the VPN
>> and Encap SAFIs.  This code is currently used to support IETF NVO3 style
>> operation.  In NVO3 terminology it provides the Network Virtualization
>> Authority (NVA) and the ability to import/export IP prefixes and MAC
>> addresses from Network Virtualization Edges (NVEs).  The code supports
>> per-NVE tables.
>>
>> The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
>> (L2) forwarding information between NVAs and NVEs is referred to as the
>> Remote Forwarder Protocol (RFP). OpenFlow is an example RFP.  RFPs are
>> integrated with BGP via the RF API contained in the new "rfapi" BGP
>> sub-directory.  Currently, only a simple example RFP is included in
>> Quagga. Developers may use this example as a starting point to integrate
>> Quagga with an RFP of their choosing, e.g., OpenFlow.  The RFAPI code
>> also supports the ability import/export of routing information
>> between VNC and customer edge routers (CEs) operating within a virtual
>> network. Import/export may take place between BGP views or to the
>> default zebra VRF.
>>
>> BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
>> information between NVAs. BGP based IP VPN support is defined in
>> RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
>> BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
>> of both the Encapsulation Subsequent Address Family Identifier (SAFI)
>> and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
>> Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
>> Encapsulation Attribute, are supported. The code is tunnely type
>> agnostic. MAC address distribution does not follow any standard BGB
>> encoding, although it was inspired by the early IETF EVPN concepts.
>> The intent is that the RF API would not need to change with support
>> of standards-based EVPN.
>>
>> The feature is conditionally compiled and disabled by default.
>> Use the --enable-bgp-vnc configure option to enable.
>>
>> The majority of this code was authored by G. Paul Ziemba
>> .
> After having played a bit with vnc, and looking at the code, it is
> really nice to see IP prefixes and MAC addresses exchanged between NVAs
> and/or between VNCs.
>
> I have however some comments:
>
> * It seems the RD_TYPE_EOI type surfaced again (see
>   http://patchwork.quagga.net/patch/1728/ ), whereas I don't see where it
>   is used. Is there a need to keep this flag ?
This is used by the ethernet code, see below.

>
> * Is it still relevant to keep HAVE_IPV6 flag ? The IPV6 flag has been
>   recently removed from quagga mainstream, as in 205e6744f2dc - bgpd:
>   remove HAVE_IPV6 conditionals.
No we can drop that.

> * My doubt is about MAC address distribution. since the way the
>   messages are carried is inherited from old EVPN draft (I don't know
>   which one ?), which is not what is present in RFC7432.

> ** For instance, RFC7432 uses new afi/safi, whereas the implementation
>reuses current ENCAP and MPLSVPN safi. 

you're analysis confirms what we said in the submission:
>
>> MAC address distribution does not follow any standard BGB
>> encoding, although it was inspired by the early IETF EVPN concepts.



> Will the internal call procedure
>be easy to change ?
We believe so.

> ** The naming convention will change. Hence, I wonder if the rfp API
>will change, because of that (ETHERNET segment id may replace logical
>net id ?).
Our expectation is that rfapi (rfapi.h) will not need to change when the
swap is made to fully standard EVPN.
 
> ** Less problematic, but present is the rework to be done if EVPN is
>ported.
Do you have an EVPN implementation to port?  If not, I don't believe one
yet exists, and it'll be radically easier to implement based on our code
vs starting from scratch.  Now if someone has an existing implementation
of EVPN (beyond RR SAFI support), this would be a different discussion.

>  I understand there may be a huge number of lines to rework ?
Yes, there are significant section of bgpd/rfapi that will need to
change, but not the interface or rfapi.h.

>bgpd# grep SAFI_MPLS_VPN rfapi/* | wc -l
>84
>bgpd#grep SAFI_ENCAP rfapi/* | wc -l
>3

> My main concern is about MAC address distribution concern. This is the
> reason why I would nack the patch.
> Maybe it could be interesting to brace the relevant code with #ifdef
> DRAFT_EVPN_XXX / #endif /* #ifdef DRAFT_EVPN_XXX */ so as to better
> handle the standard from the non standard ?

It's certainly possible to break out the L2VPN code, but everyone we've
talked to about it has said they'd much prefer to have quagga have some
L2VPN capability than to wait for fully standard EVPN.

Either way (keep, drop, ifdef), we will 

[quagga-dev 15492] Re: [PATCH] bgpd: Squash spurious "unknown afi" log messages

[Philippe Guibert]

Hi Paul

On Wed, Apr 27, 2016 at 12:19 PM, Paul Jakma  wrote:
> * bgp_packet.c: (bgp_update_receive) doesn't differentiate between NLRIs that
>   are 0 AFI/SAFI cause they weren't set, and those because a peer sent a
>   bogus AFI/SAFI, before sending sending what may be a misleading, spurious
>   log message.  Check the .nlri pointer is set and avoid this.
>
> Incorporating a suggestion from: G. Paul Ziemba 
> ---
>  bgpd/bgp_packet.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/bgpd/bgp_packet.c b/bgpd/bgp_packet.c
> index 740b0f1..9cbb5b5 100644
> --- a/bgpd/bgp_packet.c
> +++ b/bgpd/bgp_packet.c
> @@ -1631,7 +1631,7 @@ bgp_update_receive (struct peer *peer, bgp_size_t size)
>  NLRI_TYPE_MAX,
>};
>struct bgp_nlri nlris[NLRI_TYPE_MAX];
> -
> +
>/* Status must be Established. */
>if (peer->status != Established)
>  {
> @@ -1645,6 +1645,7 @@ bgp_update_receive (struct peer *peer, bgp_size_t size)
>memset (, 0, sizeof (struct attr));
>memset (, 0, sizeof (struct attr_extra));
>memset (, 0, sizeof nlris);
> +
>attr.extra = 
>
>s = peer->ibuf;
> @@ -1781,6 +1782,8 @@ bgp_update_receive (struct peer *peer, bgp_size_t size)
>/* Parse any given NLRIs */
>for (i = NLRI_UPDATE; i < NLRI_TYPE_MAX; i++)
>  {
> +  if (!nlris[i].nlri) continue;
> +
>/* We use afi and safi as indices into tables and what not.  It would
> * be impossible, at this time, to support unknown afi/safis.  And
> * anyway, the peer needs to be configured to enable the afi/safi
> --
> 2.5.5
>
>
> ___
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev

Acked-by: Philippe Guibert 

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15491] Re: [PATCH] bgpd: bgp_update_receive ignores non present NLRI

[Philippe Guibert]

Hi Paul,

On Wed, Jun 8, 2016 at 4:08 PM, Paul Jakma  wrote:
> Hi Philippe,
>
> That should already be addressed by:
>
>   http://patchwork.quagga.net/patch/1921/
>

The patch 1921 fixes my issue.
Thanks.
So i nack my commit.

> It's not related to the packet really, just the code non-sensically giving a
> warning about AFIs/SAFIs that weren't sent. ;)
>
> On Wed, 8 Jun 2016, Philippe Guibert wrote:
>
>> Fixes 518a4b7eadcb "bgpd: Regularise bgp_update_receive,
>> add missing notifies and checks"
>> Error message "UPDATE with unsupported AFI/SAFI 0/0" is wrongly
>> displayed for a packet which does not have the matching NLRI entry.
>> The patch checks presence of nlri in bgp update message.
>
>
> regards,
> --
> Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
> Fortune:
> Everyone talks about apathy, but no one does anything about it.

Nacked-by: Philippe Guibert 

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15489] Re: Round 8

[Paul Jakma]

On Wed, 8 Jun 2016, Martin Winter wrote:

So even in a set of 4 patches, I would test patch 1, patch 1+2, patch 
1+2+3 and finally patch 1+2+3+4 ?



Or test each on it’s own?


The former would be enough I think. The latter would discourage breaking 
up patches into easier to review 'stories'.


If you want me to try this, then suggest something (i.e. name of 
accumulating branch?) and I can give it a try.


'proposed'?

regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
It's amazing how much better you feel once you've given up hope.___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15486] Re: [PATCH] bgpd: bgp_update_receive ignores non present NLRI

[Donald Sharp]

Should we have the opportunity to log something here if we receive this
error condition?

donald

On Wed, Jun 8, 2016 at 2:37 AM, Philippe Guibert  wrote:

> Fixes 518a4b7eadcb "bgpd: Regularise bgp_update_receive,
> add missing notifies and checks"
> Error message "UPDATE with unsupported AFI/SAFI 0/0" is wrongly
> displayed for a packet which does not have the matching NLRI entry.
> The patch checks presence of nlri in bgp update message.
>
> Signed-off-by: Philippe Guibert 
> ---
>  bgpd/bgp_packet.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/bgpd/bgp_packet.c b/bgpd/bgp_packet.c
> index 740b0f1ce603..601d39d1c1ad 100644
> --- a/bgpd/bgp_packet.c
> +++ b/bgpd/bgp_packet.c
> @@ -1781,6 +1781,14 @@ bgp_update_receive (struct peer *peer, bgp_size_t
> size)
>/* Parse any given NLRIs */
>for (i = NLRI_UPDATE; i < NLRI_TYPE_MAX; i++)
>  {
> +  /* ignore empty nlri entries */
> +  if ((i == NLRI_WITHDRAW) && (withdraw_len == 0))
> +continue;
> +  else if ((i == NLRI_UPDATE) && (update_len == 0))
> +continue;
> +  else if ( ((i == NLRI_MP_UPDATE) || (i == NLRI_MP_WITHDRAW)) &&  \
> +(attribute_len == 0))
> +continue;
>/* We use afi and safi as indices into tables and what not.  It
> would
> * be impossible, at this time, to support unknown afi/safis.  And
> * anyway, the peer needs to be configured to enable the afi/safi
> --
> 2.1.4
>
>
> ___
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15485] Re: Round 8

[Martin Winter]

On 7 Jun 2016, at 3:24, Paul Jakma wrote:


Hi,

On Mon, 6 Jun 2016, Martin Winter wrote:


Paul,

from the testing side, I would appreciate if you could submit them in 
multiple patches into the next proposed branch. I worry a long git 
bisect nightmare to find the bad commits. (also, not sure if you 
checked if each patch was successful on it’s own on my CI system).


I did look at the CI results, where they were attached to the 
patchwork issue. I also did my own 'git rebase -i --exec make' test.


Some series of patches contain commits that need later commits to 
compile. When the series are marked as such in the emails (as git 
send-email tries to), i.e. "[patch X/Y]", the CI system seems to test 
them as a unit.


However, that gets lost once applied to git.

So, as things stand, you're going to end up with a linearised 
'proposed for merging to master' tree (need to find quick terms to 
distinguish between the 'proposed contribution' stage and the later 
'linearised, reviewed and now proposed for merging' stage ;) ) that 
will contain commits that don't compile.


If it's easy I try fix such commits. E.g., MTYPEs that are added in a 
later commit I might manually move to the first one that uses it. But 
that's not always possible.


In the future, we could get super-strict about each commit compiling - 
you should change your CI to enforce that in that case!


So even in a set of 4 patches, I would test patch 1, patch 1+2, patch 
1+2+3 and finally patch 1+2+3+4 ?


Or test each on it’s own?

My preferred way to work through this would be to submit one set 
(from one committer) into a proposed branch, then wait until the CI 
system gives the OK (or if not then get them fixed), then push the 
next set etc.. (I assume that most/all of these patches are not 
disputed from the functionality and the further review is based 
mostly on the implementation)


What would be cool would to have a system that auto-applied 
contributions to a git branch based off the last master, and made that 
available to others. And then maybe replied to the email so it'd show 
up in patchwork.


I can think of two things that'd be useful:

- a branch of just the contribution on master

- an accumulating branch, so that the latest submission to the list is
  applied to the previous submission on the list

That might help automate a lot of what at present is tedious manual 
work. And... it seems you already have a lot of the scripts to do it? 
:)


Both should be easy. I don’t see much use for the first one in case of 
patches which are just a single commit (and if there are multiple parts, 
then I would argue that we should rather commit the series independent 
of some proposed branch on approval directly to master (or whatever the 
working branch is).
For the 2nd choice, this would only be added to the accumulating branch 
on successful pass of the tests.


If you want me to try this, then suggest something (i.e. name of 
accumulating branch?) and I can give it a try.


- Martin Winter


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15484] CI Testresult: PASSED (Re: [quagga-dev, 15482] bgpd: bgp_update_receive ignores non present NLRI)

[cisystem]

Continous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF CI System 

This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter .

Patches applied :
  Patchwork 1966: http://patchwork.quagga.net/patch/1966
   [quagga-dev,15482] bgpd: bgp_update_receive ignores non present NLRI
Tested on top of Git : 86c5d2e (as of 20160315.231717 UTC)
CI System Testrun URL: https://ci1.netdef.org/browse/QUAGGA-QPWORK-305/


Regards,
  NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education Foundation,
For more information, see www.netdef.org and www.opensourcerouting.org
For questions in regards to this CI System, contact Martin Winter, 
mwin...@netdef.org

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15482] [PATCH] bgpd: bgp_update_receive ignores non present NLRI

[Philippe Guibert]

Fixes 518a4b7eadcb "bgpd: Regularise bgp_update_receive,
add missing notifies and checks"
Error message "UPDATE with unsupported AFI/SAFI 0/0" is wrongly
displayed for a packet which does not have the matching NLRI entry.
The patch checks presence of nlri in bgp update message.

Signed-off-by: Philippe Guibert 
---
 bgpd/bgp_packet.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/bgpd/bgp_packet.c b/bgpd/bgp_packet.c
index 740b0f1ce603..601d39d1c1ad 100644
--- a/bgpd/bgp_packet.c
+++ b/bgpd/bgp_packet.c
@@ -1781,6 +1781,14 @@ bgp_update_receive (struct peer *peer, bgp_size_t size)
   /* Parse any given NLRIs */
   for (i = NLRI_UPDATE; i < NLRI_TYPE_MAX; i++)
 {
+  /* ignore empty nlri entries */
+  if ((i == NLRI_WITHDRAW) && (withdraw_len == 0))
+continue;
+  else if ((i == NLRI_UPDATE) && (update_len == 0))
+continue;
+  else if ( ((i == NLRI_MP_UPDATE) || (i == NLRI_MP_WITHDRAW)) &&  \
+(attribute_len == 0))
+continue;
   /* We use afi and safi as indices into tables and what not.  It would
* be impossible, at this time, to support unknown afi/safis.  And
* anyway, the peer needs to be configured to enable the afi/safi
-- 
2.1.4


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15483] Re: [PATCH 00/10] VNC: L3 & L2 VPN application support

[Philippe Guibert]

Hi Lou,

Sorry for wrong alarm related to error message "UPDATE with
unsupported AFI/SAFI 0/0" error message".

Following the EVPN trial regarding remotes/labnc/patches/R1.0.20160315+vnc/v2,
I managed to compile, launch, and exchange BGP messages through a mesh
configuration.

I will continue the review the patch code, and get back to you quickly,

Best Regards,

Philippe

On Mon, Jun 6, 2016 at 6:00 PM, Philippe Guibert
 wrote:
> Hi Lou,
>
> I am looking deeper at EVPN implementation, with patch "VNC; L3 & L2
> VPN application support".
> To get more familiar with this, I tried to mount a setup based on Mesh
> NVA configuration example that can be found on doc/vnc.texi file, and
> make a BGP exchange between the two BGP speakers.
> At establishment, I got this error message : unsupported AFI/SAFI 0/0.
>
> So , I am wondering if there is a setup issue, or a side effect due to
> some mis-configurations ?
> I only took 2 BGP Speakers instead of 3 ( I don't think it should
> affect the behaviour).
> I am based on (HEAD, origin/patches/LabN/R1.0.20160315+vnc/v2) bgpd:
> add L3/L2VPN
> I compiled with vnc support, and tested on ubuntu14.04 release.
> You can find attached the log message obtained on my console, as well
> as the bgp configuration used, and the wireshark capture file during
> the BGP exchange.
>
> Do you have an idea how I could overcome this issue ?
> Thanks in advance,
>
> Best Regards,
>
> Philippe
> 
>
> *error messages i had*
> 2016/06/06 17:08:33 BGP: %ADJCHANGE: neighbor 10.125.0.1 Up
> 2016/06/06 17:08:34 BGP: unknown afi/safi (0/0)
> 2016/06/06 17:08:34 BGP: 10.125.0.1 [Info] UPDATE with unsupported AFI/SAFI 
> 0/0
> 2016/06/06 17:08:34 BGP: unknown afi/safi (0/0)
> 2016/06/06 17:08:34 BGP: 10.125.0.1 [Info] UPDATE with unsupported AFI/SAFI 
> 0/0
> 2016/06/06 17:08:34 BGP: unknown afi/safi (0/0)
> 2016/06/06 17:08:34 BGP: 10.125.0.1 [Info] UPDATE with unsupported AFI/SAFI 
> 0/0
> 2016/06/06 17:08:34 BGP: unknown afi/safi (0/0)
> 2016/06/06 17:08:34 BGP: 10.125.0.1 [Info] UPDATE with unsupported AFI/SAFI 
> 0/0
> 2016/06/06 17:08:39 BGP: Import timer expired.
>
>
> *configuration used *
>
> hostname nva1
> password zebra
> log stdout
> service advanced-vty
> !
> router bgp 64512
>  bgp router-id 10.125.0.2
>  neighbor 10.125.0.1 remote-as 64512
> !
>  address-family vpnv4
>  neighbor 10.125.0.1 activate
>  exit-address-family
>  vnc defaults
>   rd 64512:1
>   response-lifetime 200
>   rt both 1000:1 1000:2
>   exit-vnc
> !
>
> hostname nva2
> password zebra
> log stdout
> service advanced-vty
> !
> router bgp 64512
>  bgp router-id 10.125.0.1
>  neighbor 10.125.0.2 remote-as 64512
> !
>  address-family vpnv4
>  neighbor 10.125.0.2 activate
>  exit-address-family
>  vnc defaults
>   rd 64512:1
>   response-lifetime 200
>   rt both 1000:1 1000:2
>   exit-vnc
> !
>  vnc nve-group group1
>   prefix vn 172.16.128.0/17
>   rd 64512:1
>   rt both 1000:1 1000:2
>   exit-vnc
> !
>
> On Tue, May 17, 2016 at 1:10 PM, Lou Berger  wrote:
>> This patch set adds an L3 & L2 VPN application that makes use of the VPN
>> and Encap SAFIs.  This code is currently used to support IETF NVO3 style
>> operation.  In NVO3 terminology it provides the Network Virtualization
>> Authority (NVA) and the ability to import/export IP prefixes and MAC
>> addresses from Network Virtualization Edges (NVEs).  The code supports
>> per-NVE tables (VRFs/VSIs).
>>
>> The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
>> (L2) forwarding information between NVAs and NVEs is referred to as the
>> Remote Forwarder Protocol (RFP). OpenFlow is an example RFP.  RFPs are
>> integrated with BGP via the RF API contained in the new "rfapi" BGP
>> sub-directory.  Currently, only a simple example RFP is included in
>> Quagga. Developers may use this example as a starting point to integrate
>> Quagga with an RFP of their choosing, e.g., OpenFlow.  The RFAPI code
>> also supports the ability to import/export of routing information
>> between VNC and customer edge routers (CEs) operating within a virtual
>> network. Import/export may take place between BGP views or to the
>> default zebra VRF.
>>
>> BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
>> information between NVAs. BGP based IP VPN support is defined in
>> RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
>> BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
>> of both the Encapsulation Subsequent Address Family Identifier (SAFI)
>> and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
>> Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
>> Encapsulation Attribute, are supported. The code is tunnely type
>> agnostic. MAC address distribution does not follow any standard BGB
>> encoding, although it was inspired by the early IETF EVPN concepts.
>> The