The MPLS details aren’t that important as they work just fine.
I understand that when OSPF is redistributed into MP-BGP as a VPNv4 route, extended communities are included to preserve OSPF information. The communities are the following:
The only confusing part is the OSPF DOMAIN ID. We don’t have to talk about the 0x0005 bit. Apparently, on Cisco IOS, it represents standard OSPF to VPN MP-BGP redistribution without any transitioning/migration scenarios and as far as I know, it tells the router how to interpret the rest of the domain ID.
The domain value is based off the OSPF process ID. Apparently, only the first 4 bytes of it are based off the process ID while the 0200 are some fields within it/sub-fields.
What I don’t understand is why doesn’t XR include these by default? It feels cumbersome to define it manually on P3-XR by copying it from P4.
What exactly is the best practice when it comes to configuring domain IDs? Have some sort of custom value or should I just copy what P4 is advertising and configure it on P3-XR? It feels impractical to configure the raw HEX values manually. XE atleast allows you to specify the domain in the x.x.x.x format but XR only supports HEX
This is an interesting behavior, and it highlights the difference between IOS-XR and IOS/IOS-XE. The key point is that IOS/XE and IOS XR simply have different defaults, but it’s interesting that XR’s behavior is actually closer to what RFC 4577 recommends.
Each OSPF instance MUST be associated with one or more Domain
Identifiers. This MUST be configurable, and the default value (if
none is configured) SHOULD be NULL.
So if no OSPF Domain ID is configured, the default SHOULD be NULL. IOS XR follows that model exactly: no configured Domain ID means NULL. Classic IOS/IOS XE, however, automatically creates a non-NULL OSPFv2 Domain ID from the OSPF process ID.
Cisco actually documents this exact IOS/XR interoperability issue in the IOS-XR command reference for the domain-id command. Their IOS XR documentation says that an OSPF Domain ID must be explicitly configured on XR and specifically notes that, when IOS XR and IOS are used together, the XR Domain ID should be manually configured to match the IOS default Domain ID.
In such cases, I would consider best practice an explicitly configured domain ID on ech customer OSPF domain regardless of XR or other IOS types. This makes the intent explicit rather than depending on whatever process number happens to have been used on each PE. It should intentionally become part of the design, and of course, it should be documented.
I think the key here is the following: Don’t think of the IOS/XE process-ID-derived Domain ID as the “correct” Domain ID that XR is failing to generate. It’s just an IOS/XE default. XR defaults to NULL. In a mixed XE/XR environment, I would explicitly configure the same Domain ID on both PEs. Ideally choose and document the Domain ID deliberately rather than depending on OSPF process IDs.
