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

[Adam Vitkovsky]

> Eric Oosting [mailto:eric.oosting at gmail.com]
> Sent: Friday, February 19, 2016 3:17 PM
>
> On Fri, Feb 19, 2016 at 4:14 AM, Adam Vitkovsky
> <Adam.Vitkovsky at gamma.co.uk> wrote:
> > 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)
>
> And then there is this gem:
>
> http://www.juniper.net/documentation/en_US/junos13.2/topics/topic-
> map/bgp-sessions.html
>
> where in under certain circumstances your router switches between a more
> or less optimal method of rib management, and when it changes it resets
> every one of your bgp sessions.
>
> -e
>
Don't even get me started on BGP implementation, very "carrier grade" indeed.
One has to wonder what was the train of thoughts on this, looking at what competition does by seamlessly and dynamically calculating update groups for neighbours based on commonalities in outbound policies.
Have they thought nah let's make this process group dependent (cause we have powerful enough CPUs on all our boxes, so why to optimize) oh and every time a peer is moved to a different update group let's reset that peer or maybe all the peers in its original group -or maybe some totally unrelated peers as well just in case, as operators are going to like this approach much better?

I understand that less lines of code should facilitate stability, but I think that one should try to achieve the balance between stability and usability.



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.