Re: Info aggregation

Eric,

Eric Rosen wrote:
> 
> Cheng-Yin> Are the  proponents of  these models considering  loop prevention
> Cheng-Yin> measures?
> 
> Once the  PWs are  properly set up  according to the  provisioned hierarchy,
> split  horizon   prevents  loops.   Perhaps  you  are   asking  whether  the
> auto-discovery process  can be guaranteed to provide  the information needed
> to  set up  a cycle-free  hierarchy, even  in the  presence  of provisioning
> errors.
In this case, I am concerned with loops caused by provisioning errors
(could be in the hierarchy, or in the mesh itself). I am not sure if an
end customer would tolerate even one such service disruption, and how
viable the solution is without some kind of loop prevention.

> With BGP-based auto-discovery,  this could be an issue if  the pws needed to
> go through  an arbitrary set of  ASes,
But I think loops may form even with just 2 ASes (and even within one
AS).

> each of  which summarizes information
> from its  neighbors before passing it on.   If we wanted to  support a model
> like that, we could  use AS-path to prevent loops.  But I'm  not at all sure
> that that would be  useful, as I don't think we want  the VPLS pws to travel
> through arbitrary sets of ASes. 
I am not sure if using AS-path is sufficient as the devices (PEs or
others) doing the multipoint switching (VPLS forwarding) need to be
involved in loop prevention.

> Cheng-Yin> How  to aggregate  VPLS membership  ID, VPLS_ID/VPN_ID  ?  (cf IP
> Cheng-Yin> addresses/routes can be aggregated).
> 
> VPN ids obviously cannot be aggregated.  Probably the best we can do is make
> the inter-AS  discovery process scale  linearly with the number  of inter-AS
> VPLSes. But  I don't really think the  discovery process is going  to be the
> bottleneck here.
Perhaps not, especially if there are going to be few VPLS instances, and
there are other aspects of the service (e.g. in the forwarding plane)
which will need to be resolved first.

Thanks
Cheng-Yin