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
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
