Subject: issue 58

From: Yakov Rekhter <[email-masked]>
Date: Thu, 26 Sep 2002 06:17:41 -0700

58) Deprication of ATOMIC_AGGREGATE
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There has 
   not yet been any discussion on the proposed changes.

Comments on this issue would be appreciated.

In the absence of any objections to the changes proposed by Jeff, the
changes would be accepted. 

Yakov.

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Thu, 26 Sep 2002 06:31:38 -0700

>  58) Deprication of ATOMIC_AGGREGATE

I strongly agree with Jeff to deprecate ATOMIC_AGGREGATE.  The network
situation which ATOMIC_AGGREGATE aimed to resolve is not realistic.
-- 
Kunihiro Ishiguro

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 26 Sep 2002 12:46:11 -0400

In message <[email-masked]>, Yakov Rekhter writes
>   58) Deprication of ATOMIC_AGGREGATE

We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
rather than replaced with an AS_SET.  It was always purely
informational since no one intentionally deaggregated and reannounced.
Don't implementations still support this?

If reality is that it is informational only, then just remove the
MUSTs and indicate that it is informational.

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 26 Sep 2002 12:50:06 -0400

> Don't implementations still support this?

They do.
Please see my original long e-mail on the subject.
(I can resend it to you if need be.)

> MUSTs and indicate that it is informational.

The point is that by definition of the attribute, anywhere that policy
is used (and some places where it may not be), ATOMIC_AGGREGATE
*should* be there.  Since its not, and it would generally be
everwhere, you just shouldn't de-aggregate.

At best, leaving it as a method of informationally signalling truncation
of a AS_PATH is the best we'll get out of it - and it matches
current implementations.

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 26 Sep 2002 10:56:55 -0700

Curtis,

> >   -------------------------------------------------------------------------
> >   Status: No Consensus
> >   Change: Potentially

Could you please propose the text.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 26 Sep 2002 14:12:41 -0400

> Could you please propose the text.

FWIW, I believe my suggested changes might already cover this.

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Sep 2002 10:19:10 -0400

In message <[email-masked]>, Yakov Rekhter writes
> > >   58) Deprication of ATOMIC_AGGREGATE

This existing text is fine:

         f) ATOMIC_AGGREGATE (Type Code 6)

            ATOMIC_AGGREGATE is a well-known discretionary attribute of
            length 0. Usage of this attribute is described in 5.1.6.

This is the existing text that we are considering changing:

  5.1.6 ATOMIC_AGGREGATE

   ATOMIC_AGGREGATE is a well-known discretionary attribute.

   When a router aggregates several routes for the purpose of
   advertisement to a particular peer, and the AS_PATH of the aggregated
   route excludes at least some of the AS numbers present in the AS_PATH
   of the routes that are aggregated, the aggregated route, when
   advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute MUST NOT remove the attribute from the route when
   propagating it to other speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute MUST NOT make any NLRI of that route more specific (as
   defined in 9.1.4) when advertising this route to other BGP speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute needs to be cognizant of the fact that the actual path to
   destinations, as specified in the NLRI of the route, while having the
   loop-free property, may not be the path specified in the AS_PATH
   attribute of the route.

Suuggested new text:

  5.1.6 ATOMIC_AGGREGATE

   ATOMIC_AGGREGATE is a well-known discretionary attribute.

   When a router aggregates several routes for the purpose of
   advertisement to a particular peer, the AS_PATH of the
   aggregated route normally includes an AS_SET formed from the set of
   AS from which the aggregate was formed.  In many cases the network
   administrator can determine that the aggregate can safely be
   advertised without the AS_SET and not form route loops.

   If an aggregate excludes at least some of the AS numbers present in
   the AS_PATH of the routes that are aggregated as a result of
   dropping the AS_SET, the aggregated route, when advertised to the
   peer, SHOULD include the ATOMIC_AGGREGATE attribute.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute SHOULD NOT remove the attribute from the route when
   propagating it to other speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute MUST NOT make any NLRI of that route more specific (as
   defined in 9.1.4) when advertising this route to other BGP speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute needs to be cognizant of the fact that the actual path to
   destinations, as specified in the NLRI of the route, while having the
   loop-free property, may not be the path specified in the AS_PATH
   attribute of the route.

Diffs (for reader convenience):

@@ -4,13 +4,19 @@
    ATOMIC_AGGREGATE is a well-known discretionary attribute.
 
    When a router aggregates several routes for the purpose of
-   advertisement to a particular peer, and the AS_PATH of the aggregated
-   route excludes at least some of the AS numbers present in the AS_PATH
-   of the routes that are aggregated, the aggregated route, when
-   advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
+   advertisement to a particular peer, the AS_PATH of the
+   aggregated route normally includes an AS_SET formed from the set of
+   AS from which the aggregate was formed.  In many cases the network
+   administrator can determine that the aggregate can safely be
+   advertised without the AS_SET and not form route loops.
+
+   If an aggregate excludes at least some of the AS numbers present in
+   the AS_PATH of the routes that are aggregated as a result of
+   dropping the AS_SET, the aggregated route, when advertised to the
+   peer, SHOULD include the ATOMIC_AGGREGATE attribute.
 
    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
-   attribute MUST NOT remove the attribute from the route when
+   attribute SHOULD NOT remove the attribute from the route when
    propagating it to other speakers.
 
    A BGP speaker that receives a route with the ATOMIC_AGGREGATE

Current text in 9.1.4:

   If a BGP speaker chooses to aggregate, then it MUST 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.

Change to:

   If a BGP speaker chooses to aggregate, then it SHOULD either
   include all AS used to form the aggreagate in an AS_SET or add the
   ATOMIC_AGGREGATE attribute to the route.  This attribute is now
   primarily informational.  With the elimination of IP routing
   protocols that do not support classless routing and the elimination
   of router and host implementations that do not support classless
   routing, there is no longer a need to deaggregate.  Routes should
   not be de-aggregated.  A route that carries ATOMIC_AGGREGATE
   attribute in particular 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.

This text in 9.2.2.2 need not change.

      ATOMIC_AGGREGATE: If at least one of the routes to be aggregated
      has ATOMIC_AGGREGATE path attribute, then the aggregated route
      shall have this attribute as well.

The appendix need not change:

  Appendix 1. Comparison with RFC1771

      [...]

      Clarifications to the use of the ATOMIC_AGGREGATE attribute.

This might be a bit more wordy that is necessary.  It does address the
objections to keeping ATOMIC_AGGREGATE by making the MUST into SHOULD,
and explaining that ATOMIC_AGGREGATE is now primarily informational.

Curtis

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 30 Sep 2002 09:49:40 -0700

Curtis,

> > > >   ---------------------------------------------------------------------
--
> Diffs (for reader convenience):

That would be fine.

Yakov.