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

Mark Tinka <> Wed, 17 December 2014 20:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 720151A874E; Wed, 17 Dec 2014 12:17:51 -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 Bo8zjiPrKVYe; Wed, 17 Dec 2014 12:17:49 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BB591A86F7; Wed, 17 Dec 2014 12:17:49 -0800 (PST)
Received: from localhost ([] helo=the-host.localnet) by with esmtp (Exim 4.80.1) (envelope-from <>) id 1Y1L2U-0001Lb-L8; Wed, 17 Dec 2014 22:17:42 +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: Wed, 17 Dec 2014 22:17:38 +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="nextPart2135838.YQI8hhhvAA"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <>
X-Mailman-Approved-At: Thu, 18 Dec 2014 08:30:02 -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: Wed, 17 Dec 2014 20:17:51 -0000

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 

One more question - are you implying that this issue is not 
present in a point-to-point topology?