[L1vpn] Good discussions
"Adrian Farrel" <adrian@olddog.co.uk> Sat, 13 May 2006 18:45 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fez72-0002eV-Oi; Sat, 13 May 2006 14:45:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fez72-0002eQ-7h for l1vpn@ietf.org; Sat, 13 May 2006 14:45:12 -0400
Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fez6z-0005YH-Jn for l1vpn@ietf.org; Sat, 13 May 2006 14:45:12 -0400
Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1Fez6u-00080N-00 for l1vpn@ietf.org; Sat, 13 May 2006 19:45:04 +0100
Received: from your029b8cecfe ([217.158.132.10] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 May 2006 19:45:07 +0100
Message-ID: <00e301c676bc$f969fd80$0a23fea9@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: l1vpn@ietf.org
Date: Sat, 13 May 2006 15:19:57 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 13 May 2006 18:45:07.0965 (UTC) FILETIME=[5B523AD0:01C676BD]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc:
Subject: [L1vpn] Good discussions
X-BeenThere: l1vpn@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Layer 1 Virtual Private Networks <l1vpn.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l1vpn>, <mailto:l1vpn-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/l1vpn>
List-Post: <mailto:l1vpn@lists.ietf.org>
List-Help: <mailto:l1vpn-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l1vpn>, <mailto:l1vpn-request@lists.ietf.org?subject=subscribe>
Errors-To: l1vpn-bounces@lists.ietf.org
Hi, It is good to see some constructive discussions on this list. I want to pick out a few points with a few to edging towards something that passes for consensus. I am not specifically supporting (or denying) the OSPF solution, but I have seen a lot of misconceptions that need to be smoothed out. 1. Basic mode or Extended mode You are all encouraged to think about the extended mode requirements and the four models (including the per-VPN model). It is useful to kick start this discussion, and valuable to look at how proposed discovery solutions might work in the extended model. BUT (!) - The working group is focused on developing protocol solutions for the basic mode at the moment. - There are four extended mode solutions and it is *far* from clear that the working group wants to support all four of them. 2. Comparison with L2/3 VPN work Comparison is useful to pick up on lessons learned elsewhere. It is valuable to consider how operators might operate VPNs across the board. BUT (!) - We must be clear that the L1VPN service is selling L1 connectivity. There is no packet-based VPN here. The quote "I don't see why one would want to offer VPNs on top of these [L1 networks] without intervening L3 networks" entirely misses the point of the L1VPN working group! I suggest that contributors need to at least read the charter, but also the framework I-D. 3. Scaling There was a comment along the lines of the information in the IGP being bounded by the routing domain, but the information in the VPN being out of that control and bounded by information in the VPN(s). For L1VPNs in the basic mode this is not true. The information is bounded by the routing domain, but modified by the number of VPNs that can connect. Since we use a per-port model for VPN connectivity, the information is effectively bounded by the routing domain. NOTE very clearly (!) - In the basic mode, no VPN *site* membership is flooded across or within the core network. When we discuss "VPN membership" we mean that we are identifying which PEs have access to which VPNs. 4. Automesh The Automesh I-D in CCAMP (draft-ietf-ccamp-automesh-01.txt) builds on a piece of work in the OSPF working group (draft-ietf-ospf-cap-08.txt). This defines a new opaque LSA (the router information LSA) which can carry TLVs. The use of this new LSA for automesh is actually almost identical to that proposed for L1VPN membership, and I believe that one of the proposed uses of automesh is to set up a full mesh of TE tunnels between the PEs that provide access to the same VPN. In fact, the automesh draft is targeted at IP/MPLS networks so the scaling concerns of automesh must be at least greater than those for L1VPN. I will be taking up the scaling issues associated with automesh with the OSPF working group in the context of CCAMP. 5. Policy My view of why one would apply policy to the distribution of VPN membership information is that it relates to scaling and to confidentiality. - Scaling has been pretty well discussed, and there is also a note above. It might be that in the future we need a solution that scales much better than anything that an IGP can achieve. Let us all hope for such successful and widespread deployments of L1VPN in particular and GMPLS in general. - Confidentiality relates to the spread of information between networks. This is important if VPN internal information can leak from one VPN to another. But in L1VPN basic mode a. there is no exchange of information from the core to the VPN b. no VPN information is distributed through the core So this question simply does not arises. All VPN membership information that we are discussing is already present in the core and we are simply debating how to get this information between nodes within the core. 6. WG status / Experimental / Informational It is certainly the case that a working group draft can be informational or experimental. This discussion should not stop the working group adopting any draft. Further, those who participated in the discussion in Dallas should be very clear that there was an agreement not to have a beauty contest at this stage, but to see how things developed and let the market decide. People who expressed that opinion and who now find their preferred I-D adopted as a WG I-D would do well to maintain the opinion they expressed in Dallas. To me it seems that several vendors of optical equipment are expressing the view that this is the solution that they want to build, and I have not currently seen any overwhelming technical issues blocking the working group from looking at this work further (please tell me why I am wrong). However, I am concerned by the continued opposition from the chair of the OSPF working group and feel that we need to follow this up further. Thanks, Adrian _______________________________________________ L1vpn mailing list L1vpn@lists.ietf.org https://www1.ietf.org/mailman/listinfo/l1vpn
- [L1vpn] Good discussions Adrian Farrel
- Re: [L1vpn] Good discussions Acee Lindem