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(_dot_)tinka(_at_)seacom(_dot_)mu]
Sent: Thursday, December 18, 2014 11:28 AM
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 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.