L3NM: Multi-hop clients, enabling/disabling mpls label re-write

[rgaglian]

When connecting to an eBGP neighbor, I may need to enable/disable mpls label re-write, particularly in multi-AS situations.

Propose to add leaf to bgp container.

 container bgp {
      leaf mpls-deactivation {
        description "Set to true to disable BGP MPLS forwarding.";
        type boolean;
        default "false";
      }
      description
        "BGP-specific configuration.";
    }
 }

XR configuration guide: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/b-ncs5500-bgp-cli-reference/b-ncs5500-bgp-cli-reference_chapter_01.html#wp1815707132

"Use of the mpls option in the ebgp-multihop command prevents BGP from enabling MPLS on the peering interface and also prevents allocation of Implicit-NULL rewrite labels for nexthop addresses learned from the peer. This is useful in some scenarios in which MPLS forwarding labels to the nexthops have already been learned via BGP labeled-unicast or LDP. "

[boucadair]

I'm afraid this is more on the device model, not at the network level.

[rgaglian]

Not really, how do you know when or not to enable it? The controller needs the intend to reflect it. The device model is about "how" (native, openconfig, cli) to implement but the network intend needs to tell me what is needed.

[boucadair]

Not really, how do you know when or not to enable it?

This can be based on other parameters that are conveyed in the model, especially the content of 'carrierscarrier'. No?

[rgaglian]

not really, not all carrierscarrier are tagged interfaces. If there is a specific "algorithm" needed, it should be added to the I-D. I did not find one but fine if you can.

[oscargdd]

Roque, can you explain the use case behind?

[rgaglian]

The use case is when you have MPLS option C without RR. However, after an internal analysis, we concluded that it is indeed implementation specific. I am ok with not implementing and closing the ticket.

[boucadair]

Thank you, Roque.