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.
Attachment:
signature.asc
Description: This is a digitally signed message part.