Subject: Re: Aggregation
From: Jeffrey Haas <[email-masked]>
To: "Natale, Jonathan" <[email-masked]>
Cc: "Bgp Mail List (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Tue, 31 Oct 2000 11:39:18 -0500

On Tue, Oct 31, 2000 at 10:36:55AM -0500, Natale, Jonathan wrote:
> RFC1771 (and the latest draft, draft-ietf-idr-bgp4-10.txt) states:
> 
>    "Routes that have the following attributes shall not be aggregated
>    unless the corresponding attributes of each route are identical:
>    MULTI_EXIT_DISC, NEXT_HOP."
> 
> Cisco and gated do not seem to follow this 

>From http://www.gated.org/gated-web/code/doc/manuals/config_guide/aggr_stmt.html

: The option bgp specifies that this aggregate will use bgp rules to
: determine whether or not to include each route.  BGP specifies that
: routes with different MEDs/next hops can't be aggregated together.

> -Jonathan

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 31 Oct 2000 11:39:18 -0500
From: Jeffrey Haas <[email-masked]>
To: "Natale, Jonathan" <[email-masked]>
Cc: "Bgp Mail List (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Aggregation
Sender: [email-masked]

On Tue, Oct 31, 2000 at 10:36:55AM -0500, Natale, Jonathan wrote:
> RFC1771 (and the latest draft, draft-ietf-idr-bgp4-10.txt) states:
> 
>    "Routes that have the following attributes shall not be aggregated
>    unless the corresponding attributes of each route are identical:
>    MULTI_EXIT_DISC, NEXT_HOP."
> 
> Cisco and gated do not seem to follow this 

>From http://www.gated.org/gated-web/code/doc/manuals/config_guide/aggr_stmt.html

: The option bgp specifies that this aggregate will use bgp rules to
: determine whether or not to include each route.  BGP specifies that
: routes with different MEDs/next hops can't be aggregated together.

> -Jonathan

-- 
Jeff Haas 
NextHop Technologies

From: "Natale, Jonathan" <[email-masked]>
To: "Bgp Ietf Mail List (E-mail)" <[email-masked]>, "Bgp Mail List (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Aggregation
Date: Tue, 31 Oct 2000 10:36:55 -0500
Sender: [email-masked]

Please clarify --

RFC1771 (and the latest draft, draft-ietf-idr-bgp4-10.txt) states:

   "Routes that have the following attributes shall not be aggregated
   unless the corresponding attributes of each route are identical:
   MULTI_EXIT_DISC, NEXT_HOP."

Cisco and gated do not seem to follow this (although I have heard that Cisco
may add a knob for the MULTI_EXIT_DISC part of this). What is the intent of
this requirement? I would expect the routes to have different next hops.

Thank you,
-Jonathan

From: "Shah, Himanshu" <[email-masked]>
To: "'vikram idrp'" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: iBGP/eBGP interaction question
Date: Fri, 27 Oct 2000 08:41:54 -0400
Sender: [email-masked]

yes it is implementation dependent.
Not sending does not cause any problem unless you had 
advertised the prefix reachability through you (in which
case you should send withdraw).

-----Original Message-----
From: vikram idrp [mailto:[email-masked]]
Sent: Friday, October 27, 2000 12:02 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: iBGP/eBGP interaction question

>From: "Shah, Himanshu" <[email-masked]>
>To: "'Andrew Wu'" <[email-masked]>
>CC: "[email-masked]'" <[email-masked]>
>Subject: RE: iBGP/eBGP interaction question
>Date: Thu, 26 Oct 2000 07:44:45 -0400
>
>From what I know, withdraw is sent to best advertiser as soon he is
>selected when processing his advertised route.

Doesn't this depend upon the implementation. How would not sending cause a 
problem?

Vikram
>-----Original Message-----
>From: Andrew Wu [mailto:[email-masked]]
>Sent: Wednesday, October 25, 2000 4:39 PM
>To: 'Shah, Himanshu'
>Subject: RE: iBGP/eBGP interaction question
>
>
>
>
>-----Original Message-----
>From: Shah, Himanshu [mailto:[email-masked]]
>Sent: Tuesday, October 24, 2000 7:04 AM
>To: Andrew Wu; Anoop Ghanwani
>Cc: [email-masked]'
>Subject: RE: iBGP/eBGP interaction question
>
>
>Good point. Although, I would note that if you are engaged in
>refresh-capabilities
>1) peer has to keep Adj-Rib-out which I admit would be smaller than
>Adj-Rib-in.
>     Some implementations do not keep an explicit copy of rib-out but 
>derive
>it from rib-in.
>[Andrew Wu]
>
>If Rib-out is not there, how could the code tell if it needs to send a
>WITHDRAW a not?
>
>-andrew
>
>2) You have to keep Adj-Rib-in for those peers who do not support refresh
>capabilities
>3)  you may have to keep a list of peers who support refresh, wait for all
>refresh updates,
>      and then build rib-out using changed policies
>3) refresh generates additional traffic
>
>
>
>-----Original Message-----
>From: Andrew Wu [mailto:[email-masked]]
>Sent: Monday, October 23, 2000 9:52 PM
>To: Anoop Ghanwani; 'Ben Black'
>Cc: [email-masked]'
>Subject: RE: iBGP/eBGP interaction question
>
>
>One way to save memory is to look at supporting the
>Refresh Capability, so that when import policy
>changes, make use of Refresh to get back tranditionally
>saved info.
>
>-andrew
>
>-----Original Message-----
>From: Anoop Ghanwani
>Sent: Monday, October 23, 2000 6:37 PM
>To: 'Ben Black'
>Cc: [email-masked]'
>Subject: RE: iBGP/eBGP interaction question
>
>
>
>
>It sounds like the correct behavior would be for a router
>to withdraw the route it had previously advertised from
>all of its iBGP peers in the situation where it
>receives a better route, even if it's from an iBGP peer.
>Please correct me if my interpretation of the rules is
>incorrect.
>
>Another question:  Why does a router need to store all of
>the routes that it learns from every peer?  Some routers
>allow the operator to specify that routes that don't make it
>to the local RIB be thrown away to conserve resources.
>How are withdrawn routes and reconfiguration handled in
>that case?
>
>Thanks, -Anoop
>
> > -----Original Message-----
> > From: Ben Black [ mailto:[email-masked] <mailto:[email-masked]> ]
> > Sent: Monday, October 23, 2000 2:02 PM
> > To: Anoop Ghanwani
> > Cc: [email-masked]'
> > Subject: Re: iBGP/eBGP interaction question
> >
> >
> > the 2 things you should remember are:
> >
> > 1) barring rules restricted readvertisement among IBGP
> > neighbors, all prefixes heard from peers are stored
> > (Adj-RIB-In), and the selected best path is advertised
> > to all peers.
> >
> > 2) of the 3 methods for withdrawing a route, the one
> > relevant here is the advertisement of new NLRI for a
> > previously advertised prefix.
> >
> > does this clarify the rules that determine the answer
> > to your question?
> >
> >
> > ben
> >
> > On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote:
> > >
> > > I have a question related to the interaction between
> > > iBGP and eBGP when the same prefix is advertised
> > > by both.  Consider the following example with 5
> > > routers.
> > >
> > > Rx--------Ra---------Rb----------Rc----------Ry
> > >
> > > - We have eBGP between Rx and Ra, and between
> > >   Ry and Rc.
> > > - We have full mesh iBGP between Ra, Rb, Rc
> > >
> > > A prefix p gets advertized by Rx and Ry into the
> > > AS containing Ra, Rb, Rc.  Let's call the prefix
> > > p' coming into Ra, and p'' coming into Rc.
> > > Let's say the local pref at Ra is set to 100
> > > and at Rc it is 200.  Then the prefix p'' is used
> > > and all traffic destined to p will exit the
> > > AS from Rc.
> > >
> > > Now the local pref at Ra is changed to 300.
> > > This means that p' should become the active
> > > prefix and this change is propagated to Rb
> > > and Rc.
> > >
> > > Now the question is:  At this point, does Rc
> > > send a message to withdraw prefix p'' from
> > > its iBGP/eBGP peers?  I guess what I'm asking is:
> > > When a router receives a route from 2 BGP
> > > peers (could be iBGP, eBGP or a combination),
> > > is it required to store both, or does it just
> > > pick the best one and store that?  If it
> > > only picks the best one, then it must withdraw
> > > a route that becomes less preferred at a later
> > > time.
> > >
> > > Thanks, -Anoop
> >
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

From: "vikram idrp" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: iBGP/eBGP interaction question
Date: Fri, 27 Oct 2000 04:01:56 GMT
Sender: [email-masked]

>From: "Shah, Himanshu" <[email-masked]>
>To: "'Andrew Wu'" <[email-masked]>
>CC: "[email-masked]'" <[email-masked]>
>Subject: RE: iBGP/eBGP interaction question
>Date: Thu, 26 Oct 2000 07:44:45 -0400
>
>From what I know, withdraw is sent to best advertiser as soon he is
>selected when processing his advertised route.

Doesn't this depend upon the implementation. How would not sending cause a 
problem?

Vikram
>-----Original Message-----
>From: Andrew Wu [mailto:[email-masked]]
>Sent: Wednesday, October 25, 2000 4:39 PM
>To: 'Shah, Himanshu'
>Subject: RE: iBGP/eBGP interaction question
>
>
>
>
>-----Original Message-----
>From: Shah, Himanshu [mailto:[email-masked]]
>Sent: Tuesday, October 24, 2000 7:04 AM
>To: Andrew Wu; Anoop Ghanwani
>Cc: [email-masked]'
>Subject: RE: iBGP/eBGP interaction question
>
>
>Good point. Although, I would note that if you are engaged in
>refresh-capabilities
>1) peer has to keep Adj-Rib-out which I admit would be smaller than
>Adj-Rib-in.
>     Some implementations do not keep an explicit copy of rib-out but 
>derive
>it from rib-in.
>[Andrew Wu]
>
>If Rib-out is not there, how could the code tell if it needs to send a
>WITHDRAW a not?
>
>-andrew
>
>2) You have to keep Adj-Rib-in for those peers who do not support refresh
>capabilities
>3)  you may have to keep a list of peers who support refresh, wait for all
>refresh updates,
>      and then build rib-out using changed policies
>3) refresh generates additional traffic
>
>
>
>-----Original Message-----
>From: Andrew Wu [mailto:[email-masked]]
>Sent: Monday, October 23, 2000 9:52 PM
>To: Anoop Ghanwani; 'Ben Black'
>Cc: [email-masked]'
>Subject: RE: iBGP/eBGP interaction question
>
>
>One way to save memory is to look at supporting the
>Refresh Capability, so that when import policy
>changes, make use of Refresh to get back tranditionally
>saved info.
>
>-andrew
>
>-----Original Message-----
>From: Anoop Ghanwani
>Sent: Monday, October 23, 2000 6:37 PM
>To: 'Ben Black'
>Cc: [email-masked]'
>Subject: RE: iBGP/eBGP interaction question
>
>
>
>
>It sounds like the correct behavior would be for a router
>to withdraw the route it had previously advertised from
>all of its iBGP peers in the situation where it
>receives a better route, even if it's from an iBGP peer.
>Please correct me if my interpretation of the rules is
>incorrect.
>
>Another question:  Why does a router need to store all of
>the routes that it learns from every peer?  Some routers
>allow the operator to specify that routes that don't make it
>to the local RIB be thrown away to conserve resources.
>How are withdrawn routes and reconfiguration handled in
>that case?
>
>Thanks, -Anoop
>
> > -----Original Message-----
> > From: Ben Black [ mailto:[email-masked] <mailto:[email-masked]> ]
> > Sent: Monday, October 23, 2000 2:02 PM
> > To: Anoop Ghanwani
> > Cc: [email-masked]'
> > Subject: Re: iBGP/eBGP interaction question
> >
> >
> > the 2 things you should remember are:
> >
> > 1) barring rules restricted readvertisement among IBGP
> > neighbors, all prefixes heard from peers are stored
> > (Adj-RIB-In), and the selected best path is advertised
> > to all peers.
> >
> > 2) of the 3 methods for withdrawing a route, the one
> > relevant here is the advertisement of new NLRI for a
> > previously advertised prefix.
> >
> > does this clarify the rules that determine the answer
> > to your question?
> >
> >
> > ben
> >
> > On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote:
> > >
> > > I have a question related to the interaction between
> > > iBGP and eBGP when the same prefix is advertised
> > > by both.  Consider the following example with 5
> > > routers.
> > >
> > > Rx--------Ra---------Rb----------Rc----------Ry
> > >
> > > - We have eBGP between Rx and Ra, and between
> > >   Ry and Rc.
> > > - We have full mesh iBGP between Ra, Rb, Rc
> > >
> > > A prefix p gets advertized by Rx and Ry into the
> > > AS containing Ra, Rb, Rc.  Let's call the prefix
> > > p' coming into Ra, and p'' coming into Rc.
> > > Let's say the local pref at Ra is set to 100
> > > and at Rc it is 200.  Then the prefix p'' is used
> > > and all traffic destined to p will exit the
> > > AS from Rc.
> > >
> > > Now the local pref at Ra is changed to 300.
> > > This means that p' should become the active
> > > prefix and this change is propagated to Rb
> > > and Rc.
> > >
> > > Now the question is:  At this point, does Rc
> > > send a message to withdraw prefix p'' from
> > > its iBGP/eBGP peers?  I guess what I'm asking is:
> > > When a router receives a route from 2 BGP
> > > peers (could be iBGP, eBGP or a combination),
> > > is it required to store both, or does it just
> > > pick the best one and store that?  If it
> > > only picks the best one, then it must withdraw
> > > a route that becomes less preferred at a later
> > > time.
> > >
> > > Thanks, -Anoop
> >
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

From: "Shah, Himanshu" <[email-masked]>
To: "'Andrew Wu'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: iBGP/eBGP interaction question
Date: Thu, 26 Oct 2000 07:44:45 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C03F42.238492FA
Content-Type: text/plain;
	charset="iso-8859-1"

>From what I know, withdraw is sent to best advertiser as soon he is 
selected when processing his advertised route.

-----Original Message-----
From: Andrew Wu [mailto:[email-masked]]
Sent: Wednesday, October 25, 2000 4:39 PM
To: 'Shah, Himanshu'
Subject: RE: iBGP/eBGP interaction question

 

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]]
Sent: Tuesday, October 24, 2000 7:04 AM
To: Andrew Wu; Anoop Ghanwani
Cc: [email-masked]'
Subject: RE: iBGP/eBGP interaction question

Good point. Although, I would note that if you are engaged in
refresh-capabilities
1) peer has to keep Adj-Rib-out which I admit would be smaller than
Adj-Rib-in. 
    Some implementations do not keep an explicit copy of rib-out but derive
it from rib-in.
[Andrew Wu] 
 
If Rib-out is not there, how could the code tell if it needs to send a
WITHDRAW a not?
 
-andrew
 
2) You have to keep Adj-Rib-in for those peers who do not support refresh
capabilities
3)  you may have to keep a list of peers who support refresh, wait for all
refresh updates,
     and then build rib-out using changed policies
3) refresh generates additional traffic 

-----Original Message-----
From: Andrew Wu [mailto:[email-masked]]
Sent: Monday, October 23, 2000 9:52 PM
To: Anoop Ghanwani; 'Ben Black'
Cc: [email-masked]'
Subject: RE: iBGP/eBGP interaction question

One way to save memory is to look at supporting the
Refresh Capability, so that when import policy
changes, make use of Refresh to get back tranditionally
saved info.
 
-andrew

-----Original Message-----
From: Anoop Ghanwani 
Sent: Monday, October 23, 2000 6:37 PM
To: 'Ben Black'
Cc: [email-masked]'
Subject: RE: iBGP/eBGP interaction question

It sounds like the correct behavior would be for a router 
to withdraw the route it had previously advertised from 
all of its iBGP peers in the situation where it 
receives a better route, even if it's from an iBGP peer.  
Please correct me if my interpretation of the rules is 
incorrect. 

Another question:  Why does a router need to store all of 
the routes that it learns from every peer?  Some routers 
allow the operator to specify that routes that don't make it 
to the local RIB be thrown away to conserve resources.  
How are withdrawn routes and reconfiguration handled in 
that case? 

Thanks, -Anoop 

> -----Original Message----- 
> From: Ben Black [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Monday, October 23, 2000 2:02 PM 
> To: Anoop Ghanwani 
> Cc: [email-masked]' 
> Subject: Re: iBGP/eBGP interaction question 
> 
> 
> the 2 things you should remember are: 
> 
> 1) barring rules restricted readvertisement among IBGP 
> neighbors, all prefixes heard from peers are stored 
> (Adj-RIB-In), and the selected best path is advertised 
> to all peers. 
> 
> 2) of the 3 methods for withdrawing a route, the one 
> relevant here is the advertisement of new NLRI for a 
> previously advertised prefix. 
> 
> does this clarify the rules that determine the answer 
> to your question? 
> 
> 
> ben 
> 
> On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote: 
> > 
> > I have a question related to the interaction between 
> > iBGP and eBGP when the same prefix is advertised 
> > by both.  Consider the following example with 5 
> > routers. 
> > 
> > Rx--------Ra---------Rb----------Rc----------Ry 
> > 
> > - We have eBGP between Rx and Ra, and between 
> >   Ry and Rc. 
> > - We have full mesh iBGP between Ra, Rb, Rc 
> > 
> > A prefix p gets advertized by Rx and Ry into the 
> > AS containing Ra, Rb, Rc.  Let's call the prefix 
> > p' coming into Ra, and p'' coming into Rc.  
> > Let's say the local pref at Ra is set to 100 
> > and at Rc it is 200.  Then the prefix p'' is used 
> > and all traffic destined to p will exit the 
> > AS from Rc. 
> > 
> > Now the local pref at Ra is changed to 300. 
> > This means that p' should become the active 
> > prefix and this change is propagated to Rb 
> > and Rc. 
> > 
> > Now the question is:  At this point, does Rc 
> > send a message to withdraw prefix p'' from 
> > its iBGP/eBGP peers?  I guess what I'm asking is: 
> > When a router receives a route from 2 BGP 
> > peers (could be iBGP, eBGP or a combination), 
> > is it required to store both, or does it just 
> > pick the best one and store that?  If it 
> > only picks the best one, then it must withdraw 
> > a route that becomes less preferred at a later 
> > time. 
> > 
> > Thanks, -Anoop 
> 

------_=_NextPart_001_01C03F42.238492FA
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">
<TITLE>RE: iBGP/eBGP interaction question</TITLE>

<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=307085011-26102000><FONT face=Arial color=#0000ff size=2>From 
what I know, withdraw is sent to best advertiser as soon he is 
</FONT></SPAN></DIV>
<DIV><SPAN class=307085011-26102000><FONT face=Arial color=#0000ff 
size=2>selected when processing his advertised route.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Andrew Wu 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, October 25, 2000 
  4:39 PM<BR><B>To:</B> 'Shah, Himanshu'<BR><B>Subject:</B> RE: iBGP/eBGP 
  interaction question<BR><BR></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Shah, Himanshu 
    [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, October 24, 2000 
    7:04 AM<BR><B>To:</B> Andrew Wu; Anoop Ghanwani<BR><B>Cc:</B> 
    [email-masked]'<BR><B>Subject:</B> RE: iBGP/eBGP interaction 
    question<BR><BR></DIV></FONT>
    <DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
    size=2>Good point. Although, I would note that if you are engaged in 
    refresh-capabilities</FONT></SPAN></DIV>
    <DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff size=2>1) 
    peer has&nbsp;to keep Adj-Rib-out&nbsp;</FONT></SPAN><SPAN 
    class=968354413-24102000><FONT face=Arial color=#0000ff size=2>which I admit 
    would be smaller than Adj-Rib-in. </FONT></SPAN></DIV>
    <DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
    size=2>&nbsp;&nbsp;&nbsp; Some implementations do not 
    keep&nbsp;</FONT></SPAN><FONT size=2><FONT color=#0000ff><FONT 
    face=Arial><SPAN class=968354413-24102000>an explicit copy of rib-out but 
    derive it from rib-in.<BR><SPAN class=437403820-25102000>[Andrew 
    Wu]&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
    <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=968354413-24102000><SPAN 
    class=437403820-25102000></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=968354413-24102000><SPAN class=437403820-25102000>If Rib-out is not 
    there, how could the code tell if it needs to send a WITHDRAW a 
    not?</SPAN></SPAN></FONT></FONT></FONT></DIV>
    <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=968354413-24102000><SPAN 
    class=437403820-25102000></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=968354413-24102000><SPAN 
    class=437403820-25102000>-andrew</SPAN></SPAN></FONT></FONT></FONT></DIV>
    <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=968354413-24102000><SPAN 
    class=437403820-25102000></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
    <DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff size=2>2) 
    You have to keep&nbsp;Adj-Rib-in for those peers who do 
    not&nbsp;</FONT></SPAN><SPAN class=968354413-24102000><FONT face=Arial 
    color=#0000ff size=2>support refresh capabilities</FONT></SPAN></DIV>
    <DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
    size=2>3)&nbsp; you may have to keep a list of peers who support refresh, 
    wait for&nbsp;all refresh updates,</FONT></SPAN></DIV>
    <DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp; and then build rib-out using changed 
    policies</FONT></SPAN></DIV>
    <DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff size=2>3) 
    refresh generates additional traffic </FONT></SPAN></DIV>
    <DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Andrew Wu 
      [mailto:[email-masked]]<BR><B>Sent:</B> Monday, October 23, 2000 
      9:52 PM<BR><B>To:</B> Anoop Ghanwani; 'Ben Black'<BR><B>Cc:</B> 
      [email-masked]'<BR><B>Subject:</B> RE: iBGP/eBGP interaction 
      question<BR><BR></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=046184901-24102000>One way to save memory is to look at supporting 
      the</SPAN></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=046184901-24102000>Refresh Capability, so that when import 
      policy</SPAN></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=046184901-24102000>changes,&nbsp;make use of Refresh to get back 
      tranditionally</SPAN></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=046184901-24102000>saved info.</SPAN></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=046184901-24102000></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=046184901-24102000>-andrew</SPAN></FONT></DIV>
      <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
        <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
        size=2>-----Original Message-----<BR><B>From:</B> Anoop Ghanwani 
        <BR><B>Sent:</B> Monday, October 23, 2000 6:37 PM<BR><B>To:</B> 'Ben 
        Black'<BR><B>Cc:</B> [email-masked]'<BR><B>Subject:</B> RE: iBGP/eBGP 
        interaction question<BR><BR></DIV></FONT><BR>
        <P><FONT size=2>It sounds like the correct behavior would be for a 
        router</FONT> <BR><FONT size=2>to withdraw the route it had previously 
        advertised from </FONT><BR><FONT size=2>all of its iBGP peers in the 
        situation where it</FONT> <BR><FONT size=2>receives a better route, even 
        if it's from an iBGP peer.&nbsp; </FONT><BR><FONT size=2>Please correct 
        me if my interpretation of the rules is</FONT> <BR><FONT 
        size=2>incorrect.</FONT> </P>
        <P><FONT size=2>Another question:&nbsp; Why does a router need to store 
        all of</FONT> <BR><FONT size=2>the routes that it learns from every 
        peer?&nbsp; Some routers </FONT><BR><FONT size=2>allow the operator to 
        specify that routes that don't make it</FONT> <BR><FONT size=2>to the 
        local RIB be thrown away to conserve resources.&nbsp; </FONT><BR><FONT 
        size=2>How are withdrawn routes and reconfiguration handled in 
        </FONT><BR><FONT size=2>that case?</FONT> </P>
        <P><FONT size=2>Thanks, -Anoop</FONT> </P>
        <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
        size=2>&gt; From: Ben Black [<A 
        href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> <BR><FONT 
        size=2>&gt; Sent: Monday, October 23, 2000 2:02 PM</FONT> <BR><FONT 
        size=2>&gt; To: Anoop Ghanwani</FONT> <BR><FONT size=2>&gt; Cc: 
        [email-masked]'</FONT> <BR><FONT size=2>&gt; Subject: Re: iBGP/eBGP 
        interaction question</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
        size=2>&gt; </FONT><BR><FONT size=2>&gt; the 2 things you should 
        remember are:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
        1) barring rules restricted readvertisement among IBGP</FONT> <BR><FONT 
        size=2>&gt; neighbors, all prefixes heard from peers are stored</FONT> 
        <BR><FONT size=2>&gt; (Adj-RIB-In), and the selected best path is 
        advertised</FONT> <BR><FONT size=2>&gt; to all peers.</FONT> <BR><FONT 
        size=2>&gt; </FONT><BR><FONT size=2>&gt; 2) of the 3 methods for 
        withdrawing a route, the one</FONT> <BR><FONT size=2>&gt; relevant here 
        is the advertisement of new NLRI for a</FONT> <BR><FONT size=2>&gt; 
        previously advertised prefix.</FONT> <BR><FONT size=2>&gt; 
        </FONT><BR><FONT size=2>&gt; does this clarify the rules that determine 
        the answer</FONT> <BR><FONT size=2>&gt; to your question?</FONT> 
        <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
        size=2>&gt; ben</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
        size=2>&gt; On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani 
        wrote:</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
        &gt; I have a question related to the interaction between</FONT> 
        <BR><FONT size=2>&gt; &gt; iBGP and eBGP when the same prefix is 
        advertised</FONT> <BR><FONT size=2>&gt; &gt; by both.&nbsp; Consider the 
        following example with 5</FONT> <BR><FONT size=2>&gt; &gt; 
        routers.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
        &gt; Rx--------Ra---------Rb----------Rc----------Ry</FONT> <BR><FONT 
        size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; - We have eBGP 
        between Rx and Ra, and between</FONT> <BR><FONT size=2>&gt; 
        &gt;&nbsp;&nbsp; Ry and Rc.</FONT> <BR><FONT size=2>&gt; &gt; - We have 
        full mesh iBGP between Ra, Rb, Rc</FONT> <BR><FONT size=2>&gt; &gt; 
        </FONT><BR><FONT size=2>&gt; &gt; A prefix p gets advertized by Rx and 
        Ry into the</FONT> <BR><FONT size=2>&gt; &gt; AS containing Ra, Rb, 
        Rc.&nbsp; Let's call the prefix </FONT><BR><FONT size=2>&gt; &gt; p' 
        coming into Ra, and p'' coming into Rc.&nbsp; </FONT><BR><FONT 
        size=2>&gt; &gt; Let's say the local pref at Ra is set to 100</FONT> 
        <BR><FONT size=2>&gt; &gt; and at Rc it is 200.&nbsp; Then the prefix 
        p'' is used</FONT> <BR><FONT size=2>&gt; &gt; and all traffic destined 
        to p will exit the</FONT> <BR><FONT size=2>&gt; &gt; AS from Rc.</FONT> 
        <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Now the 
        local pref at Ra is changed to 300.</FONT> <BR><FONT size=2>&gt; &gt; 
        This means that p' should become the active</FONT> <BR><FONT size=2>&gt; 
        &gt; prefix and this change is propagated to Rb</FONT> <BR><FONT 
        size=2>&gt; &gt; and Rc.</FONT> <BR><FONT size=2>&gt; &gt; 
        </FONT><BR><FONT size=2>&gt; &gt; Now the question is:&nbsp; At this 
        point, does Rc</FONT> <BR><FONT size=2>&gt; &gt; send a message to 
        withdraw prefix p'' from</FONT> <BR><FONT size=2>&gt; &gt; its iBGP/eBGP 
        peers?&nbsp; I guess what I'm asking is:</FONT> <BR><FONT size=2>&gt; 
        &gt; When a router receives a route from 2 BGP</FONT> <BR><FONT 
        size=2>&gt; &gt; peers (could be iBGP, eBGP or a combination),</FONT> 
        <BR><FONT size=2>&gt; &gt; is it required to store both, or does it 
        just</FONT> <BR><FONT size=2>&gt; &gt; pick the best one and store 
        that?&nbsp; If it</FONT> <BR><FONT size=2>&gt; &gt; only picks the best 
        one, then it must withdraw</FONT> <BR><FONT size=2>&gt; &gt; a route 
        that becomes less preferred at a later </FONT><BR><FONT size=2>&gt; &gt; 
        time.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
        &gt; Thanks, -Anoop</FONT> <BR><FONT size=2>&gt; 
    </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C03F42.238492FA--

From: "Shah, Himanshu" <[email-masked]>
To: "'Andrew Wu'" <[email-masked]>, Anoop Ghanwani <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: iBGP/eBGP interaction question
Date: Tue, 24 Oct 2000 10:03:33 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C03DC3.352A3710
Content-Type: text/plain;
	charset="iso-8859-1"

Good point. Although, I would note that if you are engaged in
refresh-capabilities
1) peer has to keep Adj-Rib-out which I admit would be smaller than
Adj-Rib-in. 
    Some implementations do not keep an explicit copy of rib-out but derive
it from rib-in.
2) You have to keep Adj-Rib-in for those peers who do not support refresh
capabilities
3)  you may have to keep a list of peers who support refresh, wait for all
refresh updates,
     and then build rib-out using changed policies
3) refresh generates additional traffic 

-----Original Message-----
From: Andrew Wu [mailto:[email-masked]]
Sent: Monday, October 23, 2000 9:52 PM
To: Anoop Ghanwani; 'Ben Black'
Cc: [email-masked]'
Subject: RE: iBGP/eBGP interaction question

One way to save memory is to look at supporting the
Refresh Capability, so that when import policy
changes, make use of Refresh to get back tranditionally
saved info.
 
-andrew

-----Original Message-----
From: Anoop Ghanwani 
Sent: Monday, October 23, 2000 6:37 PM
To: 'Ben Black'
Cc: [email-masked]'
Subject: RE: iBGP/eBGP interaction question

It sounds like the correct behavior would be for a router 
to withdraw the route it had previously advertised from 
all of its iBGP peers in the situation where it 
receives a better route, even if it's from an iBGP peer.  
Please correct me if my interpretation of the rules is 
incorrect. 

Another question:  Why does a router need to store all of 
the routes that it learns from every peer?  Some routers 
allow the operator to specify that routes that don't make it 
to the local RIB be thrown away to conserve resources.  
How are withdrawn routes and reconfiguration handled in 
that case? 

Thanks, -Anoop 

> -----Original Message----- 
> From: Ben Black [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Monday, October 23, 2000 2:02 PM 
> To: Anoop Ghanwani 
> Cc: [email-masked]' 
> Subject: Re: iBGP/eBGP interaction question 
> 
> 
> the 2 things you should remember are: 
> 
> 1) barring rules restricted readvertisement among IBGP 
> neighbors, all prefixes heard from peers are stored 
> (Adj-RIB-In), and the selected best path is advertised 
> to all peers. 
> 
> 2) of the 3 methods for withdrawing a route, the one 
> relevant here is the advertisement of new NLRI for a 
> previously advertised prefix. 
> 
> does this clarify the rules that determine the answer 
> to your question? 
> 
> 
> ben 
> 
> On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote: 
> > 
> > I have a question related to the interaction between 
> > iBGP and eBGP when the same prefix is advertised 
> > by both.  Consider the following example with 5 
> > routers. 
> > 
> > Rx--------Ra---------Rb----------Rc----------Ry 
> > 
> > - We have eBGP between Rx and Ra, and between 
> >   Ry and Rc. 
> > - We have full mesh iBGP between Ra, Rb, Rc 
> > 
> > A prefix p gets advertized by Rx and Ry into the 
> > AS containing Ra, Rb, Rc.  Let's call the prefix 
> > p' coming into Ra, and p'' coming into Rc.  
> > Let's say the local pref at Ra is set to 100 
> > and at Rc it is 200.  Then the prefix p'' is used 
> > and all traffic destined to p will exit the 
> > AS from Rc. 
> > 
> > Now the local pref at Ra is changed to 300. 
> > This means that p' should become the active 
> > prefix and this change is propagated to Rb 
> > and Rc. 
> > 
> > Now the question is:  At this point, does Rc 
> > send a message to withdraw prefix p'' from 
> > its iBGP/eBGP peers?  I guess what I'm asking is: 
> > When a router receives a route from 2 BGP 
> > peers (could be iBGP, eBGP or a combination), 
> > is it required to store both, or does it just 
> > pick the best one and store that?  If it 
> > only picks the best one, then it must withdraw 
> > a route that becomes less preferred at a later 
> > time. 
> > 
> > Thanks, -Anoop 
> 

------_=_NextPart_001_01C03DC3.352A3710
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">
<TITLE>RE: iBGP/eBGP interaction question</TITLE>

<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff size=2>Good 
point. Although, I would note that if you are engaged in 
refresh-capabilities</FONT></SPAN></DIV>
<DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff size=2>1) 
peer has&nbsp;to keep Adj-Rib-out&nbsp;</FONT></SPAN><SPAN 
class=968354413-24102000><FONT face=Arial color=#0000ff size=2>which I admit 
would be smaller than Adj-Rib-in. </FONT></SPAN></DIV>
<DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp; Some implementations do not 
keep&nbsp;</FONT></SPAN><SPAN class=968354413-24102000><FONT face=Arial 
color=#0000ff size=2>an explicit copy of rib-out but derive it from 
rib-in.</FONT></SPAN></DIV>
<DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff size=2>2) You 
have to keep&nbsp;Adj-Rib-in for those peers who do not&nbsp;</FONT></SPAN><SPAN 
class=968354413-24102000><FONT face=Arial color=#0000ff size=2>support refresh 
capabilities</FONT></SPAN></DIV>
<DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
size=2>3)&nbsp; you may have to keep a list of peers who support refresh, wait 
for&nbsp;all refresh updates,</FONT></SPAN></DIV>
<DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp; and then build rib-out using changed 
policies</FONT></SPAN></DIV>
<DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff size=2>3) 
refresh generates additional traffic </FONT></SPAN></DIV>
<DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=968354413-24102000><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Andrew Wu 
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, October 23, 2000 9:52 
  PM<BR><B>To:</B> Anoop Ghanwani; 'Ben Black'<BR><B>Cc:</B> 
  [email-masked]'<BR><B>Subject:</B> RE: iBGP/eBGP interaction 
  question<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=046184901-24102000>One 
  way to save memory is to look at supporting the</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=046184901-24102000>Refresh Capability, so that when import 
  policy</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=046184901-24102000>changes,&nbsp;make use of Refresh to get back 
  tranditionally</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=046184901-24102000>saved info.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=046184901-24102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=046184901-24102000>-andrew</SPAN></FONT></DIV>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Anoop Ghanwani 
    <BR><B>Sent:</B> Monday, October 23, 2000 6:37 PM<BR><B>To:</B> 'Ben 
    Black'<BR><B>Cc:</B> [email-masked]'<BR><B>Subject:</B> RE: iBGP/eBGP 
    interaction question<BR><BR></DIV></FONT><BR>
    <P><FONT size=2>It sounds like the correct behavior would be for a 
    router</FONT> <BR><FONT size=2>to withdraw the route it had previously 
    advertised from </FONT><BR><FONT size=2>all of its iBGP peers in the 
    situation where it</FONT> <BR><FONT size=2>receives a better route, even if 
    it's from an iBGP peer.&nbsp; </FONT><BR><FONT size=2>Please correct me if 
    my interpretation of the rules is</FONT> <BR><FONT size=2>incorrect.</FONT> 
    </P>
    <P><FONT size=2>Another question:&nbsp; Why does a router need to store all 
    of</FONT> <BR><FONT size=2>the routes that it learns from every peer?&nbsp; 
    Some routers </FONT><BR><FONT size=2>allow the operator to specify that 
    routes that don't make it</FONT> <BR><FONT size=2>to the local RIB be thrown 
    away to conserve resources.&nbsp; </FONT><BR><FONT size=2>How are withdrawn 
    routes and reconfiguration handled in </FONT><BR><FONT size=2>that 
    case?</FONT> </P>
    <P><FONT size=2>Thanks, -Anoop</FONT> </P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: Ben Black [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> <BR><FONT 
    size=2>&gt; Sent: Monday, October 23, 2000 2:02 PM</FONT> <BR><FONT 
    size=2>&gt; To: Anoop Ghanwani</FONT> <BR><FONT size=2>&gt; Cc: 
    [email-masked]'</FONT> <BR><FONT size=2>&gt; Subject: Re: iBGP/eBGP 
    interaction question</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; the 2 things you should remember 
    are:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 1) barring 
    rules restricted readvertisement among IBGP</FONT> <BR><FONT size=2>&gt; 
    neighbors, all prefixes heard from peers are stored</FONT> <BR><FONT 
    size=2>&gt; (Adj-RIB-In), and the selected best path is advertised</FONT> 
    <BR><FONT size=2>&gt; to all peers.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; 2) of the 3 methods for withdrawing a route, 
    the one</FONT> <BR><FONT size=2>&gt; relevant here is the advertisement of 
    new NLRI for a</FONT> <BR><FONT size=2>&gt; previously advertised 
    prefix.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; does this 
    clarify the rules that determine the answer</FONT> <BR><FONT size=2>&gt; to 
    your question?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; ben</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop 
    Ghanwani wrote:</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
    size=2>&gt; &gt; I have a question related to the interaction between</FONT> 
    <BR><FONT size=2>&gt; &gt; iBGP and eBGP when the same prefix is 
    advertised</FONT> <BR><FONT size=2>&gt; &gt; by both.&nbsp; Consider the 
    following example with 5</FONT> <BR><FONT size=2>&gt; &gt; routers.</FONT> 
    <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    Rx--------Ra---------Rb----------Rc----------Ry</FONT> <BR><FONT size=2>&gt; 
    &gt; </FONT><BR><FONT size=2>&gt; &gt; - We have eBGP between Rx and Ra, and 
    between</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp; Ry and Rc.</FONT> 
    <BR><FONT size=2>&gt; &gt; - We have full mesh iBGP between Ra, Rb, 
    Rc</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; A 
    prefix p gets advertized by Rx and Ry into the</FONT> <BR><FONT size=2>&gt; 
    &gt; AS containing Ra, Rb, Rc.&nbsp; Let's call the prefix </FONT><BR><FONT 
    size=2>&gt; &gt; p' coming into Ra, and p'' coming into Rc.&nbsp; 
    </FONT><BR><FONT size=2>&gt; &gt; Let's say the local pref at Ra is set to 
    100</FONT> <BR><FONT size=2>&gt; &gt; and at Rc it is 200.&nbsp; Then the 
    prefix p'' is used</FONT> <BR><FONT size=2>&gt; &gt; and all traffic 
    destined to p will exit the</FONT> <BR><FONT size=2>&gt; &gt; AS from 
    Rc.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Now 
    the local pref at Ra is changed to 300.</FONT> <BR><FONT size=2>&gt; &gt; 
    This means that p' should become the active</FONT> <BR><FONT size=2>&gt; 
    &gt; prefix and this change is propagated to Rb</FONT> <BR><FONT size=2>&gt; 
    &gt; and Rc.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
    &gt; Now the question is:&nbsp; At this point, does Rc</FONT> <BR><FONT 
    size=2>&gt; &gt; send a message to withdraw prefix p'' from</FONT> <BR><FONT 
    size=2>&gt; &gt; its iBGP/eBGP peers?&nbsp; I guess what I'm asking 
    is:</FONT> <BR><FONT size=2>&gt; &gt; When a router receives a route from 2 
    BGP</FONT> <BR><FONT size=2>&gt; &gt; peers (could be iBGP, eBGP or a 
    combination),</FONT> <BR><FONT size=2>&gt; &gt; is it required to store 
    both, or does it just</FONT> <BR><FONT size=2>&gt; &gt; pick the best one 
    and store that?&nbsp; If it</FONT> <BR><FONT size=2>&gt; &gt; only picks the 
    best one, then it must withdraw</FONT> <BR><FONT size=2>&gt; &gt; a route 
    that becomes less preferred at a later </FONT><BR><FONT size=2>&gt; &gt; 
    time.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    Thanks, -Anoop</FONT> <BR><FONT size=2>&gt; 
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C03DC3.352A3710--

From: "Shah, Himanshu" <[email-masked]>
To: "'Anoop Ghanwani'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: iBGP/eBGP interaction question
Date: Tue, 24 Oct 2000 08:05:27 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C03DB2.B73F30FE
Content-Type: text/plain;
	charset="iso-8859-1"

The routes are stored from every peer, precisely for the reason
that you mention, reconfiguration. If operator changes the 
routing policy, subsequent decision process, may select a
better route from those stored routes. 
 
Note that policy changes on a local router does not incite new
updates from the peers and hence the requirement for storage.

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]]
Sent: Monday, October 23, 2000 9:37 PM
To: 'Ben Black'
Cc: [email-masked]'
Subject: RE: iBGP/eBGP interaction question

It sounds like the correct behavior would be for a router 
to withdraw the route it had previously advertised from 
all of its iBGP peers in the situation where it 
receives a better route, even if it's from an iBGP peer.  
Please correct me if my interpretation of the rules is 
incorrect. 

Another question:  Why does a router need to store all of 
the routes that it learns from every peer?  Some routers 
allow the operator to specify that routes that don't make it 
to the local RIB be thrown away to conserve resources.  
How are withdrawn routes and reconfiguration handled in 
that case? 

Thanks, -Anoop 

> -----Original Message----- 
> From: Ben Black [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Monday, October 23, 2000 2:02 PM 
> To: Anoop Ghanwani 
> Cc: [email-masked]' 
> Subject: Re: iBGP/eBGP interaction question 
> 
> 
> the 2 things you should remember are: 
> 
> 1) barring rules restricted readvertisement among IBGP 
> neighbors, all prefixes heard from peers are stored 
> (Adj-RIB-In), and the selected best path is advertised 
> to all peers. 
> 
> 2) of the 3 methods for withdrawing a route, the one 
> relevant here is the advertisement of new NLRI for a 
> previously advertised prefix. 
> 
> does this clarify the rules that determine the answer 
> to your question? 
> 
> 
> ben 
> 
> On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote: 
> > 
> > I have a question related to the interaction between 
> > iBGP and eBGP when the same prefix is advertised 
> > by both.  Consider the following example with 5 
> > routers. 
> > 
> > Rx--------Ra---------Rb----------Rc----------Ry 
> > 
> > - We have eBGP between Rx and Ra, and between 
> >   Ry and Rc. 
> > - We have full mesh iBGP between Ra, Rb, Rc 
> > 
> > A prefix p gets advertized by Rx and Ry into the 
> > AS containing Ra, Rb, Rc.  Let's call the prefix 
> > p' coming into Ra, and p'' coming into Rc.  
> > Let's say the local pref at Ra is set to 100 
> > and at Rc it is 200.  Then the prefix p'' is used 
> > and all traffic destined to p will exit the 
> > AS from Rc. 
> > 
> > Now the local pref at Ra is changed to 300. 
> > This means that p' should become the active 
> > prefix and this change is propagated to Rb 
> > and Rc. 
> > 
> > Now the question is:  At this point, does Rc 
> > send a message to withdraw prefix p'' from 
> > its iBGP/eBGP peers?  I guess what I'm asking is: 
> > When a router receives a route from 2 BGP 
> > peers (could be iBGP, eBGP or a combination), 
> > is it required to store both, or does it just 
> > pick the best one and store that?  If it 
> > only picks the best one, then it must withdraw 
> > a route that becomes less preferred at a later 
> > time. 
> > 
> > Thanks, -Anoop 
> 

------_=_NextPart_001_01C03DB2.B73F30FE
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">
<TITLE>RE: iBGP/eBGP interaction question</TITLE>

<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=018330912-24102000>The 
routes are stored from every peer, precisely for the reason</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=018330912-24102000>that 
you mention, reconfiguration. If operator changes the </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=018330912-24102000>routing policy, subsequent decision process, may select 
a</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=018330912-24102000>better 
route from those stored routes. </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=018330912-24102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=018330912-24102000>Note 
that policy changes on a local router does not incite new</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=018330912-24102000>updates from the peers and hence the requirement for 
storage.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=018330912-24102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=018330912-24102000></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Anoop Ghanwani 
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, October 23, 2000 9:37 
  PM<BR><B>To:</B> 'Ben Black'<BR><B>Cc:</B> [email-masked]'<BR><B>Subject:</B> 
  RE: iBGP/eBGP interaction question<BR><BR></FONT></DIV><BR>
  <P><FONT size=2>It sounds like the correct behavior would be for a 
  router</FONT> <BR><FONT size=2>to withdraw the route it had previously 
  advertised from </FONT><BR><FONT size=2>all of its iBGP peers in the situation 
  where it</FONT> <BR><FONT size=2>receives a better route, even if it's from an 
  iBGP peer.&nbsp; </FONT><BR><FONT size=2>Please correct me if my 
  interpretation of the rules is</FONT> <BR><FONT size=2>incorrect.</FONT> </P>
  <P><FONT size=2>Another question:&nbsp; Why does a router need to store all 
  of</FONT> <BR><FONT size=2>the routes that it learns from every peer?&nbsp; 
  Some routers </FONT><BR><FONT size=2>allow the operator to specify that routes 
  that don't make it</FONT> <BR><FONT size=2>to the local RIB be thrown away to 
  conserve resources.&nbsp; </FONT><BR><FONT size=2>How are withdrawn routes and 
  reconfiguration handled in </FONT><BR><FONT size=2>that case?</FONT> </P>
  <P><FONT size=2>Thanks, -Anoop</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Ben Black [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> <BR><FONT 
  size=2>&gt; Sent: Monday, October 23, 2000 2:02 PM</FONT> <BR><FONT 
  size=2>&gt; To: Anoop Ghanwani</FONT> <BR><FONT size=2>&gt; Cc: 
  [email-masked]'</FONT> <BR><FONT size=2>&gt; Subject: Re: iBGP/eBGP 
  interaction question</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; the 2 things you should remember are:</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 1) barring rules restricted 
  readvertisement among IBGP</FONT> <BR><FONT size=2>&gt; neighbors, all 
  prefixes heard from peers are stored</FONT> <BR><FONT size=2>&gt; 
  (Adj-RIB-In), and the selected best path is advertised</FONT> <BR><FONT 
  size=2>&gt; to all peers.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; 2) of the 3 methods for withdrawing a route, the one</FONT> 
  <BR><FONT size=2>&gt; relevant here is the advertisement of new NLRI for 
  a</FONT> <BR><FONT size=2>&gt; previously advertised prefix.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; does this clarify the rules that 
  determine the answer</FONT> <BR><FONT size=2>&gt; to your question?</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; ben</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; On 
  Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote:</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; I have a question related 
  to the interaction between</FONT> <BR><FONT size=2>&gt; &gt; iBGP and eBGP 
  when the same prefix is advertised</FONT> <BR><FONT size=2>&gt; &gt; by 
  both.&nbsp; Consider the following example with 5</FONT> <BR><FONT size=2>&gt; 
  &gt; routers.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; Rx--------Ra---------Rb----------Rc----------Ry</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; - We have eBGP between Rx 
  and Ra, and between</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp; Ry and 
  Rc.</FONT> <BR><FONT size=2>&gt; &gt; - We have full mesh iBGP between Ra, Rb, 
  Rc</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; A 
  prefix p gets advertized by Rx and Ry into the</FONT> <BR><FONT size=2>&gt; 
  &gt; AS containing Ra, Rb, Rc.&nbsp; Let's call the prefix </FONT><BR><FONT 
  size=2>&gt; &gt; p' coming into Ra, and p'' coming into Rc.&nbsp; 
  </FONT><BR><FONT size=2>&gt; &gt; Let's say the local pref at Ra is set to 
  100</FONT> <BR><FONT size=2>&gt; &gt; and at Rc it is 200.&nbsp; Then the 
  prefix p'' is used</FONT> <BR><FONT size=2>&gt; &gt; and all traffic destined 
  to p will exit the</FONT> <BR><FONT size=2>&gt; &gt; AS from Rc.</FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Now the local 
  pref at Ra is changed to 300.</FONT> <BR><FONT size=2>&gt; &gt; This means 
  that p' should become the active</FONT> <BR><FONT size=2>&gt; &gt; prefix and 
  this change is propagated to Rb</FONT> <BR><FONT size=2>&gt; &gt; and 
  Rc.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Now 
  the question is:&nbsp; At this point, does Rc</FONT> <BR><FONT size=2>&gt; 
  &gt; send a message to withdraw prefix p'' from</FONT> <BR><FONT size=2>&gt; 
  &gt; its iBGP/eBGP peers?&nbsp; I guess what I'm asking is:</FONT> <BR><FONT 
  size=2>&gt; &gt; When a router receives a route from 2 BGP</FONT> <BR><FONT 
  size=2>&gt; &gt; peers (could be iBGP, eBGP or a combination),</FONT> 
  <BR><FONT size=2>&gt; &gt; is it required to store both, or does it 
  just</FONT> <BR><FONT size=2>&gt; &gt; pick the best one and store that?&nbsp; 
  If it</FONT> <BR><FONT size=2>&gt; &gt; only picks the best one, then it must 
  withdraw</FONT> <BR><FONT size=2>&gt; &gt; a route that becomes less preferred 
  at a later </FONT><BR><FONT size=2>&gt; &gt; time.</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Thanks, -Anoop</FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C03DB2.B73F30FE--

From: Andrew Wu <[email-masked]>
To: Anoop Ghanwani <[email-masked]>, "'Ben Black'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: iBGP/eBGP interaction question
Date: Mon, 23 Oct 2000 18:51:47 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C03D5C.F84A5340
Content-Type: text/plain;
	charset="ISO-8859-1"

One way to save memory is to look at supporting the
Refresh Capability, so that when import policy
changes, make use of Refresh to get back tranditionally
saved info.
 
-andrew

-----Original Message-----
From: Anoop Ghanwani 
Sent: Monday, October 23, 2000 6:37 PM
To: 'Ben Black'
Cc: [email-masked]'
Subject: RE: iBGP/eBGP interaction question

It sounds like the correct behavior would be for a router 
to withdraw the route it had previously advertised from 
all of its iBGP peers in the situation where it 
receives a better route, even if it's from an iBGP peer.  
Please correct me if my interpretation of the rules is 
incorrect. 

Another question:  Why does a router need to store all of 
the routes that it learns from every peer?  Some routers 
allow the operator to specify that routes that don't make it 
to the local RIB be thrown away to conserve resources.  
How are withdrawn routes and reconfiguration handled in 
that case? 

Thanks, -Anoop 

> -----Original Message----- 
> From: Ben Black [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Monday, October 23, 2000 2:02 PM 
> To: Anoop Ghanwani 
> Cc: [email-masked]' 
> Subject: Re: iBGP/eBGP interaction question 
> 
> 
> the 2 things you should remember are: 
> 
> 1) barring rules restricted readvertisement among IBGP 
> neighbors, all prefixes heard from peers are stored 
> (Adj-RIB-In), and the selected best path is advertised 
> to all peers. 
> 
> 2) of the 3 methods for withdrawing a route, the one 
> relevant here is the advertisement of new NLRI for a 
> previously advertised prefix. 
> 
> does this clarify the rules that determine the answer 
> to your question? 
> 
> 
> ben 
> 
> On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote: 
> > 
> > I have a question related to the interaction between 
> > iBGP and eBGP when the same prefix is advertised 
> > by both.  Consider the following example with 5 
> > routers. 
> > 
> > Rx--------Ra---------Rb----------Rc----------Ry 
> > 
> > - We have eBGP between Rx and Ra, and between 
> >   Ry and Rc. 
> > - We have full mesh iBGP between Ra, Rb, Rc 
> > 
> > A prefix p gets advertized by Rx and Ry into the 
> > AS containing Ra, Rb, Rc.  Let's call the prefix 
> > p' coming into Ra, and p'' coming into Rc.  
> > Let's say the local pref at Ra is set to 100 
> > and at Rc it is 200.  Then the prefix p'' is used 
> > and all traffic destined to p will exit the 
> > AS from Rc. 
> > 
> > Now the local pref at Ra is changed to 300. 
> > This means that p' should become the active 
> > prefix and this change is propagated to Rb 
> > and Rc. 
> > 
> > Now the question is:  At this point, does Rc 
> > send a message to withdraw prefix p'' from 
> > its iBGP/eBGP peers?  I guess what I'm asking is: 
> > When a router receives a route from 2 BGP 
> > peers (could be iBGP, eBGP or a combination), 
> > is it required to store both, or does it just 
> > pick the best one and store that?  If it 
> > only picks the best one, then it must withdraw 
> > a route that becomes less preferred at a later 
> > time. 
> > 
> > Thanks, -Anoop 
> 

------_=_NextPart_001_01C03D5C.F84A5340
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">
<TITLE>RE: iBGP/eBGP interaction question</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046184901-24102000>One 
way to save memory is to look at supporting the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046184901-24102000>Refresh Capability, so that when import 
policy</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046184901-24102000>changes,&nbsp;make use of Refresh to get back 
tranditionally</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046184901-24102000>saved 
info.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046184901-24102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046184901-24102000>-andrew</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Anoop Ghanwani 
  <BR><B>Sent:</B> Monday, October 23, 2000 6:37 PM<BR><B>To:</B> 'Ben 
  Black'<BR><B>Cc:</B> [email-masked]'<BR><B>Subject:</B> RE: iBGP/eBGP 
  interaction question<BR><BR></DIV></FONT><BR>
  <P><FONT size=2>It sounds like the correct behavior would be for a 
  router</FONT> <BR><FONT size=2>to withdraw the route it had previously 
  advertised from </FONT><BR><FONT size=2>all of its iBGP peers in the situation 
  where it</FONT> <BR><FONT size=2>receives a better route, even if it's from an 
  iBGP peer.&nbsp; </FONT><BR><FONT size=2>Please correct me if my 
  interpretation of the rules is</FONT> <BR><FONT size=2>incorrect.</FONT> </P>
  <P><FONT size=2>Another question:&nbsp; Why does a router need to store all 
  of</FONT> <BR><FONT size=2>the routes that it learns from every peer?&nbsp; 
  Some routers </FONT><BR><FONT size=2>allow the operator to specify that routes 
  that don't make it</FONT> <BR><FONT size=2>to the local RIB be thrown away to 
  conserve resources.&nbsp; </FONT><BR><FONT size=2>How are withdrawn routes and 
  reconfiguration handled in </FONT><BR><FONT size=2>that case?</FONT> </P>
  <P><FONT size=2>Thanks, -Anoop</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Ben Black [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> <BR><FONT 
  size=2>&gt; Sent: Monday, October 23, 2000 2:02 PM</FONT> <BR><FONT 
  size=2>&gt; To: Anoop Ghanwani</FONT> <BR><FONT size=2>&gt; Cc: 
  [email-masked]'</FONT> <BR><FONT size=2>&gt; Subject: Re: iBGP/eBGP 
  interaction question</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; the 2 things you should remember are:</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 1) barring rules restricted 
  readvertisement among IBGP</FONT> <BR><FONT size=2>&gt; neighbors, all 
  prefixes heard from peers are stored</FONT> <BR><FONT size=2>&gt; 
  (Adj-RIB-In), and the selected best path is advertised</FONT> <BR><FONT 
  size=2>&gt; to all peers.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; 2) of the 3 methods for withdrawing a route, the one</FONT> 
  <BR><FONT size=2>&gt; relevant here is the advertisement of new NLRI for 
  a</FONT> <BR><FONT size=2>&gt; previously advertised prefix.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; does this clarify the rules that 
  determine the answer</FONT> <BR><FONT size=2>&gt; to your question?</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; ben</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; On 
  Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote:</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; I have a question related 
  to the interaction between</FONT> <BR><FONT size=2>&gt; &gt; iBGP and eBGP 
  when the same prefix is advertised</FONT> <BR><FONT size=2>&gt; &gt; by 
  both.&nbsp; Consider the following example with 5</FONT> <BR><FONT size=2>&gt; 
  &gt; routers.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; Rx--------Ra---------Rb----------Rc----------Ry</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; - We have eBGP between Rx 
  and Ra, and between</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp; Ry and 
  Rc.</FONT> <BR><FONT size=2>&gt; &gt; - We have full mesh iBGP between Ra, Rb, 
  Rc</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; A 
  prefix p gets advertized by Rx and Ry into the</FONT> <BR><FONT size=2>&gt; 
  &gt; AS containing Ra, Rb, Rc.&nbsp; Let's call the prefix </FONT><BR><FONT 
  size=2>&gt; &gt; p' coming into Ra, and p'' coming into Rc.&nbsp; 
  </FONT><BR><FONT size=2>&gt; &gt; Let's say the local pref at Ra is set to 
  100</FONT> <BR><FONT size=2>&gt; &gt; and at Rc it is 200.&nbsp; Then the 
  prefix p'' is used</FONT> <BR><FONT size=2>&gt; &gt; and all traffic destined 
  to p will exit the</FONT> <BR><FONT size=2>&gt; &gt; AS from Rc.</FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Now the local 
  pref at Ra is changed to 300.</FONT> <BR><FONT size=2>&gt; &gt; This means 
  that p' should become the active</FONT> <BR><FONT size=2>&gt; &gt; prefix and 
  this change is propagated to Rb</FONT> <BR><FONT size=2>&gt; &gt; and 
  Rc.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Now 
  the question is:&nbsp; At this point, does Rc</FONT> <BR><FONT size=2>&gt; 
  &gt; send a message to withdraw prefix p'' from</FONT> <BR><FONT size=2>&gt; 
  &gt; its iBGP/eBGP peers?&nbsp; I guess what I'm asking is:</FONT> <BR><FONT 
  size=2>&gt; &gt; When a router receives a route from 2 BGP</FONT> <BR><FONT 
  size=2>&gt; &gt; peers (could be iBGP, eBGP or a combination),</FONT> 
  <BR><FONT size=2>&gt; &gt; is it required to store both, or does it 
  just</FONT> <BR><FONT size=2>&gt; &gt; pick the best one and store that?&nbsp; 
  If it</FONT> <BR><FONT size=2>&gt; &gt; only picks the best one, then it must 
  withdraw</FONT> <BR><FONT size=2>&gt; &gt; a route that becomes less preferred 
  at a later </FONT><BR><FONT size=2>&gt; &gt; time.</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Thanks, -Anoop</FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C03D5C.F84A5340--

From: Anoop Ghanwani <[email-masked]>
To: "'Ben Black'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: iBGP/eBGP interaction question
Date: Mon, 23 Oct 2000 18:36:59 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C03D5A.E6CBC9C0
Content-Type: text/plain;
	charset="ISO-8859-1"

It sounds like the correct behavior would be for a router
to withdraw the route it had previously advertised from 
all of its iBGP peers in the situation where it
receives a better route, even if it's from an iBGP peer.  
Please correct me if my interpretation of the rules is
incorrect.

Another question:  Why does a router need to store all of
the routes that it learns from every peer?  Some routers 
allow the operator to specify that routes that don't make it
to the local RIB be thrown away to conserve resources.  
How are withdrawn routes and reconfiguration handled in 
that case?

Thanks, -Anoop

> -----Original Message-----
> From: Ben Black [mailto:[email-masked]]
> Sent: Monday, October 23, 2000 2:02 PM
> To: Anoop Ghanwani
> Cc: [email-masked]'
> Subject: Re: iBGP/eBGP interaction question
> 
> 
> the 2 things you should remember are:
> 
> 1) barring rules restricted readvertisement among IBGP
> neighbors, all prefixes heard from peers are stored
> (Adj-RIB-In), and the selected best path is advertised
> to all peers.
> 
> 2) of the 3 methods for withdrawing a route, the one
> relevant here is the advertisement of new NLRI for a
> previously advertised prefix.
> 
> does this clarify the rules that determine the answer
> to your question?
> 
> 
> ben
> 
> On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote:
> > 
> > I have a question related to the interaction between
> > iBGP and eBGP when the same prefix is advertised
> > by both.  Consider the following example with 5
> > routers.
> > 
> > Rx--------Ra---------Rb----------Rc----------Ry
> > 
> > - We have eBGP between Rx and Ra, and between
> >   Ry and Rc.
> > - We have full mesh iBGP between Ra, Rb, Rc
> > 
> > A prefix p gets advertized by Rx and Ry into the
> > AS containing Ra, Rb, Rc.  Let's call the prefix 
> > p' coming into Ra, and p'' coming into Rc.  
> > Let's say the local pref at Ra is set to 100
> > and at Rc it is 200.  Then the prefix p'' is used
> > and all traffic destined to p will exit the
> > AS from Rc.
> > 
> > Now the local pref at Ra is changed to 300.
> > This means that p' should become the active
> > prefix and this change is propagated to Rb
> > and Rc.
> > 
> > Now the question is:  At this point, does Rc
> > send a message to withdraw prefix p'' from
> > its iBGP/eBGP peers?  I guess what I'm asking is:
> > When a router receives a route from 2 BGP
> > peers (could be iBGP, eBGP or a combination),
> > is it required to store both, or does it just
> > pick the best one and store that?  If it
> > only picks the best one, then it must withdraw
> > a route that becomes less preferred at a later 
> > time.
> > 
> > Thanks, -Anoop
> 

------_=_NextPart_001_01C03D5A.E6CBC9C0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: iBGP/eBGP interaction question</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>It sounds like the correct behavior would be for a router</FONT>
<BR><FONT SIZE=2>to withdraw the route it had previously advertised from </FONT>
<BR><FONT SIZE=2>all of its iBGP peers in the situation where it</FONT>
<BR><FONT SIZE=2>receives a better route, even if it's from an iBGP peer.&nbsp; </FONT>
<BR><FONT SIZE=2>Please correct me if my interpretation of the rules is</FONT>
<BR><FONT SIZE=2>incorrect.</FONT>
</P>

<P><FONT SIZE=2>Another question:&nbsp; Why does a router need to store all of</FONT>
<BR><FONT SIZE=2>the routes that it learns from every peer?&nbsp; Some routers </FONT>
<BR><FONT SIZE=2>allow the operator to specify that routes that don't make it</FONT>
<BR><FONT SIZE=2>to the local RIB be thrown away to conserve resources.&nbsp; </FONT>
<BR><FONT SIZE=2>How are withdrawn routes and reconfiguration handled in </FONT>
<BR><FONT SIZE=2>that case?</FONT>
</P>

<P><FONT SIZE=2>Thanks, -Anoop</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Ben Black [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, October 23, 2000 2:02 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Anoop Ghanwani</FONT>
<BR><FONT SIZE=2>&gt; Cc: [email-masked]'</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: iBGP/eBGP interaction question</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; the 2 things you should remember are:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1) barring rules restricted readvertisement among IBGP</FONT>
<BR><FONT SIZE=2>&gt; neighbors, all prefixes heard from peers are stored</FONT>
<BR><FONT SIZE=2>&gt; (Adj-RIB-In), and the selected best path is advertised</FONT>
<BR><FONT SIZE=2>&gt; to all peers.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 2) of the 3 methods for withdrawing a route, the one</FONT>
<BR><FONT SIZE=2>&gt; relevant here is the advertisement of new NLRI for a</FONT>
<BR><FONT SIZE=2>&gt; previously advertised prefix.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; does this clarify the rules that determine the answer</FONT>
<BR><FONT SIZE=2>&gt; to your question?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ben</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Mon, Oct 23, 2000 at 01:50:33PM -0700, Anoop Ghanwani wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I have a question related to the interaction between</FONT>
<BR><FONT SIZE=2>&gt; &gt; iBGP and eBGP when the same prefix is advertised</FONT>
<BR><FONT SIZE=2>&gt; &gt; by both.&nbsp; Consider the following example with 5</FONT>
<BR><FONT SIZE=2>&gt; &gt; routers.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Rx--------Ra---------Rb----------Rc----------Ry</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; - We have eBGP between Rx and Ra, and between</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; Ry and Rc.</FONT>
<BR><FONT SIZE=2>&gt; &gt; - We have full mesh iBGP between Ra, Rb, Rc</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; A prefix p gets advertized by Rx and Ry into the</FONT>
<BR><FONT SIZE=2>&gt; &gt; AS containing Ra, Rb, Rc.&nbsp; Let's call the prefix </FONT>
<BR><FONT SIZE=2>&gt; &gt; p' coming into Ra, and p'' coming into Rc.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Let's say the local pref at Ra is set to 100</FONT>
<BR><FONT SIZE=2>&gt; &gt; and at Rc it is 200.&nbsp; Then the prefix p'' is used</FONT>
<BR><FONT SIZE=2>&gt; &gt; and all traffic destined to p will exit the</FONT>
<BR><FONT SIZE=2>&gt; &gt; AS from Rc.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Now the local pref at Ra is changed to 300.</FONT>
<BR><FONT SIZE=2>&gt; &gt; This means that p' should become the active</FONT>
<BR><FONT SIZE=2>&gt; &gt; prefix and this change is propagated to Rb</FONT>
<BR><FONT SIZE=2>&gt; &gt; and Rc.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Now the question is:&nbsp; At this point, does Rc</FONT>
<BR><FONT SIZE=2>&gt; &gt; send a message to withdraw prefix p'' from</FONT>
<BR><FONT SIZE=2>&gt; &gt; its iBGP/eBGP peers?&nbsp; I guess what I'm asking is:</FONT>
<BR><FONT SIZE=2>&gt; &gt; When a router receives a route from 2 BGP</FONT>
<BR><FONT SIZE=2>&gt; &gt; peers (could be iBGP, eBGP or a combination),</FONT>
<BR><FONT SIZE=2>&gt; &gt; is it required to store both, or does it just</FONT>
<BR><FONT SIZE=2>&gt; &gt; pick the best one and store that?&nbsp; If it</FONT>
<BR><FONT SIZE=2>&gt; &gt; only picks the best one, then it must withdraw</FONT>
<BR><FONT SIZE=2>&gt; &gt; a route that becomes less preferred at a later </FONT>
<BR><FONT SIZE=2>&gt; &gt; time.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Thanks, -Anoop</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03D5A.E6CBC9C0--

From: "vikram idrp" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: iBGP/eBGP interaction question
Date: Mon, 23 Oct 2000 23:49:43 GMT
Sender: [email-masked]

Depending upon circumstances,
1> you may want to store the routes irrespective of being best or
2> withdraw any non-best BGP routes.
With the former efficiency of bandwidth is gained and extra preliminary 
packet parsing is avoided. The switch is just matter of withdrawl by the 
current Best BGP routes Advertising router. However, this is at the expense 
of memory.
When a route is withdrawn, but a look-alike route exists, it can make it to 
the Fib, without having the advertising router to send explicit 
announcements (if the state of the route hasn't changed). On becoming 
unreachable a withdrawl must be sent by the adverstising router or if a 
given attribute associated with the route changes, it must be appropriately 
reflected at all times.

HTH.
Vikram

>From: Anoop Ghanwani <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: iBGP/eBGP interaction question
>Date: Mon, 23 Oct 2000 13:50:33 -0700
>
>
>I have a question related to the interaction between
>iBGP and eBGP when the same prefix is advertised
>by both.  Consider the following example with 5
>routers.
>
>Rx--------Ra---------Rb----------Rc----------Ry
>
>- We have eBGP between Rx and Ra, and between
>   Ry and Rc.
>- We have full mesh iBGP between Ra, Rb, Rc
>
>A prefix p gets advertized by Rx and Ry into the
>AS containing Ra, Rb, Rc.  Let's call the prefix
>p' coming into Ra, and p'' coming into Rc.
>Let's say the local pref at Ra is set to 100
>and at Rc it is 200.  Then the prefix p'' is used
>and all traffic destined to p will exit the
>AS from Rc.
>
>Now the local pref at Ra is changed to 300.
>This means that p' should become the active
>prefix and this change is propagated to Rb
>and Rc.
>
>Now the question is:  At this point, does Rc
>send a message to withdraw prefix p'' from
>its iBGP/eBGP peers?  I guess what I'm asking is:
>When a router receives a route from 2 BGP
>peers (could be iBGP, eBGP or a combination),
>is it required to store both, or does it just
>pick the best one and store that?  If it
>only picks the best one, then it must withdraw
>a route that becomes less preferred at a later
>time.
>
>Thanks, -Anoop

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

From: Anoop Ghanwani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: iBGP/eBGP interaction question
Date: Mon, 23 Oct 2000 13:50:33 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C03D32.E3696C10
Content-Type: text/plain

I have a question related to the interaction between
iBGP and eBGP when the same prefix is advertised
by both.  Consider the following example with 5
routers.

Rx--------Ra---------Rb----------Rc----------Ry

- We have eBGP between Rx and Ra, and between
  Ry and Rc.
- We have full mesh iBGP between Ra, Rb, Rc

A prefix p gets advertized by Rx and Ry into the
AS containing Ra, Rb, Rc.  Let's call the prefix 
p' coming into Ra, and p'' coming into Rc.  
Let's say the local pref at Ra is set to 100
and at Rc it is 200.  Then the prefix p'' is used
and all traffic destined to p will exit the
AS from Rc.

Now the local pref at Ra is changed to 300.
This means that p' should become the active
prefix and this change is propagated to Rb
and Rc.

Now the question is:  At this point, does Rc
send a message to withdraw prefix p'' from
its iBGP/eBGP peers?  I guess what I'm asking is:
When a router receives a route from 2 BGP
peers (could be iBGP, eBGP or a combination),
is it required to store both, or does it just
pick the best one and store that?  If it
only picks the best one, then it must withdraw
a route that becomes less preferred at a later 
time.

Thanks, -Anoop

------_=_NextPart_001_01C03D32.E3696C10
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>iBGP/eBGP interaction question</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>I have a question related to the interaction between</FONT>
<BR><FONT SIZE=2>iBGP and eBGP when the same prefix is advertised</FONT>
<BR><FONT SIZE=2>by both.&nbsp; Consider the following example with 5</FONT>
<BR><FONT SIZE=2>routers.</FONT>
</P>

<P><FONT SIZE=2>Rx--------Ra---------Rb----------Rc----------Ry</FONT>
</P>

<P><FONT SIZE=2>- We have eBGP between Rx and Ra, and between</FONT>
<BR><FONT SIZE=2>&nbsp; Ry and Rc.</FONT>
<BR><FONT SIZE=2>- We have full mesh iBGP between Ra, Rb, Rc</FONT>
</P>

<P><FONT SIZE=2>A prefix p gets advertized by Rx and Ry into the</FONT>
<BR><FONT SIZE=2>AS containing Ra, Rb, Rc.&nbsp; Let's call the prefix </FONT>
<BR><FONT SIZE=2>p' coming into Ra, and p'' coming into Rc.&nbsp; </FONT>
<BR><FONT SIZE=2>Let's say the local pref at Ra is set to 100</FONT>
<BR><FONT SIZE=2>and at Rc it is 200.&nbsp; Then the prefix p'' is used</FONT>
<BR><FONT SIZE=2>and all traffic destined to p will exit the</FONT>
<BR><FONT SIZE=2>AS from Rc.</FONT>
</P>

<P><FONT SIZE=2>Now the local pref at Ra is changed to 300.</FONT>
<BR><FONT SIZE=2>This means that p' should become the active</FONT>
<BR><FONT SIZE=2>prefix and this change is propagated to Rb</FONT>
<BR><FONT SIZE=2>and Rc.</FONT>
</P>

<P><FONT SIZE=2>Now the question is:&nbsp; At this point, does Rc</FONT>
<BR><FONT SIZE=2>send a message to withdraw prefix p'' from</FONT>
<BR><FONT SIZE=2>its iBGP/eBGP peers?&nbsp; I guess what I'm asking is:</FONT>
<BR><FONT SIZE=2>When a router receives a route from 2 BGP</FONT>
<BR><FONT SIZE=2>peers (could be iBGP, eBGP or a combination),</FONT>
<BR><FONT SIZE=2>is it required to store both, or does it just</FONT>
<BR><FONT SIZE=2>pick the best one and store that?&nbsp; If it</FONT>
<BR><FONT SIZE=2>only picks the best one, then it must withdraw</FONT>
<BR><FONT SIZE=2>a route that becomes less preferred at a later </FONT>
<BR><FONT SIZE=2>time.</FONT>
</P>

<P><FONT SIZE=2>Thanks, -Anoop</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03D32.E3696C10--

From: "vikram idrp" <[email-masked]>
To: [email-masked]
Date: Fri, 20 Oct 2000 23:40:08 GMT
Sender: [email-masked]

Hi,
I have a question on communities. Can VPNs be implemented using communities? 
if so are these solutions deployed in the current internet?

thanks,
Vikram
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: draft-ietf-idr-bgp-confed-rfc1965bis-01.txt
Date: Wed, 18 Oct 2000 10:18:21 -0600
Sender: [email-masked]

FYI...

-danny

[snip]

diff draft-ietf-idr-bgp-confed-rfc1965bis-00.txt draft-ietf-idr-bgp-confed-rfc1
965bis-01.txt
0a1,5
> 
> 
> 
> 
> 
11c16
<                <draft-ietf-idr-bgp-confed-rfc1965bis-00.txt>
---
>              <draft-ietf-idr-bgp-confed-rfc1965bis-01.txt>
248c253
<    A member of a BGP confederation will use its Routing Domain ID in all
---
>    A member of a BGP confederation will use its Member AS Number in all
428c433
<    imcomparable MEDs.
---
>    incomparable MEDs.

Reply-To: <[email-masked]>
From: "James Tsillas" <[email-masked]>
To: "IDR" <[email-masked]>
Subject: EBGP vs. imported  route conflict
Date: Tue, 17 Oct 2000 09:27:17 -0400
Importance: Normal
Sender: [email-masked]

What is the correct way to handle a situation
where an EBGP route is received for a route
which has been imported (as a manual network
or a redistributed IGP route).

I'm guessing this is not a valid configuration
but I'd like to know what the consensus is as
far as dealing with it in the routing protocol.

-Jim.

To: [email-masked]
Cc: [email-masked]
Subject: -bgp-confed-rfc1965bis-00
Date: Fri, 13 Oct 2000 11:09:27 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Rob,

The IDR WG would like to ask the IESG to advance
-bgp-confed-rfc1965bis-00 to a Proposed Standard.

Yakov.
------- Forwarded Message

Date:    Tue, 26 Sep 2000 08:09:33 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: WG last call on -bgp-confed-rfc1965bis-00

Folks,

In response to the attached request I'd like to start
IDR WG Last Call on the document. The Last Call will
be closed in two weeks (oct 10).

Yakov.
- ------- Forwarded Message

Date:    Mon, 25 Sep 2000 10:22:08 -0600
From:    Danny McPherson <[email-masked]>
To:      [email-masked]
Subject: BGP Confeds

Folks, we'd like to move this to Proposed Standard:

draft-ietf-idr-bgp-confed-rfc1965bis-00.txt

Comments?

- - -danny

- ------- End of Forwarded Message

------- End of Forwarded Message

Date: Tue, 10 Oct 2000 21:54:34 -0400 (EDT)
From: abha ahuja <[email-masked]>
To: Danny McPherson <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
Sender: [email-masked]

> If there are additional emails in the thread perhaps the author(s) could 
> forward them to the list.  Or better yet, perhaps someone could figure out why 
> they're not being posted?

The list maintainers are checking out the merit side to see if it may be
something on that end...  :)

-abha ;)

> From: Bruce Cole <[email-masked]>
> To:  Andrew Partan <[email-masked]>
> cc:  Ian Duncan <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
> 
> > On Sun, Oct 08, 2000 at 03:37:36PM -0400, Ian Duncan wrote:
> > > See Bruce Cole's e-mails for a better articulation of what's on.
> > 
> > His mail has not made it to the list; thus I can't comment on it.
> > 
> > Its seems as if a number of messages on this thread have not made
> > it to the list.
> > 	[email-masked] (Andrew Partan)
> 
> 
> Strange, I didn't see a copy echoed back via the list either.  Here's
> the sendmail log and the messages.  Problems at mail.merit.edu?
> 
> Oct  6 14:10:43 red sendmail[22199]: OAA22199: from=<[email-masked]>, 
> size=777, class=0, pri=120777, nrcpts=4, msgid=<[email-masked]
> er.net>, proto=ESMTP, relay=dakine.juniper.net [172.17.12.87]
> Oct  6 14:10:48 red sendmail[22200]: OAA22199: to=<[email-masked]>, 
> ctladdr=<[email-masked]> (1039/1039), delay=00:00:05, xdelay=00:00:01, 
> mailer=esmtp, relay=mail.merit.edu. [198.108.1.41], stat=Sent (Ok: queued as 
> 0A40C5DDFB)
> 
> 
> Oct  6 15:29:42 red sendmail[28241]: PAA28241: from=<[email-masked]>, 
> size=1904, class=0, pri=121904, nrcpts=4, msgid=<[email-masked]
> per.net>, proto=ESMTP, relay=dakine.juniper.net [172.17.12.87]
> Oct  6 15:29:48 red sendmail[28242]: PAA28241: to=<[email-masked]>, 
> ctladdr=<[email-masked]> (1039/1039), delay=00:00:06, xdelay=00:00:01, 
> mailer=esmtp, relay=mail.merit.edu. [198.108.1.41], stat=Sent (Ok: queued as 
> 4DC985DD9A)
> 
> Return-Path: [email-masked]
> Delivery-Date: Fri Oct  6 14:10:43 2000
> Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by 
> dakine.juniper.net (8.8.8/8.7.3) with ESMTP id OAA14296 for 
> <[email-masked]>; Fri, 6 Oct 2000 14:10:43 -0700 (PDT)
> Received: from juniper.net (dakine.juniper.net [172.17.12.87])
> 	by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA22199;
> 	Fri, 6 Oct 2000 14:10:43 -0700 (PDT)
> Message-Id: <[email-masked]>
> To: "Ian Duncan" <[email-masked]>
> cc: Enke Chen <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
> In-reply-to: Your message of "Fri, 06 Oct 2000 14:22:09 EDT."
>              <[email-masked]> 
> Date: Fri, 06 Oct 2000 14:10:42 -0700
> From: Bruce Cole <[email-masked]>
> 
> Yes, I have similar feelings.  
> This draft seems to describe a model that only maps well to cisco
> route-map configurations.  It is not sufficiently general to describe
> the policy language of other shipping implementations.  So I object to
> this draft being considered as a working group document, in its
> current form.
> 
> Specifically, expecting prefix matching to be sequence number
> driven, instead of tree driven, is undesirable.
> 
> Here's the second:
> 
> 
> 
> 
> 
> Return-Path: [email-masked]
> Delivery-Date: Fri Oct  6 15:29:42 2000
> Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by 
> dakine.juniper.net (8.8.8/8.7.3) with ESMTP id PAA14584 for 
> <[email-masked]>; Fri, 6 Oct 2000 15:29:42 -0700 (PDT)
> Received: from juniper.net (dakine.juniper.net [172.17.12.87])
> 	by red.juniper.net (8.9.3/8.9.3) with ESMTP id PAA28241;
> 	Fri, 6 Oct 2000 15:29:42 -0700 (PDT)
> Message-Id: <[email-masked]>
> To: Enke Chen <[email-masked]>
> cc: "Ian Duncan" <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
> In-reply-to: Your message of "Fri, 06 Oct 2000 14:32:38 PDT."
>              <[email-masked]> 
> Date: Fri, 06 Oct 2000 15:29:42 -0700
> From: Bruce Cole <[email-masked]>
> 
> > > Yes, I have similar feelings.
> > 
> > > This draft seems to describe a model that only maps well to cisco
> > > route-map configurations.
> > 
> > Not true. It would map well to several vendors config, and cisco
> > might be one of them.
> > 
> > (BTW, you might mean prefix filter instead of route-map).
> 
> You're reinforcing the point that this is vendor specific.
> 
> > > It is not sufficiently general to describe
> > > the policy language of other shipping implementations.
> > 
> > Again the draft describes only one model, and uses one ORF-Type number.
> 
> So is the intent that the set of ORF-types will eventually be
> sufficiently general to express one's entire routing policy?  We're
> far from that point now, yet that seems to be the goal that is hinted
> at in the original ORF draft's introduction.
> 
> > >  So I object to
> > > this draft being considered as a working group document, in its
> > > current form.
> > > 
> > > Specifically, expecting prefix matching to be sequence number
> > > driven, instead of tree driven, is undesirable.
> > 
> > Not true. Sequence numbers and tree-based implementation are not
> > mutually exclusive.
> 
> I believe you misunderstand me.  In your text:
> 
> "
>    Address ORF entry that matches the NLRI of the route. In that case
>    the "first-match" rule applies. That is, the ORF entry with the
>    smallest sequence number (among all the matching ORF entries) is
>    considered as the sole match, and it would determine whether the
>    route should be advertised.
> "
> 
> Here you've defined sequence number ordering to affect the matching
> decision.
> 
> 
> 
> 
> 

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
Date: Tue, 10 Oct 2000 19:47:41 -0600
Sender: [email-masked]

> the way this is normally handled is to title the document "Cisco's <blah
> blah>" and progress it as informational.

This would seem most appropriate to me as well.  I think ORF in general is a 
good idea, but anything beyond Informational would potentially constrain 
alternative implementations [that MAY or MAY NOT] be more useful.

Along these lines, I've attached Bruce's/Enke's email exchange for the benefit 
of the WG, Bruce brings up some good points (to which I agree).  [Note that it 
was initially intended by the authors of the attached email that it be 
distributed to the IDR WG, else I wouldn't be posting it here.  Let's hope 
this email makes it -- or perhaps there's a filter that nukes everything with 
[email-masked] in it :-) ]

If there are additional emails in the thread perhaps the author(s) could 
forward them to the list.  Or better yet, perhaps someone could figure out why 
they're not being posted?

-danny

[snip]
Date: Mon, 09 Oct 2000 13:29:56 PDT
From: Bruce Cole <[email-masked]>
To:  Andrew Partan <[email-masked]>
cc:  Ian Duncan <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt 

> On Sun, Oct 08, 2000 at 03:37:36PM -0400, Ian Duncan wrote:
> > See Bruce Cole's e-mails for a better articulation of what's on.
> 
> His mail has not made it to the list; thus I can't comment on it.
> 
> Its seems as if a number of messages on this thread have not made
> it to the list.
> 	[email-masked] (Andrew Partan)

Strange, I didn't see a copy echoed back via the list either.  Here's
the sendmail log and the messages.  Problems at mail.merit.edu?

Oct  6 14:10:43 red sendmail[22199]: OAA22199: from=<[email-masked]>, 
size=777, class=0, pri=120777, nrcpts=4, msgid=<[email-masked]
er.net>, proto=ESMTP, relay=dakine.juniper.net [172.17.12.87]
Oct  6 14:10:48 red sendmail[22200]: OAA22199: to=<[email-masked]>, 
ctladdr=<[email-masked]> (1039/1039), delay=00:00:05, xdelay=00:00:01, 
mailer=esmtp, relay=mail.merit.edu. [198.108.1.41], stat=Sent (Ok: queued as 
0A40C5DDFB)

Oct  6 15:29:42 red sendmail[28241]: PAA28241: from=<[email-masked]>, 
size=1904, class=0, pri=121904, nrcpts=4, msgid=<[email-masked]
per.net>, proto=ESMTP, relay=dakine.juniper.net [172.17.12.87]
Oct  6 15:29:48 red sendmail[28242]: PAA28241: to=<[email-masked]>, 
ctladdr=<[email-masked]> (1039/1039), delay=00:00:06, xdelay=00:00:01, 
mailer=esmtp, relay=mail.merit.edu. [198.108.1.41], stat=Sent (Ok: queued as 
4DC985DD9A)

Return-Path: [email-masked]
Delivery-Date: Fri Oct  6 14:10:43 2000
Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by 
dakine.juniper.net (8.8.8/8.7.3) with ESMTP id OAA14296 for 
<[email-masked]>; Fri, 6 Oct 2000 14:10:43 -0700 (PDT)
To: "Ian Duncan" <[email-masked]>
cc: Enke Chen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
Date: Fri, 06 Oct 2000 14:10:42 -0700
From: Bruce Cole <[email-masked]>

Yes, I have similar feelings.  
This draft seems to describe a model that only maps well to cisco
route-map configurations.  It is not sufficiently general to describe
the policy language of other shipping implementations.  So I object to
this draft being considered as a working group document, in its
current form.

Specifically, expecting prefix matching to be sequence number
driven, instead of tree driven, is undesirable.

Here's the second:

Return-Path: [email-masked]
Delivery-Date: Fri Oct  6 15:29:42 2000
Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by 
dakine.juniper.net (8.8.8/8.7.3) with ESMTP id PAA14584 for 
<[email-masked]>; Fri, 6 Oct 2000 15:29:42 -0700 (PDT)
To: Enke Chen <[email-masked]>
cc: "Ian Duncan" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
Date: Fri, 06 Oct 2000 15:29:42 -0700
From: Bruce Cole <[email-masked]>

> > Yes, I have similar feelings.
> 
> > This draft seems to describe a model that only maps well to cisco
> > route-map configurations.
> 
> Not true. It would map well to several vendors config, and cisco
> might be one of them.
> 
> (BTW, you might mean prefix filter instead of route-map).

You're reinforcing the point that this is vendor specific.

> > It is not sufficiently general to describe
> > the policy language of other shipping implementations.
> 
> Again the draft describes only one model, and uses one ORF-Type number.

So is the intent that the set of ORF-types will eventually be
sufficiently general to express one's entire routing policy?  We're
far from that point now, yet that seems to be the goal that is hinted
at in the original ORF draft's introduction.

> >  So I object to
> > this draft being considered as a working group document, in its
> > current form.
> > 
> > Specifically, expecting prefix matching to be sequence number
> > driven, instead of tree driven, is undesirable.
> 
> Not true. Sequence numbers and tree-based implementation are not
> mutually exclusive.

I believe you misunderstand me.  In your text:

"
   Address ORF entry that matches the NLRI of the route. In that case
   the "first-match" rule applies. That is, the ORF entry with the
   smallest sequence number (among all the matching ORF entries) is
   considered as the sole match, and it would determine whether the
   route should be advertised.
"

Here you've defined sequence number ordering to affect the matching
decision.

From: Randy Bush <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt
Date: Tue, 10 Oct 2000 14:43:04 -0700
Sender: [email-masked]

> o The Prefix-ORF has been implemented and deployed. The draft
>   simply documents the implementation to make it possible for
>   other vendors to interoperate if they choose to implement
>   the same mechanism.

the way this is normally handled is to title the document "Cisco's <blah
blah>" and progress it as informational.

randy

To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt
Date: Tue, 10 Oct 2000 13:48:58 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:
Let me clarify a couple of points related to this draft:

o The Prefix-ORF has been implemented and deployed. The draft
  simply documents the implementation to make it possible for
  other vendors to interoperate if they choose to implement
  the same mechanism.

o The draft does not claim the mechanism to represent the
  best practice/model. We intend to make it an experimental
  RFC (rather than a standard track RFC).  We encourage and
  welcome efforts to pursue other mechanisms that would
  remedy any shortcomings or limitations the Prefix-ORF
  might have.

Thanks. -- Enke

To: "Alix Fortune" <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC 
Date: Mon, 09 Oct 2000 17:34:54 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alix,

> What RFC # is draft-chen-bgp-prefix-orf-00.txt

It is an Internet Draft, not an RFC.

Yakov.

From: "Alix Fortune" <[email-masked]>
To: <[email-masked]>
Cc: "Alix Fortune" <[email-masked]>
Subject: RFC
Date: Mon, 9 Oct 2000 19:01:12 -0700
Sender: [email-masked]

What RFC # is draft-chen-bgp-prefix-orf-00.txt

Thank you

Date: Mon, 09 Oct 2000 18:35:49 -0400
To: [email-masked]
From: RJ Atkinson <[email-masked]>
Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
Cc: [email-masked]
Sender: [email-masked]

At 18:13 09/10/00, Danny McPherson wrote:

>>         Reality is what it is.  
>> 
>>         If making it "standards track' bothers some folks, 
>> then it could go out as an Informational status RFC.  
>> Regardless, it is good to get the implementation details
>> publicly documented in some RFC.
>
>I think this documentation belongs in what's referred to
>as "User Configuration Guidelines", it's openly available 
>on cisco.com.

        An Informational RFC would be still be a fine thing.  
Anything, including humour, is appropriate for an 
Informational RFC.  Of course, you don't have to read or
use it if you don't want to.

Ran
[email-masked]

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
Date: Mon, 09 Oct 2000 16:13:59 -0600
Sender: [email-masked]

>         Reality is what it is.  
> 
>         If making it "standards track' bothers some folks, 
> then it could go out as an Informational status RFC.  
> Regardless, it is good to get the implementation details
> publicly documented in some RFC.

I think this documentation belongs in what's referred to
as "User Configuration Guidelines", it's openly available 
on cisco.com.

-danny

Date: Mon, 09 Oct 2000 16:32:58 -0400
To: [email-masked]
From: RJ Atkinson <[email-masked]>
Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
Cc: [email-masked]
Sender: [email-masked]

At 16:30 09/10/00, you wrote:

>Then again, using the IETF as a means to thrust a given 
>implementation onto standards track, especially when 
>considering BGP policy *specification*, clearly isn't a 
>very fine thing.

        Reality is what it is.  

        If making it "standards track' bothers some folks, 
then it could go out as an Informational status RFC.  
Regardless, it is good to get the implementation details
publicly documented in some RFC.

Ran
[email-masked]

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt 
Date: Mon, 09 Oct 2000 14:30:06 -0600
Sender: [email-masked]

> Mumble.  It isn't clear to me that the IETF ought to
> be in the business of specifying/standardising any
> operator policy.  IETF ought to standardise protocols,
> not policies, generally speaking, IMHO.

Unless I've missed something, this is precisely what Ian & Vivek 
were referring to.  I agree.

> Some operators might find it useful to have a vendor-independent
> way of exchanging this.  Hence the world has standards.
> In this case I don't know that it matters whether a spec
> is on the IETF standards-track or is merely published as
> an Informational RFC.  Having the spec documented in some 
> RFC does seem desirable regardless of the status of the RFC.

Perhaps, though a more generalized mechanism providing the 
same functionality, or perhaps more, is clearly more desirable.

> BGP already has a number of mechanisms that are available 
> to operators, not all of which are used by any given operator.  
>  From an operator perspective, it is desirable that all of BGP
> be fully and openly documented, rather than having large
> chunks be poorly defined or undefined or vendor-unique.
> Interoperability is a very fine thing.

Then again, using the IETF as a means to thrust a given 
implementation onto standards track, especially when 
considering BGP policy *specification*, clearly isn't a 
very fine thing.

-danny

Date: Mon, 9 Oct 2000 16:18:07 -0400
From: Andrew Partan <[email-masked]>
To: Ian Duncan <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt
Sender: [email-masked]

On Sun, Oct 08, 2000 at 03:37:36PM -0400, Ian Duncan wrote:
> See Bruce Cole's e-mails for a better articulation of what's on.

His mail has not made it to the list; thus I can't comment on it.

Its seems as if a number of messages on this thread have not made
it to the list.
	[email-masked] (Andrew Partan)

From: Randy Bush <[email-masked]>
To: RJ Atkinson <[email-masked]>
Cc: Vivek Menezes <[email-masked]>, [email-masked]
Subject: RE: draft-chen-bgp-prefix-orf-00.txt
Date: Mon, 09 Oct 2000 12:42:10 -0700
Sender: [email-masked]

>> I think Ian makes a good point. It makes more sense 
>> to first standardize routing policy/ filtering. 
> Mumble.  It isn't clear to me that the IETF ought to
> be in the business of specifying/standardising any
> operator policy.  IETF ought to standardise protocols,
> not policies, generally speaking, IMHO.

no one is suggesting this.  or at least my normally sensitive
operator ears are not hearing it.

>> Exchanging standardized routing policy/filtering
>> is just an implementation issue. 
> Some operators might find it useful to have a vendor-independent
> way of exchanging this.

i think that is the sole point being made.

i think you are falling for one of the bgp puns.  in this discussion,
"exchanging policy" is meant as my router being able to push its
inbound filter to my peer's outbound filter.

randy

Date: Mon, 09 Oct 2000 15:31:37 -0400
To: Vivek Menezes <[email-masked]>
From: RJ Atkinson <[email-masked]>
Subject: RE: draft-chen-bgp-prefix-orf-00.txt
Cc: [email-masked]
Sender: [email-masked]

At 13:22 09/10/00, Vivek Menezes wrote:
>I think Ian makes a good point. It makes more sense 
>to first standardize routing policy/ filtering. 

Mumble.  It isn't clear to me that the IETF ought to
be in the business of specifying/standardising any
operator policy.  IETF ought to standardise protocols,
not policies, generally speaking, IMHO.

> 
>Exchanging standardized routing policy/filtering
>is just an implementation issue. 

Some operators might find it useful to have a vendor-independent
way of exchanging this.  Hence the world has standards.
In this case I don't know that it matters whether a spec
is on the IETF standards-track or is merely published as
an Informational RFC.  Having the spec documented in some 
RFC does seem desirable regardless of the status of the RFC.

>If we exchange filtering between peers (make it a part of the protocol) then it would imply that we would be standardizing such policy.

No.  Actually we would be standardising a mechanism 
for policy information exchange.  Cooperating parties
could then either use or not use that mechanism.  

BGP already has a number of mechanisms that are available 
to operators, not all of which are used by any given operator.  
 From an operator perspective, it is desirable that all of BGP
be fully and openly documented, rather than having large
chunks be poorly defined or undefined or vendor-unique.
Interoperability is a very fine thing.

From: Vivek Menezes <[email-masked]>
To: "'Ian Duncan'" <[email-masked]>, Randy Bush <[email-masked]>, Andrew Partan <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-chen-bgp-prefix-orf-00.txt
Date: Mon, 9 Oct 2000 10:22:32 -0700 
Sender: [email-masked]

I think Ian makes a good point. It makes more sense to first standardize 
routing policy/ filtering. Exchanging standardized routing policy/filtering
is just an
implementation issue. 

If we exchange filtering between peers (make it a part of the protocol) then
it would imply that we would be standardizing such policy.

Vivek. 

-----Original Message-----
From: Ian Duncan [mailto:[email-masked]]
Sent: Sunday, October 08, 2000 12:38 PM
To: Randy Bush; Andrew Partan
Cc: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt

Randy and Andrew,

Randy Bush wrote:
> 
> just to be clear, there are isps who use prefix and prefix-length filters,
> and will not buy routers that won't.
> 
> of course, like the rest of this spec, pushing that to my peer is a
luxury.

And Andrew Partan wrote:
>
> I don't understand your objections.  We use prefix filters on
> *every* eBGP peering session we have.  The ability to push this
> filtering to our peers would be useful.

I obviously wasn't clear enough in my intent. I have no objection to
filtering, 
that'd be lunacy. I do object to the ratification by this WG of a primitive
and 
implementation centric method of expressing filter definitions within the 
protocol. See Bruce Cole's e-mails for a better articulation of what's on.

Ian.

Date: Sun, 08 Oct 2000 15:37:36 -0400
From: "Ian Duncan" <[email-masked]>
Organization: Nortel Networks
To: Randy Bush <[email-masked]>, Andrew Partan <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt
Sender: [email-masked]

Randy and Andrew,

Randy Bush wrote:
> 
> just to be clear, there are isps who use prefix and prefix-length filters,
> and will not buy routers that won't.
> 
> of course, like the rest of this spec, pushing that to my peer is a luxury.

And Andrew Partan wrote:
>
> I don't understand your objections.  We use prefix filters on
> *every* eBGP peering session we have.  The ability to push this
> filtering to our peers would be useful.

I obviously wasn't clear enough in my intent. I have no objection to filtering, 
that'd be lunacy. I do object to the ratification by this WG of a primitive and 
implementation centric method of expressing filter definitions within the 
protocol. See Bruce Cole's e-mails for a better articulation of what's on.

Ian.

Date: Sat, 7 Oct 2000 15:39:13 -0400
From: Andrew Partan <[email-masked]>
To: Ian Duncan <[email-masked]>
Cc: Enke Chen <[email-masked]>, [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt
Sender: [email-masked]

[Resending as the 1st time it didn't make it to the IDR list.]

> I recognized that your draft describes *a* model. If your seeking to
> standardize it then there's an implied judgement of the value it offers.

I don't understand your objections.  We use prefix filters on
*every* eBGP peering session we have.  The ability to push this
filtering to our peers would be useful.

Working in parallel on better ways of doing routing is also useful
(and what we end up with may have not much in common with today's
bgp), but using this as reason to stop work on improvements in
today's bgp (even if the improvements may be slight) is rather
silly.
	[email-masked] (Andrew Partan)

Date: Fri, 06 Oct 2000 14:22:09 -0400
From: "Ian Duncan" <[email-masked]>
Organization: Nortel Networks
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt
Sender: [email-masked]

Enke,

I recognized that your draft describes *a* model. If your seeking to
standardize it then there's an implied judgement of the value it offers.
It's a fact that if the working group adopts this model as a basis for 
developing a standard then other models become much more difficult to 
introduce. I don't like the model. It's primitive and restrictive. When 
it's applied in the protocol it forces, in practical terms at any rate, 
the implementations to be equally primitive. This sucks.

The input I've had is that sane folk are looking for significantly more 
flexibility and scalability in BGP policy description. I'd rather have us
work first on getting a satisfactory syntax for peer routing policy and 
then worry about the minor problem of the mechanics of embedding it in 
the protocol.

Ian.

Enke Chen wrote:
> 
> Ian,
> The ID draft-chen-bgp-prefix-orf describes *a* model (not *the* model),
> and it doesn't make any judgement on whether this is the only possible
> model, or the best model.
> 
> -- Enke
> 
> >
> > >
> > > Folks,
> > >
> > > If there are any objections to the attached request, please
> > > send them to this list within next two week.
> >
> > I have a concern. The request is vague as to how we should be
> > considering the draft. I accept the idea that there may be value
> > in passing policy to peers via BGP. I deny the impicit assertion
> > that the policy description model offered is the only or the best
> > for the purpose. It is a painfully familiar description model but
> > there are others available from which we can draw.
> >
> > Is your request that the working group adopt this draft as an
> > appropriate starting point for a standard or are we being asked
> > for something less than that?
> >
> > Ian.
> >
> > > Yakov.
> > > ------- Forwarded Message
> > >
> > > Date:    Sun, 24 Sep 2000 11:59:30 -0700
> > > From:    Enke Chen <[email-masked]>
> > > To:      [email-masked], [email-masked]
> > > cc:      [email-masked]
> > > Subject: draft-chen-bgp-prefix-orf-00.txt
> > >
> > > Hi, Yakov and Sue:
> > > I would like to request that the draft be considered as an IDR WG
> > > document.
> > >
> > > Thank you in advance for your consideration.
> > >
> > > - -- Enke
> > >
> > > ------- End of Forwarded Message
> >

To: Anoop Ghanwani <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: BGP extended communities 
Date: Thu, 05 Oct 2000 16:47:44 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Anoop,

> Is there a draft or RFC that provides the specification
> for implementing the extended community attribute for
> BGP?  Thanks, -Anoop

see draft-ramachandra-bgp-ext-communities-04.txt .

Yakov.

From: Anoop Ghanwani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: BGP extended communities
Date: Thu, 5 Oct 2000 16:14:30 -0700 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C02F22.04051790
Content-Type: text/plain

Is there a draft or RFC that provides the specification
for implementing the extended community attribute for
BGP?  Thanks, -Anoop

------_=_NextPart_001_01C02F22.04051790
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>BGP extended communities</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Is there a draft or RFC that provides the specification</FONT>
<BR><FONT SIZE=2>for implementing the extended community attribute for</FONT>
<BR><FONT SIZE=2>BGP?&nbsp; Thanks, -Anoop</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C02F22.04051790--

Date: Thu, 05 Oct 2000 12:55:51 -0400
From: "Ian Duncan" <[email-masked]>
Organization: Nortel Networks
To: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: draft-chen-bgp-prefix-orf-00.txt
Sender: [email-masked]

Yakov,

> 
> Folks,
> 
> If there are any objections to the attached request, please
> send them to this list within next two week.

I have a concern. The request is vague as to how we should be
considering the draft. I accept the idea that there may be value 
in passing policy to peers via BGP. I deny the impicit assertion 
that the policy description model offered is the only or the best 
for the purpose. It is a painfully familiar description model but 
there are others available from which we can draw.

Is your request that the working group adopt this draft as an 
appropriate starting point for a standard or are we being asked
for something less than that?

Ian.

> Yakov.
> ------- Forwarded Message
> 
> Date:    Sun, 24 Sep 2000 11:59:30 -0700
> From:    Enke Chen <[email-masked]>
> To:      [email-masked], [email-masked]
> cc:      [email-masked]
> Subject: draft-chen-bgp-prefix-orf-00.txt
> 
> Hi, Yakov and Sue:
> I would like to request that the draft be considered as an IDR WG
> document.
> 
> Thank you in advance for your consideration.
> 
> - -- Enke
> 
> ------- End of Forwarded Message