Subject: missing issue - implemented route selections not necessarily consistant with draft

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Oct 2002 10:57:54 -0400

Reviewing my inbox, I think we dropped an issue - or I've misplaced
the resolution of it.

Our route selection tie-breaking process in -17 doesn't match at
least two of the $LARGE_ROUTER_VENDORs.

Noted differences are (per vrishab sikand):
1) originator ID (to be substituited for router id, when present
in path attribute)
2) cluster list length
3) peer id (configured ip address of peer in the neighbor command)    

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 24 Oct 2002 08:33:44 -0700

Jeff,

> 3) peer id (configured ip address of peer in the neighbor command)    

These are all have to do with route selection in the presence
of Route Reflectors. So, these issues have to be covered in the
Route Reflector spec (the Route Reflector spec has to have a section
on how Route Reflectors impact BGP Route Selection process).

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Oct 2002 11:36:51 -0400

Yakov,

> on how Route Reflectors impact BGP Route Selection process).

Thanks.  That addresses my concern.

Hopefully Andrew will add this to his Codex Errata for route reflectors.

-- 
Jeff Haas 
NextHop Technologies

---

From: vrishab sikand <[email-masked]>
Date: Thu, 24 Oct 2002 08:45:55 -0700 (PDT)

The original thought expressed in the route reflector RFC was that: those routers which are not configured as route reflectors do not need to have "any" knowledge route reflector attributes. This i think was done to ease the migration to RR's.
I understand that  for the major vendors, even if you are not configured as a RR, they perform these additional steps. So I believe these belong in the main bgp specification.
 
 Yakov Rekhter <[email-masked]> wrote:Jeff,

Yakov.

---------------------------------
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 24 Oct 2002 08:48:23 -0700

Vrishab,

> The original thought expressed in the route reflector RFC was that:
> those rou ters which are not configured as route reflectors do not
> need to have "any" kno wledge route reflector attributes. This i
> think was done to ease the migration to RR's.  I understand that
> for the major vendors, even if you are not configured as a RR, they
> perform these additional steps. So I believe these belong in the
> main bgp specification.

The point is not whether a route is *configured* to act as an RR or not.
The point is whether a router *implements* the stuff specified in the
RR spec or not.

Yakov.

> --0-1274477441-1035474355=:88280
> Content-Type: text/html; charset=us-ascii
> 
> <P>The original thought expressed in the route reflector RFC was that: those 
routers which are not configured as route reflectors do not need to have "any" 
knowledge route reflector attributes. This i think was done to ease the migrati
on to RR's.
> <P>I&nbsp;understand that &nbsp;for the major vendors, even if you are not co
nfigured as a RR, they perform these additional steps. So I believe these belon
g in the main bgp specification.
> <P>&nbsp;
> <P>&nbsp;<B><I>Yakov Rekhter &lt;[email-masked]&gt;</I></B> wrote:
> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 
2px solid">Jeff,<BR><BR>&gt; Reviewing my inbox, I think we dropped an issue - 
or I've misplaced<BR>&gt; the resolution of it.<BR>&gt; <BR>&gt; Our route sele
ction tie-breaking process in -17 doesn't match at<BR>&gt; least two of the $LA
RGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per vrishab sikand)
:<BR>&gt; 1) originator ID (to be substituited for router id, when present<BR>&
gt; in path attribute)<BR>&gt; 2) cluster list length<BR>&gt; 3) peer id (confi
gured ip address of peer in the neighbor command) <BR><BR>These are all have to
 do with route selection in the presence<BR>of Route Reflectors. So, these issu
es have to be covered in the<BR>Route Reflector spec (the Route Reflector spec 
has to have a section<BR>on how Route Reflectors impact BGP Route Selection pro
cess).<BR><BR>Yakov.</BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
> <a href="http://webhosting.yahoo.com/ ">Y! Web Hosting</a> - Let the expert h
ost your web site
> --0-1274477441-1035474355=:88280--

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Oct 2002 12:00:25 -0400

On Thu, Oct 24, 2002 at 08:45:55AM -0700, vrishab sikand wrote:
> I understand that  for the major vendors, even if you are not
> configured as a RR, they perform these additional steps. So I
> believe these belong in the main bgp specification.

There is a difference from being a route reflector by configuration
and understanding the path attributes because you have code to support it.

However, this does argue that route reflectors using these
extensions may have inconsitant route-selection when some of the
clients don't understand the extensions.   This is hardly transparent.

-- 
Jeff Haas 
NextHop Technologies

---

From: vrishab sikand <[email-masked]>
Date: Thu, 24 Oct 2002 09:00:30 -0700 (PDT)

2.  Design Criteria

   Route Reflection was designed to satisfy the following criteria.

           o Simplicity

             Any alternative must be both simple to configure as well
             as understand.

           o Easy Migration

             It must be possible to migrate from a full mesh
             configuration without the need to change either topology
             or AS. This is an unfortunate management overhead of the
             technique proposed in [3].

           o Compatibility

             It must be possible for non compliant IBGP peers
             to continue be part of the original AS or domain
             without any loss of BGP routing information.

These criteria were motivated by operational experiences of a very
 large and topology rich network with many external connections.

*******************************************************************************************
The above is the design criteria quoted from RFC 2796. They explicitly state design goal is to interoperate with non compliant IBGP neighbors.
Image the case were a routers which dont support router reflector rfc (You may be tempted to say: junk it). If it is deployed in a network in which there are routers which support RR functionality. There will be inconsistent routing

**************************************************************************************************

 Yakov Rekhter <[email-masked]> wrote:Vrishab,

Yakov.

> Yakov Rekhter wrote:Jeff,
> 
The original thought expressed in the route reflector RFC was that: those 
routers which are not configured as route reflectors do not need to have "any" 
knowledge route reflector attributes. This i think was done to ease the migrati
on to RR's.
I understand that  for the major vendors, even if you are not co
nfigured as a RR, they perform these additional steps. So I believe these belon
g in the main bgp specification.

> Our route sele
ction tie-breaking process in -17 doesn't match at
> 1) originator ID (to be substituited for router id, when present
&
gt; in path attribute)
> 3) peer id (confi
gured ip address of peer in the neighbor command) 

These are all have to
do with route selection in the presence
of Route Reflectors. So, these issu
es have to be covered in the
Route Reflector spec (the Route Reflector spec 
has to have a section
on how Route Reflectors impact BGP Route Selection pro
cess).

Yakov.

---

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

> Noted differences are (per vrishab sikand): 1) originator ID (to be
> substituited for router id, when present in path attribute) 2)
> cluster list length 3) peer id (configured ip address of peer in the
> neighbor command)

- What about arrival time of a route as decision factor... ?
I believe there are implementations that choose the 'older' route
(whatever that is) before router-id in certain circunstances.

Which may seen as a behaviour in which the route selection does not
depend on the route attributes entirely...

  Pedro.

---

From: vrishab sikand <[email-masked]>
Date: Thu, 24 Oct 2002 11:37:39 -0700 (PDT)

on "careful" reading you may observe that step is just before using configured peer id. i.e. All attributes which come with the route or session are used first. If they are equal only then use time. In order avoid a flap for no good reason.
Having said that, using time does not make for very deterministic route selection.
 Pedro Roque Marques <[email-masked]> wrote:

Pedro

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 29 Oct 2002 10:44:47 -0500

In message <[email-masked]>, vrishab sikand
 writes:
> --0-386623435-1035484659=:38642
> Content-Type: text/plain; charset=us-ascii
> 
> 

Doing this or not will not cause interoperability problems since it is
after the IGP cost in the decision.  If router A forwards to router B
because the cost to reach the route is shorter through router B, then
router B won't forward back to router A (higher IGP cost).

This just prevents changing the decision if the route from the lower
BGP Identifier flaps a lot.

Putting this in the spec as optional would be harmless and useful.

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 31 Oct 2002 15:29:45 -0500

Curtis,

> Putting this in the spec as optional would be harmless and useful.

I hadn't actually thought about it those particular terms.

However, I'll pass along some comments from this last NANOG:
Some operators would *really* prefer deterministic route selection.

Of course, as you note, if we make it past the IGP cost steps, we
are simply choosing stuff based on arbitrary criteria to be deterministic
and that some of the implementation changes to introduce temporal
ordering are to introduce stability.

Potentially competing goals.

In response to a comment from a particular lady, I suggested that we
should make sure our implementations all show (during your show ip route
equivalent) what in the tie-breaking process was used to select
a given route.

If we actually decided to go with this, it'd be a cool thing to put
into the MIB.

-- 
Jeff Haas 
NextHop Technologies