[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