Thanks, appreciate the thoughts/insights BGP-based ELINE ... Is this Kompella you speak of ? If so, seems like a lot for a simply/quick p2p pw
Aaron > On Jul 6, 2018, at 8:28 AM, James Bensley <[email protected]> wrote: > > > >> On 5 July 2018 14:08:02 BST, Aaron Gould <[email protected]> wrote: >> I really like the simplicity of my ldp-based l2vpn's... eline and elan >> >> You just made me realize how that would change if I turned off ldp. >> >> So, SR isn't able to signal those l2circuits, and manual vpls instances >> ? >> ... I would have to do all that with bgp ? I use bgp in some cases for >> rfc4762, but not for simple martini l2circuits. >> >> My entire cell backhaul environment is based on ldp based pseudowires. > > Hi Aaron, > > Yes that would be a change in your existing setup but only if you turned off > LDP. SR fully supports (on paper at least!) running LDP and SR simultaneously > so you wouldn't need a big bang approach and have to hard switch if you were > to move to BGP signalled services and/or SR. However, I don't think SR is > designed to be run along side LDP long term either. I'm sure bugs will pop > up, if you can use LDP for only signalling L2 VPNs somehow and SR for > transport LSP signalling you wouldn't need to migrate. I think on Juniper you > might be able to raise the "preference" (Administrative Distance is Cisco > parlance) of LDP separate from the IGP but I don't think you can do that on > Cisco? > > I'm ranting a bit here, but I'd personally look to move to all BGP signalled > services if I was moving to SR. You have one protocol for IGP transport (SR > extended OSPF or SR extended IS-IS) and one protocol for all service > transport signalling (BGP). We (the industry) have our lovely L3 VPNs > already, with standard BGP communities, RTs and RDs and then a bunch of > policies and route reflectors to efficiently control route distribution and > label allocation. We also have high-availability of that information through > RR clusters and features like BGP Add-Path and PIC. We also have good > scalability from signalled services using FAT and Entropy labels. > > Now with BGP signalled EVPN using MPLS for transport instead of VXLAN, we > have again RTs and RDs and communities et al. This means we can use similar > policies on the same RR's to control route (MAC or GW) and label distribution > efficiently and only to those who exactly need to carry the extra state. We > get to use the same HA and scalability benefits too. Even with BGP signalled > and BGP based auto discovery for ELINE services, we control who has that > AFI/SAFI combo enabled cleanly. With LDP, the configuration and control are > both fully distributed to the PEs. Not a major issue, but "BGP for > everything" helps to keep the design, implementation and limitations of all > our services more closely aligned. > > If you're also using FlowSpec, BMP, BGP-LS, BGP-MDT etc, it makes sense to me > to keep capitalising on that single signaling protocol for all services. > > Cheers, > James. > > P.s. sorry, on a plane so I've got time to kill. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
