Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Jonathan:
>   I did raise this issue before several days ago, the case that BGP only
> advertises IBGP/EBGP routes to its peers, but sometimes a better route,
> say IGP or static is used for forwarding. Thus making the statement not
> totally true. We suggested that the statement be revised to imply that 
> reachability of these routes are gauranteed by the BGP speaker not their
> implied "use" in the forwarding table.
> 
> Thanks,
> Ben


Ben, Jonathan,

If an IGP route is used for forwarding, it should be exported to BGP
and that route advertised in which case it would get the origin IGP
and one AS in the AS path.  [If an IGP route is used simply to resolve
the next-hop, that doesn't count, but I think you knew that since your
comments don't imply the opposite.]  Using one route but advertising a
route learned by another means is a violation of the protocol spec.
Even in the case of virtual routing tables for VPNs, each route is in
effect "used" but in a limited context and advertising the route to
some other context where it is not used would generally not be a good
idea.

Router vendors have provided knobs to allow the providers to violate
the specs.  If one router vendor does it and one large enough customer
uses it, chances are another router vendor will follow suit, whether
it is a good practice or not.

One case that I am aware of where such a violation occurs is
advertising the route to an exchange point.  There is often no peering
with the exchange point provider but the exchange point provider
sometimes gets an AS number.  The shared address of the exchange point
itself is advertised into IBGP (and sometimes to EBGP) and that
advertisement is in turn advertised out to EBGP even though the IGP
route is used.

Another case is where singly homed sites appear as both static routes
injected into IBGP and as IGP routes.  Configurations are set so that
the IBGP route is preferred by BGP so BGP communities attached to the
route can be respected.  It should be possible to suppress injecting
the static into the IGP, leaving only an IBGP route to the router to
which the static is attached, removing the moral dilema on other
routers of which route to advertise to EBGP peers.  But it doesn't
actually make any real difference, so it is usually just passed into
the IGP as well.

In some cases the IGP might yield a different next-hop if two routers
share a prefix advertised into BGP to get communities, and advertised
into the IGP by more than one router.  This would be the case if the
IGP cost to the shared prefix was different (the closest advertiser is
not the best route).

If this is done, and done wrong or right, there is no interoperability
problem.  If configured sufficiently wrong, there may be a black hole
or route loop.  Given the guidlelines that Alex just sent out (or
replied to), there is no reason to put this in the BGP spec.

When usage sometimes deviates from the spec, and in some cases from
safe practices, this can be documented in the applicability statement
which is currently rfc1772 and needs a lot of work.  [Aside: I don't
know of any usage that could not be accommodated without violating the
spec.  If someone does then it would be useful to document it in the
applicability statemen, not the protocol spec.  The usages seem to
fall into affecting route preference independently of the BGP route
which carries BGP communities needed for export.]

The text cited below is in a paragraph that is essentially saying BGP
can support IP style forwarding but can't turn IP into NIMROD (or ERP
given the time that this paragraph was written).  This is introductory
text, and we may be arguing about its precision with regard to some
issue tangential to the context of the paragraph in which the
statement appears.  Regardless, dropping the "in neighboring ASs" for
the reason you've cited is fine.  [Now lets move on to page 3...  :-) ]

Curtis

ps - there is some confusion below regarding the term route.  An OSPF
route is a route.  A BGP route is a route.  A route has iformation
other than the prefix.  It is possible to convert a route of one type
into a route of another type, or convert any (useful) route into a
forwarding entry.  There is no problem with the use of the word route
below.


> -----Original Message-----
> From: Natale, Jonathan
> To: [e-mail]
> Sent: 9/13/02 6:42 PM
> Subject: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
> 
> I propose changing:
> "To characterize the set of policy decisions that can be enforced
>    using BGP, 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."
> 
> To:
> "To characterize the set of policy decisions that can be enforced
>    using BGP, one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with)
>    only those prefixes that it itself uses. Whether or not to require
> the
> prefixes be used itself by virtue of a bgp learned route MAY be an
> administratively configurable option."
> 
> Since:
> 1) This rule applies to IBGP as well as to EBGP. 
> 2) The prefix need not necessarily be in the local routing table via
> bgp.
> 3) Juniper has a advertise inactive concept, Cisco does not.
> 4) The term route (vs prefix) is defined to include the attributes which
> means that Cisco is non-compliant (in that it will advertise a route if
> the
> route's prefix is installed via another protocol), and juniper may be
> configured to be non-compliant (turning off advertise inactive).
> 
>