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

[Yakov Rekhter <yakov@juniper.net>]

Lou,

> Yakov,
>          See below.

see in-line...

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

Here is the text I'll add to the spec to discuss this issue:

     Use of Traffic Engineering Attribute does not increase the number
     of routes.
  
     When the routes differ in other than the Traffic Engineering
     Attribute (e.g., differ in the set of Route Targets, and/or
     NEXT_HOP), use of Traffic Engineering Attribute has no impact
     on the number of BGP Update messages required to carry the routes.
     Only when the routes have all, but the Traffic Engineering
     Attribute the same, use of the attribute may increase the number
     of BGP Update messages required to carry the routes.

Yakov.