Subject: RE: using default route to reach peer

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 24 Oct 2002 16:56:28 -0400

key word is "MAY"
key concept is documenting existing behavior:
"one goal of the update is document existing practice"
--http://www.ietf.org/html.charters/idr-charter.html

"The point specifically here is that an implementation must be able to deal
w/ potentially looping routes. i.e. a route which by being installed in a
routing table causes itself to be looping..."
...WRONG, that is not the point.  But that IS already covered in the draft
(it was NOT in the RFC).

but I will concede that "they" do have a bug such that they will install bgp
routes that will become mutually recursive once installed. 'nough said.

I see the "not peer based on default route" as confronting the situation
when you are multihomed to 2 different AS's and get the default route from 1
and are doing multihop to the other, and then the route to the multihop peer
goes away.  Do you want to peer to the multihop peer THRU the first peer???
Probably not.

-----Original Message-----
From: Pedro Roque Marques [mailto:[email-masked]] 
Sent: Thursday, October 24, 2002 2:47 PM
To: Natale, Jonathan
Cc: [email-masked]
Subject: using default route to reach peer

Natale, Jonathan writes:

> Folks, IOS does not allow a BGP peer to be reached via the default 
> route.  This seems like a good rule to me.  Is this specified in the/a 
> RFC/Draft somewhere?  Should it be added as a "MAY"?

I'm wondering if the document when finished will be published w/ by Cisco
Press... it is starting to seem as if it comes closer to document and
semi-officially sanction the behaviour of a particular implementation than
actually address the underlying technical issues.

The point specifically here is that an implementation must be able to deal
w/ potentially looping routes. i.e. a route which by being installed in a
routing table causes itself to be looping...

A simple minded aproach to the problem above that some implementations take
is to simply deny peering on the default route w/ the logic that any route
installed via that peering session that would be more specific for the
peering session address or nexthop of the default route would cause all
received routes to become looping.

There are implementations however that have a much more complete aproach to
the root problem and have no use for the quick fast hack of denying peering
on default.

The later is imho an implementation specific quirk which is probably already
documented sufficiently on books published under the label of the equipment
vendor in question.

I've no problem w/ any particular vendor or its implementation but puting
down as a standard the solutions of a particular implementation, which may
or may not be the most apropriate, i don't think the spec is doing a
service...

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 24 Oct 2002 14:08:24 -0700 (PDT)

Natale, Jonathan writes:

> key word is "MAY" key concept is documenting existing behavior: "one
> goal of the update is document existing practice"

Can i add to the spec 'an implementation MAY choose to calculate the
first 100 prime numbers between generating 2 sets of update
messages'... ?

> "The point specifically here is that an implementation must be able
> to deal w/ potentially looping routes. i.e. a route which by being
> installed in a routing table causes itself to be looping..."
> ...WRONG, that is not the point.

Are you going to put forward any argument other than the capital
letters ?

If that is not the point, do you mind giving us a rational for not
peering over the default route. Why is it such a good idea ?

The fact of the matter is that it works just fine when the apropriate
safe gurards against looping routes are in place, usually for
applications other than strictly internet routing.

  Pedro.