[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Yakov,
        see below.

At 12:00 PM 8/28/2008, Yakov Rekhter wrote:

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.


ahh, that wasn't obvious.  Need some specific language to that effect.


> 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.
Sure, but as the doc says more than on NLRI can be included in a MP_REACH_NLRI attribute. 


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.
sure this is made clear in the l1vpn document. What isn't made clear is that, per this document, when TE attributes cannot be aggregated, each <PPI, CPI> tuple needs its own MP_REACH_NLRI attribute *and* advertisement. 

Lou


Yakov.