[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
There is a draft in CCAMP that I want to bounce off the OSPF working group.
draft-ietf-ccamp-automesh-01.txt uses the new opaque LSA defined in
draft-ietf-ospf-cap-08.txt in order to carry information about "mesh
groups". Members of mesh groups would be connected together by tunnels to
provide a sub-mesh across the network.
There are many applicabilities of this feature, but it is wanted in CCAMP to
allow the construction of a mesh of MPLS-TE tunnels between a set of MPLS
label switching routers (LSRs) within the network. This set might be a
sub-set of the PEs, or might be a sub-set of the P-routers used to build a
The management of the mesh membership information is not the responsibility
of the IGP. Rather, this is opaque information that is delivered to an
application. Thus, SPF is acting as a transport for routing-related
Any router may be a member of more than one mesh group, and many routers
might not be in any mesh group (consider the PE mesh case where all
P-routers are not in the group).
My questions to you:
1. Is it a concern that P-routers are being used to store and forward
opaque information only needed by a small subset of the routers
in the network?
2. Is there a scaling concern that there is no control on the number of
mesh groups that may exist, nor the number of mesh groups to
which any router can belong?
This question arises in the context of
draft-bryskin-l1vpn-ospf-auto-discovery-01.txt that is being discussed in
the L1VPN working group. This I-D proposes to use the IGPs (specifically
OSPF) to distribute information about which VPNs can be accessed through the
PEs (not general VPN membership or reachability information, but just a list
of VPN IDs and the link I-Ds that are used to reach them). Loud voices have
been raised in L1VPN about the scalability and appropriateness of such an
idea, and since it seems to be very similar to automesh, I want to see
whether you all think there is a problem with automesh.