LSPs are created in the network through MPLS. They can be created statically, by RSVP traffic engineering (TE), or by LDP. LSPs created by LDP perform hop-by-hop path setup instead of an end-to-end path.

The control plane enables label switched routers (LSRs) to discover their potential peer routers and to establish LDP sessions with those peers to exchange label binding information.

LDP creates LSPs to perform the hop-by-hop path setup so that MPLS packets can be transferred between the nodes on the MPLS network.

For a given network (10.0.0.0), hop-by-hop LSPs are set up between each of the adjacent routers (or, nodes) and each node allocates a local label and passes it to its neighbor as a binding:

1. R4 allocates local label L4 for prefix 10.0.0.0 and advertises it to its neighbors (R3).

2. R3 allocates local label L3 for prefix 10.0.0.0 and advertises it to its neighbors (R1, R2, R4).

3. R1 allocates local label L1 for prefix 10.0.0.0 and advertises it to its neighbors (R2, R3).

4. R2 allocates local label L2 for prefix 10.0.0.0 and advertises it to its neighbors (R1, R3).

5. R1’s label information base (LIB) keeps local and remote labels bindings from its neighbors.

6. R2’s LIB keeps local and remote labels bindings from its neighbors.

7. R3’s LIB keeps local and remote labels bindings from its neighbors.

8. R4’s LIB keeps local and remote labels bindings from its neighbors.

Once label bindings are learned, the LDP control plane is ready to setup the MPLS forwarding plane as shown in the following figure.

1. Because R3 is next hop for 10.0.0.0 as notified by the FIB, R1 selects label binding from R3 and installs forwarding entry (label L1, label L3).

2. Because R3 is next hop for 10.0.0.0 (as notified by FIB), R2 selects label binding from R3 and installs forwarding entry (label L2, label L3).

3. Because R4 is next hop for 10.0.0.0 (as notified by FIB), R3 selects label binding from R4 and installs forwarding entry (label L3, label L4).

4. Because next hop for 10.0.0.0 (as notified by FIB) is beyond R4, R4 uses NO-LABEL as the outbound and installs the forwarding entry (label L4); the outbound packet is forwarded IP-only.

5. Incoming IP traffic on ingress LSR R1 gets label-imposed and is forwarded as an MPLS packet with label L3.

6. Incoming IP traffic on ingress LSR R2 gets label-imposed and is forwarded as an MPLS packet with label L3.

7. R3 receives an MPLS packet with label L3, looks up in the MPLS label forwarding table and switches this packet as an MPLS packet with label L4.

8. R4 receives an MPLS packet with label L4, looks up in the MPLS label forwarding table and finds that it should be Unlabeled, pops the top label, and passes it to the IP forwarding plane.

9. IP forwarding takes over and forwards the packet onward.

Note	For local labels, only up to 12000 rewrites are supported. If the rewrites exceed this limit, MPLS LSD or MPLS LDP or both the processes may crash.

When a control plane failure occurs, connectivity can be affected. The forwarding states installed by the router control planes are lost, and the in-transit packets could be dropped, thus breaking NSF.

1. The R4 LSR control plane restarts.

2. LIB is lost when the control plane restarts.

3. The forwarding states installed by the R4 LDP control plane are immediately deleted.

4. Any in-transit packets flowing from R3 to R4 (still labeled with L4) arrive at R4.

5. The MPLS forwarding plane at R4 performs a lookup on local label L4 which fails. Because of this failure, the packet is dropped and NSF is not met.

6. The R3 LDP peer detects the failure of the control plane channel and deletes its label bindings from R4.

7. The R3 control plane stops using outgoing labels from R4 and deletes the corresponding forwarding state (rewrites), which in turn causes forwarding disruption.

8. The established LSPs connected to R4 are terminated at R3, resulting in broken end-to-end LSPs from R1 to R4.

9. The established LSPs connected to R4 are terminated at R3, resulting in broken LSPs end-to-end from R2 to R4.

The graceful restart mechanism is divided into different phases:

Control communication failure detection

Control communication failure is detected when the system detects either:

• Missed LDP hello discovery messages

• Missed LDP keepalive protocol messages

• Detection of Transmission Control Protocol (TCP) disconnection a with a peer

Forwarding state maintenance during failure

Persistent forwarding states at each LSR are achieved through persistent storage (checkpoint) by the LDP control plane. While the control plane is in the process of recovering, the forwarding plane keeps the forwarding states, but marks them as stale. Similarly, the peer control plane also keeps (and marks as stale) the installed forwarding rewrites associated with the node that is restarting. The combination of local node forwarding and remote node forwarding plane states ensures NSF and no disruption in the traffic.

Control state recovery

Recovery occurs when the session is reestablished and label bindings are exchanged again. This process allows the peer nodes to synchronize and to refresh stale forwarding states.

1. The router R4 LSR control plane restarts.

2. With the control plane restart, LIB is gone but forwarding states installed by R4’s LDP control plane are not immediately deleted but are marked as stale.

3. Any in-transit packets from R3 to R4 (still labeled with L4) arrive at R4.

4. The MPLS forwarding plane at R4 performs a successful lookup for the local label L4 as forwarding is still intact. The packet is forwarded accordingly.

5. The router R3 LDP peer detects the failure of the control plane and channel and deletes the label bindings from R4. The peer, however, does not delete the corresponding forwarding states but marks them as stale.

6. At this point there are no forwarding disruptions.

7. The peer also starts the neighbor reconnect timer using the reconnect time value.

8. The established LSPs going toward the router R4 are still intact, and there are no broken LSPs.

When the LDP control plane recovers, the restarting LSR starts its forwarding state hold timer and restores its forwarding state from the checkpointed data. This action reinstates the forwarding state and entries and marks them as old.

The restarting LSR reconnects to its peer, indicated in the FT Session TLV, that it either was or was not able to restore its state successfully. If it was able to restore the state, the bindings are resynchronized.

The peer LSR stops the neighbor reconnect timer (started by the restarting LSR), when the restarting peer connects and starts the neighbor recovery timer. The peer LSR checks the FT Session TLV if the restarting peer was able to restore its state successfully. It reinstates the corresponding forwarding state entries and receives binding from the restarting peer. When the recovery timer expires, any forwarding state that is still marked as stale is deleted.

If the restarting LSR fails to recover (restart), the restarting LSR forwarding state and entries will eventually timeout and is deleted, while neighbor-related forwarding states or entries are removed by the Peer LSR on expiration of the reconnect or recovery timers.

The carrier supporting carrier feature enables one MPLS VPN-based service provider to allow other service providers to use a segment of its backbone network. The service provider that provides the segment of the backbone network to the other provider is called the backbone carrier. The service provider that uses the segment of the backbone network is called the customer carrier.

A backbone carrier offers Border Gateway Protocol and Multiprotocol Label Switching (BGP/MPLS) VPN services. The customer carrier can be either:

• An Internet service provider (ISP)

• A BGP/MPLS VPN service provider

In either case, MPLS is run in the backbone network and between the backbone and customer carrier (the PE-CE link).

The figure shows two customers, A and X, connecting their remote sites through the backbone carrier. The PE device of the backbone network connects with both customers through MPLS but under different VRFs according to interface-VRF mapping. The MPLS label distribution protocol for PE-CE connectivity can be either BGP or LDP, and requires them to run in a customer VRF context on the PE device.

The MPLS LDP CSC provides the following benefits to service providers who are backbone carriers and to customer carriers.

Benefits to the Backbone Carrier

• The backbone carrier can accommodate many customer carriers and give them access to its backbone. The backbone carrier does not need to create and maintain separate backbones for its customer carriers. Using one backbone network to support multiple customer carriers simplifies the backbone carrier's VPN operations. The backbone carrier uses a consistent method for managing and maintaining the backbone network. This is also cheaper and more efficient than maintaining separate backbones.

• The MPLS LDP CSC feature is scalable. CSC can change the VPN to meet changing bandwidth and connectivity needs. The feature can accommodate unplanned growth and changes. The CSC feature enables tens of thousands of VPNs to be configured over the same network, and it allows a service provider to offer both VPN and internet services.

• The MPLS LDP CSC feature is a flexible solution. The backbone carrier can accommodate many types of customer carriers. The backbone carrier can accept customer carriers who are ISPs or VPN service providers or both. The backbone carrier can accommodate customer carriers that require security and various bandwidths.

Benefits to the Customer Carriers

• The MPLS LDP CSC feature removes from the customer carrier the burden of configuring, operating, and maintaining its own backbone. The customer carrier uses the backbone network of a backbone carrier, but the backbone carrier is responsible for network maintenance and operation.

• Customer carriers who use the VPN services provided by the backbone carrier receive the same level of security that Frame Relay or ATM-based VPNs provide. Customer carriers can also use IPSec in their VPNs for a higher level of security; it is completely transparent to the backbone carrier.

• Customer carriers can use any link layer technology (SONET, Digital Subscriber Line, Frame Relay, and so on) to connect the CE routers to the PE routers and the PE routers to the P routers. The MPLS LDP CSC feature is link layer independent. The CE routers and PE routers use IP or MPLS to communicate, and the backbone carrier uses MPLS.

• The customer carrier can use any addressing scheme and still be supported by a backbone carrier. The customer address space and routing information are independent of the address space and routing information of other customer carriers or the backbone provider.

To support multiple VRFs, IOS XR LDP configuration model is extended to allow VRF submode and per-VRF configuration and feature or interface enabling.

IOS XR LDP process is not distributed nor it is multi-instance, hence the single LDP process services all the configured VRFs. In large scale VRF deployment, it is recommended to enable VRF under LDP with appropriate policies and label filtering.

The following restrictions and recommendations apply to the MPLS LDP CSC feature:

• Only IPv4 address family is supported for a default or a non-default VRF.

• No T-LDP support in a VRF context.

• An address family under VRF and VRF interface must be configured for non-default VRFs.

• Following scenarios are not supported :

  • Different VRFs between a given PE-CE device pair (VRFs configured on different links and interfaces)

  • LDP/BGP CSC co-existence on a given VRF between a given PE-CE device pair:

    • Single link

    • Parallel links: LDP CSC on one link and BGP CSC on the other

• LDP router-id must be configured per-VRF. If not configured for non-default VRF, LDP computes router-id from available loopback interfaces under the VRF.

• It is recommended to configure a routable discovery transport address under a VRF IPv4 address-family submode for deterministic transport endpoint and connection.

• When LDP CSC is configured and in use:

  • BGP label allocation policy for VRF prefixes must be per-prefix

  • Selective VRF Download (SVD) feature must be disabled

For the control plane, the underlying address family can be either IPv4-only, IPv6-only or both. Whereas for the LSP setup, an LSP is setup for IPv4 or IPv6 FEC prefix.

The functions of LDP in the MPLS LDP IPv6 setup are as follows:

• Receive routing updates from routing information base (RIB) for global IPv6 prefixes

• Assign local labels for IPv6 prefixes

• Receive IPv6 address or state notifications for local IPv6 enabled interfaces from IP Address Repository Manager (IP-ARM/IM) and LAS for IPv6 link-local unicast addresses

• Advertise/Accept IPv6 label bindings and address bindings to/from peers

• Setup MPLS forwarding to create IPv6 LSPs

• Provide IPv6 LSP information to MPLS OAM as and when requested

• Service MIB requests for IPv6 control plane queries and generate MIB traps

• Provide LDPv6 convergence status for a link to IGP for LDP-IGP Sync feature for IPv6

• Support IPv6 address family for all existing LDP features that intersect with prefixes and/or addresses

Topological Scenarios

A typical deployment scenario consists of single-stack IP address-family (IPv4-only or IPv6-only) enabled interfaces between a set of routers.

Three topology scenarios in which the LSRs are connected through one or more dual-stack LDP enabled interfaces, or one or more single-stack LDP enabled interfaces are defined as follows:

Note	R2 is the main router.

1. One dual-stack interface/same neighbor:

   
   R1_ _ _ _ _ _ _ _R2
        IPv4+IPv6
   
   

2. Two single-stack interfaces/same neighbor:

   
            
        1. (IPv4)
   R1_ _ _ _ _ _ _ _ _R2
     _ _ _ _ _ _ _ _ _
        2. (IPv6)
   
   
   

3. Two single-stack interfaces/different neighbors with different address families:

   
   
        1. (IPv4)          2. (IPv6)
   R1_ _ _ _ _ _ _ _ R2_ _ _ _ _ _ _ _ R3
   
   
   

Case Study

A description of the control plane and LSP setup scenarios for the previously shown three configurations are as follows:

Case 1:

Neighbor Discovery: Both IPv4 and IPv6 Hellos sent on the interface to R1.

Transport Connection: IPv4 endpoints or IPv6 endpoints (as per user preference).

Label binding exchange: Both IPv4 and IPv6 prefixes.

Address binding exchange: Both IPv4 and IPv6 addresses.

LSPs: Both IPv4 and IPv6 over the same nexthop interface to R1.

Case 2:

Neighbor Discovery: IPv4 Hellos on interface-1 to R1 and IPv6 Hellos on interface-2 to R1.

Transport Connection: IPv4 endpoints or IPv6 endpoints (as per user preference).

Label binding exchange: Both IPv4 and IPv6 prefixes.

Address binding exchange: Both IPv4 and IPv6 addresses.

LSPs: IPv4 over nexthop interface-1 to R1 and IPv6 over nexthop interface-2 to R1.

Case 3:

Neighbor Discovery: IPv4 Hellos on interface-1 to R1 and IPv6 Hellos on interface-2 to R3.

Transport Connection: IPv4 endpoints with R1 and IPv6 endpoints with R3.

Label binding exchange: Both IPv4 and IPv6 prefixes to R1 and R3.

Note

Even if all the three LSRs are dual-stack, traffic from R1 to R3 will not be completely labeled. If there is IPv6 traffic, it is unlabeled from R1 to R2. Labels are imposed only at R2 (although in this specific case implicit null imposition) to R3. If there is IPv4 traffic, it is labeled from R1 to R2. But the traffic will go unlabeled between R2 and R3 given that no IPv4 adjacency exists between R2 and R3.

Address binding exchange: Both IPv4 and IPv6 addresses to R1 and R3.

LSPs: IPv4 over nexthop interface-1 to R1 and IPv6 over nexthop interface-2 to R3.

IPv6 support in MPLS LDP has the following restrictions and constraints:

• IPv6 address family is supported only under default VRF

• Implicit enabling of IPv6 address family is not allowed. It needs explicit enabling.

• It is recommended to configure a routable IPv6 discovery transport address when only LDP IPv6 is configured without explicitly specifying a router-id

The following features are supported in LDP IPv6:

• Single-stack (native IPv6) and dual-stack (IPv4+IPv6) topologies

• New operating modes in LDP:

  • Native LDP IPv6

  • LDP IPv6 over IPv4 and LDP IPv4 over IPv6 connection endpoints

    LDP Hellos carry optional transport address type length value (TLV) to notify a peer about TCP or transport connection endpoint. An LSR can include either IPv4 or IPv6 transport address TLV in an IPv4 or IPv6 Hello message. There is no difference in the TLV format of transport address for IPv4 and IPv6.

    Only one transport connection is established between two discovered peers, whether there be single address family Hello adjacencies or multi-address family (both IPv4 and IPv6) Hello adjacencies.

    In a dual-stack setup, when LDP has the option to establish transport connection either using IPv4 endpoints or IPv6 endpoints, IPv6 connection is preferred over IPv4 connection. If LDP is locally enabled for both IPv4 and IPv6 address families, every new session is treated as potential dual-stack connection. Under such circumstances, IPv6 preference is kept in place for maximum fifteen seconds for the session to establish, after which the LDP tries to establish a connection with the peer using IPv4. A user can override this default behavior by specifying the preference for a set of dual-stack peers to use IPv4 transport for the connection. Furthermore, a user may also specify maximum wait time to wait to establish the preferred transport connection. If the preferred transport establishment times out, LDP tries to establish connection with other non-preferred transport address families. This applies to both the cases when an LSR acts as active side or passive side for the TCP connection.

    To override default IPv6 transport preference for dual-stack cases, use the mpls ldp neighbor dual-stack transport-connection prefer ipv4 for-peers command. To specify the maximum time the preferred address family connection must wait to establish a connection before resorting to a non-preferred address family, use the mpls ldp neighbor dual-stack transport-connection max-wait command.

    Once a transport connection is established, it is not torn down depending on preferences. If the address family related to established transport connection is disabled under LDP, the corresponding transport connection is reset to reestablish the connection.

    For a single-stack setup, there is no contention; the transport connection uses the given address family.

• LDP Control Plane is IPv6 aware

• LDP IPv6 LSP forwarding setup

  LDP interacts with LSD in order to setup IPv6 LSP forwarding. The steps involved in this interaction are:

  • Label allocation for an IPv6 prefix is learnt from RIB.

  • Setup imposition and label switching forwarding path for given IPv6 prefix by creating IPv6 forwarding rewrites.

  • Like LDP IPv4, rewrite delete and label free operations are performed when a route disappears or is disallowed under LDP due to label policy.

  • There is no new requirement related to MPLS enabling or disabling. LDP also MPLS-enables in LSD (if not already) any LDP enabled interface, which is in the UP state for IP4 and/or IPv6 and has IPv4 and/or IPv6 addresses assigned.

  • In case of dual-stack LDP, a single Resource-Complete is sent by LDP to LSD once RIB-Converged notification is received for both IPv4 and IPv6 redistribute tables.

• Distribution of IPv4 and IPv6 bindings over a single LDP session established over IPv4 or IPv6

• LDP Downstream on Demand

• LDP session protection

  LDP session protection is a feature to protect an IPv6 LDP session. In case of dual-stack hello adjacencies with a peer, there is only a single targeted hello adjacency to protect the session. Session protection forms targeted adjacency of address family same as the transport connection. For IPv6, the target of the session protection is the remote transport connection endpoint. For IPv4, the target of the session protection is remote LSR ID.

• LDP IGPv6 sync on IPv6 interface

  This feature lets IGP support LDP IGP Sync feature for IPv6 address family. This means that Intermediate System-to-Intermediate System (IS-IS) allows IGP under an interface’s IPv6 address family, whereas OSPFv3 implements it just like existing support in OSPF for IPv4. When the IGP Sync feature is enabled, LDP convergence status on an interface is considered by the IGP under the context of a given address family. This behavior applies to IGP Sync for both non-TE as well as TE tunnel interfaces.

• LDP Typed Wildcard for IPv6 prefix FEC

  This feature adds support for Typed Wildcard for IPv6 Prefix FEC. The support includes:

  • Being able to send or receive IPv6 Prefix Typed Wildcard FEC element in label messages.

  • Respond to Typed Wildcard Label Requests received from peer by replaying its label database for IPv6 prefixes.

  • Make use of Typed Wildcard Label Requests towards peers to request replay of peer label database for IPv6 prefixes. For example, on local inbound policy changes.

• Label allocation, advertisement and accept policies for IPv6 prefixes

• Local label assignment and advertisement for IPv6 default-route (::/0)

• Session MD5 authentication for IPv6 transport

• IPv6 Explicit-Null label

  IPv6 explicit null label feature support includes:

  • Advertisement and receipt of IPv6 explicit-null label to and from peers.

  • IPv6 explicit-null outgoing label in forwarding setup.

  • Explicit-null advertisement policy for a set of IPv6 prefixes and/or set of peers.

  • Explicit-null configuration change. Change in explicit-null configuration is handled by first transferring a wildcard withdraw with null label to peer(s), followed by advertising the appropriate null (implicit or explicit) label to the peer(s) again. This works without any issue as long as a single IP address family is enabled. In case of a dual-stack LSR peer, a change of configuration related to explicit-null advertisement for a given address family may cause unnecessary mix-up in the other address family.

• LDP IPv6 LFA FRR

  Local LFA FRR for IPv6 is supported. However, it is required that the primary and backup paths are of the same address family type, that is, an IPv4 primary path must not have an IPv6 backup path.

• NSF for LDP IPv6 traffic

  Non-stop forwarding (NSF) support is either provided through LDP NSR or graceful restart mechanisms.

• IGP/LDP NSR for IPv6

• IGP/LDP Graceful Restart for IPv6

• LDP ICCP IPv6 neighbor node

  LDP Inter-Chassis Communication Protocol (ICCP) is supported with IPv6 neighbor node. ICCP is used as a mechanism for multi-chassis LACP.

• SSO/ISSU for LDP IPv6

• MPLS OAM: New FECs

  LSPV supports two new FECs.

  • LDP IPv6 Prefix FEC Encoding/Decoding

    Label Switched Path Verification (LSPV) encodes/decodes the LDP IPv6 Prefix FEC. Prefix is in the network byte order and the trailing bits are to be set to zero when prefix length is shorter than 128 bits.

  • Generic IPv6 Prefix FEC Encoding/Decoding

    LSPV encodes/decodes the generic IPv6 Prefix FEC. Prefix is in the network byte order and the trailing bits are to be set to zero when prefix length is shorter than 128 bits.

    Generic IPv6 FEC is used in addition to the LDP IPv6 FEC. This serves the following primary purposes:

    • Allows user to perform LSP ping and traceroute to verify data plane without involving control plane of the FEC in echo request and response.

    • If support for a new FEC is preferred in the future, the generic FEC can be used until corresponding control plane is explicitly supported by LSPV.

• IPv6 LSR MIB

  MPLS OAM LDP MIBS is extended to support IPv6. All LSR MIB objects that reference an InSegment prefix and OutSegment next hop address are modified to support IPv6.

• LSP ping support for LDP IPv6

• LSP trace-route support for LDP IPv6

• LSP tree-trace support for LDP IPv6

The following features are not supported in LDP IPv6:

• LDPv6 over TEv4 (traffic engineering)

• L2VPN/PW (over IPv6 LSPs)

• L3VPN (over IPv6 LSPs)

• LDP auto-config for IPv6 IGP/Interfaces

• LDP ICCP with IPv6 neighbor node

• Multicast extension to LDP (mLDP) for IPv6 FEC with label binding through IPv4 and IPv6 transport

• Native IPv4 and IPv6 L3VPN over LDP IPv6 core

• L2VPN signaling with LDP when the nexthop address is IPv6

• IPv6 LDP CSC

The LDP configuration model was changed with the introduction of explicit address family enabling under LDP (VRF) global and LDP (VRF) interfaces. However, in order to support backward compatibility, the old configuration model was still supported for default VRF. There was, however, no option to disable the implicitly enabled IPv4 address family under default VRF's global or interface level.

A new configuration mpls ldp default-vrf implicit-ipv4 disable is now available to the user to disable the implicitly enabled IPv4 address family for the default VRF. The new configuration provides a step towards migration to new configuration model for the default VRF that mandates enabling address family explicitly. This means that if the new option is configured, the user has to explicitly enable IPv4 address family for default VRF global and interface levels. It is recommended to migrate to this explicitly enabled IPv4 configuration model.

For detailed configuration steps, see Disabling Implicit IPv4

LDP stores label bindings associated with FEC prefix in its Label Information Base (LIB) [TIB in Cisco LDP]. An entry in LIB corresponds to a prefix and holds the following bindings:

• Local binding: Local label assigned for this prefix (which is learnt through local RIB).

• Remote bindings: Array of peer labels (prefix-label bindings received in label mapping message from peer(s)).

An entry in LIB can exist due to local binding presence, or due to remote binding(s) presence, or due to both local and remote bindings presence. The forwarding setup, however, mandates that local binding be present for a prefix.

Extensions have been implemented to support IPv6 prefixes for LIB in LDP. For per-address family convergence or preference reasons, separate or new LIB is implemented to keep and maintain IPv6 prefixes. In case of dual-stack LDP, LIBv4 is preferred over LIBv6 wherever possible. For example, during background housekeeping function, LIBv4 is processed before LIBv6.

LDP needs to maintain IPv6 address database for local and peer interface addresses. The IPv4 address module for local/peer addresses is extended to keep IPv4/IPv6 addresses in their respective databases, much like LIB database. In case of a dual-stack LDP, IPv4 local address database function is preferred over IPv6 local address database function where ever possible.

LDP computes default local transport address for IPv6 from its IPv6 interface or address database by picking the lowest operational loopback interface with global unicast IPv6 address. This means that any change in this loopback state or address, flaps or changes the default transport address for IPv6 and may cause session flaps using such an address as transport endpoint. For example, if a session is currently active on Loopback2 as during it's inception it was the lowest loopback with an IPv6 address, and a lower loopback, Loopback0, is configured with an IPv6 address, the session does not flap. However, if it does flap, the next time the session is attempted, Loopback0 is used.

The session flaps when configuring discovery transport address explicitly.

Use the discovery transport-address command under the LDP address family submode to specify the global transport address for IPv4 or IPv6.

It is recommended to configure global transport-address for IPv6 address family to avoid a potentially unstable default transport address.

LDP base specification allows exchange of IPv4/IPv6 bindings (address/label) on an established session. When both IPv4 and IPv6 address families are enabled under LDP, LDP distributes address/label bindings for both address families to its established peer according to local policies. Following are a few significant points pertaining to bindings support for IPv6:

• LDP allocates/advertises local label bindings for link-local IPv6 address prefixes. If received, such FEC bindings are ignored.

• LDP sends only the Prefix FEC of the single address family type in a FEC TLV and not include both. If such a FEC binding is received, the entire message is ignored.

• LDP sends only the addresses belonging to same address family in a single address list TLV (in address or address withdraw message).

If an address family is not enabled on receiving LSR, LDP discards any bindings received from peer(s) for the address family. This means that when address family is enabled, LDP needs to reset existing sessions with the peers in order to re-learn the discarded bindings. The implementation is optimized to reset only those sessions which were previously known to be dual-stack and had sent bindings for both address families.

LDP uses IPv6 adjacency information instead of IP address to map an IPv6 link-local nexthop to an LDP peer.

In addition to other usual checks before using a label from nexthop LDP peer, LDP uses the nexthop label for a prefix of a given address family, if there are one or more LDP hello adjacencies of the same address family type established with the peer.

LDP allows a user to configure label policies for allocation, acceptance, receipt, and advertisement of labels for the given prefixes.

Following are the significant points pertaining to the IPv6 support for label policies:

• Label policies and their configurations are allowed under address family IPv6.

• Any policy that specifies prefix or a set of prefixes through an ACL, supports both IPv4 and IPv6 variants for address(s) or ACLs.

• Any policy that specifies peer address or set of peer addresses through an ACL, supports both IPv4 and IPv6 variant for peer address(s) or ACL.

• Any policy that specifies the peer’s LSR ID in a peer ACL continues to take IPv4 ACL based policy irrespective of the feature configuration.

Intermediate System-to-Intermediate System (IS-IS) is an Interior Gateway Protocol (IGP) that advertises link-state information throughout the network to create a picture of the network topology. IPv6 IS-IS extends the address families supported by IS-IS to include IPv6, in addition to IPv4.

Previously, IS-IS supported registration of only LDP IPv4 sync status change. This has now been enhanced to support registration of notifications of LDP IPv6 sync status change. IS-IS determines the link-metrics to be advertised based on the LDP-IGP sync status on the IPv4 and IPv6 address families.

IS-IS supports non-stop forwarding (NSF) by preserving the LDPv6-IGP sync status across high availability (HA) events of IS-IS process restarts and failover.

IS-IS also supports LDPv6-IGP sync for LFA-FRR by checking the sync status of the backup interface (if it is configured with LDP IPv6 sync).

The compliance check prevents sessions being formed with prior RFC 7552 implementation of LDP IPv6.

If the dual-stack capability TLV is not present in the received Hellos and the compliance check is configured, the local and remote preferences must match to establish a session. If the preferences do not match, the LDP Hellos are dropped and the session is not established. Compliance check has therefore been disabled by default.

Use the command neighbor dual-stack tlv-compliance in MPLS LDP configuration to enable the compliance check.

This example shows how to configure LDP for non-directly connected routers.

RP/0/RSP0/CPU0:router# configure
RP/0/RSP0/CPU0:router(config)# mpls ldp
RP/0/RSP0/CPU0:router(config-ldp)# router-id 192.0.2.1
RP/0/RSP0/CPU0:router(config-ldp)# neighbor 198.51.100.1:0 password encrypted 13061E010803
RP/0/RSP0/CPU0:router(config-ldp)# address-family ipv4
RP/0/RSP0/CPU0:router(config-ldp-af)# discovery targeted-hello accept
RP/0/RSP0/CPU0:router(config-ldp-af)# neighbor 198.51.100.1 targeted
RP/0/RSP0/CPU0:router(config-ldp-af)# commit

This section shows the LDP targeted neighbor running configuration.

mpls ldp
router-id 192.0.2.1
neighbor 198.51.100.1:0 password encrypted 13061E010803
address-family ipv4
  discovery targeted-hello accept
  neighbor 198.51.100.1 targeted
!

RP/0/RSP0/CPU0:router#show mpls ldp discovery
Wed Nov 28 04:30:31.862 UTC
 
Local LDP Identifier: 192.0.2.1:0
Discovery Sources:
  Targeted Hellos:  <<< targeted hellos based session
    192.0.2.1 -> 198.51.100.1(active/passive), xmit/recv   <<< both transmit and receive of targeted hellos between the neighbors
      LDP Id: 198.51.100.1:0
          Hold time: 90 sec (local:90 sec, peer:90 sec)
          Established: Nov 28 04:19:55.340 (00:10:36 ago)

RP/0/RSP0/CPU0:router#show mpls ldp neigbhor
Wed Nov 28 04:30:38.272 UTC
 
Peer LDP Identifier: 198.51.100.1:0
  TCP connection: 198.51.100.1:0:13183 - 192.0.2.1:646; MD5 on
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 20/20; Downstream-Unsolicited
  Up time: 00:10:30
  LDP Discovery Sources:
    IPv4: (1)
      Targeted Hello (192.0.2.1 -> 198.51.100.1, active/passive) <<< targeted LDP based session
    IPv6: (0)
  Addresses bound to this peer:
    IPv4: (4)
     198.51.100.1        10.0.0.1       172.16.0.1       192.168.0.1 
    IPv6: (0)