Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP

On Friday, December 19, 2014 01:25:15 AM Aissaoui, Mustapha 
(Mustapha) wrote:

> 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.
As an operator, having to upgrade a non-compliant device 
that is not yet ready to run LDPv6 so that a neighboring 
LDPv6-capable device planning to run LDPv6 can still form 
LDPv4 adjacencies is quite heavy-handed.

Upgrading a device for anything LDPv6 should, ideally, be in 
the interest of getting LDPv6 deployed, and not to prevent 
LDPv4 adjacency tear-down due to capability incompatibility.

On the other hand, it might be worthwhile looking into 
adding a knob for an LDPv6-compliant device to tell it to 
have backwards compatibility with non-compliant devices on 
the wire. Since one would, in all likelihood, be upgrading a 
non-compliant device to make it compliant, the heavy-hand 
makes sense here since an operator needs to get the code in 
anyway.

Mark.

signature.asc
Description: This is a digitally signed message part.