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

[Yakov Rekhter <[e-mail]>]

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