Subject: Working Group last call

From: Yakov Rekhter <[email-masked]>
Date: Sun, 22 Sep 2002 18:05:54 -0700

Folks,

Just to remind you the it ends tomorrow (see below).

Yakov.
------- Forwarded Message

Date:    Wed, 11 Sep 2002 09:27:45 -0700
From:    Yakov Rekhter <[email-masked]>
To:      Alex Zinin <[email-masked]>
cc:      [email-masked], [email-masked]
Subject: Re: Working Group last call 

Alex,

> Yakov,
> 
>   I'd like to ask the WG chairs to extend the comment period
>   for at least another two weeks--as I indicated in one of my
>   messages earlier, I'm hearing that people are in deadlines
>   and ask for more time to review.

The WG chairs are pleased to grant the two weeks extension (from 9/9 
to 9/23).

Please track down those people who indicated that two weeks would
not be enough. We are counting on you to get the comments from these 
people in as early as possible.

Sue & Yakov.

------- End of Forwarded Message

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 23 Sep 2002 13:59:21 -0400

> Just to remind you the it ends tomorrow (see below).

Just got my comments in. [mea maxima culpa]

Might I suggest that considering this last call might be one step
premature without seeing the updated text?

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 24 Sep 2002 02:27:14 -0400

> premature without seeing the updated text?

It is definitely premature.  You have to repeat the last call if
anything but editorial changes are made.  Replacing the FSM is more
than an editorial change.

Curtis

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 24 Sep 2002 05:55:46 -0700

Curtis,

> than an editorial change.

Just to clarify, what ended yesterday is the comment period on both
the -17 version excluding FSM, and on the FSM text, as posted
(separately) by Sue.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 24 Sep 2002 12:08:50 -0400

Yakov,

> the -17 version excluding FSM, and on the FSM text, as posted

Unfortunately, I missed the deadline for this comment due to lack of
time.  Please consider this comment for -19 if we have reason to
make it this far:

Deprecation of ATOMIC_AGGREGATE:

[This is a summary of some discussions from those who have "been there,
done that" during the CIDR deployment period and also comments
from network operators on the NANOG list.]

When BGP-4 was originally drafted, the topic of aggregation was new
enough that people didn't exactly know how it would be used.
Additionally, there were some transition issues when aggregated
networks would need to be de-aggregated and re-advertised into
a classful routing mesh such as BGP-3.

The ATOMIC_AGGREGATE flag was intended to prevent a route from being
de-aggregated when de-aggregation would introduce routing loops.
Note that de-aggregation in this context specifically means making
a less specific route into one or more more-specific routes.

The current BGP draft has two situations where ATOMIC_AGGREGATE
should be appeneded to a route:
1. When a route's AS_PATH is intentionally truncated, such as what
   happens by default on Cisco's, or using the "brief" option on
   GateD.  Juniper has a similar feature - I'm unsure of the default.
2. When two routes are implicitly aggregated in the LocRib such
   that a more specific route is not selected when a less specific
   route is from a given peer.

   Note that this particular feature is not implemented anywhere that
   I am aware of.

3. There is a third case not covered by the specification: Implicit
   aggregation on export - a more specific route is not exported
   and only a less specific one is.

When network operators were asked about de-aggregation practices,
I received about 40 responses.  The majority of these responses confused
de-aggregation with leaking existing more-specific routes that are
used internally rather than explicitly de-aggregating a less-specific route.  

There were a very few cases of explicit de-aggregation.  One form
was done for purposes of dealing with another ISP creating a routing
DoS by advertising IP space that didn't belong to them - leaked more
specifics alleviated the problem in many cases.  (Note that this is
a security issue in the routing system.)

The second case was de-aggregating routes internally (and sending the
routes via IBGP marked with NO-ADVERTISE) for purposes of traffic
engineering routing internally where a given upstream failed to
provide enough routing information to allow traffic flows to be
optimized based on supplied prefixes.

My conclusions to this are:
1. De-aggregation is not a common practice.
2. It is no longer a major concern since classful inter-domain routing 
   is pretty much gone.
3. The spec doesn't match reality and should be corrected.

My suggestions are thus this:
Section 5.1.6 should be updated as follows:
   ATOMIC_AGGREGATE is a well-known discretionary attribute.  Its
   use is deprecated.

   When a router explicitly 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 (usually due to truncation), the 
   aggregated route, when advertised to the peer, MUST include the 
   ATOMIC_AGGREGATE attribute.

Section 9.1.4 should be updated as follows:
Original text:
:    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 either install both the less and the more
:    specific routes or it MUST aggregate the two routes and install the
:    aggregated route, provided that both routes have the same value of
:    the NEXT_HOP attribute.
: 
:    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.

Replace with:

   It is common practice that more specific routes are often
   implicitly aggregated by selecting or advertising only a less-specific
   route when overlapping routes are present.  As such, all routes
   SHOULD be treated as if ATOMIC_AGGREGATE is present and not be made
   more specific (de-aggregated).  De-aggregation may lead to routing
   loops.

Section 9.2.2 should remain as it is.

Implications of not making the above updates:
ATOMIC_AGGREGATE is not implemented as documented.  Current operational
practices do not seem to often trigger situations that it was
intended to remediate.  After all, by the way it is currently documented,
many of the routes in the Internet would likely have ATOMIC_AGGREGATE.

The original motivation for this investigation (aside from a few years
of wondering what this portion of the spec *really* meant) was
making sure the MIB is correctly documented.  I can do this now,
even if the spec is not corrected by simply noting that the values:
lessSpecificRouteNotSelected(1),
lessSpecificRouteSelected(2)

mean:
ATOMIC_AGGREGATE not present
ATOMIC_AGGREGATE present

rather than documenting anything about less and more specific routes.

The v2MIB can be fixed to just call it what it is since it hasn't
been RFC'ed yet.

Lastly, the spec would just be incorrect.
But all said, nothing bad would really come of this.

-- 
Jeff Haas 
NextHop Technologies