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

[Lou Berger <lberger@labn.net>]

Yakov,
        See below.

At 07:47 PM 8/28/2008, Yakov Rekhter wrote:
> 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.

great.

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

sure, but there's potential for significant impact on number/size of 
advertisements and corresponding processing.

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

I believe it is both worthwhile and appropriate to discuss how this 
draft impacts/relates to scaling.  In essence, I'm suggesting a 
similar/parallel to section 5 of rfc 5195.  (which also states things 
that are "quite clear if you would read" BGP specs.)

Lou

> Yakov.