On Fri, 26 Apr 2019 at 05:26, Igor Sukhomlinov <[email protected]> wrote: > > Hi all,
Hi Igor > I wonder if anyone has experience with integrating a UMMT/Seamless > MPLS domain (BGP-LU running over isolated IGP regions) with an > existing flat LDP network. > > The customer wants to make sure the existing LDP domain is still > running while the newer BGP enabled domain is steadily coming online, Well the whole point of Seamless MPLS is to carve up the network into separate transport areas so making sure the existing LDP domain runs whilst bringing up BGP is not really an option unless you want to create a weird migration topology, whereby you start to implement LDP prefix filters so that certain LSRs don’t receive label mappings for certain IGP prefixes, and you deploy BGP-LU to those nodes to replace LDP. This would be unnecessary complexity in my opinion for no real benefit. > but what is the best approach to transport the services between the > networks? > > The documentation is scarce, but I have a feeling a few approaches are > available: Have you read: https://www.ietf.org/archive/id/draft-ietf-mpls-seamless-mpls-07.txt https://tools.ietf.org/rfc/rfc5283.txt https://ripe65.ripe.net/presentations/68-RIPE_65_Seamless_MPLS.pdf https://images.tmcnet.com/online-communities/next-generation-communications/whitepapers/NP2013051418EN_Seamless_MPLS_EN_TechWhitePaper-1.pdf > - service segmentation - introducing dedicated service gateways that > participate in the existing LDP and the new domain and hold the state > for all the services that need to go between the new and legacy > networks This doesn’t scale well. Your service edge PEs end up having all your VRFs configured on them to perform next-hop-self or VPLS/bridge domains, or all your pseudowires for stitching. You’ll chew threw the RIB/FIB/LFIB in no time (depending on the scale). They also become a place of constant change operations as every new provision requires the VRF/bridge domain/whatever be configured on these devices. They’ll also become a place of high state churn as they’ll see all customer AND core route service state changes (route or MAC advertise/withdraw, label allocation, VC state changes, etc.). It would be like having in-forwarding-path route-reflectors. > - transport label integration - somehow exchange prefixes between > BGP-LU domain and LDP domains This is pretty common in Seamless networks and works well. A unique IGP per network domain with BGP-LU at the ABRs. IGPs scale quite well these days, I’ve had no issues with 250 PEs per area (this could be higher but the device IGP settings weren’t configured following scalability best practises). So how you split your network can be achieved one of a number of ways. You could make every domain a unique IGP area. The core being area OSPF area 0 or ISIS level-2 and each domain aggregation node/ABR straddles multiple IGP areas/levels. You need look at what your vendors offers to make the right choice when using this all-one-AS approach. Some vendors like Cisco/Huawei/ALU allow multiple OSPF or ISIS processes to run on the same box. If you use a different process for each IGP an ABR connects to, you’ll have implicit route filtering / separation between IGP areas/levels. Some vendors like Juniper can’t run multiple IGP processes. In this case you can do something like run both IGPs, e.g. ISIS in the core and OSPF in the access and the ABRs have to run both protocols, which will again give you implicit route filtering between IGPs. Or run the same IGP in the core and access layers and on the ABRs you need to add explicit route/prefix filters to prevent all routes from being advertised everywhere. I’ve worked on all three of these IGP deployment methods and they each have pro’s and con’s based on your own operational madness and what your network can support. > - Option A/B This is another option. It scales really well. I can be as simple as OSPF Area 0 or IS-IS level 2 everywhere and run each domain as a unique private BGP AS, using Inter-AS MPLS option A/B/C as suites you best. Like above, pro’s and con’s based on the specific devices you’re using and what you can support operationally. From personal experience; Option C scales the most but it also the most complex to troubleshoot. Option A scales the least and it the easiest to troubleshoot. Option B was somewhere in the middle. > - complete migration - move services from the existing LDP domain to a > new BGP domain, forget about interop. Can’t really comment on this as it’s quite specific to your setup and requirements, I don’t fully understand the statement. Cheers, James. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
