Subject: [L1vpn] Good discussions

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 13 May 2006 15:19:57 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/l1vpn

---

From: Acee Lindem <[email-masked]>
Date: Wed, 17 May 2006 17:16:04 -0400

Hi Adrian,

Adrian Farrel wrote:

> 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.
>
> 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 (!)
> Comparison is useful to pick up on lessons learned elsewhere. It is 
> valuable to consider how operators might operate VPNs across the board.
> BUT (!)
> 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 (!)
> 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 
> 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.
> 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.

If there is no requirement to ever offer these L1VPN services outside of 
the
environment described above then I'm less concerned with overloading 
OSPF or
compatibility with :L2/L3 VPNs where BGP or LDP are used. As I
stated in my previous post, I'd ask that this be clearly stated in the 
request for
the IANA opaque LSA allocation.

Additionally, being judicious about which applications use OSPF for
information dissemination is not new nor a product of my invention. This is
due to a number of factors including the desire to minimize OSPF 
flooding in
order to minimize convergence time and maximize IGP robustness. It is 
also due
to all the experience we have solving these types of problems with BGP and
the BGP's ability to support policy on a peer basis.

Thanks,
Acee