Hi Mark,
The issue will exist on a p2p link but in that case you could always add a
per-interface configuration knob which disables the dual-stack behavior and
will prevent sending IPv6 FECs and IPv6 addresses over a session on that link.
Regards,
Mustapha.
-----Original Message-----
From: Mark Tinka [mailto:mark(_dot_)tinka(_at_)seacom(_dot_)mu]
Sent: Wednesday, December 17, 2014 3:18 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; IETF-Announce
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to
LDP for
IPv6) to Proposed Standard
On Wednesday, December 17, 2014 03:26:54 PM Aissaoui, Mustapha (Mustapha)
wrote:
It is actually testing against existing LDP IPv4 implementations when
the LSR compliant to this draft sends LDP IPv6 FECs and LDP IPv6
addresses over the LDP
IPv4 session.
Here is a brief summary of the issues as I described to the list this
summer: "
When an LSR which supports LDP IPv6 according to this draft is in a
LAN with a broadcast interface, it can peer with LSRs which support
this draft and LSRs which do not. When it peers using IPv4 LDP control
plane with an LSR which does not support this draft, we have seen
during our testing an issue that the advertisement of
IPv6 addresses or IPv6 FECs to that peer will cause it to bring down
the IPv4 LDP session.
In other words, there are deployed LDP implementations which are
compliant to RFC 5036 for LDP IPv4 but are not compliant to RFC 5036
when it comes to handling IPv6 address or IPv6 FECs over an LDP IPv4
session. This is making us very concerned that when users enable
dual-stack LDP IPv4/IPv6, they will bring down LDP IPv4 sessions which
have been working in a multi-vendor environments for so many years. "
Thanks for the explanation, Mustapha.
Operationally, sounds a bit like IS-IS in a mixed single and dual stack
environment,
but with IS-IS running in ST (Single
Topology) mode.
Of course, the IS-IS solution is to support MT (Multi-
Topology) so that adjacencies between a single stack and dual stack device
work
just fine.
I realize I'm simplifying things a bit, but not sure if we can borrow a leaf
from the IS-
IS solution, if we are going to implement an integrated LDPv4/LDPv6 in the
same
code base.
One more question - are you implying that this issue is not present in a
point-to-point
topology?
Mark.