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.tinka@xxxxxxxxx] > Sent: Wednesday, December 17, 2014 3:18 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@xxxxxxxx; ietf@xxxxxxxx; 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.