[c-nsp] Seamless MPLS interacting with flat LDP domains

[James Bensley]

On Fri, 26 Apr 2019 at 05:26, Igor Sukhomlinov <dvalinswamp at gmail.com> 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.