Re: Info aggregation

Eric, Alex,

Eric Rosen wrote:
> 
> Alex> Some more questions here: when taken to a large scale
> Alex> (not necessarily just one VPLS)
> 
> Alex> o what VPLS info from other AS'es do PEs need to know?
> 
> Vach has been pushing a hierarchical model, in which, for each VPLS, each AS
> has a "gateway" that only needs to  know how to reach a gateway in the other
> ASes, and  within an AS,  each PE only  needs to know  how to reach  its own
> gateway.
> 
> I've been  pushing a somewhat different model  in which each PE  has to know
> how to reach its gateway (to a  particular AS), and has to know how many PEs
> supporting that  same VPLS there  are in  the other AS.   A PE sets  up that
> number of pseudowires  to the gateway, which splices  them together with pws
> that go to  the next AS.  (The splicing can  be done in such a  way as to be
> transparent to  the forwarding  plane, though some  have suggested  that the
> gateway  might  need  to  be  an  OAM  boundary,  even  if  that  sacrifices
> scalability.)
Are the proponents of these models considering loop prevention measures? 
 
> Both  models provide  a good  summarization of  information, I  think.  They
> differ  in regard  to the  amount and  kind of  state needed  in the  PEs as
> opposed to the gateway.  The hierarchical  model helps with the scale of the
> individual PEs, but  requires MAC lookup in the  gateways, and also requires
> of course that a hierarchy be provisioned.
> 
> (I hope I've not done Vach's model too much of an injustice.)
> 
> Alex>  o given the edge-to-edge nature of PWs, is it feasible
> Alex>    to summarize signalling information among AS'es at all?
> 
> Both models bound the number  of signaling inter-AS connections, so that the
> number of  these connections does not grow  as the number of  PEs grows. The
> hierarchical model limits some of the signaling information to the hierarchy
> boundaries.
I think this is limiting distribution of L2VPN info to a smaller number
of devices (this is fine, disregarding forwarding loops and resiliency
for now). In what scenario will it reduce the amount of L2VPN info on
the devices where this information is distributed? 

> 
> Alex>  o if not, how do we scope distribution of signalling info
> Alex>    so amount of info per participating node has reasonable
> Alex>    growth characteristics?
> 
> I think it is impossible to make L2 scale as well as L3, because of the flat
> and non-aggregatable  address space,  and because of  the need  to multicast
> packets with  unknown DAs.  
Yes.

> However, whereas  we want our L3  networks to be
> able to grow  without bound, I don't think the  same requirement exists with
> respect to L2 networks.
I would like to understand what this requirement means. 
If we consider IP and Ethernet (not network based VPLS/VPN), then yes,
if a LAN becomes large we can subnet it and interconnect the subnets
with IP. Similarly for end customer IP VPN and LAN.

If the L2 network is required to support VPLS sites in different SP
networks or regions, using network based VPLS, does this imply the
network based VPLS solution should scale for large networks (i.e. PEs
should be able to support a large number of total VPLS instances)?
Or are we saying, only a few SP networks or regions can be
interconnected to offer VPLS because:
i) that's all we need or 
ii) it seems we cannot really scale network based VPLS or/and another
solution would be needed to allow large number of VPLS instances
offering?

> Alex>  o is it feasible to summarize VPLS membership information
> Alex>    among AS'es?
How to aggregate VPLS membership ID, VPLS_ID/VPN_ID ? (cf IP
addresses/routes can be aggregated).

Thanks,
Cheng-Yin