[j-nsp] Enable EVPN on existing mpls l3vpn network

[Adam Vitkovsky]

> tim tiriche
> Sent: Thursday, February 18, 2016 6:44 PM
>
> Hello,
>
> I have an existing L3VPN network with NSR.
>
> If i want to enable EVPN, is it just a matter of enabling family evpn signalling
> on the bgp neighbors?
>
> Will doing so, cause a session reset or affect existing production services or
> something else i need to be aware of?  this will be on the junos
> recommended 13.3R8 code.  I read NSR is not supported for EVPN.  If i
> enable family evpn signalling will NSR be supported for existing l3vpn
> functionality?
>
> -Tim
>
Hello Tim,

Every time you'll be adding new Subsequent Address Family (EVPN) or a new Address Family (IPv6) on a particular BGP session the BGP speaker you are adding these on will need to advertise it as new capability (notifying the neighbour that it can now tx/rx messages for this AFI/SAFI).
Unfortunately though, capabilities are exchanged only in the Open message -and that one is sent only when the TCP session is first established.
So in order to advertise new capabilities the existing session needs to be torn down and brought up again.
(and there's also the RFC requirement saying that when a neighbour receives unrecognized optional parameters in open message it may terminate the session)

You ask why on earth the capabilities can't be exchanged over the established TCP session in 2016?
Well that's a good question and I myself would like to hear the story behind why the proposals did not fly.


Regarding the NSR
It works per session -so if any of the AFs or SAFs using the TCP session do not support NSR -the session won't be preserved across the RE switchovers.
So as suggested already you should run a separate TCP session for SAFs that do not support NSR -this session is then not going to be protected by NSR.


Couple of consideration regarding the EVPN
Pure EVPN (i.e. without the PBB font-end) does C-MAC learning in control plane so make sure your BGP speakers can hold all the MAC routes you intend to carry.
Also you might want to introduce mLDP into the core so EVPN can forward multi-destination traffic effectively.


 adam


        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.