Subject: RE: issue 58

From: "Gray, Eric" <[email-masked]>
Date: Mon, 30 Sep 2002 10:30:25 -0400

Curtis,

	Is there any reason why "should" is not capitalized in 
the (fourth sentence of) proposed text for 9.1.4? Also, why
use "can not" instead of MUST NOT in the fifth and sixth 
sentences in this proposed text (again, 9.1.4)?  I believe 
it is not your intent to make this part non-normative, is it? 

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, September 30, 2002 10:19 AM
> To: Yakov Rekhter
> Cc: [email-masked]; [email-masked]
> Subject: Re: issue 58
> 
> 
> In message <[email-masked]>, Yakov Rekhter
> writes
> :
> > Curtis,
> >
> > > >   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.
> > >
> > >
> > > 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.
> >
> > Could you please propose the text.
> >
> > Yakov.
> 
> 
> 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: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Sep 2002 12:09:01 -0400

In message <[email-masked]
> it is not your intent to make this part non-normative, is it? 

Eric,

Thanks.  I missed the "should not" and the "can not".  The second
instance of "can not" just clarifies the prior sentence, in effect
providing some justification, but is not intended as a further
normative statement so I think its OK as is.  I just left that
sentence untouched.

> >    routing, there is no longer a need to deaggregate.  Routes should
                                                                  ^^^^^^ SHOULD
> >    not be de-aggregated.  A route that carries ATOMIC_AGGREGATE
       ^^^ NOT
> >    attribute in particular can not be de-aggregated. That is, the NLRI
                               ^^^^^^^ MUST NOT
> >    only ASs listed in the AS_PATH attribute of the route.

Its safe to say the the only thing we want to remain normative is
"don't de-aggregate" and we've strengthenned that statement a bit to
mean "don't de-aggregate BGP under any circumstances".

Curtis