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

[Yakov Rekhter <[e-mail]>]

Lou,

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

Sure. To make it obvious I'll add the following:

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

That does not change the number of routes that PEs and RRs have
to maintain. 

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

It would be quite clear if you would read base BGP spec (which is
quoted as a Normative Refence in this document). Quoting Section 
3.1 of BGP spec (rfc4271):

   Multiple routes that have the same path attributes can be advertised
   in a single UPDATE message by including multiple prefixes in the NLRI
   field of the UPDATE message.

Yakov.