RE: Info aggregation

Cheng-Yin,

Stay tuned for my draft.  Yes, there are some loop issues that are addressed.
Eric jumped the gun a little when he spoke of my draft because I have been
talking to a couple of people about the requirements of the solution.

I believe Eric has captured the gist of what I am proposing.  There are two
different problems, both of which have there own positives and negatives.  E.g.,
something along the lines of 10(c) requires a 3-label stack, vc label per PE,
and the replication issues are significant.  The other approach is to have a
2-label stack learning gateway, and have it perform replications.  That way you
distribute the replication, but you incur the learning.

Both models have their uses, depending on the inter-region traffic patterns.

-Vach

> -----Original Message-----
> From: Cheng-Yin Lee [mailto:[email protected]]
> Sent: Tuesday, May 13, 2003 12:55 PM
> To: [email protected]
> Cc: Alex Zinin; [email protected]
> Subject: 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
>
>
>