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

From: Yakov Rekhter <[email-masked]>
Date: Tue, 02 Sep 2008 14:30:38 -0700

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.
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Lou Berger <[email-masked]>
Date: Wed, 03 Sep 2008 08:21:18 -0400

>      of BGP Update messages required to carry the routes.

Is this from babel fish?  How about:

Use of Traffic Engineering Attribute does not increase the number
of routes, but may increase the number of BGP Update messages
required to distribute the 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.
There is also no impact when routes share all other attribute
information and have an aggregated or identical Traffic Engineering Attribute.
When routes share all other attribute information and have different
Traffic Engineering Attributes, routes must be distributed in
per-route BGP Update messages rather than a single message.

Lou

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 03 Sep 2008 08:18:21 -0700

Lou,

> per-route BGP Update messages rather than a single message.

Almost there... The only change is to the first paragraph,
as follows:

   Use of Traffic Engineering Attribute does not increase the number 
   of routes, but may increase the number of BGP Update messages 
   required to distribute the routes depending on whether these routes 
   share the same BGP Traffic Engineering attribute or not (see below).

The second paragraph is fine.

Yakov.

---

From: Lou Berger <[email-masked]>
Date: Wed, 03 Sep 2008 13:32:17 -0400

looks fine to me.  I'll look for it in the updated draft...

Lou

At 11:18 AM 9/3/2008, Yakov Rekhter wrote:
> > information and have an aggregated or identical Traffic 
> Engineering Attribute
>.