From idr-bounces@ietf.org Mon Dec 03 02:45:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz5yb-00020z-Vl; Mon, 03 Dec 2007 02:44:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz5ya-00020q-KG for idr@ietf.org; Mon, 03 Dec 2007 02:44:24 -0500 Received: from postfix.iai.uni-bonn.de ([131.220.8.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz5yZ-0003Fr-0V for idr@ietf.org; Mon, 03 Dec 2007 02:44:24 -0500 X-IAI-Env-From: : [81.173.185.4] Received: from [192.171.2.2] (xdsl-81-173-185-4.netcologne.de [81.173.185.4]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 5834F5C85E; Mon, 3 Dec 2007 08:44:19 +0100 (MET) (envelope-from ub@cs.uni-bonn.de) (envelope-to VARIOUS) (2) (internal use: ta=1, tu=1, te=1, am=P, au=ub) Message-ID: <4753B3CC.40903@cs.uni-bonn.de> Date: Mon, 03 Dec 2007 08:44:12 +0100 From: Uli Bornhauser User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: idr@ietf.org X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Idr] Status of the AddPath Capability X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hello Everybody, my name is Uli Bornhauser, and I am a PhD. Student at the University of Bonn, Germany. I’m working in the area of Inter Domain Routing, trying to develop new BGP routing architectures. This area of research is motivated by routing anomalies as temporal and consistent divergence, for example, that come along with iBGP scaling techniques such as iBGP Route Reflection. Obviously, there are various approaches discussed in literature to avoid these and other routing anomalies using Route Reflection. As some of you certainly know, some interesting approaches try to avoid these anomalies by advertising additional path information via a BGP session between two BGP peers (AddPath capability). Extensions to advertise several paths for a single destination through the same BGP sessions are discussed by Daniel Walton, Alvaro Retana, and Enke Chen [1] as well as Manav Bhatia, Joel M. Halpern, and Paul Jakma [2], for example. In the last months, I have considered some new approaches which can avoid various routing anomalies in general. However, to make these approaches usable in practice its seems to be necessary to exchange more path information in the AS than specified in BGPv4, as described in the Internet Drafts mentioned above. >From my point of view, an interesting question is what status these documents have? Is anyone working in this area and are there efforts at the current point in time to include these extension in BGP? The last information about this topic I found is the IETF‐65 IDR minutes [3]. What happen after that? Are there any new developments in this area in 2007? I am grateful for all comments and suggestions. Regards Uli Bornhauser -- ______________________________________________________________ Uli Bornhauser University of Bonn Institute of Computer Science IV Email: ub@cs.uni-bonn.de Roemerstr. 164 Phone: +49 (228) 73 - 4550 D - 53117 Bonn Fax: +49 (228) 73 - 4571 Germany _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Dec 04 10:42:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZu8-0007MZ-B9; Tue, 04 Dec 2007 10:41:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZu6-0007LP-A7 for idr@ietf.org; Tue, 04 Dec 2007 10:41:46 -0500 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzZu5-0003TU-PM for idr@ietf.org; Tue, 04 Dec 2007 10:41:46 -0500 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Dec 2007 07:41:43 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 07:39:11 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lB4FdBE42551 for ; Tue, 4 Dec 2007 07:39:11 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200712041539.lB4FdBE42551@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53654.1196782751.1@juniper.net> Date: Tue, 04 Dec 2007 07:39:11 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 04 Dec 2007 15:39:11.0118 (UTC) FILETIME=[D0C7FAE0:01C8368B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Idr] WG minutes X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, Attached are the WG minutes. Thanks to Scott Brim for taking the notes. Please review/comment. The deadline is Dec 18, 2007. Yakov. -------------------------------------------------------------- Notes from IDR, Monday 1740 IDR WG document status update, Sue Hares & Yakov Rekhter See slide. Still no procedures for assigning communities. Dave Ward will write a short draft. Discuss on mailing list. Discussion of whether it's okay to get a hum on link-state interdomain routing. Conclusion: Not now. BGP IPsec Tunnel Encapsulation Attribute: draft-berger-idr-encaps-ipsec-00.txt, Lou Berger, Russ White. See slides. Only comments not on slides included here. Exclude AH? Not security-reviewed yet. Necessary. SAFI is the foundation, but move it to softwires since this is not an IDR requirement. Comments: - John Scudder would like to see a version that expands on no-label and multiple-next-hop options. Lou asks for text. John agrees. - Yakov: whether to support multiple next hops to a destination? Variations on this topic has been discussed in the IDR WG before (both multiple next hops, and multiple routes to a destination). This topic is broader than encap-ipsec, and therefore has to be discussed on its own. Encap-ipsec should not provide its own way of handling this. - Rahul: re alt-address, if using 2547, different RDs provides you with what you need today. Lou: "without optimization, would need to advertise prefixes for each next-hop". So he agrees there is a mechanism. Rahul: don't need another. Yakov: don't need yet another flavor. Lou and Russ: don't care, will look at generic mechanisms and see if adequate. Lou: seems reasonable alt address should be removed from next version. - Brian Dickson: something about withdraws including next_hop. Lou: write a draft. Yakov: already was a draft. - Proposing that this be a WG doc? No, not here. Move it to softwires. DWard prefers if you wrote another version of the draft and asked to present it at softwires. Alain agrees. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Dec 04 17:56:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgfI-0003G2-Qx; Tue, 04 Dec 2007 17:54:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgfH-0003Fl-GW for idr@ietf.org; Tue, 04 Dec 2007 17:54:55 -0500 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzgfG-0003d9-58 for idr@ietf.org; Tue, 04 Dec 2007 17:54:55 -0500 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 5181253E0FC; Tue, 4 Dec 2007 17:54:53 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id d2IYDD0BqlGU; Tue, 4 Dec 2007 17:54:45 -0500 (EST) Received: from pmesker-xp.jnpr.net (natint3.juniper.net [66.129.224.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 73F6153E0EA; Tue, 4 Dec 2007 17:54:45 -0500 (EST) Message-Id: <842AFB32-BC3C-4552-AF49-314F9F45E4F9@bgp.nu> From: "John G. Scudder" To: Yakov Rekhter In-Reply-To: <200712041539.lB4FdBE42551@magenta.juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Idr] WG minutes Date: Tue, 4 Dec 2007 14:54:43 -0800 References: <200712041539.lB4FdBE42551@magenta.juniper.net> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Dec 4, 2007, at 7:39 AM, Yakov Rekhter wrote: > - John Scudder would like to see a version that expands on > no-label and multiple-next-hop options. Lou asks for text. > John agrees. I didn't agree to provide any text for the draft, which is what the above would seem to suggest. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 07 13:28:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hvO-0007I5-DF; Fri, 07 Dec 2007 13:27:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hvM-0007EK-JC for idr@ietf.org; Fri, 07 Dec 2007 13:27:44 -0500 Received: from postfix.iai.uni-bonn.de ([131.220.8.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0hvL-0008Ji-0y for idr@ietf.org; Fri, 07 Dec 2007 13:27:44 -0500 X-IAI-Env-From: : [81.173.191.221] Received: from [192.171.2.3] (xdsl-81-173-191-221.netcologne.de [81.173.191.221]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 755355C831; Fri, 7 Dec 2007 19:27:41 +0100 (MET) (envelope-from ub@cs.uni-bonn.de) (envelope-to VARIOUS) (3) (internal use: ta=1, tu=1, te=1, am=P, au=ub) Message-ID: <47599085.8050204@cs.uni-bonn.de> Date: Fri, 07 Dec 2007 19:27:17 +0100 From: Uli Bornhauser User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" Subject: Re: [Idr] Status of the AddPath Capability References: <6D26D1FE43A66F439F8109CDD4241965FFB64B@INEXC1U01.in.lucent.com> In-Reply-To: <6D26D1FE43A66F439F8109CDD4241965FFB64B@INEXC1U01.in.lucent.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: idr@ietf.org, "Horneffer, Martin" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Mantav, hi all, thank you for the information. They help me to get a better overview about the current status of the addpath capability. Mantav, while you might be right that there was a want of interest regarding addpath in the past, I think this does not match the current situation. For my studies I cooperate with Deutsche Telekom AG, who is also very interested in a support of addpath in their routers. So, interest at this point seems to be abundant. Well, you ask what I have in mind: I made some analysis regarding both full-mesh iBGP and iBGP Route Reflection to study new approaches avoiding routing anomalies. One approach requires the advertisement of additional routing information as described by the Addpath-capability. Greetings Uli Bhatia, Manav (Manav) schrieb: > > The discussion has fallen into an abeyance because of lack of provider interest for such a capability, i.e. to advertise multiple paths in BGP. And the two drafts thus stand in limbo. > > However this should not discourage you from your work. What exactly do you have in your mind? > > Cheers, > Manav > -- ______________________________________________________________ Uli Bornhauser University of Bonn Institute of Computer Science IV Email: ub@cs.uni-bonn.de Roemerstr. 164 Phone: +49 (228) 73 - 4550 D - 53117 Bonn Fax: +49 (228) 73 - 4571 Germany _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Dec 09 13:01:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1QSN-0000XC-LN; Sun, 09 Dec 2007 13:00:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1QSM-0000Tu-0z for idr@ietf.org; Sun, 09 Dec 2007 13:00:46 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1QSL-0004Kj-NQ for idr@ietf.org; Sun, 09 Dec 2007 13:00:46 -0500 Received: by py-out-1112.google.com with SMTP id d32so5881905pye for ; Sun, 09 Dec 2007 10:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=mGYYFmTIBbutZv/gIVoviSTeyjiINvjvJUBVek7+Rt4=; b=COk7emPC7Z3GmO6WZUFLTYHfLBPxtBJkfvwZlyJVy04vN95ozr07bE5t7G0rnLLb8crsgQgmm1AXbC7OyZomSMHosGJTFRG2IfSxBBd7hGk5oIHrR2ENm0S2np6CTJoHZgB+5ukCcGjs6S+4Ef2X+UBg1jtrolyjINgP8/Gd2U8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SKv/l6gBVg++kb5s1ZAkxTyH1jk0ahFEsQ/wBNzrNfEfcO+vFSjEcVwTIwR8WQDpSMEPXgN/7NTaZ90MDs0k157Vbcv0NVcUF+GWb0db/mQ0AXJIPy7UcFlSZio5COIlxycja9DBGDFxM7KlaR5RS8aur4Eu1e0ON7cruWjO/Xo= Received: by 10.142.156.2 with SMTP id d2mr21895wfe.1197223243143; Sun, 09 Dec 2007 10:00:43 -0800 (PST) Received: by 10.142.47.6 with HTTP; Sun, 9 Dec 2007 10:00:43 -0800 (PST) Message-ID: <8320074d0712091000i77a26727s6969d9e20e467d1@mail.gmail.com> Date: Sun, 9 Dec 2007 23:30:43 +0530 From: "Rohan Sen" To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Idr] Clarification requested for RFC 4271 Section 6.8 'Connection Collision Detection' X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hello, I am implementing a BGP state machine on Linux and am facing a doubt related to connection collision which seem to rise from a possibly contradicting statement in RFC 4271. Let me try to explain my understanding with 2 routers L (local BGP) and R (remote BGP). if (routerId(L) < routerId(R)) { 1. the local system closes the BGP connection that already exists (the one that is already in the OpenConfirm state) <--------- What if this is the connection initiated by the remote peer then this connection cannot be closed and accepted at the same time 2. accepts the BGP connection initiated by the remote system. } else { 3. the local system closes the newly created BGP connection (the one associated with the newly received OPEN message) <-------- What if this is the connection initiated by L then we are closing the connection opened by us even if we have higher router id 4. continues to use the existing one (the one that is already in the OpenConfirm state) } Also elsewhere in this RFC (Page 35) it states that: "Based on the value of the BGP Identifier, a convention is established for detecting which BGP connection is to be preserved when a collision occurs. The convention is to compare the BGP Identifiers of the peers involved in the collision and to retain only the connection initiated by the BGP speaker with the higher-valued BGP Identifier." This statement is again contradicting the other cases viz. case (1) and case (3). I am really confused in this regard and would really appreciate any help to understand this scenario better/correctly. -- thanks, Rohan Sen _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 10 07:18:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1had-0003Ac-Gj; Mon, 10 Dec 2007 07:18:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1hac-0003AS-Au for idr@ietf.org; Mon, 10 Dec 2007 07:18:26 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1hab-0007ai-Oz for idr@ietf.org; Mon, 10 Dec 2007 07:18:26 -0500 X-IronPort-AV: E=Sophos;i="4.23,276,1194217200"; d="scan'208";a="453591" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2007 13:18:25 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBACIPmn009940; Mon, 10 Dec 2007 13:18:25 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBACIJmm006771; Mon, 10 Dec 2007 12:18:24 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 13:18:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Clarification requested for RFC 4271 Section 6.8 'ConnectionCollision Detection' Date: Mon, 10 Dec 2007 13:18:22 +0100 Message-ID: In-Reply-To: <8320074d0712091000i77a26727s6969d9e20e467d1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Clarification requested for RFC 4271 Section 6.8 'ConnectionCollision Detection' Thread-Index: Acg6jY2cxrx5yZaiSI24zzR0PvCRGAAmBLSQ References: <8320074d0712091000i77a26727s6969d9e20e467d1@mail.gmail.com> From: "Jan Novak (janovak)" To: "Rohan Sen" , X-OriginalArrivalTime: 10 Dec 2007 12:18:23.0225 (UTC) FILETIME=[C227E690:01C83B26] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3094; t=1197289105; x=1198153105; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=janovak@cisco.com; z=From:=20=22Jan=20Novak=20(janovak)=22=20 |Subject:=20RE=3A=20[Idr]=20Clarification=20requested=20for =20RFC=204271=20Section=206.8=20'ConnectionCollision=20Detec tion' |Sender:=20; bh=q5+yrm6XSXA3mZ0A3Ip2bZvDOnNHv67SrsQ5fzedKBU=; b=qC683Pu/sjBhCW0OyNJE0VV1UHth6CTMHTnVi7+iQWaOtBstt6KJvUuVTC yefbgVpyqzuhR0finWMPXeW49qM4/hfJqWgnAJ+w1k1Yo78F3Ppl8UdTxF/t Jj2Qae6Inb; Authentication-Results: ams-dkim-1; header.From=janovak@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, I think you just miss the significance of this: If, among these connections, there is a connection to a remote BGP speaker whose BGP Identifier equals the one in the OPEN message, and this connection collides with the connection over which the OPEN message is received, then the local system performs the following collision resolution procedure: so the first connection has already been accepted since at the time when the first OPEN message was received there was no collision detected yet and only upon the receival of the second OPEN message the collision resolution procedure as specified by you below is executed - and that procedure clearly states which of the two connections will be closed. Jan The climate of Edinburgh is such that the weak succumb young .... and the strong envy them. Dr. Johnson =20 > -----Original Message----- > From: Rohan Sen [mailto:senrohan@gmail.com]=20 > Sent: 09 December 2007 18:01 > To: idr@ietf.org > Subject: [Idr] Clarification requested for RFC 4271 Section=20 > 6.8 'ConnectionCollision Detection' >=20 > Hello, >=20 >=20 > I am implementing a BGP state machine on Linux and am facing a doubt > related to connection collision which seem to rise from a possibly > contradicting statement in RFC 4271. >=20 > Let me try to explain my understanding with 2 routers L (local BGP) > and R (remote BGP). >=20 > if (routerId(L) < routerId(R)) { > 1. the local system closes the BGP connection that > already exists (the one that is already in the OpenConfirm > state) <--------- What if this is the connection initiated > by the remote peer then this connection cannot be closed and accepted > at the same time > 2. accepts the BGP connection initiated by the remote system. > } else { > 3. the local system closes the newly created BGP > connection (the one associated with the newly received OPEN > message) <-------- What if this is the connection initiated > by L then we are closing the connection opened by us even if we have > higher router id > 4. continues to use the existing one (the one that is already in the > OpenConfirm state) > } >=20 > Also elsewhere in this RFC (Page 35) it states that: > "Based on the value of the BGP Identifier, a convention is established > for detecting which BGP connection is to be preserved when a > collision occurs. The convention is to compare the BGP Identifiers > of the peers involved in the collision and to retain only the > connection initiated by the BGP speaker with the higher-valued BGP > Identifier." >=20 >=20 > This statement is again contradicting the other cases viz. case (1) > and case (3). >=20 > I am really confused in this regard and would really appreciate any > help to understand this scenario better/correctly. >=20 > --=20 > thanks, > Rohan Sen >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr >=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 17 13:41:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Kt5-0006Xw-Nh; Mon, 17 Dec 2007 13:40:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Kt4-0006Xl-NW for idr@ietf.org; Mon, 17 Dec 2007 13:40:22 -0500 Received: from corp.force10networks.com ([64.186.164.204] helo=mx.force10networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Ksx-0004ND-6l for idr@ietf.org; Mon, 17 Dec 2007 13:40:22 -0500 Received: from EXCH-CLUSTER-03.force10networks.com ([10.11.0.53]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Dec 2007 10:39:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Dec 2007 10:39:58 -0800 Message-ID: <44ED058B21DF294ABE394CABE5C1B52101303A58@EXCH-CLUSTER-03.force10networks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2 Thread-Index: AchA3Dmes3c+T6OPRCKUF/E+KVifHQ== From: "Kalpesh Zinjuwadia" To: X-OriginalArrivalTime: 17 Dec 2007 18:39:58.0490 (UTC) FILETIME=[39B057A0:01C840DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Subject: [Idr] Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0016650814==" Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============0016650814== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C840DC.39E87841" This is a multi-part message in MIME format. ------_=_NextPart_001_01C840DC.39E87841 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had a question regarding how to fill up bgpM2AsPath4byteTable table as described in BGP4 MIBv2 (draft-ietf-idr-bgp4-mibv2). If a BGP speaker supports 4-byte AS space as described in RFC 4893 and stores the AS-PATH and AGGR attributes w/ 4-byte ASN, there won't be AS4-PATH and AS4-AGGR attributes in its RIB. It'll generate these attributes, if required, while advertising update to other speakers. BGP4 MIBv2 has bgpM2AsPath4bytePathPresent entry in bgpM2AsPath4byteTable table. It's description says that it's true if a NEW speaker is functioning between 2-byte and 4-byte AS space. It further says that the AS4-PATH and AS4-AGGR are present in this NEW speaker. My question is - for implementation mentioned above, how to fill up this table as AS4-PATH and AS4-AGGR are not present and generated on need basis? Let me know if I'm missing something here... =20 Thanks, Kalpesh =20 Extract from draft-ietf-idr-bgp4-mibv2-05 . . . bgpM2AsPath4bytePathPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This value may only be true if this BGP Speaker is functioning as a router between ASs that are in 2-byte and 4-byte AS space. If this value is true, then the NEW_AS_PATH attributes are present and the 4-byte versions of the appropriate path attributes are in this row. =20 If this value is false, then the following values will be present in the row: =20 bgpM2PathAttrAggregatorAS - zero (0). bgpM2AsPathCalcLength - zero (0). bgpM2AsPathString - zero (0) length string. bgpM2AsPathIndex - zero (0)." ::=3D { bgpM2AsPath4byteEntry 1 } =20 ------_=_NextPart_001_01C840DC.39E87841 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I had a question regarding how to fill up =
bgpM2AsPath4byteTable table as described in BGP4 MIBv2 =
(draft-ietf-idr-bgp4-mibv2). If a BGP speaker supports 4-byte AS space =
as described in RFC 4893 and stores the AS-PATH and AGGR attributes w/ =
4-byte ASN, there won’t be AS4-PATH and AS4-AGGR attributes in its =
RIB. It’ll generate these attributes, if required, while =
advertising update to other speakers. BGP4 MIBv2 has =
bgpM2AsPath4bytePathPresent entry in bgpM2AsPath4byteTable table. =
It’s description says that it’s true if a NEW speaker is =
functioning between 2-byte and 4-byte AS space. It further says that the =
AS4-PATH and AS4-AGGR are present in this NEW speaker. My question is =
– for implementation mentioned above, how to fill up this table as =
AS4-PATH and AS4-AGGR are not present and generated on need basis? Let =
me know if I’m missing something =
here…
 
Thanks,
Kalpesh
 
Extract =
from =
draft-ietf-idr-bgp4-mibv2-05
. . =
.
bgpM2AsPath4bytePathPresent =
OBJECT-TYPE
        =
SYNTAX     =
TruthValue
        =
MAX-ACCESS read-only
        =
STATUS     =
current
        =
DESCRIPTION
       &nbs=
p;    "This value may only be true if this BGP =
Speaker
       &nbs=
p;     is functioning as a router between ASs =
that
       &nbs=
p;     are in 2-byte and 4-byte AS space.  If =
this
       &nbs=
p;     value is true, then the NEW_AS_PATH =
attributes
     =
;        are =
present and the 4-byte versions of =
the
       &nbs=
p;     appropriate path attributes are in this =
row.
 
       &nbs=
p;     If this value is false, then the following =
values
       &nbs=
p;     will be present in the =
row:
 
       &nbs=
p;     bgpM2PathAttrAggregatorAS - zero =
(0).
       &nbs=
p;     bgpM2AsPathCalcLength - zero =
(0).
       &nbs=
p;     bgpM2AsPathString - zero (0) length =
string.
       &nbs=
p;     bgpM2AsPathIndex - zero =
(0)."
        =
::=3D { bgpM2AsPath4byteEntry 1 =
}
 
------_=_NextPart_001_01C840DC.39E87841-- --===============0016650814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0016650814==-- From idr-bounces@ietf.org Mon Dec 17 17:26:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4OPO-0006lx-6c; Mon, 17 Dec 2007 17:25:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4OPJ-0006lL-GQ for idr@ietf.org; Mon, 17 Dec 2007 17:25:56 -0500 Received: from manos.scc.mi.org ([204.11.140.250]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4OPI-0003FC-S7 for idr@ietf.org; Mon, 17 Dec 2007 17:25:53 -0500 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 2C09A4E521; Mon, 17 Dec 2007 17:25:52 -0500 (EST) Date: Mon, 17 Dec 2007 17:25:52 -0500 From: Jeffrey Haas To: Kalpesh Zinjuwadia Subject: Re: [Idr] Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2 Message-ID: <20071217222552.GA12717@scc.mi.org> References: <44ED058B21DF294ABE394CABE5C1B52101303A58@EXCH-CLUSTER-03.force10networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44ED058B21DF294ABE394CABE5C1B52101303A58@EXCH-CLUSTER-03.force10networks.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Kalpesh, draft-ietf-idr-bgp4-mibv2-06 was issued prior to the last IETF. The major focus of that re-issue was to clean up all of the previously raised issues for the MIBv2 and also start the integration work into the previously released BGP MIB. Unless you have some internal motivation to support the old version of the mib as documented in -05, I'd consider working on -06. -06 starts with the premise that 4 byte AS numbers are directly supported. This does hide some of the internals of RFC 4893 when operating in a 2 byte / 4 byte mode. There was no solid consensus as to how much 2/4 byte detail to expose in the MIB when -05 was issued. In the context of the -06 MIB, if the details of the 2 / 4 byte mode need to be exposed, it would be via an extension MIB similar to the communities MIB documented in draft-jhaas-idr-bgp4-mibv2-community-00.txt Feedback from the IDR working group on the need for the extension MIB for the additional objects for 2/4byte interaction would be helpful. In the context of the -05 draft: On Mon, Dec 17, 2007 at 10:39:58AM -0800, Kalpesh Zinjuwadia wrote: > I had a question regarding how to fill up bgpM2AsPath4byteTable table as > described in BGP4 MIBv2 (draft-ietf-idr-bgp4-mibv2). If a BGP speaker > supports 4-byte AS space as described in RFC 4893 and stores the AS-PATH > and AGGR attributes w/ 4-byte ASN, there won't be AS4-PATH and AS4-AGGR > attributes in its RIB. It'll generate these attributes, if required, > while advertising update to other speakers. One way to consider RFC 4893 is that if you're a 4 byte capable speaker, and are participating in 4 byte peering sessions, you'll probably be storing the AS Paths natively in 4 byte format. In that particular case, the 4byte objects would have been absent. That detail wasn't clear in the -05 draft. In the case of a 2-byte only speaker that implemented this MIB, or a 4-byte capable speaker operating in 2-byte-only mode, the internal versions of the ASes would be in 2 byte format and the additional path attributes would be stored. After receiving a little feedback after -05 was issued, this seemed to not be how people would be implementing this portion of the MIB. If the BGP speaker was 2-byte-only, then it would likely treat the 4-byte attributes as "unknown" and it would show up in the table for unknown path attributes. > BGP4 MIBv2 has > bgpM2AsPath4bytePathPresent entry in bgpM2AsPath4byteTable table. It's > description says that it's true if a NEW speaker is functioning between > 2-byte and 4-byte AS space. It further says that the AS4-PATH and > AS4-AGGR are present in this NEW speaker. My question is - for > implementation mentioned above, how to fill up this table as AS4-PATH > and AS4-AGGR are not present and generated on need basis? Let me know if > I'm missing something here... You haven't missed anything here. In essence, there are 3 potential things to display in a MIB that could represent a 2-byte/4-byte interaction: 1. What is being used internally. 2. Received 2-byte managed objects 3. Received 4-byte managed objects as NEW_ Path attributes. Given that a common criticism of the BGP MIB is that is too unwieldy to start with, the -06 version of the MIB simply chooses #1. While #2 and #3 could be represented in an extension MIB, the primary benefit would seem to be for debugging 2byte/4byte interaction issues. MIBs seem to be a particularly poor way to do this. My personal inclination would be to not include such a table as part of the IETF standards, however I will yield to the consensus of the WG should we wish one. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Dec 18 11:49:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fW9-0007MK-Ei; Tue, 18 Dec 2007 11:42:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fW7-0007Lo-Ml for idr@ietf.org; Tue, 18 Dec 2007 11:42:03 -0500 Received: from mk-outboundfilter-1.mail.uk.tiscali.com ([212.74.114.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4fVy-0003hX-9F for idr@ietf.org; Tue, 18 Dec 2007 11:42:03 -0500 X-Trace: 2640230/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.31 X-SBRS: None X-RemoteIP: 62.241.162.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHWGZ0c+8aIf/2dsb2JhbACqLg X-IronPort-AV: E=Sophos;i="4.24,180,1196640000"; d="scan'208";a="2640230" Received: from galaxy.systems.pipex.net ([62.241.162.31]) by smtp.pipex.tiscali.co.uk with ESMTP; 18 Dec 2007 16:41:28 +0000 Received: from pc6 (1Cust103.tnt6.lnd4.gbr.da.uu.net [62.188.135.103]) by galaxy.systems.pipex.net (Postfix) with SMTP id 59B93E00008E; Tue, 18 Dec 2007 16:41:26 +0000 (GMT) Message-ID: <012001c8418c$52f3dec0$0601a8c0@pc6> From: "tom.petch" To: "Jeffrey Haas" References: <44ED058B21DF294ABE394CABE5C1B52101303A58@EXCH-CLUSTER-03.force10networks.com> <20071217222552.GA12717@scc.mi.org> Subject: Re: [Idr] Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2 Date: Tue, 18 Dec 2007 16:39:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Jeff Camping onto a related topic .... Geoff Huston has picked up and developped the draft-michaelson-4byte-as-representation I-D that was last called here a year ago, and this now says that the representation MUST be asdot ie a decimal number below 65536, or x.y when it would be above 65535. This is gaining some traction in RIPE. If and when a standard is adopted, then I think that there should be a TC in this MIB with an appropriate DISPLAY-HINT (I cannot recall seeing anything like it anywhere). Tom Petch ----- Original Message ----- From: "Jeffrey Haas" To: "Kalpesh Zinjuwadia" Cc: Sent: Monday, December 17, 2007 11:25 PM Subject: Re: [Idr] Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2 > Kalpesh, > > draft-ietf-idr-bgp4-mibv2-06 was issued prior to the last IETF. The > major focus of that re-issue was to clean up all of the previously > raised issues for the MIBv2 and also start the integration work into the > previously released BGP MIB. Unless you have some internal motivation > to support the old version of the mib as documented in -05, I'd consider > working on -06. > > -06 starts with the premise that 4 byte AS numbers are directly > supported. This does hide some of the internals of RFC 4893 when > operating in a 2 byte / 4 byte mode. There was no solid consensus as to > how much 2/4 byte detail to expose in the MIB when -05 was issued. > > In the context of the -06 MIB, if the details of the 2 / 4 byte mode > need to be exposed, it would be via an extension MIB similar to the > communities MIB documented in draft-jhaas-idr-bgp4-mibv2-community-00.txt > > Feedback from the IDR working group on the need for the extension MIB > for the additional objects for 2/4byte interaction would be helpful. > > In the context of the -05 draft: > > On Mon, Dec 17, 2007 at 10:39:58AM -0800, Kalpesh Zinjuwadia wrote: > > I had a question regarding how to fill up bgpM2AsPath4byteTable table as > > described in BGP4 MIBv2 (draft-ietf-idr-bgp4-mibv2). If a BGP speaker > > supports 4-byte AS space as described in RFC 4893 and stores the AS-PATH > > and AGGR attributes w/ 4-byte ASN, there won't be AS4-PATH and AS4-AGGR > > attributes in its RIB. It'll generate these attributes, if required, > > while advertising update to other speakers. > > One way to consider RFC 4893 is that if you're a 4 byte capable speaker, > and are participating in 4 byte peering sessions, you'll probably be > storing the AS Paths natively in 4 byte format. In that particular > case, the 4byte objects would have been absent. That detail wasn't > clear in the -05 draft. > > In the case of a 2-byte only speaker that implemented this MIB, or a > 4-byte capable speaker operating in 2-byte-only mode, the internal > versions of the ASes would be in 2 byte format and the additional path > attributes would be stored. > > After receiving a little feedback after -05 was issued, this seemed to > not be how people would be implementing this portion of the MIB. If the > BGP speaker was 2-byte-only, then it would likely treat the 4-byte > attributes as "unknown" and it would show up in the table for unknown > path attributes. > > > BGP4 MIBv2 has > > bgpM2AsPath4bytePathPresent entry in bgpM2AsPath4byteTable table. It's > > description says that it's true if a NEW speaker is functioning between > > 2-byte and 4-byte AS space. It further says that the AS4-PATH and > > AS4-AGGR are present in this NEW speaker. My question is - for > > implementation mentioned above, how to fill up this table as AS4-PATH > > and AS4-AGGR are not present and generated on need basis? Let me know if > > I'm missing something here... > > You haven't missed anything here. In essence, there are 3 potential > things to display in a MIB that could represent a 2-byte/4-byte > interaction: > > 1. What is being used internally. > 2. Received 2-byte managed objects > 3. Received 4-byte managed objects as NEW_ Path attributes. > > Given that a common criticism of the BGP MIB is that is too unwieldy to > start with, the -06 version of the MIB simply chooses #1. While #2 and > #3 could be represented in an extension MIB, the primary benefit would > seem to be for debugging 2byte/4byte interaction issues. MIBs seem to > be a particularly poor way to do this. > > My personal inclination would be to not include such a table as part of > the IETF standards, however I will yield to the consensus of the WG > should we wish one. > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Dec 18 14:32:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iAd-0004x8-Cp; Tue, 18 Dec 2007 14:32:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iAb-0004pY-7q for idr@ietf.org; Tue, 18 Dec 2007 14:32:01 -0500 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4iAa-0000nc-Sp for idr@ietf.org; Tue, 18 Dec 2007 14:32:01 -0500 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 427F84E4A6; Tue, 18 Dec 2007 14:32:00 -0500 (EST) Date: Tue, 18 Dec 2007 14:32:00 -0500 From: Jeffrey Haas To: "tom.petch" Subject: Re: [Idr] Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2 Message-ID: <20071218193200.GA9530@scc.mi.org> References: <44ED058B21DF294ABE394CABE5C1B52101303A58@EXCH-CLUSTER-03.force10networks.com> <20071217222552.GA12717@scc.mi.org> <012001c8418c$52f3dec0$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012001c8418c$52f3dec0$0601a8c0@pc6> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Tom, On Tue, Dec 18, 2007 at 04:39:16PM +0100, tom.petch wrote: > Geoff Huston has picked up and developped the > draft-michaelson-4byte-as-representation > I-D that was last called here a year ago, and this now says that the > representation MUST be asdot ie a decimal number below 65536, or x.y when it > would be above 65535. This is gaining some traction in RIPE. If and when a > standard is adopted, then I think that there should be a TC in this MIB with an > appropriate DISPLAY-HINT (I cannot recall seeing anything like it anywhere). This MIB makes use of InetAutonomousSystemNumber from INET-ADDRESS-MIB. I'd like to say "when that MIB is updated, all will be well". However, the mapping of a DISPLAY-HINT for INTEGER dervied object types won't do "the Right Thing". DISPLAY-HINTs for INTEGER, by their nature, can't do math. There is a strong push to make use of the textual conventions defined in the INET-ADDRESS-MIB when possible. If the goal is to make use of the display representation in that draft, the wider SNMP community has a problem, not just the BGP MIBv2. I would strongly suggest that this issue be raised to the OPS group directly. I believe any changes to the BGP MIBv2 will fall out from there. A weak hack would be to partition an AS Number into a "top half" and a "bottom half" and leave the DISPLAY-HINT to be "d". However, that won't give you your dotted notation, it'll simply give you two objects. From a MIB perspective, that's not a problem since the AS numbers are not part of an INDEX. I think it's a poor solution. I'd rather punt this issue to the OPS group. :-) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr