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

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 18 Sep 2002 16:56:01 -0400

Comments below

Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Wednesday, September 18, 2002 3:49 PM
> To: Abarbanel, Benjamin
> Cc: 'Natale, Jonathan '; [email-masked] '
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
> 
> 
> 
> In message 
> <[email-masked]>, 
> "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.
> 
Then all other route types that win over the BGP routes in the Routing table
should be automatically exported to BGP. The problem is most vendors I know
off, make it a configuration option that might not be enabled and thus open
the door to a potential route use and advertise inconsistency.   

Maybe we need to add a sentence about this point somewhere (how aboute
RFC1772)?

> 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.

But sometimes when you convert route type A to type B you might loose A's
attributes, such when its converted back to A, it is less informative. Also,
that is why people might not want to redistribute between protocols too
much.

Ben
> 
> 
> > -----Original Message-----
> > From: Natale, Jonathan
> > To: [email-masked]
> > 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).
> > 
> > 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Sep 2002 20:02:01 -0400

In message <[email-masked]>, 
> Maybe we need to add a sentence about this point somewhere (how aboute

The text says you can't advertise routes you don't use.  It does not
say you must advertise all of the routes you use.

> that is why people might not want to redistribute between protocols too

Conversion between route types does lose information.  Are you arguing
with the definition of route on this basis?  I don't see what point
you are trying to make.

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 19 Sep 2002 11:25:13 -0400

On Wed, Sep 18, 2002 at 04:56:01PM -0400, Abarbanel, Benjamin wrote:
> should be automatically exported to BGP.

Probably the simplest way of dealing with this is dealing with
the case when a route in LocRib and the Routing table conflict
and the Routing Table has a non-BGP route installed in it is
to note that (in almost all cases if not always) the route actually
installed in the Routing Table is the one passed to Phase 3 of
the selection process.

-- 
Jeff Haas 
NextHop Technologies