Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)

[Yakov Rekhter <yakov@juniper.net>]

Lou,

> At 12:02 PM 8/27/2008, Yakov Rekhter wrote:
> >Lou,
> >
> > > If you drop the "unless they share identical Traffic Engineering
> > > Attributes" then we have alignment.
> >
> >If they do share identical TE attributes, then there is no
> >problem  to aggregate such routes. So, the current text is correct.
> >
> >Yakov.
> 
> I think you need some additional semantic and aggregation function 
> definition if you want to aggregate. (For example: Does the TE 
> aggregate represent the resources available to *each* route or to 
> *all* the routes?  If the latter, what's the distribution function?)

Constructing BGP TE attribute when aggregating routes with identical 
BGP TE attributes follows procedure of rfc4201.

> Also I think some discussion on impact on scaling is 
> warranted.  (consider the case where each <PPI, CPI> tuple from a PE 
> now needs it's own advisement due to dissimilar TE information per port.)

As I said before, the granularity of L1VPN auto-discovery advertisements
is a single PE-CE port anyway. So, each <PPI, CPI> tuple from a PE
forms its own route anyway.

And while on the subject of scaling, please keep in mind that BGP
only stores L1VPN routes on PEs that have sites of that VPN connected
to them, and on an RR if used, but *not* on any of the P routers. In
contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
and PE. So, clearly BGP-based approach scales better than OSPF-based
approach.

Yakov.