[j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

[Aaron Gould]

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 <jwbensley at gmail.com> wrote:
> 
> 
> 
>> On 5 July 2018 14:08:02 BST, Aaron Gould <aaron1 at gvtc.com> 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.