Subject: Info aggregation

From: Alex Zinin <[email-masked]>
Date: Sat, 3 May 2003 18:27:34 -0700

Mark Seery <[email-masked]> wrote:
...
> In section 3. you raise the important attribute of
> scaling - summarization. Would you agree that all
> inter-domain proposals should address this issue? 

Definitely.

The point in my message was to identify the difference
between the way _BGP_ operates as an IP routing protocol
where we know information can be aggregated, and the way
_BGP_ would be used for VPLS. Nonetheless, this is an
important generic issue I think the WG should discuss.
Some data points for discussion below:

> Also with respect to summarization, is the inability
> to summarize a function of the proposal in question,
> or a function of the fact that Ethernet does not have
> a summarizable address plane/structure (in L3VPNs even
> though a VPN idenitifer is required IP prefixes are
> still basically being used - I believe?). So without a
> good address plane for scalable networking, we are
> left with signaling names: VE IDs, PE IDs, VPLS IDs,
> Group IDs etc. What we are really dealing with here is
> members of a set, not subnetworks. Do we qualify these
> names? Do we create relationships for sets, and
> subsets,......Seems like this basic issue has to be
> dealt with.

Indeed.
Some more questions here: when taken to a large scale
(not necessarily just one VPLS)

 o what VPLS info from other AS'es do PEs need to know?

 o given the edge-to-edge nature of PWs, is it feasible
   to summarize signalling information among AS'es at all?

 o if not, how do we scope distribution of signalling info
   so amount of info per participating node has reasonable
   growth characteristics?

 o is it feasible to summarize VPLS membership information
   among AS'es?

 o how do we get discovery, signaling, and data plane to work
   together in a scalable form?

This topic is related to the one about whether intra-AS and
inter-AS problem spaces should be addressed separately, which
I will also comment on.
   
Alex

> So strangely enough, multicast (where PEs
> in a VPLS are in the same multicast group) addresses
> this issue very nicely - if we stick to the concept of
> a LAN segment. If we continue to put more and more
> bridging functionality within a PE, then I think
> multicast is limited in its ability to address this
> problem, i.e. how many members are there in each
> multicast group when every PE is a bridge?

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 05 May 2003 11:57:25 -0700

Alex,

[clipped...]
 
> (not necessarily just one VPLS)

few more questions - see in-line... 

>  o what VPLS info from other AS'es do PEs need to know?

   - what VPLS info from other PEs do PEs need to know? Is that
     different when PEs are in the same AS vs in different ASs ?
>    so amount of info per participating node has reasonable

   - given the edge-to-edge nature of PWs, is it feasible
     to have a PW between a pair of PEs without requiring
     signaling peering between these PEs ?

   - if not, how do we scope the amount of signaling
     peering required ?

   - what is the addition overhead (in addition to the overhead
     associated with autodiscovery), if any, associated with
     distribution of signaling info ?
  
>  o is it feasible to summarize VPLS membership information

    if not, how to we scope distribution of membership info
    so amount of info per participating node has reasonable
    growth characteristics ?
  
>    together in a scalable form?

Yakov.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 12 May 2003 14:50:24 -0400

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.) 

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.

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.  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.

Alex>  o is it feasible to summarize VPLS membership information
Alex>    among AS'es? 

Yes, to a certain extent, as explained above.

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 13 May 2003 15:54:42 -0400

Eric, Alex,

> gateway  might  need  to  be  an  OAM  boundary,  even  if  that  sacrifices
Are the proponents of these models considering loop prevention measures? 
 
> hierarchical model limits some of the signaling information to the hierarchy
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? 

> packets with  unknown DAs.  
Yes.

> However, whereas  we want our L3  networks to be
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
How to aggregate VPLS membership ID, VPLS_ID/VPN_ID ? (cf IP
addresses/routes can be aggregated).

Thanks,
Cheng-Yin

---

From: "Vach Kompella" <[email-masked]>
Date: Tue, 13 May 2003 13:23:24 -0700

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-masked]]
> Sent: Tuesday, May 13, 2003 12:55 PM
> To: [email-masked]
> Cc: Alex Zinin; [email-masked]
> Subject: Re: Info aggregation
>
>
> Eric, Alex,
>
> Eric Rosen wrote:
> >

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 13 May 2003 16:34:57 -0400

Vach,
Would you be addressing loops due to misconfiguration e.g. in the
gateway hierarchy?

Thanks
Cheng-Yin

---

From: Eric Rosen <[email-masked]>
Date: Wed, 14 May 2003 11:07:16 -0400

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.  

With BGP-based auto-discovery,  this could be an issue if  the pws needed to
go through  an arbitrary set of  ASes, 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. 

Eric> Both  models bound the  number of  signaling inter-AS  connections, so
Eric> that the  number of these connections  does not grow as  the number of
Eric> PEs  grows.  The  hierarchical  model  limits some  of  the  signaling
Eric> information to the hierarchy boundaries. 

Cheng-Yin> I think this is limiting  distribution of L2VPN info to a smaller
Cheng-Yin> number of devices

I don't think so, when you impose hierarchy or add inter-AS gateways you are
explicitly  distributing the info  to more  devices, in  order to  bound the
amount of something or other that each device must deal with. 

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.

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Thu, 15 May 2003 17:11:13 -0400

Eric,

> to  set up  a cycle-free  hierarchy, even  in the  presence  of provisioning
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.

> 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
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.

> VPLSes. But  I don't really think the  discovery process is going  to be the
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