IETF Logo Mail Archive

Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

Mark Tinka <mark.tinka@seacom.mu> Sun, 12 January 2014 12:02 UTC

Return-Path: <mark.tinka@seacom.mu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAF41ADF23 for <mpls@ietfa.amsl.com>; Sun, 12 Jan 2014 04:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.589
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDmsZImkZ27b for <mpls@ietfa.amsl.com>; Sun, 12 Jan 2014 04:02:00 -0800 (PST)
Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5A61ADE84 for <mpls@ietf.org>; Sun, 12 Jan 2014 04:01:59 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from <mark.tinka@seacom.mu>) id 1W2JjX-0007Cf-P8; Sun, 12 Jan 2014 14:01:39 +0200
From: Mark Tinka <mark.tinka@seacom.mu>
Organization: SEACOM
To: adrian@olddog.co.uk
Date: Sun, 12 Jan 2014 14:01:35 +0200
User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; )
References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> <201401091646.48102.mark.tinka@seacom.mu> <029901cf0d53$5beb7d00$13c27700$@olddog.co.uk>
In-Reply-To: <029901cf0d53$5beb7d00$13c27700$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6815982.1QttyuDH4S"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <201401121401.39144.mark.tinka@seacom.mu>
Cc: mpls@ietf.org, stephen.farrell@cs.tcd.ie
Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mark.tinka@seacom.mu
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jan 2014 12:02:02 -0000

On Thursday, January 09, 2014 05:56:24 PM Adrian Farrel 
wrote:

> I don't get this.
> Only the end points of the encryption need to be aware of
> it. It is only used when the end points agree to do it.
> If one end point does not agree we have status quo. If
> both end points agree then the transit points (if they
> exist) don't participate.

Thanks, Adrian. This clarifies, then.

I just wanted to make sure that if one end supports 
encryption (and independently encrypts the flow) while the 
other end does not, we don't lose traffic.

As you explain, both ends must agree to OE support before 
anything can happen, and if they don't, existing forwarding 
paradigms remain in place, which is fine by me.

Mark.

v2.23.0 | Report a Bug | By Email