Hi Mark, both proposed methods to solve this LDP backward compatibility issue rely on detecting a specific TLV from the peer. So, the absence of the TLV will indicate that the peer LSR is not compliant to the LDP IPv6 draft in a similar way ISIS uses the absence of the Multi-Topology TLV to consider the neighbor is MT=0 capable only. So there is no need for a CLI knob. What we were debating is if we should use the LDP capability TLV mechanism which LDP uses to advertise any new capability not supported by previous implementations versus overloading another TLV which was not meant for capability discovery. Mustapha. > -----Original Message----- > From: Mark Tinka [mailto:mark.tinka@xxxxxxxxx] > Sent: Thursday, December 18, 2014 11:28 AM > 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 Thursday, December 18, 2014 05:38:16 PM Aissaoui, Mustapha (Mustapha) > wrote: > > > Hi Mark, > > The issue will exist on a p2p link... > > Yes, figured as much. > > > 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. > > Yes, easier to do on a point-to-point link compared to a broadcast network. > > That said, I'm still for more of an MT-type solution a la IS-IS, so that this applies to > the entire protocol. This way, operators do not have to fuff around with yet-another- > knob (until they really have to). > > Any thoughts around this? > > Cheers, > > Mark.