[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