Subject: Active Route

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 2 Oct 2002 10:19:49 -0400

Folks,

This issue seems to have been convoluted into issue 32.2.  I am in agreement
with 32.2 (other than style/conciseness--I think it is a little long winded,
but I can live with it), but it is not what I raised.  

The issue I raised, and would like to be [re-]considered is with:

"one must focus on the rule that a BGP speaker advertises to its peers
(other BGP speakers which it communicates with) in neighboring ASs only
those routes that it itself uses."

This means that if the speaker's routing table has a non-bgp route to a
destination but does not have bgp route to the same destination (for
example, based on administrative distance), then the speaker may not
advertise that route to it's peers. This is true on Juniper by default for
EBGP, but is NOT TRUE [ever?] on Juniper for IBGP, and is NOT TRUE on
Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on
Cisco.

Now we are proposing that the quoted clause above be completely removed.
This means that it will be allowable to advertise a route to a destination
that is not locally reachable.  This is obviously (to me, but not to all--
which is why it should not be removed) bad. 

Thank you.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 02 Oct 2002 11:56:36 -0400

In message <[email-masked]
> those routes that it itself uses."

That is called route orgination and it is allowed by:

  9.4 Originating BGP routes

   A BGP speaker may originate BGP routes by injecting routing
   information acquired by some other means (e.g. via an IGP) into BGP.
   [...]  The decision whether to distribute non-BGP
   acquired routes within an AS via BGP or not depends on the
   environment within the AS (e.g. type of IGP) and should be controlled
   via configuration.

Advice on what to put in the AS_PATH and NEXT_HOP is in the document.

> Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on

   [...]  The decision whether to distribute non-BGP
   acquired routes within an AS via BGP or not depends on the
   environment within the AS (e.g. type of IGP) and should be controlled
   via configuration.

> which is why it should not be removed) bad. 

In the summary, one of the entries is incorrect:

  11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2

  ...

  Since this issue and issue 32.2 are very similar, and 32.2 is at consensus,
  this issue has also been moved to consensus in favor of 32.2.

These are not the same so the entry in Andrews summary is wrong.

We never reached full consensus on 11.2 but seemed to have more
support for either 1) leaving it as, 2) take it out.  There were some
semantic arguments about what it meant to "use" a route with a few
people offering an interpretation of "use" that would make the
statement false under some conditions.

I suggest that we change 11.2 and return it to "no consensus".

The edit to change the same paragraph in 32.2 was to reflect the
intent of the paragraph to indicate that BGP supports destination
based routing and not some form of source specified routing.

I don't think there was ever consensus on what to do with the
statement "a BGP speaker advertises to its peers (other BGP speakers
which it communicates with) in neighboring ASs only those routes that
it itself uses".  Some reasonable choices are:

  1.  Omit it (the implied consensus of the rewrite of the paragraph
      in 32.2).

  2.  Leave it as is and put it in another paragraph to separate it
      from the destination based routing statement.

  3.  Clean up the wording and put it in another paragraph to separate
      it from the destination based routing statement.

The separate paragraph for 2 would be the exact sentence we now have.

   A BGP speaker advertises to its peers (other BGP speakers which it
   communicates with) in neighboring ASs only those routes that it
   itself uses.

In possibility 3 we (try to) clear up the ambiguity about the meaning
of the word "use" in this sentence.

   A BGP speaker advertises to its peers (other BGP speakers which it
   communicates with) in neighboring ASs only those routes that it
   itself uses.  In this context a BGP speaker is said to "use" a BGP
   route if it is the most preferred BGP route and is either directly
   used in forwarding or in a specifically configured case where the
   BGP route would be forwarded internally but IGP forwarding
   information is used.  The latter case reflects a usage in which the
   IGP is used for forwarding but BGP is originated to IBGP to carry
   attributes that cannot be carried by the IGP (for example, BGP
   communities [N]).  Other special cases such as virtual routers and
   multiple instances of BGP on a single router are beyond the scope
   of this document but for each of these the statement "a BGP speaker
   advertises to its peers (other BGP speakers which it communicates
   with) in neighboring ASs only those routes that it itself uses" can
   (and should in the definition of the extension) be made true with
   an appropriate definition of the word "use".

Unless someone volunteers better wording this may be a good starting
point.  I thing the last sentence borders on ridiculous in a protocol
spec but may be necessary to address specific objections raised on
this mailing list.  If we want to elaborate on the meaning of the word
"use" and address the objections this is what we end up with.

Of course looking at what we ended up with, I'd also go along with the
other two options (leave it out or put the one sentence in a separate
paragraph as is).

Curtis

---

From: Dennis Ferguson <[email-masked]>
Date: Wed, 02 Oct 2002 12:29:02 -0700

Jon,

> Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on

I would note that, for implementation reasons, it requires a moderately
unnatural act for Juniper routers to ever advertise a route to any
BGP peer, whether internal or external, which is not the route it is
using for forwarding.  I suspect that if you don't add "advertise inactive",
you'll find that the routers strictly conform to the quoted behaviour for
both EBGP and IBGP.  The knob is a relatively late addition added as a
concession to the fact that people are used to the Cisco behaviour, and some
have built configurations which depend on it.  I personally consider the
Cisco behaviour to be a bug, but it is the way some of the world works.

> which is why it should not be removed) bad. 

I think the algorithm Juniper routers use when the knob is enabled is that
there are two routes potentially available for readvertisement, the route
which the router is using for forwarding and the best BGP route which would
be usable for forwarding if the preferred (non-BGP) route(s) wasn't present.
If policy prohibits readvertisement of the first route but permits
readvertisement of the second route, the second route is readvertised.
While telling lies about the route you are using seems theoretically
fragile it is, however, hard to find practical cases where the above
algorithm would actually break much of anything.

Dennis Ferguson

---

From: [email-masked]
Date: Wed, 16 Oct 2002 00:28:17 -0700

Jonathan,

Thank you for pointing out that this issue did not get resolved.

Curtis,

It sounds like you hit the nail on the head here.  To reiterate, we have
3 options:

We now need to decide on which one we want to do.

I've updated the issue list, and reopened this issue.  A slew of possible
texts have flown about, and I have left them out of the issue list since
they complicate the discussion, until we decide which option we are going
to pursue.

Andrew

On Wed, Oct 02, 2002 at 11:56:36AM -0400, Curtis Villamizar wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> To: "Natale, Jonathan" <[email-masked]>
> Cc: [email-masked]
> Reply-To: [email-masked]
> Subject: issue 11.2 (was Re: Active Route)
> In-reply-to: Your message of "Wed, 02 Oct 2002 10:19:49 EDT."
>              <[email-masked]> 
> Date: Wed, 02 Oct 2002 11:56:36 -0400
> From: Curtis Villamizar <[email-masked]>
> Precedence: bulk
> X-OriginalArrivalTime: 02 Oct 2002 15:59:36.0421 (UTC) FILETIME=[B4CCA150:01C26A2C]
> 
>