IETF Logo Mail Archive

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

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 09 January 2014 15:56 UTC

Return-Path: <adrian@olddog.co.uk>
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 95E421AE435 for <mpls@ietfa.amsl.com>; Thu, 9 Jan 2014 07:56:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level:
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 PZhJKe90qJ1C for <mpls@ietfa.amsl.com>; Thu, 9 Jan 2014 07:56:49 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 463C31AE43B for <mpls@ietf.org>; Thu, 9 Jan 2014 07:56:42 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09FuUCm017898; Thu, 9 Jan 2014 15:56:30 GMT
Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09FuPlm017833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 15:56:27 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: mark.tinka@seacom.mu
References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> <201401091514.32953.mark.tinka@seacom.mu> <022b01cf0d45$5566f8f0$0034ead0$@olddog.co.uk> <201401091646.48102.mark.tinka@seacom.mu>
In-Reply-To: <201401091646.48102.mark.tinka@seacom.mu>
Date: Thu, 09 Jan 2014 15:56:24 -0000
Message-ID: <029901cf0d53$5beb7d00$13c27700$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMUV0gQu98E8zPvuS9WnPXs2HJTsgISsrp2ATum82gCb2dYC5fECXPw
Content-Language: en-gb
X-TM-AS-MML: No
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: adrian@olddog.co.uk
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: Thu, 09 Jan 2014 15:56:51 -0000

Hi again Mark,

Just pursuing one point...

> > Transit nodes (and so domains) do not
> > need to be aware of the encryption which is below the
> > top labels and potentially below the entropy label. End
> > nodes that do not support will, erm, not support :-)
> 
> Given LSP's can interconnect various nodes in the same
> domain in any number of ways, OE would require all MPLS
> nodes support it in unison, to avoid global domain traffic
> drops, yes?

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.

So I can't fathom your statement.
Can you give me an example?

Thanks,
Adrian

v2.23.0 | Report a Bug | By Email