Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28982 for ; Tue, 31 Oct 2000 11:48:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id E05AC5DDEC; Tue, 31 Oct 2000 11:45:36 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CC3D95DDEB; Tue, 31 Oct 2000 11:45:36 -0500 (EST) Received: from mailrelay00.aa.ops.us.uu.net (mailrelay00.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id E0BCF5DDEE for ; Tue, 31 Oct 2000 11:44:13 -0500 (EST) Received: from presque.djinesys.com ([198.108.6.10]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id LAA20037 for ; Tue, 31 Oct 2000 11:44:12 -0500 (EST) Received: from squaw.nexthoptechnologies.com (dj129.djinesys.com [198.108.6.129]) by presque.djinesys.com (8.9.3/8.9.3) with ESMTP id LAA42308; Tue, 31 Oct 2000 11:36:26 -0500 (EST) (envelope-from jhaas@djinesys.com) Received: (from jhaas@localhost) by squaw.nexthoptechnologies.com (8.9.3/8.9.1) id LAA17670; Tue, 31 Oct 2000 11:39:18 -0500 (EST) Date: Tue, 31 Oct 2000 11:39:18 -0500 From: Jeffrey Haas To: "Natale, Jonathan" Cc: "Bgp Mail List (E-mail)" , "'tli@Procket.com'" , "'idr@merit.edu'" Subject: Re: Aggregation Message-ID: <20001031113918.A9396@squaw.nexthoptechnologies.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us In-Reply-To: ; from jnatale@northchurch.net on Tue, Oct 31, 2000 at 10:36:55AM -0500 Sender: owner-idr@merit.edu Precedence: bulk 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 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28903 for ; Tue, 31 Oct 2000 11:44:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E1635DDE3; Tue, 31 Oct 2000 11:44:12 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0DC505DDE1; Tue, 31 Oct 2000 11:44:12 -0500 (EST) Received: from presque.djinesys.com (unknown [198.108.6.10]) by segue.merit.edu (Postfix) with ESMTP id 842DD5DDE0 for ; Tue, 31 Oct 2000 11:44:10 -0500 (EST) Received: from squaw.nexthoptechnologies.com (dj129.djinesys.com [198.108.6.129]) by presque.djinesys.com (8.9.3/8.9.3) with ESMTP id LAA42308; Tue, 31 Oct 2000 11:36:26 -0500 (EST) (envelope-from jhaas@djinesys.com) Received: (from jhaas@localhost) by squaw.nexthoptechnologies.com (8.9.3/8.9.1) id LAA17670; Tue, 31 Oct 2000 11:39:18 -0500 (EST) Date: Tue, 31 Oct 2000 11:39:18 -0500 From: Jeffrey Haas To: "Natale, Jonathan" Cc: "Bgp Mail List (E-mail)" , "'tli@Procket.com'" , "'idr@merit.edu'" Subject: Re: Aggregation Message-ID: <20001031113918.A9396@squaw.nexthoptechnologies.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us In-Reply-To: ; from jnatale@northchurch.net on Tue, Oct 31, 2000 at 10:36:55AM -0500 Sender: owner-idr@merit.edu Precedence: bulk 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 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA27847 for ; Tue, 31 Oct 2000 10:39:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E0AF5DDD0; Tue, 31 Oct 2000 10:39:00 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3E7EC5DDCE; Tue, 31 Oct 2000 10:39:00 -0500 (EST) Received: from nsa-mail.us.newbridge.com (nsa-mail.us.newbridge.com [209.58.11.226]) by segue.merit.edu (Postfix) with ESMTP id CD3A95DDC4; Tue, 31 Oct 2000 10:38:56 -0500 (EST) Received: (from smtpd@localhost) by nsa-mail.us.newbridge.com (8.9.3/8.9.2) id KAA21753; Tue, 31 Oct 2000 10:30:07 -0500 (EST) Received: from nsa-gw1.us.newbridge.com(209.58.11.225), claiming to be "herndon-mh1.us.newbridge.com" via SMTP by nsa-mail.us.newbridge.com, id smtpdBAAa005J_; Tue Oct 31 10:30:04 2000 Received: from okemo.northc.com by herndon-mh1.us.newbridge.com with ESMTP; Tue, 31 Oct 2000 10:37:16 -0500 Received: by okemo.northc.com with Internet Mail Service (5.5.2650.21) id ; Tue, 31 Oct 2000 10:36:53 -0500 Message-Id: From: "Natale, Jonathan" To: "Bgp Ietf Mail List (E-mail)" , "Bgp Mail List (E-mail)" , "'tli@Procket.com'" , "'idr@merit.edu'" Subject: Aggregation Date: Tue, 31 Oct 2000 10:36:55 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-idr@merit.edu Precedence: bulk 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 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA11568 for ; Fri, 27 Oct 2000 08:51:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE7B85DDA6; Fri, 27 Oct 2000 08:51:09 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D922C5DDA3; Fri, 27 Oct 2000 08:51:09 -0400 (EDT) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 3000C5DD93 for ; Fri, 27 Oct 2000 08:51:08 -0400 (EDT) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id IAA11836; Fri, 27 Oct 2000 08:51:05 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; FRI, 27 Oct 2000 08:41:55 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 08:41:55 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E563A80B3@newman.tenornet.com> From: "Shah, Himanshu" To: "'vikram idrp'" , "Shah, Himanshu" , Andrew.Wu@cosinecom.com Cc: idr@merit.edu Subject: RE: iBGP/eBGP interaction question Date: Fri, 27 Oct 2000 08:41:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk 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:vikram_idrp@hotmail.com] Sent: Friday, October 27, 2000 12:02 AM To: hshah@tenornetworks.com; Andrew.Wu@cosinecom.com Cc: idr@merit.edu Subject: RE: iBGP/eBGP interaction question >From: "Shah, Himanshu" >To: "'Andrew Wu'" >CC: "'idr@merit.edu'" >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:Andrew.Wu@cosinecom.com] >Sent: Wednesday, October 25, 2000 4:39 PM >To: 'Shah, Himanshu' >Subject: RE: iBGP/eBGP interaction question > > > > >-----Original Message----- >From: Shah, Himanshu [mailto:hshah@tenornetworks.com] >Sent: Tuesday, October 24, 2000 7:04 AM >To: Andrew Wu; Anoop Ghanwani >Cc: 'idr@merit.edu' >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:Andrew.Wu@cosinecom.com] >Sent: Monday, October 23, 2000 9:52 PM >To: Anoop Ghanwani; 'Ben Black' >Cc: 'idr@merit.edu' >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: 'idr@merit.edu' >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:ben@layer8.net ] > > Sent: Monday, October 23, 2000 2:02 PM > > To: Anoop Ghanwani > > Cc: 'idr@merit.edu' > > 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA04886 for ; Fri, 27 Oct 2000 00:04:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4B165DED1; Fri, 27 Oct 2000 00:02:01 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CB3BD5DE12; Fri, 27 Oct 2000 00:02:01 -0400 (EDT) Received: from hotmail.com (f157.law10.hotmail.com [64.4.15.157]) by segue.merit.edu (Postfix) with ESMTP id D68215DDF1 for ; Fri, 27 Oct 2000 00:01:57 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Oct 2000 21:01:57 -0700 Received: from 209.58.11.227 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 27 Oct 2000 04:01:56 GMT X-Originating-IP: [209.58.11.227] From: "vikram idrp" To: hshah@tenornetworks.com, Andrew.Wu@cosinecom.com Cc: idr@merit.edu Subject: RE: iBGP/eBGP interaction question Date: Fri, 27 Oct 2000 04:01:56 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Oct 2000 04:01:57.0192 (UTC) FILETIME=[A645F480:01C03FCA] Sender: owner-idr@merit.edu Precedence: bulk >From: "Shah, Himanshu" >To: "'Andrew Wu'" >CC: "'idr@merit.edu'" >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:Andrew.Wu@cosinecom.com] >Sent: Wednesday, October 25, 2000 4:39 PM >To: 'Shah, Himanshu' >Subject: RE: iBGP/eBGP interaction question > > > > >-----Original Message----- >From: Shah, Himanshu [mailto:hshah@tenornetworks.com] >Sent: Tuesday, October 24, 2000 7:04 AM >To: Andrew Wu; Anoop Ghanwani >Cc: 'idr@merit.edu' >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:Andrew.Wu@cosinecom.com] >Sent: Monday, October 23, 2000 9:52 PM >To: Anoop Ghanwani; 'Ben Black' >Cc: 'idr@merit.edu' >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: 'idr@merit.edu' >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:ben@layer8.net ] > > Sent: Monday, October 23, 2000 2:02 PM > > To: Anoop Ghanwani > > Cc: 'idr@merit.edu' > > 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA21326 for ; Thu, 26 Oct 2000 07:54:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB8C55DDC4; Thu, 26 Oct 2000 07:54:03 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A8F095DDDC; Thu, 26 Oct 2000 07:54:03 -0400 (EDT) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id B53CA5DDC4 for ; Thu, 26 Oct 2000 07:54:01 -0400 (EDT) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id HAA17884; Thu, 26 Oct 2000 07:53:59 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; THU, 26 Oct 2000 07:44:47 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 07:44:46 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E563A80AE@newman.tenornet.com> From: "Shah, Himanshu" To: "'Andrew Wu'" Cc: "'idr@merit.edu'" Subject: RE: iBGP/eBGP interaction question Date: Thu, 26 Oct 2000 07:44:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03F42.238492FA" Sender: owner-idr@merit.edu Precedence: bulk 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:Andrew.Wu@cosinecom.com] Sent: Wednesday, October 25, 2000 4:39 PM To: 'Shah, Himanshu' Subject: RE: iBGP/eBGP interaction question -----Original Message----- From: Shah, Himanshu [mailto:hshah@tenornetworks.com] Sent: Tuesday, October 24, 2000 7:04 AM To: Andrew Wu; Anoop Ghanwani Cc: 'idr@merit.edu' 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:Andrew.Wu@cosinecom.com] Sent: Monday, October 23, 2000 9:52 PM To: Anoop Ghanwani; 'Ben Black' Cc: 'idr@merit.edu' 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: 'idr@merit.edu' 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:ben@layer8.net ] > Sent: Monday, October 23, 2000 2:02 PM > To: Anoop Ghanwani > Cc: 'idr@merit.edu' > 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" RE: iBGP/eBGP interaction question
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:Andrew.Wu@cosinecom.com]
Sent: Wednesday, October 25, 2000 4:39 PM
To: 'Shah, Himanshu'
Subject: RE: iBGP/eBGP interaction question

 
-----Original Message-----
From: Shah, Himanshu [mailto:hshah@tenornetworks.com]
Sent: Tuesday, October 24, 2000 7:04 AM
To: Andrew Wu; Anoop Ghanwani
Cc: 'idr@merit.edu'
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:Andrew.Wu@cosinecom.com]
Sent: Monday, October 23, 2000 9:52 PM
To: Anoop Ghanwani; 'Ben Black'
Cc: 'idr@merit.edu'
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: 'idr@merit.edu'
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:ben@layer8.net]
> Sent: Monday, October 23, 2000 2:02 PM
> To: Anoop Ghanwani
> Cc: 'idr@merit.edu'
> 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-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA10195 for ; Tue, 24 Oct 2000 10:14:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E060B5DE26; Tue, 24 Oct 2000 10:13:17 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C56A15DE1F; Tue, 24 Oct 2000 10:13:17 -0400 (EDT) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 486B75DE1F for ; Tue, 24 Oct 2000 10:12:55 -0400 (EDT) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id KAA20311; Tue, 24 Oct 2000 10:12:49 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; TUE, 24 Oct 2000 10:03:39 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 10:03:39 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E563A80A4@newman.tenornet.com> From: "Shah, Himanshu" To: "'Andrew Wu'" , Anoop Ghanwani Cc: "'idr@merit.edu'" Subject: RE: iBGP/eBGP interaction question Date: Tue, 24 Oct 2000 10:03:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DC3.352A3710" Sender: owner-idr@merit.edu Precedence: bulk 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:Andrew.Wu@cosinecom.com] Sent: Monday, October 23, 2000 9:52 PM To: Anoop Ghanwani; 'Ben Black' Cc: 'idr@merit.edu' 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: 'idr@merit.edu' 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:ben@layer8.net ] > Sent: Monday, October 23, 2000 2:02 PM > To: Anoop Ghanwani > Cc: 'idr@merit.edu' > 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" 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.
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:Andrew.Wu@cosinecom.com]
Sent: Monday, October 23, 2000 9:52 PM
To: Anoop Ghanwani; 'Ben Black'
Cc: 'idr@merit.edu'
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: 'idr@merit.edu'
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:ben@layer8.net]
> Sent: Monday, October 23, 2000 2:02 PM
> To: Anoop Ghanwani
> Cc: 'idr@merit.edu'
> 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-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA08281 for ; Tue, 24 Oct 2000 08:16:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79EA15DDBB; Tue, 24 Oct 2000 08:15:12 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 602345DE13; Tue, 24 Oct 2000 08:15:12 -0400 (EDT) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 259F75DDBB for ; Tue, 24 Oct 2000 08:15:10 -0400 (EDT) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id IAA10523; Tue, 24 Oct 2000 08:14:41 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; TUE, 24 Oct 2000 08:05:36 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 08:05:36 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E563A80A3@newman.tenornet.com> From: "Shah, Himanshu" To: "'Anoop Ghanwani'" Cc: "'idr@merit.edu'" Subject: RE: iBGP/eBGP interaction question Date: Tue, 24 Oct 2000 08:05:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DB2.B73F30FE" Sender: owner-idr@merit.edu Precedence: bulk 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:anoop@cosinecom.com] Sent: Monday, October 23, 2000 9:37 PM To: 'Ben Black' Cc: 'idr@merit.edu' 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:ben@layer8.net ] > Sent: Monday, October 23, 2000 2:02 PM > To: Anoop Ghanwani > Cc: 'idr@merit.edu' > 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" RE: iBGP/eBGP interaction question
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:anoop@cosinecom.com]
Sent: Monday, October 23, 2000 9:37 PM
To: 'Ben Black'
Cc: 'idr@merit.edu'
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:ben@layer8.net]
> Sent: Monday, October 23, 2000 2:02 PM
> To: Anoop Ghanwani
> Cc: 'idr@merit.edu'
> 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-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA01265 for ; Mon, 23 Oct 2000 21:53:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 977425DDF6; Mon, 23 Oct 2000 21:53:06 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 87F7D5DDF3; Mon, 23 Oct 2000 21:53:06 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by segue.merit.edu (Postfix) with ESMTP id 0F9C55DDD4 for ; Mon, 23 Oct 2000 21:53:05 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 18:51:48 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29110E9687@exchsrv1.cosinecom.com> From: Andrew Wu To: Anoop Ghanwani , "'Ben Black'" Cc: "'idr@merit.edu'" Subject: RE: iBGP/eBGP interaction question Date: Mon, 23 Oct 2000 18:51:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D5C.F84A5340" Sender: owner-idr@merit.edu Precedence: bulk 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: 'idr@merit.edu' 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:ben@layer8.net ] > Sent: Monday, October 23, 2000 2:02 PM > To: Anoop Ghanwani > Cc: 'idr@merit.edu' > 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" 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: 'idr@merit.edu'
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:ben@layer8.net]
> Sent: Monday, October 23, 2000 2:02 PM
> To: Anoop Ghanwani
> Cc: 'idr@merit.edu'
> 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-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA01097 for ; Mon, 23 Oct 2000 21:38:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 604B25DDB2; Mon, 23 Oct 2000 21:38:18 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4610A5DDF6; Mon, 23 Oct 2000 21:38:18 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by segue.merit.edu (Postfix) with ESMTP id BA8605DDB2 for ; Mon, 23 Oct 2000 21:38:16 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 18:37:00 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29110BDA3D@exchsrv1.cosinecom.com> From: Anoop Ghanwani To: "'Ben Black'" Cc: "'idr@merit.edu'" Subject: RE: iBGP/eBGP interaction question Date: Mon, 23 Oct 2000 18:36:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D5A.E6CBC9C0" Sender: owner-idr@merit.edu Precedence: bulk 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:ben@layer8.net] > Sent: Monday, October 23, 2000 2:02 PM > To: Anoop Ghanwani > Cc: 'idr@merit.edu' > 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" 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:ben@layer8.net]
> Sent: Monday, October 23, 2000 2:02 PM
> To: Anoop Ghanwani
> Cc: 'idr@merit.edu'
> 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-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA29902 for ; Mon, 23 Oct 2000 19:51:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5841A5DDEC; Mon, 23 Oct 2000 19:51:06 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 492E95DDD4; Mon, 23 Oct 2000 19:51:06 -0400 (EDT) Received: from hotmail.com (unknown [64.4.14.176]) by segue.merit.edu (Postfix) with ESMTP id D04EF5DDB2 for ; Mon, 23 Oct 2000 19:51:04 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Oct 2000 16:49:44 -0700 Received: from 209.58.11.227 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 23 Oct 2000 23:49:43 GMT X-Originating-IP: [209.58.11.227] From: "vikram idrp" To: anoop@cosinecom.com, idr@merit.edu Subject: Re: iBGP/eBGP interaction question Date: Mon, 23 Oct 2000 23:49:43 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Oct 2000 23:49:44.0188 (UTC) FILETIME=[EB0F8BC0:01C03D4B] Sender: owner-idr@merit.edu Precedence: bulk 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 >To: "'idr@merit.edu'" >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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA27937 for ; Mon, 23 Oct 2000 16:52:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 085335DD99; Mon, 23 Oct 2000 16:51:57 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E70775DDB2; Mon, 23 Oct 2000 16:51:56 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by segue.merit.edu (Postfix) with ESMTP id 6D9AD5DD99 for ; Mon, 23 Oct 2000 16:51:55 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 13:50:34 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29110BDA34@exchsrv1.cosinecom.com> From: Anoop Ghanwani To: "'idr@merit.edu'" Subject: iBGP/eBGP interaction question Date: Mon, 23 Oct 2000 13:50:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D32.E3696C10" Sender: owner-idr@merit.edu Precedence: bulk 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 iBGP/eBGP interaction question

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-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA11450 for ; Fri, 20 Oct 2000 19:40:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15EA75DDD8; Fri, 20 Oct 2000 19:40:11 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E2C6C5DDD2; Fri, 20 Oct 2000 19:40:10 -0400 (EDT) Received: from hotmail.com (f222.law10.hotmail.com [64.4.15.222]) by segue.merit.edu (Postfix) with ESMTP id 734455DDA4 for ; Fri, 20 Oct 2000 19:40:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Oct 2000 16:40:08 -0700 Received: from 209.58.11.227 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 20 Oct 2000 23:40:08 GMT X-Originating-IP: [209.58.11.227] From: "vikram idrp" To: idr@merit.edu Date: Fri, 20 Oct 2000 23:40:08 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Oct 2000 23:40:08.0641 (UTC) FILETIME=[14C4CB10:01C03AEF] Sender: owner-idr@merit.edu Precedence: bulk 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28992 for ; Wed, 18 Oct 2000 12:18:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 966D25DDC3; Wed, 18 Oct 2000 12:18:17 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 814A85DDC5; Wed, 18 Oct 2000 12:18:17 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id BCD245DDC3 for ; Wed, 18 Oct 2000 12:18:15 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA25964 for ; Wed, 18 Oct 2000 10:18:21 -0600 Message-Id: <200010181618.KAA25964@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: draft-ietf-idr-bgp-confed-rfc1965bis-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 2000 10:18:21 -0600 Sender: owner-idr@merit.edu Precedence: bulk FYI... -danny [snip] diff draft-ietf-idr-bgp-confed-rfc1965bis-00.txt draft-ietf-idr-bgp-confed-rfc1 965bis-01.txt 0a1,5 > > > > > 11c16 < --- > 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA06409 for ; Tue, 17 Oct 2000 09:29:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CD855DDBE; Tue, 17 Oct 2000 09:29:12 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EBCAB5DDA7; Tue, 17 Oct 2000 09:29:11 -0400 (EDT) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 358955DD9B for ; Tue, 17 Oct 2000 09:29:10 -0400 (EDT) Received: from tsillas (tsillas [192.168.0.133]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id JAA10220 for ; Tue, 17 Oct 2000 09:29:09 -0400 (EDT) Reply-To: From: "James Tsillas" To: "IDR" Subject: EBGP vs. imported route conflict Date: Tue, 17 Oct 2000 09:27:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idr@merit.edu Precedence: bulk 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04498 for ; Fri, 13 Oct 2000 14:09:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A88D05DE03; Fri, 13 Oct 2000 14:09:29 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 977E35DDCA; Fri, 13 Oct 2000 14:09:29 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 4B3F15DDB5 for ; Fri, 13 Oct 2000 14:09:28 -0400 (EDT) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA02987; Fri, 13 Oct 2000 11:09:27 -0700 (PDT) Message-Id: <200010131809.LAA02987@omega.cisco.com> To: rcoltun@redback.com Cc: idr@merit.edu Subject: -bgp-confed-rfc1965bis-00 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2982.971460566.1@cisco.com> Date: Fri, 13 Oct 2000 11:09:27 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk 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 To: idr@merit.edu 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 To: idr@merit.edu 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 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA21392 for ; Tue, 10 Oct 2000 21:55:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D46215DDA6; Tue, 10 Oct 2000 21:54:38 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C1EB55DDA7; Tue, 10 Oct 2000 21:54:38 -0400 (EDT) Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id 4322A5DDA6 for ; Tue, 10 Oct 2000 21:54:37 -0400 (EDT) Received: from choplifter.gpcc.itd.umich.edu (smtp@choplifter.gpcc.itd.umich.edu [141.211.2.143]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id VAA21811; Tue, 10 Oct 2000 21:54:36 -0400 (EDT) Received: from localhost (ahuja@localhost) by choplifter.gpcc.itd.umich.edu (8.8.8/5.1-client) with ESMTP id VAA02492; Tue, 10 Oct 2000 21:54:34 -0400 (EDT) Date: Tue, 10 Oct 2000 21:54:34 -0400 (EDT) From: abha ahuja X-Sender: ahuja@choplifter.gpcc.itd.umich.edu To: Danny McPherson Cc: idr@merit.edu Subject: Re: draft-chen-bgp-prefix-orf-00.txt In-Reply-To: <200010110147.TAA00613@tcb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > 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 > To: Andrew Partan > cc: Ian Duncan , idr@merit.edu, cole@juniper.net > 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. > > --asp@partan.com (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=, > size=777, class=0, pri=120777, nrcpts=4, msgid=<200010062110.OAA22199@red.junip > er.net>, proto=ESMTP, relay=dakine.juniper.net [172.17.12.87] > Oct 6 14:10:48 red sendmail[22200]: OAA22199: to=, > ctladdr= (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=, > size=1904, class=0, pri=121904, nrcpts=4, msgid=<200010062229.PAA28241@red.juni > per.net>, proto=ESMTP, relay=dakine.juniper.net [172.17.12.87] > Oct 6 15:29:48 red sendmail[28242]: PAA28241: to=, > ctladdr= (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: cole@juniper.net > 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 > ; 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: <200010062110.OAA22199@red.juniper.net> > To: "Ian Duncan" > cc: Enke Chen , idr@merit.edu, cole@juniper.net > Subject: Re: draft-chen-bgp-prefix-orf-00.txt > In-reply-to: Your message of "Fri, 06 Oct 2000 14:22:09 EDT." > <39DE1851.FADF61F6@nortelnetworks.com> > Date: Fri, 06 Oct 2000 14:10:42 -0700 > From: Bruce Cole > > 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: cole@juniper.net > 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 > ; 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: <200010062229.PAA28241@red.juniper.net> > To: Enke Chen > cc: "Ian Duncan" , idr@merit.edu, cole@juniper.net > Subject: Re: draft-chen-bgp-prefix-orf-00.txt > In-reply-to: Your message of "Fri, 06 Oct 2000 14:32:38 PDT." > <20001006213323.82A5217BC17@postal.redback.com> > Date: Fri, 06 Oct 2000 15:29:42 -0700 > From: Bruce Cole > > > > 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. > > > > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA21351 for ; Tue, 10 Oct 2000 21:48:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F8255DDF3; Tue, 10 Oct 2000 21:47:34 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F79F5DDEE; Tue, 10 Oct 2000 21:47:34 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id AA7FD5DDB1 for ; Tue, 10 Oct 2000 21:47:32 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id TAA00613 for ; Tue, 10 Oct 2000 19:47:41 -0600 Message-Id: <200010110147.TAA00613@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-bgp-prefix-orf-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Oct 2000 19:47:41 -0600 Sender: owner-idr@merit.edu Precedence: bulk > the way this is normally handled is to title the document "Cisco's 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 cole@juniper.net 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 To: Andrew Partan cc: Ian Duncan , idr@merit.edu, cole@juniper.net 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. > --asp@partan.com (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=, size=777, class=0, pri=120777, nrcpts=4, msgid=<200010062110.OAA22199@red.junip er.net>, proto=ESMTP, relay=dakine.juniper.net [172.17.12.87] Oct 6 14:10:48 red sendmail[22200]: OAA22199: to=, ctladdr= (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=, size=1904, class=0, pri=121904, nrcpts=4, msgid=<200010062229.PAA28241@red.juni per.net>, proto=ESMTP, relay=dakine.juniper.net [172.17.12.87] Oct 6 15:29:48 red sendmail[28242]: PAA28241: to=, ctladdr= (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: cole@juniper.net 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 ; 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: <200010062110.OAA22199@red.juniper.net> To: "Ian Duncan" cc: Enke Chen , idr@merit.edu, cole@juniper.net Subject: Re: draft-chen-bgp-prefix-orf-00.txt In-reply-to: Your message of "Fri, 06 Oct 2000 14:22:09 EDT." <39DE1851.FADF61F6@nortelnetworks.com> Date: Fri, 06 Oct 2000 14:10:42 -0700 From: Bruce Cole 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: cole@juniper.net 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 ; 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: <200010062229.PAA28241@red.juniper.net> To: Enke Chen cc: "Ian Duncan" , idr@merit.edu, cole@juniper.net Subject: Re: draft-chen-bgp-prefix-orf-00.txt In-reply-to: Your message of "Fri, 06 Oct 2000 14:32:38 PDT." <20001006213323.82A5217BC17@postal.redback.com> Date: Fri, 06 Oct 2000 15:29:42 -0700 From: Bruce Cole > > 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA18853 for ; Tue, 10 Oct 2000 17:43:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2C575DDAA; Tue, 10 Oct 2000 17:43:06 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D2E785DD9C; Tue, 10 Oct 2000 17:43:06 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 9814D5DD91 for ; Tue, 10 Oct 2000 17:43:05 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j7Au-0007Zk-00; Tue, 10 Oct 2000 14:43:04 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: idr@merit.edu Subject: Re: draft-chen-bgp-prefix-orf-00.txt References: <20001010204943.6F12017BC37@postal.redback.com> Message-Id: Date: Tue, 10 Oct 2000 14:43:04 -0700 Sender: owner-idr@merit.edu Precedence: bulk > 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 " and progress it as informational. randy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA18137 for ; Tue, 10 Oct 2000 16:50:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B1915DD8C; Tue, 10 Oct 2000 16:49:45 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 664875DD91; Tue, 10 Oct 2000 16:49:45 -0400 (EDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 03F9B5DD8C for ; Tue, 10 Oct 2000 16:49:44 -0400 (EDT) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by postal.redback.com (Postfix) with ESMTP id 6F12017BC37; Tue, 10 Oct 2000 13:49:43 -0700 (PDT) To: idr@merit.edu Cc: enke@redback.com Subject: Re: draft-chen-bgp-prefix-orf-00.txt Date: Tue, 10 Oct 2000 13:48:58 -0700 From: Enke Chen Message-Id: <20001010204943.6F12017BC37@postal.redback.com> Sender: owner-idr@merit.edu Precedence: bulk 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 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA03278 for ; Mon, 9 Oct 2000 20:35:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D5095DDF1; Mon, 9 Oct 2000 20:34:57 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2D7475DDEE; Mon, 9 Oct 2000 20:34:57 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id DF7775DDB3 for ; Mon, 9 Oct 2000 20:34:55 -0400 (EDT) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA28059; Mon, 9 Oct 2000 17:34:54 -0700 (PDT) Message-Id: <200010100034.RAA28059@omega.cisco.com> To: "Alix Fortune" Cc: idr@merit.edu Subject: Re: RFC In-reply-to: Your message of "Mon, 09 Oct 2000 19:01:12 PDT." <000d01c0325e$013f1580$2cd9f83f@ALIX.flashcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28057.971138094.1@cisco.com> Date: Mon, 09 Oct 2000 17:34:54 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alix, > What RFC # is draft-chen-bgp-prefix-orf-00.txt It is an Internet Draft, not an RFC. Yakov. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA02370 for ; Mon, 9 Oct 2000 19:03:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CDE65DDF0; Mon, 9 Oct 2000 19:00:41 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 573905DE06; Mon, 9 Oct 2000 19:00:41 -0400 (EDT) Received: from c014.sfo.cp.net (c014-h001.c014.sfo.cp.net [209.228.12.65]) by segue.merit.edu (Postfix) with SMTP id A1B6B5DDF0 for ; Mon, 9 Oct 2000 19:00:39 -0400 (EDT) Received: (cpmta 13833 invoked from network); 9 Oct 2000 16:00:37 -0700 Received: from 3ff8d92c.dsl.flashcom.net (HELO ALIX) (63.248.217.44) by smtp.flashcom.net (209.228.12.65) with SMTP; 9 Oct 2000 16:00:37 -0700 X-Sent: 9 Oct 2000 23:00:37 GMT Message-ID: <000d01c0325e$013f1580$2cd9f83f@ALIX.flashcom.com> From: "Alix Fortune" To: Cc: "Alix Fortune" Subject: RFC Date: Mon, 9 Oct 2000 19:01:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-idr@merit.edu Precedence: bulk What RFC # is draft-chen-bgp-prefix-orf-00.txt Thank you Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA02143 for ; Mon, 9 Oct 2000 18:42:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BAA25DDA4; Mon, 9 Oct 2000 18:42:00 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EC8835DDEA; Mon, 9 Oct 2000 18:41:59 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by segue.merit.edu (Postfix) with ESMTP id 8CF0D5DDA4 for ; Mon, 9 Oct 2000 18:41:58 -0400 (EDT) Received: from mosquito.extremenetworks.com ([10.0.8.94]) by sol.extremenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T895HK5S; Mon, 9 Oct 2000 15:40:26 -0700 Message-Id: <4.3.2.7.2.20001009183429.00aa7560@sc-sol-04.extremenetworks.com> X-Sender: rja@sc-sol-04.extremenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Oct 2000 18:35:49 -0400 To: danny@tcb.net From: RJ Atkinson Subject: Re: draft-chen-bgp-prefix-orf-00.txt Cc: idr@merit.edu In-Reply-To: <200010092213.QAA22148@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk 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 rja@inet.org Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA01880 for ; Mon, 9 Oct 2000 18:14:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C0FA5DE08; Mon, 9 Oct 2000 18:13:52 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 57EE05DE1E; Mon, 9 Oct 2000 18:13:52 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 7E3455DE08 for ; Mon, 9 Oct 2000 18:13:50 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id QAA22148 for ; Mon, 9 Oct 2000 16:13:59 -0600 Message-Id: <200010092213.QAA22148@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-bgp-prefix-orf-00.txt Date: Mon, 09 Oct 2000 16:13:59 -0600 Sender: owner-idr@merit.edu Precedence: bulk > 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 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA00696 for ; Mon, 9 Oct 2000 16:39:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 720115DDEF; Mon, 9 Oct 2000 16:39:10 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 615DE5DDEE; Mon, 9 Oct 2000 16:39:10 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by segue.merit.edu (Postfix) with ESMTP id D4FB95DDE7 for ; Mon, 9 Oct 2000 16:39:07 -0400 (EDT) Received: from mosquito.extremenetworks.com ([10.0.8.94]) by sol.extremenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T895HJQ1; Mon, 9 Oct 2000 13:37:36 -0700 Message-Id: <4.3.2.7.2.20001009163120.00ae5620@sc-sol-04.extremenetworks.com> X-Sender: rja@sc-sol-04.extremenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Oct 2000 16:32:58 -0400 To: danny@tcb.net From: RJ Atkinson Subject: Re: draft-chen-bgp-prefix-orf-00.txt Cc: idr@merit.edu In-Reply-To: <200010092030.OAA20976@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk 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 rja@inet.org Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA00526 for ; Mon, 9 Oct 2000 16:30:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1641B5DDEC; Mon, 9 Oct 2000 16:29:59 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 05A2B5DDE9; Mon, 9 Oct 2000 16:29:59 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 56AED5DDE7 for ; Mon, 9 Oct 2000 16:29:57 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id OAA20976 for ; Mon, 9 Oct 2000 14:30:06 -0600 Message-Id: <200010092030.OAA20976@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-bgp-prefix-orf-00.txt Date: Mon, 09 Oct 2000 14:30:06 -0600 Sender: owner-idr@merit.edu Precedence: bulk > 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 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA00297 for ; Mon, 9 Oct 2000 16:19:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23D895DE65; Mon, 9 Oct 2000 16:18:11 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 12FC55DE64; Mon, 9 Oct 2000 16:18:11 -0400 (EDT) Received: from tower.partan.com (tower.partan.com [198.6.255.248]) by segue.merit.edu (Postfix) with ESMTP id 9B1885DE62 for ; Mon, 9 Oct 2000 16:18:09 -0400 (EDT) Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id QAA00375; Mon, 9 Oct 2000 16:18:07 -0400 (EDT) Date: Mon, 9 Oct 2000 16:18:07 -0400 From: Andrew Partan To: Ian Duncan Cc: idr@merit.edu Subject: Re: draft-chen-bgp-prefix-orf-00.txt Message-ID: <20001009161807.A351@partan.com> References: <20001006161702.4485F17BC02@postal.redback.com> <39DE1851.FADF61F6@nortelnetworks.com> <39E0CD00.302B5094@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <39E0CD00.302B5094@nortelnetworks.com>; from iduncan@nortelnetworks.com on Sun, Oct 08, 2000 at 03:37:36PM -0400 Sender: owner-idr@merit.edu Precedence: bulk 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. --asp@partan.com (Andrew Partan) Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA29725 for ; Mon, 9 Oct 2000 15:42:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2A995DDE6; Mon, 9 Oct 2000 15:42:21 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D25D05DDE5; Mon, 9 Oct 2000 15:42:21 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id BF2725DDA4 for ; Mon, 9 Oct 2000 15:42:20 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13iioM-000Oye-00; Mon, 09 Oct 2000 12:42:10 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: RJ Atkinson Cc: Vivek Menezes , idr@merit.edu Subject: RE: draft-chen-bgp-prefix-orf-00.txt References: <4.3.2.7.2.20001009152631.00afa420@sc-sol-04.extremenetworks.com> Message-Id: Date: Mon, 09 Oct 2000 12:42:10 -0700 Sender: owner-idr@merit.edu Precedence: bulk >> 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 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA29682 for ; Mon, 9 Oct 2000 15:38:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E83155DD90; Mon, 9 Oct 2000 15:37:49 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D4ED15DDA4; Mon, 9 Oct 2000 15:37:49 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by segue.merit.edu (Postfix) with ESMTP id 1E84A5DD90 for ; Mon, 9 Oct 2000 15:37:48 -0400 (EDT) Received: from mosquito.extremenetworks.com ([10.0.8.71]) by sol.extremenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T895H259; Mon, 9 Oct 2000 12:36:14 -0700 Message-Id: <4.3.2.7.2.20001009152631.00afa420@sc-sol-04.extremenetworks.com> X-Sender: rja@sc-sol-04.extremenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Oct 2000 15:31:37 -0400 To: Vivek Menezes From: RJ Atkinson Subject: RE: draft-chen-bgp-prefix-orf-00.txt Cc: idr@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA27676 for ; Mon, 9 Oct 2000 13:23:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 90D1C5DDC4; Mon, 9 Oct 2000 13:22:49 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 80ECF5DDC5; Mon, 9 Oct 2000 13:22:49 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by segue.merit.edu (Postfix) with ESMTP id AE4D75DDC4 for ; Mon, 9 Oct 2000 13:22:47 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA09330; Mon, 9 Oct 2000 10:22:36 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id <4NB00X5D>; Mon, 9 Oct 2000 10:22:36 -0700 Message-ID: From: Vivek Menezes To: "'Ian Duncan'" , Randy Bush , Andrew Partan Cc: idr@merit.edu Subject: RE: draft-chen-bgp-prefix-orf-00.txt Date: Mon, 9 Oct 2000 10:22:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk 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:iduncan@nortelnetworks.com] Sent: Sunday, October 08, 2000 12:38 PM To: Randy Bush; Andrew Partan Cc: idr@merit.edu 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13221 for ; Sun, 8 Oct 2000 15:52:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E2795DDC9; Sun, 8 Oct 2000 15:51:58 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A0C25DDCE; Sun, 8 Oct 2000 15:51:58 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by segue.merit.edu (Postfix) with ESMTP id 20EA45DDC9 for ; Sun, 8 Oct 2000 15:51:57 -0400 (EDT) Received: from zcard00m.ca.nortel.com by ertpg14e1.nortelnetworks.com; Sun, 8 Oct 2000 15:44:43 -0400 Received: from zmerd004.ca.nortel.com ([47.124.0.133]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4KW017LZ; Sun, 8 Oct 2000 15:44:36 -0400 Received: from nortelnetworks.com (iduncan-2.ca.nortel.com [47.130.166.171]) by zmerd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4QKYQABA; Sun, 8 Oct 2000 15:44:36 -0400 Message-ID: <39E0CD00.302B5094@nortelnetworks.com> Date: Sun, 08 Oct 2000 15:37:36 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Ian Duncan" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush , Andrew Partan Cc: idr@merit.edu Subject: Re: draft-chen-bgp-prefix-orf-00.txt References: <20001006161702.4485F17BC02@postal.redback.com> <39DE1851.FADF61F6@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA28676 for ; Sat, 7 Oct 2000 15:44:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E88D5DDAB; Sat, 7 Oct 2000 15:44:27 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4EA015DDA8; Sat, 7 Oct 2000 15:44:27 -0400 (EDT) Received: from tower.partan.com (tower.partan.com [198.6.255.248]) by segue.merit.edu (Postfix) with ESMTP id DA38F5DDA0 for ; Sat, 7 Oct 2000 15:44:25 -0400 (EDT) Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id PAA16419; Sat, 7 Oct 2000 15:39:14 -0400 (EDT) Date: Sat, 7 Oct 2000 15:39:13 -0400 From: Andrew Partan To: Ian Duncan Cc: Enke Chen , idr@merit.edu Subject: Re: draft-chen-bgp-prefix-orf-00.txt Message-ID: <20001007153913.A16385@partan.com> References: <20001006161702.4485F17BC02@postal.redback.com> <39DE1851.FADF61F6@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <39DE1851.FADF61F6@nortelnetworks.com>; from iduncan@nortelnetworks.com on Fri, Oct 06, 2000 at 02:22:09PM -0400 Sender: owner-idr@merit.edu Precedence: bulk [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. --asp@partan.com (Andrew Partan) Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA13001 for ; Fri, 6 Oct 2000 14:33:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 71BE85DE0C; Fri, 6 Oct 2000 14:32:31 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A3905DDFA; Fri, 6 Oct 2000 14:32:31 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by segue.merit.edu (Postfix) with ESMTP id E89225DDEB for ; Fri, 6 Oct 2000 14:32:28 -0400 (EDT) Received: from zcard00m.ca.nortel.com by ertpg14e1.nortelnetworks.com; Fri, 6 Oct 2000 14:29:09 -0400 Received: from zmerd004.ca.nortel.com ([47.124.0.133]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4KW0BJ1Z; Fri, 6 Oct 2000 14:29:04 -0400 Received: from nortelnetworks.com (iduncan-2.ca.nortel.com [47.130.166.171]) by zmerd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4LFQJH30; Fri, 6 Oct 2000 14:29:03 -0400 Message-ID: <39DE1851.FADF61F6@nortelnetworks.com> Date: Fri, 06 Oct 2000 14:22:09 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Ian Duncan" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Enke Chen Cc: idr@merit.edu Subject: Re: draft-chen-bgp-prefix-orf-00.txt References: <20001006161702.4485F17BC02@postal.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk 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 > > > To: yakov@cisco.com, skh@merit.edu > > > cc: enke@redback.com > > > 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 > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA28413 for ; Thu, 5 Oct 2000 19:48:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29D445DE03; Thu, 5 Oct 2000 19:47:47 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0D0F85DE06; Thu, 5 Oct 2000 19:47:47 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id AEB7E5DE03 for ; Thu, 5 Oct 2000 19:47:45 -0400 (EDT) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA28359; Thu, 5 Oct 2000 16:47:44 -0700 (PDT) Message-Id: <200010052347.QAA28359@omega.cisco.com> To: Anoop Ghanwani Cc: "'idr@merit.edu'" Subject: Re: BGP extended communities In-reply-to: Your message of "Thu, 05 Oct 2000 16:14:30 PDT." <7EB7C6B62C4FD41196A80090279A29110BD9BC@exchsrv1.cosinecom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28357.970789664.1@cisco.com> Date: Thu, 05 Oct 2000 16:47:44 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk 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. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA28101 for ; Thu, 5 Oct 2000 19:17:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC3025DE00; Thu, 5 Oct 2000 19:15:46 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AB9A35DDFF; Thu, 5 Oct 2000 19:15:46 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by segue.merit.edu (Postfix) with ESMTP id 318255DDB7 for ; Thu, 5 Oct 2000 19:15:45 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 16:14:40 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29110BD9BC@exchsrv1.cosinecom.com> From: Anoop Ghanwani To: "'idr@merit.edu'" Subject: BGP extended communities Date: Thu, 5 Oct 2000 16:14:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F22.04051790" Sender: owner-idr@merit.edu Precedence: bulk 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 BGP extended communities

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

------_=_NextPart_001_01C02F22.04051790-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA23295 for ; Thu, 5 Oct 2000 13:18:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CBD5A5DE2A; Thu, 5 Oct 2000 13:17:21 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BA8865DE08; Thu, 5 Oct 2000 13:17:21 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by segue.merit.edu (Postfix) with ESMTP id 796EF5DE06 for ; Thu, 5 Oct 2000 13:17:20 -0400 (EDT) Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Thu, 5 Oct 2000 12:02:48 -0500 Received: from zmerd004.ca.nortel.com ([47.124.0.133]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 42TDS25C; Thu, 5 Oct 2000 13:02:36 -0400 Received: from nortelnetworks.com (iduncan-2.ca.nortel.com [47.130.166.171]) by zmerd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T5Y11K0J; Thu, 5 Oct 2000 13:02:36 -0400 Message-ID: <39DCB297.94A2443D@nortelnetworks.com> Date: Thu, 05 Oct 2000 12:55:51 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Ian Duncan" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter , idr@merit.edu Subject: Re: draft-chen-bgp-prefix-orf-00.txt References: <200009242205.PAA23254@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk 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 > To: yakov@cisco.com, skh@merit.edu > cc: enke@redback.com > 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