Re: diffs to draft-ietf-idr-bgp4-03.txt

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Yakov Rekhter writes:
> Curtis,
> 
> I have some problems with your proposed replacement text
> for the overlapping routes.
> 
> Current text:
> 
>    If a BGP speaker receives overlapping routes, the Decision Process
>    shall take into account the semantics of the overlapping routes. In
>    particular, if a BGP speaker accepts the less specific route while
>    rejecting the more specific route from the same peer, then the
>    destinations represented by the overlap may not forward along the ASs
>    listed in the AS_PATH attribute of that route. Therefore, a BGP
>    speaker has the following choices:
>    
>          a)   Install both the less and the more specific routes
>    
>          b)   Install the more specific route only
>    
>          c)   Install the non-overlapping part of the less specific
>               route only (that implies de-aggregation)
>    
>          d)   Aggregate the two routes and install the aggregated route
>    
>          e)   Install the less specific route only
>    
>          f)   Install neither route
>    
>    If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE
>    attribute to the route. A route that carries ATOMIC_AGGREGATE
>    attribute can not be de-aggregated. That is, the NLRI of this route
>    can not be made more specific.  Forwarding along such a route does
>    not guarantee that IP packets will actually traverse only ASs listed
>    in the AS_PATH attribute of the route.  If a BGP speaker chooses a),
>    it must not advertise the more general route without the more
>    specific route.
>    
>    
> Proposed replacement:
> 
>    If a BGP speaker receives overlapping routes, the Decision Process
>    shall consider both routes based on configured acceptance policy.
>    If both are accepted the Decision Process will install both the
>    less and the more specific routes or aggregate the two routes and
>    install the aggregated route.
             ^^^^^^^^^^^^^^^^^^^^

Should be "both the more specific route and the aggregated route".

>    If a BGP speaker chooses to aggregate, then it should add ATOMIC_AGGREGATE
>    attribute to the route. A route that carries ATOMIC_AGGREGATE
>    attribute can not be de-aggregated. That is, the NLRI of this route
>    can not be made more specific.  Forwarding along such a route does
>    not guarantee that IP packets will actually traverse only ASs listed
>    in the AS_PATH attribute of the route.  If a BGP speaker chooses to
>    install both routes it must not advertise the more general route
>    without the more specific route.
> 
> 
> The proposed replacement text is incomplete, as it only covers cases
> (a) and (d).
> 
> Moreover, while the original text requires to add ATOMIC_AGGREGATE only
> when only the less specific route is installed, the new text requires
> to add ATOMIC_AGGREGATE when the two routes (more specific and less
> specific) are aggregated. What is the reason for that change ?
> 
> Yakov.


The proposed text contains the phrase

   If a BGP speaker receives overlapping routes, the Decision Process
   shall consider both routes based on configured acceptance policy.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   If both are accepted ...
   ^^^^^^^^^^^^^^^^^^^^

Now look at cases b, c, e, f, the ones omitted.

  >      b)   Install the more specific route only

  Wrong.  You've accepted both routes.

  >      c)   Install the non-overlapping part of the less specific
  >           route only (that implies de-aggregation)

  Deaggrgation is dead.

  >      e)   Install the less specific route only

  Wrong.  You've accepted both routes.

  >      f)   Install neither route

  Wrong.  You've accepted both routes.

This leaves only a, and d.

  >      a)   Install both the less and the more specific routes

  >      d)   Aggregate the two routes and install the aggregated route

Actually, d) should be changed to "aggregate the two routes and
install both routes".

Since deaggregation is dead, ATOMIC_AGGREGATE doesn't matter very
much.  Some routers put ATOMIC_AGGREGATE on by default.

Curtis


ps- Here is an interesting question wrt e):

If router A receives a more specific and rejects it (ie: filters on
prefixes being too long) and router B in the same AS receives a less
specific route, is router B non-conformant to BGP is it advertises the
less specific route without adding ATOMIC_AGGREGATE?

This would mean a route learned from router A would have
ATOMIC_AGGREGATE and could not be deaggregated but the same route from
router B with the same AS path could be deaggregated?  What purpose
does this serve?

Are Sprint's Cisco routers not conforming to BGP by not setting
ATOMIC_AGGREGATE in cases where they did not generate an aggregate but
blocked the more specific of a prefix they received?