Plane Only - Alcatel-Lucent 7450 Manual

The SR OS LDP implementation does not interoperate with an implementation using a 32-bit
LSR-ID as defined in draft-ietf-mpls-ldp-ipv6 to establish an IPv6 LDP session. The latter
specifies an LSR can send both IPv4 and IPv6 Hellos over an interface such that it can establish
either an IPv4 or an IPv6 LDP session with LSRs on the same subnet. It thus does not allow for
separate LDP IPv4 and LDP IPv6 LDP sessions between two routers.
The SR OS LDP implementation should interoperate with an implementation using a 32-bit LSR-
ID as defined in draft-ietf-mpls-ldp-ipv6 to establish an IPv4 LDP session and to resolve both IPv4
and IPv6 prefix FECs.
The SR OS LDP implementation otherwise complies with all other aspects of draft-ietf-mpls-ldp-
ipv6, including the support of the dual-stack capability TLV in the Hello message. The latter is
used by an LSR to inform its peer that it is capable of establishing either an LDP IPv4 or LDP
IPv6 session and to convey the IP family preference for the LDP Hello adjacency and thus for the
resulting LDP session. This is required because the implementation described in draft-ietf-mpls-
ldp-ipv6 allows for a single session between LSRs, and both LSRs must agree if the session should
be brought up using IPv4 or IPv6 when both IPv4 and IPv6 Hellos are exchanged between the two
LSRs. The SR OS implementation has a separate session for each IP family between two LSRs
and, as such, this TLV is used to indicate the family preference and to also indicate that it supports
resolving IPv6 FECs over an IPv4 LDP session.
Interoperability with Implementations Compliant with RFC 5036 for IPv4
LDP Control Plane Only
This implementation supports advertising and resolving IPv6 prefix FECs over an LDP IPv4
session using a 32-bit LSR-ID in compliance with draft-ietf-mpls-ldp-ipv6. When introducing an
LSR based on the SR OS in a LAN with a broadcast interface, it can peer with third party LSR
implementations which support draft-ietf-mpls-ldp-ipv6 and LSRs which do not. When its peers
using IPv4 LDP control plane with a third-party LSR implementation which does not support it,
the advertisement of IPv6 addresses or IPv6 FECs to that peer may cause it to bring down the IPv4
LDP session.
In other words, there are deployed third-party LDP implementations which are compliant with
RFC 5036 for LDP IPv4, but which are not compliant with RFC 5036 for handling IPv6 address
or IPv6 FECs over an LDP IPv4 session. To address this issue, draft-ietf-mpls-ldp-ipv6 modifies
RFC 5036 by requiring implementations complying with draft-ietf-mpls-ldp-ipv6 to check for the
dual-stack capability TLV in the IPv4 Hello message from the peer. Without the peer advertising
this TLV, an LSR must not send IPv6 addresses and FECs to that peer. SR OS implementation
implements this change.
7450 ESS MPLS Guide
Label Distribution Protocol
Page 615