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 JAA27505 for ; Wed, 31 Jan 2001 09:49:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7804E5DED5; Wed, 31 Jan 2001 09:47:12 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4D15E5DEE4; Wed, 31 Jan 2001 09:47:12 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 7D78A5DED5 for ; Wed, 31 Jan 2001 09:47:10 -0500 (EST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id GAA09861 for ; Wed, 31 Jan 2001 06:47:10 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id GAA38667 for ; Wed, 31 Jan 2001 06:47:09 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200101311447.GAA38667@garnet.juniper.net> To: idr@merit.edu Subject: 4 bytes ASs MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38664.980952429.1@garnet.juniper.net> Date: Wed, 31 Jan 2001 06:47:09 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, As we agreed at the last WG meeting, here is the document. Yakov. ------- Forwarded Message Date: Wed, 31 Jan 2001 07:15:13 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-as4bytes-00.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-00.txt Pages : 7 Date : 30-Jan-01 Currently the Autonomous System number is encoded in BGP as a two- octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010130111631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010130111631.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- 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 RAA25464 for ; Fri, 26 Jan 2001 17:21:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id A3E0A5DDDB; Fri, 26 Jan 2001 17:20:44 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 947565DDB6; Fri, 26 Jan 2001 17:20:44 -0500 (EST) Received: from mx2out.umbc.edu (mx2out.umbc.edu [130.85.253.52]) by segue.merit.edu (Postfix) with ESMTP id EC2335DD90 for ; Fri, 26 Jan 2001 17:20:42 -0500 (EST) Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id RAA09163; Fri, 26 Jan 2001 17:20:41 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id RAA472782; Fri, 26 Jan 2001 17:20:41 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Fri, 26 Jan 2001 17:20:41 -0500 From: Vijay Gill X-X-Sender: To: ben abarbanel Cc: Subject: Re: BGP Imported Routes In-Reply-To: <3A71F446.DEE1446E@ipoptical.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Fri, 26 Jan 2001, ben abarbanel wrote: > Found a case where one of the big router vendors when receiving imported > STATIC, CONNECTED, ISIS and OSPF routes into BGP. Not all types for the > same route destination are kept in the BGP L-RIB. In fact when we > removed the "redistribute STATIC" statement from the configuration. The > other route types for the same destination did not magically appear in > the BGP L-RIB table. After searching in the standard I did not see any > mention of secondary or tertiary Imported routes into BGP criteria. It If this is what I think this is, then see advertise-inactive /vijay 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 RAA25194 for ; Fri, 26 Jan 2001 17:05:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 377215DDBE; Fri, 26 Jan 2001 17:04:56 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 213965DD90; Fri, 26 Jan 2001 17:04:56 -0500 (EST) Received: from merlin.prod.itd.earthlink.net (merlin.prod.itd.earthlink.net [207.217.120.156]) by segue.merit.edu (Postfix) with ESMTP id CC56A5DF04 for ; Fri, 26 Jan 2001 17:04:53 -0500 (EST) Received: from optic3.ipoptical.com (dialup-209.244.228.61.Washington1.Level3.net [209.244.228.61]) by merlin.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id OAA05469 for ; Fri, 26 Jan 2001 14:04:52 -0800 (PST) Received: from ipoptical.com (bena.ipoptical.com [172.16.2.30]) by optic3.ipoptical.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CQBY2JZ0; Fri, 26 Jan 2001 17:03:31 -0500 Message-ID: <3A71F446.DEE1446E@ipoptical.com> Date: Fri, 26 Jan 2001 17:03:50 -0500 From: ben abarbanel X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: idr@merit.edu Subject: BGP Imported Routes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Found a case where one of the big router vendors when receiving imported STATIC, CONNECTED, ISIS and OSPF routes into BGP. Not all types for the same route destination are kept in the BGP L-RIB. In fact when we removed the "redistribute STATIC" statement from the configuration. The other route types for the same destination did not magically appear in the BGP L-RIB table. After searching in the standard I did not see any mention of secondary or tertiary Imported routes into BGP criteria. It seems to me that we could be faced with BGP not propagating Imported route reachability information to its peers when redistirbution configuration changes occur. Even though the current router still has forwarding reachability with the other route types? Anybody had experience with this? Thanks, Ben 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 EAA08184 for ; Fri, 26 Jan 2001 04:37:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 829055DEF6; Fri, 26 Jan 2001 04:37:19 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6C5B95DEEA; Fri, 26 Jan 2001 04:37:19 -0500 (EST) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by segue.merit.edu (Postfix) with ESMTP id D71095DDEC for ; Fri, 26 Jan 2001 04:37:17 -0500 (EST) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Jan 2001 01:34:59 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911011823C9@exchsrv1.cosinecom.com> From: Anoop Ghanwani To: "'Venu V.'" , idr@merit.edu Subject: RE: Immediate Next-Hop Date: Fri, 26 Jan 2001 01:34:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0877B.3EA2D5C0" 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_01C0877B.3EA2D5C0 Content-Type: text/plain; charset="iso-8859-1" If a router doesn't do the BGP NEXT_HOP resolution before installing it in the Loc-RIB, it might install a route whose NEXT_HOP is actually unreachable. In other words, this protects the router from installing a route as an "active route" in those cases where it already knows that BGP NEXT_HOP, and therefore the route in question, is in fact not reachable. Likewise, when the immediate next hop changes, BGP needs to find out if and how the BGP NEXT_HOP continues to be reachable. If not, it should remove the route from its Loc-RIB and withdraw it from its peers. This process also ensures that less-preferred routes get activated and installed in those cases where the best route's NEXT_HOP is not reachable. -Anoop > -----Original Message----- > From: Venu V. [mailto:venuv@netplane.com] > Sent: Wednesday, January 24, 2001 4:21 AM > To: idr@merit.edu > Subject: Immediate Next-Hop > > > Hi All, > > The RFC 1771 Section 9.1.2 says that > > "The local speaker MUST determine the immediate > next hop to the address depicted by the NEXT_HOP attribute of the > selected route by performing a lookup in the IGP and > selecting one of > the possible paths in the IGP. This immediate next hop > MUST be used > when installing the selected route in the Loc-RIB. If the route to > the address depicted by the NEXT_HOP attribute changes > such that the > immediate next hop changes, route selection should be > recalculated as > specified above" > > I have a question regarding this section, why does BGP needs > to get the > Immediate next-hop for the NEXT_HOP attribute and install in LOC_RIB? > > BGP can check if the NEXT-HOP is reachable by looking into > FIB and if the > Immediate next-hop changes why is route selection needs to be > re-calculated? > > > Thanks, > Venu > > > ------_=_NextPart_001_01C0877B.3EA2D5C0 Content-Type: text/html; charset="iso-8859-1" RE: Immediate Next-Hop

If a router doesn't do the BGP NEXT_HOP resolution
before installing it in the Loc-RIB, it might install
a route whose NEXT_HOP is actually unreachable.
In other words, this protects the router from installing a
route as an "active route" in those cases where it already knows
that BGP NEXT_HOP, and therefore the route in question,
is in fact not reachable. 

Likewise, when the immediate next hop changes, BGP needs to
find out if and how the BGP NEXT_HOP continues to be
reachable.  If not, it should remove the route from its
Loc-RIB and withdraw it from its peers. 

This process also ensures that less-preferred routes get
activated and installed in those cases where the best
route's NEXT_HOP is not reachable.

-Anoop

> -----Original Message-----
> From: Venu V. [mailto:venuv@netplane.com]
> Sent: Wednesday, January 24, 2001 4:21 AM
> To: idr@merit.edu
> Subject: Immediate Next-Hop
>
>
> Hi All,
>
> The RFC 1771 Section 9.1.2  says that
>
> "The local speaker MUST determine the immediate
>    next hop to the address depicted by the NEXT_HOP attribute of the
>    selected route by performing a lookup in the IGP and
> selecting one of
>    the possible paths in the IGP.  This immediate next hop
> MUST be used
>    when installing the selected route in the Loc-RIB.  If the route to
>    the address depicted by the NEXT_HOP attribute changes
> such that the
>    immediate next hop changes, route selection should be
> recalculated as
>    specified above"
>
> I have a question regarding this section, why does BGP needs
> to get the
> Immediate next-hop for the NEXT_HOP attribute and install in LOC_RIB?
>
> BGP can check if the NEXT-HOP is reachable by looking into
> FIB and if the
> Immediate next-hop changes why is route selection needs to be
> re-calculated?
>
>
> Thanks,
> Venu
>
>
>

------_=_NextPart_001_01C0877B.3EA2D5C0-- 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 HAA14846 for ; Wed, 24 Jan 2001 07:21:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id C55815DDC1; Wed, 24 Jan 2001 07:21:15 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A8A655DDD3; Wed, 24 Jan 2001 07:21:15 -0500 (EST) Received: from xover.hjinc.com (unknown [38.160.241.130]) by segue.merit.edu (Postfix) with ESMTP id 34E9E5DDC1 for ; Wed, 24 Jan 2001 07:21:14 -0500 (EST) Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 07:18:38 -0500 Message-ID: From: "Venu V." To: idr@merit.edu Subject: Immediate Next-Hop Date: Wed, 24 Jan 2001 07:21:21 -0500 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 Hi All, The RFC 1771 Section 9.1.2 says that "The local speaker MUST determine the immediate next hop to the address depicted by the NEXT_HOP attribute of the selected route by performing a lookup in the IGP and selecting one of the possible paths in the IGP. This immediate next hop MUST be used when installing the selected route in the Loc-RIB. If the route to the address depicted by the NEXT_HOP attribute changes such that the immediate next hop changes, route selection should be recalculated as specified above" I have a question regarding this section, why does BGP needs to get the Immediate next-hop for the NEXT_HOP attribute and install in LOC_RIB? BGP can check if the NEXT-HOP is reachable by looking into FIB and if the Immediate next-hop changes why is route selection needs to be re-calculated? Thanks, Venu 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 LAA00766 for ; Fri, 19 Jan 2001 11:27:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 610FA5DE56; Fri, 19 Jan 2001 11:27:26 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 505CE5DDC2; Fri, 19 Jan 2001 11:27:26 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id B34E85DDC7 for ; Fri, 19 Jan 2001 11:27:24 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id JAA29983 for ; Fri, 19 Jan 2001 09:27:08 -0700 Message-Id: <200101191627.JAA29983@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: BGP CIDR Aggregation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 2001 09:27:08 -0700 Sender: owner-idr@merit.edu Precedence: bulk > I have a query about what is the standard way of performing NLRI prefix > aggregation in BGP. Can we aggregate two routes that have same network > prefix or do we perform aggregation only when we have (More specific/ Less > specific routes) More specific, sure, less specific, unlikely... > For example, a route "11.1.253.160/27" exists in the LOC_RIB table. The BGP > speaker received another route "11.1.253.180/27". How do we advertise the > routes? It's unlikely you received an advertisement for 11.1.253.180/27 as it's an invalid aggregate per there are bits in the prefix outside the mask 255.255.255.240. If the new route was perhaps for, say, 11.1.253.192/27, then you could consider some type of aggregation, perhaps 11.1.253.128/25, which is the smallest aggregate that contains both prefixes. > Do we advertise both the routes or aggregate both the routes into a single > route "11.1.253.0/24" and advertise the route? This is more a matter of local policy than BGP protocol behavior. > In the second case the aggregated route also represents prefixes > then the initial set of prefixes present in LOC_RIB. If I parse this correctly, it's fine, so long as the local AS has the authority to advertise the larger aggregate. This could be accomplished a number of ways (e.g., via 'dynamic' proxy aggregation, static configuration, etc..), and is again, more a matter of local policy than anything. Some of the 'dynamic aggregation' stuff which you seem to allude to is discussed under the AGGREGATOR and ATOMIC_AGGREGATE sections of the BGP spec. -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 JAA02752 for ; Thu, 18 Jan 2001 09:19:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5CEBF5DDFE; Thu, 18 Jan 2001 09:15:38 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 372935DE12; Thu, 18 Jan 2001 09:15:38 -0500 (EST) Received: from xover.hjinc.com (unknown [38.160.241.130]) by segue.merit.edu (Postfix) with ESMTP id C1B905DDFE for ; Thu, 18 Jan 2001 09:15:36 -0500 (EST) Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jan 2001 09:13:15 -0500 Message-ID: From: "Venu V." To: idr@merit.edu Subject: BGP CIDR Aggregation Date: Thu, 18 Jan 2001 09:15:33 -0500 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 Hi All, I have a query about what is the standard way of performing NLRI prefix aggregation in BGP. Can we aggregate two routes that have same network prefix or do we perform aggregation only when we have (More specific/ Less specific routes) For example, a route "11.1.253.160/27" exists in the LOC_RIB table. The BGP speaker received another route "11.1.253.180/27". How do we advertise the routes? Do we advertise both the routes or aggregate both the routes into a single route "11.1.253.0/24" and advertise the route? In the second case the aggregated route also represents prefixes then the initial set of prefixes present in LOC_RIB. Thanks, Venu 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 UAA08815 for ; Mon, 15 Jan 2001 20:22:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 814625DE11; Mon, 15 Jan 2001 20:22:07 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 62BBA5DE03; Mon, 15 Jan 2001 20:22:07 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 6D83A5DE00 for ; Mon, 15 Jan 2001 20:22:05 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id SAA15311 for ; Mon, 15 Jan 2001 18:21:50 -0700 Message-Id: <200101160121.SAA15311@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: BGP Route Oscillation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Jan 2001 18:21:50 -0700 Sender: owner-idr@merit.edu Precedence: bulk > It is worth noting that neither of the loops you describe seem > to occur when RFC 1771 route selection rules are used, but no mention > in the draft is made of the route selection rules you are using to > get those results. Since you're really talking about the effect > of the modified route selection rules in the current BGP4 draft > it would probably be better to mention this explicitly. I guess you're referring to the MED talk wrt comparing MEDs only between routes from the same neighboring AS? I agree that some explicit explanation of route selection rules should be provided. Of course, we're also planning to dicuss how this can occur with other attributes considered after MED (e.g., router id). Anyways, thanks for the input, we'll try to be more explicit in the next version of the draft. -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 UAA08653 for ; Mon, 15 Jan 2001 20:08:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id BEA5E5DE04; Mon, 15 Jan 2001 20:07:28 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AE3995DE03; Mon, 15 Jan 2001 20:07:28 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 9CE1C5DE00 for ; Mon, 15 Jan 2001 20:07:26 -0500 (EST) Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA20942; Mon, 15 Jan 2001 17:07:05 -0800 (PST) Message-Id: <200101160107.RAA20942@red.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: danny@ambernetworks.com Cc: idr@merit.edu Subject: Re: BGP Route Oscillation In-reply-to: Your message of "Mon, 15 Jan 2001 16:22:06 MST." <200101152322.QAA14661@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Jan 2001 17:07:05 -0800 From: Dennis Ferguson Sender: owner-idr@merit.edu Precedence: bulk Danny, > I do understand your point though and we'll try to convey > something of this nature in the next revision of the draft > (which should provide more information in terms of the > general looping properities of BGP). It is worth noting that neither of the loops you describe seem to occur when RFC 1771 route selection rules are used, but no mention in the draft is made of the route selection rules you are using to get those results. Since you're really talking about the effect of the modified route selection rules in the current BGP4 draft it would probably be better to mention this explicitly. Dennis Ferguson 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 TAA08155 for ; Mon, 15 Jan 2001 19:19:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB73C5DDA5; Mon, 15 Jan 2001 19:16:45 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A8D3C5DE11; Mon, 15 Jan 2001 19:16:45 -0500 (EST) Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.66.129.230]) by segue.merit.edu (Postfix) with ESMTP id 44F255DDA5 for ; Mon, 15 Jan 2001 19:16:40 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA64304; Mon, 15 Jan 2001 19:16:12 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101160016.TAA64304@workhorse.fictitious.org> To: danny@ambernetworks.com Cc: idr@merit.edu Reply-To: curtis@avici.com Subject: Re: BGP Route Oscillation In-reply-to: Your message of "Mon, 15 Jan 2001 16:22:06 MST." <200101152322.QAA14661@tcb.net> Date: Mon, 15 Jan 2001 19:16:12 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <200101152322.QAA14661@tcb.net>, Danny McPherson writes: > > > The latter rule was always used back when routing policy was > > configured (usually this was done based on know topology > ^^ at ANS :-) At least someone got it right. ;-) > > distances > > (from the routing registry) and relative capacity of private peerings > > and peer networks to resolve other ties in topology distance or based > > on the request of the destination origin AS or prefix owner). > > Though a minor observation would be that this requires > per-prefix policies, as well as near intimate knowledge > of other networks by the network operator. I'm not aware > of ANY [large] provider today that performs per-prefix > policies on routes learned from peers and I don't think > implicitly removing this dynamic portion of route selection > is a viable option in today's networks. Then again, I could > be wrong... It requires per border AS policy at the very minimum but that would mean ASx would always be preferred to ASy regardless of the origin AS or prefix. Per origin AS policy wouldn't work because routes sometimes get advertised with differing origin AS, particularly aggregates. A subset of per origin AS policy can be converted to prefixes based on a routing registry, leaving the bulk of the configuration based on per border AS. The ability to use AS path length plus a configured metric to set local_pref would also go a long way toward solving this without heavy reliance on registries and per prefix policy. AS path lenght can be biased move heavily such that per border AS policy only resolves ties in AS path length. What we are talking about here is usage (on what basis do we set local_pref). > I do understand your point though and we'll try to convey > something of this nature in the next revision of the draft > (which should provide more information in terms of the > general looping properities of BGP). The main point is that an available workaround is to using local_pref so no two AS advertise a given prefix at the same local_pref solves type II churn. > Thanks! > > -danny De Nada, Curtis 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 SAA07479 for ; Mon, 15 Jan 2001 18:22:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id A43BA5DDFD; Mon, 15 Jan 2001 18:22:25 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 943395DDD0; Mon, 15 Jan 2001 18:22:25 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id C2A2C5DDA5 for ; Mon, 15 Jan 2001 18:22:23 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id QAA14661 for ; Mon, 15 Jan 2001 16:22:06 -0700 Message-Id: <200101152322.QAA14661@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: BGP Route Oscillation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Jan 2001 16:22:06 -0700 Sender: owner-idr@merit.edu Precedence: bulk > The latter rule was always used back when routing policy was > configured (usually this was done based on know topology ^^ at ANS :-) > distances > (from the routing registry) and relative capacity of private peerings > and peer networks to resolve other ties in topology distance or based > on the request of the destination origin AS or prefix owner). Though a minor observation would be that this requires per-prefix policies, as well as near intimate knowledge of other networks by the network operator. I'm not aware of ANY [large] provider today that performs per-prefix policies on routes learned from peers and I don't think implicitly removing this dynamic portion of route selection is a viable option in today's networks. Then again, I could be wrong... I do understand your point though and we'll try to convey something of this nature in the next revision of the draft (which should provide more information in terms of the general looping properities of BGP). Thanks! -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 SAA07303 for ; Mon, 15 Jan 2001 18:07:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 626965DE4C; Mon, 15 Jan 2001 18:05:24 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3854C5DE13; Mon, 15 Jan 2001 18:05:24 -0500 (EST) Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.66.129.230]) by segue.merit.edu (Postfix) with ESMTP id 329735DE4C for ; Mon, 15 Jan 2001 18:05:01 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA63921; Mon, 15 Jan 2001 18:02:15 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101152302.SAA63921@workhorse.fictitious.org> To: Yakov Rekhter Cc: idr@merit.edu Reply-To: curtis@avici.com Subject: Re: BGP Route Oscillation In-reply-to: Your message of "Mon, 15 Jan 2001 11:47:11 PST." <200101151947.LAA30882@garnet.juniper.net> Date: Mon, 15 Jan 2001 18:02:15 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <200101151947.LAA30882@garnet.juniper.net>, Yakov Rekhter writes: > Folks, > > Any objections to the attached ? If yes, please send them to > the list asap (within the next 5 days). > > Yakov. Yakov, Minor correction in section 6.2. I've included the text as it currently exists in the draft. 6.2. Potential Workarounds for Type II Churn 1) Do not accept MEDs from peers (this may not be a feasible alternative). 2) Utilize other BGP attributes higher in the decision process so that the BGP decision algorithm never reaches the MED step. As this completely overrides MEDs, Option 1 may make more sense. 3) Always compare BGP MEDs, regardless of whether or not they were obtained from a single AS. This is probably a bad idea since MEDs may be derived in a number of ways, and are typically done so as a matter of operator-specific policy and largely a function of available metric space provided by the employed IGP. As such, comparing MED values for a single prefix learned from multiple ASs is ill-advised. This mostly defeats the purpose of MEDs; Option 1 may be a more viable alternative. 4) Future drafts will propose other solutions for Type II Churn You might be able to loosen the restriction in bullet 2. 2) Utilize other BGP attributes higher in the decision process so that the BGP decision algorithm selects a single AS before it reaches the MED step. For example, if local-pref were set based on the advertising AS, then you first eliminated all routes except those in a single AS. In the example, router Re would pick either X or Y based on local-pref and never change that selection. This leaves two simple workarounds for the two types of problems. Type I: Make inter-cluster or inter-sub-AS link metrics higher than intra-cluster or intra-sub-AS metrics. Type II: Make route selections based on local pref assigned to advertising AS first and then used IGP cost and MED to make selection among routes from the same AS. The latter rule was always used back when routing policy was configured (usually this was done based on know topology distances (from the routing registry) and relative capacity of private peerings and peer networks to resolve other ties in topology distance or based on the request of the destination origin AS or prefix owner). When this method fell out of favor, it created the opportunities for route loops in networks using RR and/or confederations (all major networks). Curtis 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 OAA04672 for ; Mon, 15 Jan 2001 14:50:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9DBF65DE5F; Mon, 15 Jan 2001 14:47:14 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7FBCB5DE65; Mon, 15 Jan 2001 14:47:14 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id AB7C05DE5F for ; Mon, 15 Jan 2001 14:47:12 -0500 (EST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA00549 for ; Mon, 15 Jan 2001 11:47:12 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id LAA30882 for ; Mon, 15 Jan 2001 11:47:11 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200101151947.LAA30882@garnet.juniper.net> To: idr@merit.edu Subject: BGP Route Oscillation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30879.979588031.1@garnet.juniper.net> Date: Mon, 15 Jan 2001 11:47:11 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, Any objections to the attached ? If yes, please send them to the list asap (within the next 5 days). Yakov. ------- Forwarded Message Date: Fri, 05 Jan 2001 12:38:48 -0700 From: Danny McPherson To: idr@merit.edu, yakov@juniper.net Subject: BGP Route Oscillation I'd like to ask that the IDR WG accept this draft as a WG item and encourage solutions proposals. Thanks! - -danny - ------- Forwarded Message To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcpherson-bgp-route-oscillation-00.txt Date: Thu, 04 Jan 2001 07:26:57 -0500 - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Persistent Route Oscillation Condition Author(s) : D. McPherson, V. Gill, D. Walton, A. Retana Filename : draft-mcpherson-bgp-route-oscillation-00.txt Pages : 18 Date : 03-Jan-01 The Border Gateway Protocol (BGP) [1] is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mcpherson-bgp-route-oscillation-00.tx t Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcpherson-bgp-route-oscillation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mcpherson-bgp-route-oscillation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010103133616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcpherson-bgp-route-oscillation-00.txt - - --OtherAccess Content-Type: Message/External-body; name="draft-mcpherson-bgp-route-oscillation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" - - --OtherAccess-- - - --NextPart-- - ------- 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 JAA04382 for ; Thu, 11 Jan 2001 09:57:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF0ED5DD90; Thu, 11 Jan 2001 09:56:53 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B120E5DDB7; Thu, 11 Jan 2001 09:56:53 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 0B29D5DD90 for ; Thu, 11 Jan 2001 09:56:52 -0500 (EST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id GAA02065 for ; Thu, 11 Jan 2001 06:56:51 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id GAA92938 for ; Thu, 11 Jan 2001 06:56:51 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200101111456.GAA92938@garnet.juniper.net> To: idr@merit.edu Subject: -12.txt of BGP4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92935.979225011.1@garnet.juniper.net> Date: Thu, 11 Jan 2001 06:56:51 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, The only changes in this version are (a) the version number, (b) the dates, and (c) authors' information for myself. Yakov. ------- Forwarded Message Date: Thu, 11 Jan 2001 07:27:13 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp4-12.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter, T. Li Filename : draft-ietf-idr-bgp4-12.txt Pages : 60 Date : 10-Jan-01 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-12.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010110132703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-12.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010110132703.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- 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 HAA19039 for ; Wed, 10 Jan 2001 07:24:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 128A65DDD5; Wed, 10 Jan 2001 07:24:16 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E83045DDD0; Wed, 10 Jan 2001 07:24:15 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id E84AF5DDAC for ; Wed, 10 Jan 2001 07:24:14 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14GKIQ-0009R6-00; Wed, 10 Jan 2001 04:24:06 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Peter Lewis" Cc: Subject: Re: MPLS World, February 6-9, Paris References: <027901c07afb$12d36e00$8001a8c0@oleane.com> Message-Id: Date: Wed, 10 Jan 2001 04:24:06 -0800 Sender: owner-idr@merit.edu Precedence: bulk > Looking Farther Ahead slime spammer finally stops polluting ietf mailing list with his scams? that's what i would like to see ahead. 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 GAA18668 for ; Wed, 10 Jan 2001 06:48:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D14C5DDA9; Wed, 10 Jan 2001 06:45:53 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3E96A5DDAC; Wed, 10 Jan 2001 06:45:53 -0500 (EST) Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by segue.merit.edu (Postfix) with ESMTP id 678245DDA9 for ; Wed, 10 Jan 2001 06:45:51 -0500 (EST) Received: from oleane (dyn-1-1-059.Vin.dialup.oleane.fr [195.25.4.59]) by smtp4.cluster.oleane.net with SMTP id f0ABjnF78279 for ; Wed, 10 Jan 2001 12:45:49 +0100 (CET) Message-ID: <027901c07afb$12d36e00$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World, February 6-9, Paris Date: Wed, 10 Jan 2001 12:47:13 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0276_01C07B03.745DDA40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idr@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0276_01C07B03.745DDA40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 MPLS World, February 6-9, Paris.=20 =20 http://www.upperside.fr/congress/congress.htm =20 With the challenges and uncertainties engendered by the development of = the MPLS architecture, the MPLS World Conference is, in essence, an open = platform for debate on the future of telecommunications networks.=20 Looking Farther Ahead=20 MPLS World is preoccupied with future developments, like using MPLS in = the access network and in the LAN. MPLambdaS, MPLS/mobility convergence = are addressed in papers never before given. MPLS is a unique occasion = for participants to unveil their work and expose new ideas.=20 =20 The exhibition =20 Already 20 exhibitors for this very first MPLS exhibition. Upper Side = will fullfill his objectives. Vendors shouldn't miss the opportunity: http://www.upperside.fr/congress/exhi.htm ------=_NextPart_000_0276_01C07B03.745DDA40 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
MPLS World, February 6-9, Paris.=20
 
http://www.uppersi= de.fr/congress/congress.htm
 
With the=20 challenges and uncertainties engendered by the development of the MPLS=20 architecture, the MPLS World Conference is, in essence, an open platform = for=20 debate on the future of telecommunications networks.=20

Looking=20 Farther Ahead

MPLS World is preoccupied with future = developments,=20 like using MPLS in the access network and in the LAN. MPLambdaS, = MPLS/mobility=20 convergence are addressed in papers never before given. MPLS is a unique = occasion for participants to unveil their work and expose new ideas.=20
 
The=20 exhibition
 
Already 20=20 exhibitors for this very first MPLS exhibition. Upper Side will fullfill = his=20 objectives. Vendors shouldn't miss the opportunity:
http://www.upperside.f= r/congress/exhi.htm
 
------=_NextPart_000_0276_01C07B03.745DDA40-- 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 OAA10501 for ; Mon, 8 Jan 2001 14:29:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 10E0D5DE35; Mon, 8 Jan 2001 14:27:57 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EDF385DE3A; Mon, 8 Jan 2001 14:27:56 -0500 (EST) Received: from jhawk-foo.bbnplanet.com (jhawk-foo.bbnplanet.com [199.94.208.163]) by segue.merit.edu (Postfix) with ESMTP id CBEA55DE35 for ; Mon, 8 Jan 2001 14:27:49 -0500 (EST) Received: (from jhawk@localhost) by jhawk-foo.bbnplanet.com (8.8.8+Sun/8.8.8) id OAA10514; Mon, 8 Jan 2001 14:27:48 -0500 (EST) Date: Mon, 8 Jan 2001 14:27:48 -0500 From: John Hawkinson To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Nominal feedback on draft-ramachandra-bgp-ext-communities-08.txt Message-ID: <20010108142748.R23906@jhawk-foo.bbnplanet.com> References: <20010108141054.Q23906@jhawk-foo.bbnplanet.com> <200101081921.LAA99179@garnet.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <200101081921.LAA99179@garnet.juniper.net>; from yakov@juniper.net on Mon, Jan 08, 2001 at 11:21:55AM -0800 Sender: owner-idr@merit.edu Precedence: bulk > > I was hoping to leave that to the authors. Presumably they've already > > implemented something in their implementations, right? > > I just thought that you have any specific prefence. But documenting > what is implemented would be fine with me too. My larger concern is that different vendors may do different things, and I'd like to prevent that. > How about (X+1)= 0x4000 and (Y+1)=0x8000 ? Fine by me, though I'd be more inclined to consider x+1=8000 and y+1=c000, giving the largest chunk to the IANA-assigned "official" space rather than to the private space. > > But you choose not to address the complexity question ;-) > > I'll try to address the question, once you'll elaborate a bit on what > is exactly so complex in ext communities ? Well, we used to have communities where there was one level of hierarchy, the AS. Now we introduce many levels of hierarchy, including 2-byte ASes, 4-byte ASes, and IP addresses. And beyond that, new formats can be defined with Types. I'm not really certain what a legitimate use of a new community Type would be. I'm not objecting, mind you, but I do think that the spec isn't terribly clear on this, and so I wonder if we're adding much more complexity than we need, and if we couldn't just get by with, say, 4-byte ASes and nothing else. --jhawk 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 OAA10221 for ; Mon, 8 Jan 2001 14:11:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 782105DDE5; Mon, 8 Jan 2001 14:10:58 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 677AF5DDCB; Mon, 8 Jan 2001 14:10:58 -0500 (EST) Received: from jhawk-foo.bbnplanet.com (jhawk-foo.bbnplanet.com [199.94.208.163]) by segue.merit.edu (Postfix) with ESMTP id E6A6D5DDC1 for ; Mon, 8 Jan 2001 14:10:56 -0500 (EST) Received: (from jhawk@localhost) by jhawk-foo.bbnplanet.com (8.8.8+Sun/8.8.8) id OAA10492; Mon, 8 Jan 2001 14:10:55 -0500 (EST) Date: Mon, 8 Jan 2001 14:10:54 -0500 From: John Hawkinson To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Nominal feedback on draft-ramachandra-bgp-ext-communities-08.txt Message-ID: <20010108141054.Q23906@jhawk-foo.bbnplanet.com> References: <200101081834.NAA10438@jhawk-foo.bbnplanet.com> <200101081902.LAA95929@garnet.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <200101081902.LAA95929@garnet.juniper.net>; from yakov@juniper.net on Mon, Jan 08, 2001 at 11:02:03AM -0800 Sender: owner-idr@merit.edu Precedence: bulk > > a) It might be nice if the draft specified a recommended display format > > for these things, since things are liable to get confusing with 3+ different > > ways to look at a given community. > > Please propose one. I was hoping to leave that to the authors. Presumably they've already implemented something in their implementations, right? > > b) It seems wrong to have types 0x8000-0xffff be > > "vendor-specific". Shouldn't they be "site"-specific, or such? Vendors > > should register their types with the IANA to prevent collisions in the > > vendor space. > > How about if we'll follow the approach used by multi-protocol > extensions. That is, type values 0 through X are to be > assigned by IANA using the "IETF Consensus" policy defined in RFC > 2434. Type values (X+1) through Y are to be assigned by IANA, > using the "First Come First Served" policy defined in RFC 2434. > Finally type values (Y+1) through 0xffff are for "private use", > and values in this range are not to be assigned by IANA. That sounds good to me. I don't have any strong opinions on what the values of X and Y should be, it's not terribly clear to me what the use of such Type extensions will be for. Perhaps the document would benefit by examples. But you choose not to address the complexity question ;-) --jhawk 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 NAA09416 for ; Mon, 8 Jan 2001 13:39:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id D33C75DE13; Mon, 8 Jan 2001 13:34:08 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C36B85DE85; Mon, 8 Jan 2001 13:34:08 -0500 (EST) Received: from jhawk-foo.bbnplanet.com (jhawk-foo.bbnplanet.com [199.94.208.163]) by segue.merit.edu (Postfix) with ESMTP id 452625DE13 for ; Mon, 8 Jan 2001 13:34:07 -0500 (EST) Received: (from jhawk@localhost) by jhawk-foo.bbnplanet.com (8.8.8+Sun/8.8.8) id NAA10438; Mon, 8 Jan 2001 13:34:06 -0500 (EST) Date: Mon, 8 Jan 2001 13:34:06 -0500 (EST) Message-Id: <200101081834.NAA10438@jhawk-foo.bbnplanet.com> To: idr@merit.edu Subject: Nominal feedback on draft-ramachandra-bgp-ext-communities-08.txt From: John Hawkinson Sender: owner-idr@merit.edu Precedence: bulk Hi. I finally got around to reading draft-ramachandra-bgp-ext-communities-08.txt; I know it (and prior versions) have been around for a while, but there doesn't seem to have been much feedback on IDR (at least, I don't recall any and a casual perusal of the archives doesn't show much). Three brief comments: a) It might be nice if the draft specified a recommended display format for these things, since things are liable to get confusing with 3+ different ways to look at a given community. b) It seems wrong to have types 0x8000-0xffff be "vendor-specific". Shouldn't they be "site"-specific, or such? Vendors should register their types with the IANA to prevent collisions in the vendor space. c) Boy, this seems a lot more complex than what we had, or than the minimum necessary extension. Are we sure this complexity is all warranted? Thanks. --jhawk 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 LAA05744 for ; Sat, 6 Jan 2001 11:37:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADE1D5DDF7; Sat, 6 Jan 2001 11:37:27 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9D4B15DDDB; Sat, 6 Jan 2001 11:37:27 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id CFDAB5DDBC for ; Sat, 6 Jan 2001 11:37:25 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id JAA22028 for ; Sat, 6 Jan 2001 09:36:16 -0700 Message-Id: <200101061636.JAA22028@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: BGP Route Oscillation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Jan 2001 09:36:16 -0700 Sender: owner-idr@merit.edu Precedence: bulk I'd like to ask that the IDR WG accept this draft as a WG item and encourage solutions proposals. Thanks! -danny - ------- Forwarded Message To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcpherson-bgp-route-oscillation-00.txt Date: Thu, 04 Jan 2001 07:26:57 -0500 - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Persistent Route Oscillation Condition Author(s) : D. McPherson, V. Gill, D. Walton, A. Retana Filename : draft-mcpherson-bgp-route-oscillation-00.txt Pages : 18 Date : 03-Jan-01 The Border Gateway Protocol (BGP) [1] is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mcpherson-bgp-route-oscillation-00.tx t Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcpherson-bgp-route-oscillation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mcpherson-bgp-route-oscillation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010103133616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcpherson-bgp-route-oscillation-00.txt - - --OtherAccess Content-Type: Message/External-body; name="draft-mcpherson-bgp-route-oscillation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" - - --OtherAccess-- - - --NextPart-- - ------- 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 EAA01749 for ; Sat, 6 Jan 2001 04:58:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FD815DD8C; Sat, 6 Jan 2001 04:58:06 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 80AE35DDB7; Sat, 6 Jan 2001 04:58:06 -0500 (EST) Received: from outtolunch.merit.edu (outtolunch.merit.edu [198.108.60.177]) by segue.merit.edu (Postfix) with ESMTP id 6E9DA5DD8C for ; Sat, 6 Jan 2001 04:58:05 -0500 (EST) Date: Sat, 6 Jan 2001 04:58:05 -0500 (EST) From: Abha Ahuja Reply-To: abha ahuja To: idr@merit.edu Subject: Posting to the IDR list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Hey All! Just an FYI... I'm not sure if an announcement ever went out to the list, but we set this up similar to the NANOG list... In order to post to idr, you need to be subscribed to the idr-post list. When this change was made, we automatically subscribed the idr list that was current at the time. If you have problems posting (and are a recent subscriber), you should double check that you are subscribed to idr-post. Thanks! -abha ;) 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 RAA24990 for ; Fri, 5 Jan 2001 17:56:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF09D5DE18; Fri, 5 Jan 2001 17:56:12 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DFB245DE26; Fri, 5 Jan 2001 17:56:12 -0500 (EST) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 370965DE18 for ; Fri, 5 Jan 2001 17:56:11 -0500 (EST) Received: from tenornetworks.com (kavi [192.168.0.173]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f05MtYF01912; Fri, 5 Jan 2001 17:55:35 -0500 (EST) Message-ID: <3A565010.F20A80EA@tenornetworks.com> Date: Fri, 05 Jan 2001 17:52:00 -0500 From: Xavier Briard Organization: Tenor Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jaihari Loganathan Cc: "'Alvaro Retana'" , "'idr@merit.edu'" Subject: Re: well-known communities References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yes, Jaihari this is more what I meant. As an example node C originally advertises N to node B in the following network: A --- B --- C[N] N <- N <- B in turn advertises network N to node A. Subsequently C is configured to send N with a NO_ADVERTISE community. My question was "should B send an explicit withdraw for N to node A before STOPPING advertising it?". And the consensus seems to say "yes". Thanks Xavier Jaihari Loganathan wrote: > > This won't be replacement right? > New attribute info says don't send. > Old one advised to send. > > So no new path is sent. > Old one is withdrawn. > > -----Original Message----- > From: Alvaro Retana [mailto:aretana@cisco.com] > Sent: Friday, January 05, 2001 2:39 PM > To: Xavier Briard > Cc: idr@merit.edu > Subject: Re: well-known communities > > On Fri, 5 Jan 2001, Xavier Briard wrote: > > Xavier: > > -> RFC1997 specifies that routes received with NO_EXPORT, NO_ADVERTISE > -> or NO_EXPORT_SUBCONFED "MUST NOT be advertised" to certain peers. > -> > -> Does this also imply that a BGP speaker should send an explicit > -> Withdraw to those peers if it USED TO advertise those routes prior > -> to receiving them with such a community? > > Note that a way to withdraw a path is to send a replacement -- which is > what you're doing here by sending a new one (different attribute > information). > > So...yes, the 'old' path should be withdrawn. > > Alvaro. 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 RAA24910 for ; Fri, 5 Jan 2001 17:50:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0EC795DF35; Fri, 5 Jan 2001 17:48:38 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F24AB5DF34; Fri, 5 Jan 2001 17:48:37 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 675E55DEF5 for ; Fri, 5 Jan 2001 17:48:36 -0500 (EST) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [161.44.59.25]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA12221; Fri, 5 Jan 2001 14:48:08 -0800 (PST) Date: Fri, 5 Jan 2001 17:48:14 -0500 (EST) From: Alvaro Retana To: Jaihari Loganathan Cc: Xavier Briard , "'idr@merit.edu'" Subject: RE: well-known communities In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Fri, 5 Jan 2001, Jaihari Loganathan wrote: -> This won't be replacement right? New attribute info says don't send. -> Old one advised to send. -> -> So no new path is sent. -> Old one is withdrawn. -> -----Original Message----- -> From: Alvaro Retana [mailto:aretana@cisco.com] ... -> So...yes, the 'old' path should be withdrawn. Yes, that's what I meant. ;-) Alvaro. 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 RAA24813 for ; Fri, 5 Jan 2001 17:39:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FC225DE3D; Fri, 5 Jan 2001 17:38:48 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8E77C5DE2E; Fri, 5 Jan 2001 17:38:48 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 0E2995DE18 for ; Fri, 5 Jan 2001 17:38:47 -0500 (EST) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [161.44.59.25]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA05554; Fri, 5 Jan 2001 14:38:49 -0800 (PST) Date: Fri, 5 Jan 2001 17:38:56 -0500 (EST) From: Alvaro Retana To: Xavier Briard Cc: idr@merit.edu Subject: Re: well-known communities In-Reply-To: <3A5613E1.76944091@tenornetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Fri, 5 Jan 2001, Xavier Briard wrote: Xavier: -> RFC1997 specifies that routes received with NO_EXPORT, NO_ADVERTISE -> or NO_EXPORT_SUBCONFED "MUST NOT be advertised" to certain peers. -> -> Does this also imply that a BGP speaker should send an explicit -> Withdraw to those peers if it USED TO advertise those routes prior -> to receiving them with such a community? Note that a way to withdraw a path is to send a replacement -- which is what you're doing here by sending a new one (different attribute information). So...yes, the 'old' path should be withdrawn. Alvaro. 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 NAA21245 for ; Fri, 5 Jan 2001 13:39:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 47B715DE8E; Fri, 5 Jan 2001 13:38:52 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 324D25DE95; Fri, 5 Jan 2001 13:38:52 -0500 (EST) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 6C44A5DE8E for ; Fri, 5 Jan 2001 13:38:49 -0500 (EST) Received: from tenornetworks.com (kavi [192.168.0.173]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f05IclF15708 for ; Fri, 5 Jan 2001 13:38:47 -0500 (EST) Message-ID: <3A5613E1.76944091@tenornetworks.com> Date: Fri, 05 Jan 2001 13:35:13 -0500 From: Xavier Briard Organization: Tenor Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: idr@merit.edu Subject: well-known communities Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk RFC1997 specifies that routes received with NO_EXPORT, NO_ADVERTISE or NO_EXPORT_SUBCONFED "MUST NOT be advertised" to certain peers. Does this also imply that a BGP speaker should send an explicit Withdraw to those peers if it USED TO advertise those routes prior to receiving them with such a community? Is this a correct/common interpretation? Thanks in advance, Xavier -- Xavier Briard Tenor Networks 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 LAA08398 for ; Thu, 4 Jan 2001 11:25:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C18C5DE72; Thu, 4 Jan 2001 11:25:18 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2B0B75DE68; Thu, 4 Jan 2001 11:25:18 -0500 (EST) Received: from mailrelay00.ny.ops.us.uu.net (mailrelay00.ny.ops.us.uu.net [147.225.48.15]) by segue.merit.edu (Postfix) with ESMTP id A82585DE19 for ; Thu, 4 Jan 2001 11:25:16 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mailrelay00.ny.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id QAA05674 for ; Thu, 4 Jan 2001 16:25:15 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA11678; Thu, 4 Jan 2001 08:24:53 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA09012; Thu, 4 Jan 2001 11:24:42 -0500 (EST) Message-Id: <200101041624.LAA09012@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: "Rijsman, Bruno" Cc: "'Robert Raszuk'" , Yakov Rekhter , "'mpls@UU.NET'" , "BGP exploder (E-mail)" , "IDRP exploder (E-mail)" Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question In-reply-to: Your message of Sun, 31 Dec 2000 10:49:15 -0500. <49FF5C6DDBD8D311BBBD009027DE980CC11D8A@uniwest1.redstonecom.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 04 Jan 2001 11:24:42 -0500 From: Eric Rosen Sender: owner-idr@merit.edu Precedence: bulk Right now the draft says: The Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). The following high-order three bits must be zero. The remaining 20 bits contain the label value. Barring objection, I will change this to: The Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order 20 bits contain the label value, the following three bits must be zero, and the low order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). and reissue the draft. 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 KAA23510 for ; Mon, 1 Jan 2001 10:00:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6556E5DDFB; Mon, 1 Jan 2001 09:59:48 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 48C995DE1D; Mon, 1 Jan 2001 09:59:48 -0500 (EST) Received: from rubellite.lion-access.net (rubellite.lion-access.net [212.19.217.4]) by segue.merit.edu (Postfix) with ESMTP id D8D705DDFB for ; Mon, 1 Jan 2001 09:59:46 -0500 (EST) Received: from xtreme (1Cust8.tnt26.rtm1.nl.uu.net [213.116.146.8]) by rubellite.lion-access.net (I-Lab) with SMTP id 56A0C28B1; Mon, 1 Jan 2001 14:58:46 +0000 (GMT) From: "Joris Dobbelsteen" To: "6Bone (E-mail)" <6Bone@isi.edu>, "Enum WG (E-mail)" , "FTPEXT WG (E-mail)" , "IDR WG (E-mail)" , "IPng WG (E-mail)" , "IPTel WG (E-mail)" , "Kerberos WG (E-mail)" , "Lynx-Dev (E-mail)" , "NAT WG (E-mail)" , "OSPF WG (E-mail)" , "WebDAV WG (E-mail)" , "WREC WG (E-mail)" , "WWW WG (E-mail)" Subject: Happy new year Date: Mon, 1 Jan 2001 16:01:04 +0100 Message-ID: <000701c07403$aa00d8c0$01ff1fac@Joris2K.local> 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 CWS, 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 To all WGs I'm subscribed to, nobody does it, so I'll just send it: Happy new year and a good start of the new millennium Hope I can say this for all members of the WGs... - Joris