[L1vpn] Your Discusses and Comments on draft-ietf-l1vpn-bgp-auto-discovery-04.txt
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 15 May 2008 14:08 UTC
Return-Path: <l1vpn-bounces@ietf.org>
X-Original-To: l1vpn-archive@megatron.ietf.org
Delivered-To: ietfarch-l1vpn-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C313A6940; Thu, 15 May 2008 07:08:37 -0700 (PDT)
X-Original-To: l1vpn@core3.amsl.com
Delivered-To: l1vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9B33A6940 for <l1vpn@core3.amsl.com>; Thu, 15 May 2008 07:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.815
X-Spam-Level:
X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbeQbZC8reGi for <l1vpn@core3.amsl.com>; Thu, 15 May 2008 07:08:21 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 320673A68DD for <l1vpn@ietf.org>; Thu, 15 May 2008 07:08:20 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m4EIHahY003355; Wed, 14 May 2008 19:17:36 +0100
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m4EIHXBl003336; Wed, 14 May 2008 19:17:35 +0100
Message-ID: <02a101c8b5ee$c6768880$0200a8c0@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: dward@cisco.com, Pasi.Eronen@nokia.com, tim.polk@nist.gov
Date: Wed, 14 May 2008 19:17:17 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Cc: l1vpn@ietf.org
Subject: [L1vpn] Your Discusses and Comments on draft-ietf-l1vpn-bgp-auto-discovery-04.txt
X-BeenThere: l1vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Layer 1 Virtual Private Networks <l1vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l1vpn>, <mailto:l1vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/l1vpn>
List-Post: <mailto:l1vpn@ietf.org>
List-Help: <mailto:l1vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l1vpn>, <mailto:l1vpn-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: l1vpn-bounces@ietf.org
Errors-To: l1vpn-bounces@ietf.org
Hi, The editor has made a new version of this draft based on your issues and the subsequent email exchanges. > http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-bgp-auto-discovery-05.txt We hope that the changes (summarised below alongside your coments) address your points and you can clear your Discusses. Thanks, Adrian === > Pasi Eronen: > > Discuss [2008-05-05]: > Process comment: Sandy Murphy's SecDir review needs a response. > > As noted in Sandy Murphy's SecDir review, this document seems to > expand the L1VPN concept significantly beyond the scope of RFC 4847 > and draft-ietf-l1vpn-applicability-basic-mode, both of which > explicitly rule out inter-as/inter-provider L1VPNs. Expanding the > scope of inter-AS/inter-provider VPNs makes the assumption about > transitive trust of all BGP speakers rather dubious. The I-D has been updated to make clear that inter-AS/inter-provider are out of scope. The following paragraph has been added to the end of Section 2. Although multi-AS L1VPNs are currently out of scope for the Basic Mode, the mechanisms defined in this document appear to be easily applicable to a multi-AS scenario should such a need arise in the future. At that time additional work may be required to examine various aspects including security. === > Pasi Eronen: > > Comment [2008-05-05]: > Sandy's SecDir review also identified a number of places that would > benefit from some clarification of the text, and provided editorial > comments that should be taken into acccount. We believe these have been picked up, discussed with Sandy as necessary, and fixed in the new I-D. === > Tim Polk: > > Comment [2008-05-08]: > Sandy Murphy has asked what happens if the basic security assumption > does not hold. > > Given the importance of the basic trust assumption - all the participants > are trustworthy, and trust is transitive - it would also be nice if the > security considerations noted *why* the wg feels this is a reasonable > assumption. (I assume it is based on the fact that all the peers are > members of the same provider network?) This is fixed by a simple addition right at the end of Section 6. This points out that the restriction of the technique to a single provider network means that the trust model is much more applicable. _______________________________________________ L1vpn mailing list L1vpn@ietf.org https://www.ietf.org/mailman/listinfo/l1vpn
- [L1vpn] Your Discusses and Comments on draft-ietf… Adrian Farrel
- Re: [L1vpn] Your Discusses and Comments on draft-… Pasi.Eronen