Subject: [Idr] Question about aggregation

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Fri, 16 Mar 2007 14:31:20 -0700

Hi,

I have a question related to route aggregation, that I could not find  
specified in RFC4271.
Suppose a router aggregates two entries: 10.0.1/24 and 10.0.2/24 with  
same ASPATH [A B C] into a single entry:
10.0/16 [A B C]
Then 10.0.1/24 decides to change provider and switches to a new  
aspath [A D C], and we'll have in the table:
10.0/16 [A B C]
10.0.1/24 [A D C]

which is fine since forwarding will follow longest match.
Now suppose 10.0.2/24 decides to change providers to path [A E C],  
then we end up w/:
10.0/16 [A B C]
10.0.1/24 [A D C]
10.0.2/24 [A E C]

And the initial entry is now a bogus entry. How do routers usually  
get rid of these stale entries?
The same question applies if all more specific routes are withdrawn,  
is the aggregate also withdrawn?
Do routers keep state of more specific routes in Adj-RIB-In and  
update Local-RIB accordingly?

Also, in section 9.1.4 of the RFC (overlapping routes) it's said:

"If a BGP speaker receives overlapping routes, the Decision Process
    MUST consider both routes based on the configured acceptance policy.
    If both a less and a more specific route are accepted, then the
    Decision Process MUST install, in Loc-RIB, either both the less and
    the more specific routes or aggregate the two routes and install, in
    Loc-RIB, the aggregated route, provided that both routes have the
    same value of the NEXT_HOP attribute."

But in section 9.2.2.2 (aggregating routing information) it's said:

"Path attributes of the same type code may be aggregated,
    according to the following rules:

       NEXT_HOP:
          When aggregating routes that have different NEXT_HOP
          attributes, the NEXT_HOP attribute of the aggregated route
          SHALL identify an interface on the BGP speaker that performs
          the aggregation.
"

So it seems the first sentence was not updated according to the  
aggregation rules of the new RFC.

Thanks,

--Ricardo

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Tue, 27 Mar 2007 18:03:29 +0200

Hi, 

> -----Original Message-----
> From: Ricardo V. Oliveira [mailto:[email-masked]] 
> Sent: Friday, March 16, 2007 10:31 PM
> To: [email-masked]
> Subject: [Idr] Question about aggregation
> 
> Hi,
> 
> I have a question related to route aggregation, that I could 
> not find specified in RFC4271.
> Suppose a router aggregates two entries: 10.0.1/24 and 
> 10.0.2/24 with same ASPATH [A B C] into a single entry:
> 10.0/16 [A B C]
> Then 10.0.1/24 decides to change provider and switches to a 
> new aspath [A D C], and we'll have in the table:
> 10.0/16 [A B C]
> 10.0.1/24 [A D C]
> 
> Now suppose 10.0.2/24 decides to change providers to path [A 
> E C], then we end up w/:
> 10.0/16 [A B C]
> 10.0.1/24 [A D C]
> 10.0.2/24 [A E C]
> 
> And the initial entry is now a bogus entry. How do routers 
> usually get rid of these stale entries?

In this case 10.0/16 should disappear as soon as there is no longer any
specific route matching AS-PATH attribute (per section 9.2.2.2,
paragraph about AS-PATH).

> The same question applies if all more specific routes are 
> withdrawn, is the aggregate also withdrawn?

It should be (also per 9.2.2.2).

> Do routers keep state of more specific routes in Adj-RIB-In 
> and update Local-RIB accordingly?
> 
Adj-RIB-In and Local-RIB are not necessarily stored separately, at least
RFC does not require this. Implementation could in store specific routes
along with aggregate in the Local-RIB (which is result of applying
policy to Adj-RIB-In), but propagate to Adj-RIB-Out only aggregated
route (as result of applying outgoing policy).

> Also, in section 9.1.4 of the RFC (overlapping routes) it's said:
[...]
> But in section 9.2.2.2 (aggregating routing information) it's said:
[...]
> So it seems the first sentence was not updated according to 
> the aggregation rules of the new RFC.
> 

There doesn't seem to be contradiction - one sentence is dealing with
routes that have same value of NEXT-HOP, the other one is dealing with
aggregation of different NEXT-HOP attributes. Both are practical cases.
Second case just exaplins what to do when routes do not fit description
in 9.1.4.

Cheers,

iLya

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Tue, 27 Mar 2007 11:06:15 -0700

> Second case just exaplins what to do when routes do not fit  

Thanks fo the reply Ilya.
Section 9.2.2.2. is suppose to describe the necessary conditions for  
aggregation of different routes. None of these conditions require  
that NEXT_HOP be the same for different routes (which was required by  
previous RFC).
However, this condition is described in section 9.1.4 as a necessary  
condition for aggregation, which to me seems a contradiction. If the  
scenario in 9.1.4 is a special case, then it should be mentioned as  
such in the text to avoid confusion with the later section.

--Ricardo