Re: [L1vpn] Good discussions

[Acee Lindem <[e-mail]>]

Hi Adrian,

Adrian Farrel wrote:

> 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.

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


>
> Thanks,
> Adrian
>
>
> _______________________________________________
> L1vpn mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/l1vpn
>

_______________________________________________
L1vpn mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l1vpn