RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard

["Aissaoui, Mustapha (Mustapha)" <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, December 17, 2014 3:18 PM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: [e-mail]; [e-mail]; 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.