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

Mark Tinka <> Fri, 19 December 2014 12:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9E5FF1A6F7F; Fri, 19 Dec 2014 04:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.589
X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0EQ-p0qYZW4D; Fri, 19 Dec 2014 04:24:56 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C12C1A6F2E; Fri, 19 Dec 2014 04:24:55 -0800 (PST)
Received: from localhost ([] helo=the-host.localnet) by with esmtp (Exim 4.80.1) (envelope-from <>) id 1Y1wbu-0008S5-R4; Fri, 19 Dec 2014 14:24:46 +0200
From: Mark Tinka <>
Organization: SEACOM
To: "Aissaoui, Mustapha (Mustapha)" <>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard
Date: Fri, 19 Dec 2014 14:24:45 +0200
User-Agent: KMail/1.13.6 (Linux/; KDE/4.6.0; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2618500.qoVPgfzSpL"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <>
X-Mailman-Approved-At: Fri, 19 Dec 2014 09:57:38 -0800
Cc: "" <>, "" <>, IETF-Announce <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Dec 2014 12:24:57 -0000

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