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

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
Date: Thu, 24 Oct 2002 21:35:40 +0530

Hi,
            It is quiet possible that, we may receive multiple routes for
same destination with  varying CLUSTER list length's, even though we are not
enabled  ( or Implemented)   RR features on a router.  So i feel we can add
this in base spec with indication as   optional to implement. 
 
This is cisco's best path selection algorithm
 
         http://www.cisco.com/warp/public/459/25.shtml
<http://www.cisco.com/warp/public/459/25.shtml> 
 
Venu 

-----Original Message-----
From: vrishab sikand [mailto:[email-masked]]
Sent: Thursday, October 24, 2002 9:16 PM
To: Yakov Rekhter; Jeffrey Haas
Cc: [email-masked]
Subject: Re: missing issue - implemented route selections not necessarily
consistant with draft 

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,

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

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.

   _____  

Do you Yahoo!?
Y! Web Hosting <http://webhosting.yahoo.com/>  - Let the expert host your
web site

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 24 Oct 2002 09:12:40 -0700

Venu,

> this in base spec with indication as  optional to implement. 

If you don't implement the RR spec, then *by definition* you can't
recognize CLUSTER_LIST attribute (as this attribute is defined
in the RR spec). And if you can't recognize the attribute, then you
can't take it into account for your route selection. 

In other words, you either implement the RR spec (and in this case
you also implement the route selection procedures specific to the
RR spec), or you don't (and in this case you can't take into account
various attributes defined in the RR spec).

Yakov.

> ------_=_NextPart_001_01C27B77.329D9CF0
> Content-Type: text/html;
> 	charset="iso-8859-1"
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
> 
> 
> <META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
> <BODY>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002>Hi,</SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;It 
> is quiet possible that, we may receive multiple routes for same destination 
> with&nbsp; varying CLUSTER&nbsp;list length's, even though we are not 
> enabled&nbsp; ( or Implemented)&nbsp;&nbsp; RR features on a router.&nbsp; So
 
> i&nbsp;feel  we can add this in base spec&nbsp;with indication as&nbsp;&nbsp;
 
> optional to implement. </SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=985534615-24102002>Thi
s 
> is cisco's best path selection algorithm</SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A 
> href="http://www.cisco.com/warp/public/459/25.shtml">http://www.cisco.com/war
p/public/459/25.shtml</A></SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=985534615-24102002>Ven
u 
> </SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT><FONT face=Tahoma size=2>-----Original
 
> Message-----<BR><B>From:</B> vrishab sikand 
> [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, October 24, 2002 9:16 
> PM<BR><B>To:</B> Yakov Rekhter; Jeffrey Haas<BR><B>Cc:</B> 
> [email-masked]<BR><B>Subject:</B> Re: missing issue - implemented route 
> selections not necessarily consistant with draft <BR><BR></DIV>
> <BLOCKQUOTE></FONT>
>   <P>The original thought expressed in the route reflector RFC was that: thos
e 
>   routers which are not configured as route reflectors do not need to have "a
ny" 
>   knowledge route reflector attributes. This i think was done to ease the 
>   migration to RR's. 
>   <P>I&nbsp;understand that &nbsp;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. 
>   <P> 
>   <P>&nbsp;<B><I>Yakov Rekhter &lt;[email-masked]&gt;</I></B> wrote: 
>   <BLOCKQUOTE 
>   style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"
>Jeff,<BR><BR>&gt; 
>     Reviewing my inbox, I think we dropped an issue - or I've misplaced<BR>&g
t; 
>     the resolution of it.<BR>&gt; <BR>&gt; Our route selection tie-breaking 
>     process in -17 doesn't match at<BR>&gt; least two of the 
>     $LARGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per vrisha
b 
>     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 (configured 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 issues 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 
>   process).<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 host your web site</BLOCKQUOTE></BODY></HTML>
> 
> ------_=_NextPart_001_01C27B77.329D9CF0--

---

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

Yakov.
I agree. Thanks for the explanation. 
It seems that every implementation must atleast be able to decode ORIGINATOR ID and CLUSTER LIST attributes, even if they dont support rest of RR features. If they dont do so, then they cannot be deployed in a network which has route reflectors.
 Yakov Rekhter <[email-masked]> wrote:
Venu,

Yakov.

> Yakov Rekhter wrote: 
> Y! Web Hosting - Let the expert host your
> web site
> 
> 
> class=985534615-24102002>Hi,
> > class=985534615-24102002>        &nbs
p;   It 
> with  varying CLUSTER list length's, even though we are not 
> enabled  ( or Implemented)   RR features on a router.  So

> i feel we can add this in base spec with indication as  

> optional to implement. 
> > class=985534615-24102002> 
> Thi
s 
> is cisco's best path selection algorithm
> > class=985534615-24102002> 
> > class=985534615-24102002>         > href="http://www.cisco.com/warp/public/459/25.shtml">http://www.cisco.com/war
p/public/459/25.shtml
> > class=985534615-24102002> 
> Ven
u 
> 
> > class=985534615-24102002> 
> > class=985534615-24102002> 
> > class=985534615-24102002> 
> > class=985534615-24102002>-----Original

> Message-----
From: vrishab sikand 
> [mailto:[email-masked]]
Sent: Thursday, October 24, 2002 9:16 
> PM
Cc: 
> [email-masked]
Subject: Re: missing issue - implemented route 
> selections not necessarily consistant with draft 

The original thought expressed in the route reflector RFC was that: thos
e 
ny" 
> knowledge route reflector attributes. This i think was done to ease the 
I understand that  for the major vendors, even if you are not 

> Reviewing my inbox, I think we dropped an issue - or I've misplaced
&g
t; 
> Noted differences are (per vrisha
b 
> sikand):
> 1) originator ID (to be substituited for router id, when

> present
3) 

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

Yakov.

---------------------------------

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

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

---

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

In message <[email-masked]>, Yakov Rekhter writes
> > <http://www.cisco.com/warp/public/459/25.shtml> 

It is also worth pointing out that because RR attributes (CLUSTER_LIST
length) are considered after IGP cost, considering it or not does not
cause any interoperability problems between RR incapable routers and
RR capable routers.

Therefore it does not need to go into the BGP spec and the RR spec
does not need to be changed.  Statements about migration in the RR
spec remain accurate.

Curtis