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

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> Wed, 17 December 2014 13:27 UTC

Return-Path: <mustapha.aissaoui@alcatel-lucent.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9271A8A86; Wed, 17 Dec 2014 05:27:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2ykSdIbHaf2; Wed, 17 Dec 2014 05:27:02 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6871A8A85; Wed, 17 Dec 2014 05:27:01 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 286AD2F98A889; Wed, 17 Dec 2014 13:26:57 +0000 (GMT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id sBHDQr42006441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 08:26:58 -0500
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 08:26:54 -0500
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
To: "mark.tinka@seacom.mu" <mark.tinka@seacom.mu>, "mpls@ietf.org" <mpls@ietf.org>
Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard
Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgApvIICAACbQ0A==
Date: Wed, 17 Dec 2014 13:26:54 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340D947C2515@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> <201412170803.47595.mark.tinka@seacom.mu>
In-Reply-To: <201412170803.47595.mark.tinka@seacom.mu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/pVb6RYNTqdtb9hGvvoUzB5INd8U
X-Mailman-Approved-At: Wed, 17 Dec 2014 10:06:38 -0800
Cc: "ietf@ietf.org" <ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Dec 2014 13:27:03 -0000

Hi Mark,
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.
"

Regards,
Mustapha.

> -----Original Message-----
> From: Mark Tinka [mailto:mark.tinka@seacom.mu]
> Sent: Wednesday, December 17, 2014 1:04 AM
> To: mpls@ietf.org
> Cc: Aissaoui, Mustapha (Mustapha); ietf@ietf.org; IETF-Announce
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for
> IPv6) to Proposed Standard
> 
> On Tuesday, December 16, 2014 07:21:42 PM Aissaoui, Mustapha
> (Mustapha) wrote:
> 
> > Hi Adrian and all,
> > I was the one who raised the interop issues we found while testing our
> > implementation of LDP IPv6 against existing and deployed
> > implementations.
> 
> Mustapha, I'm curious - are testing against other LDPv6 implementations, or LDPv4
> implementations?
> 
> Mark.