MPLS

Automatic Derivation of remote discriminator for S-BFD session in SR-TE (MX204, MX480, MX960, MX10008, and MX2008)—Starting in Junos OS Release 22.4R1, you can use the automatically derived remote discriminator for Seamless BFD (S-BFD) sessions on segment routing–traffic engineering (SR-TE) paths. With this feature, you don't need to configure a remote discriminator in the S-FBD configuration on the ingress or transit device and a matching local-discriminator on its respective endpoint. Instead, the egress provider edge device will now accept an IP address as a local discriminator.

To configure this feature, use the set protocols bfd sbfd local-discriminator-ip command.

Additionally, you can now use a common sBFD template with the S-FBD configurations on multiple controller-provisioned SR-TE policies. In these sBFD sessions, Junos OS automatically derives the remote discriminator from the tunnel endpoint for matching SR-TE policies.

[See sbfd and Routing Engine-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution.]

Support for LDP tunneling over SR-TE (ACX5448, MX480, MX960, and MX2010)—Starting in Junos OS Release 22.4R1, you can tunnel LDP label-switched paths (LSPs) over segment routing-traffic engineering (SR-TE) in OSPF networks. Tunneling LDP over SR-TE provides consistency and coexistence of both LDP LSPs and SR-TE LSPs.

To configure LDP tunneling over SR-TE, include the tunnel-source-protocol configuration statement at the [edit protocols ospf traffic-engineering] and ldp-tunneling configuration statement at the [edit protocols ospf source-packet-routing source-routing-path] hierarchy levels.

[See Tunneling LDP over SR-TE.]

PCEP multipath support for SR-TE (MX480, PTX10008, and QFX5200)—Starting in Junos OS Release 22.4R1, you can configure the multipath feature (primary or secondary paths) for Path Computation Element Protocol (PCEP) segment routing-traffic engineering (SR-TE) as defined in draft-ietf-pce-multipath-06. We support the following multipath capabilities:

• When the PCEP multipath feature is enabled, you can configure multiple primary or secondary paths in a candidate path that you configure and control using Path Computation Client (PCC).Note that the PCEP multipath feature is enabled by default.

• When the PCEP multipath feature is disabled, you can configure only one primary path in a candidate path. Note that a secondary path configuration is not allowed.

The PCEP multipath feature removes the compute-profile restriction of 1 on the maximum number of segment lists (maximum-computed-segment-lists).

[See Configuring Multiple Paths for Path Computation Element Protocol SR-TE Overview.]

Support for ingress and transit-chained CNHs for LDP, RSVP, L2VPN, L3VPN, and static protocols (MX204, MX240, MX304, MX480, MX960, MX10003, MX10004, MX10008, MX10016, MX2010, and MX2020)—Starting in Junos OS Release 22.4R1, you can configure chained composite next hops (CNHs) for devices carrying ingress or transit traffic in the network. We now support the following options:

• On the LDP ingress router, set routing-options forwarding-table chained-composite-next-hop ingress ldp

• For the LDP, RSVP, L2VPN, L3VPN, and static protocols on the transit router:

  • set routing-options forwarding-table chained-composite-next-hop transit ldp

  • set routing-options forwarding-table chained-composite-next-hop transit rsvp

  • set routing-options forwarding-table chained-composite-next-hop transit static

  • set routing-options forwarding-table chained-composite-next-hop transit l2vpn

  • set routing-options forwarding-table chained-composite-next-hop transit l3vpn

We support class of service (CoS) and rewrite rules for ingress and transit-chained CNHs for these configuration commands.

[See labeled-bgp, chained-composite-next-hop, and ingress (Chained Composite Next Hop).]