From idr-bounces@ietf.org Thu Apr 26 20:32:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhEO6-0008Um-HH; Thu, 26 Apr 2007 20:32:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhEO5-0008Ue-Lj for idr@ietf.org; Thu, 26 Apr 2007 20:32:37 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhEO4-00023w-Fs for idr@ietf.org; Thu, 26 Apr 2007 20:32:37 -0400 Received: by an-out-0708.google.com with SMTP id d30so461581and for ; Thu, 26 Apr 2007 17:32:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=GghCXtpwOoo1vXgckFYgEIbWB/m+T84NU0seVf4e3iswOsg38RbBfaRLZYNP+fxdipcx/J3zL+JFELuD2RQ04iOM7lglBJIkBCv6tNpdAkyPF23j6moPvo601op16/o1Dpcc7PFFuqxK/mvYkHsWPu7SnvsErc/PemHSEeWThpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=thg+hMgf5P3vZsZHAg180bPOtB8rDqdV47QzSU+xq6U2egghq42r7SZD6gp9saiP1JPuWs64tGDhh3rS7T5KV+u8QqVAvdhwdNDl9ZUnMGcRIlJfuK7trXS5P4roDzhdk+QhU9lwmgM5vr01Gk/o+iMqYoljeu6L0e7iC/N2oQM= Received: by 10.100.178.7 with SMTP id a7mr1595973anf.1177633956140; Thu, 26 Apr 2007 17:32:36 -0700 (PDT) Received: by 10.100.119.17 with HTTP; Thu, 26 Apr 2007 17:32:36 -0700 (PDT) Message-ID: <1a2367b80704261732p4eee7806sd32c1a13d965b774@mail.gmail.com> Date: Thu, 26 Apr 2007 17:32:36 -0700 From: "Gaurav Shrivastava" To: idr@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Idr] 6PE: Open capability negiotiation 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="===============0685739873==" Errors-To: idr-bounces@ietf.org --===============0685739873== Content-Type: multipart/alternative; boundary="----=_Part_246320_30449154.1177633956079" ------=_Part_246320_30449154.1177633956079 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Why do we need to negotiate both "IPv6 unicast 2/1" and "IPv6+label 2/4" capabilities when 6PE is enabled with a neighbor? We can only format updates with only one afi/safi pair and not both. Thanks, -- ./gaurav.. ------=_Part_246320_30449154.1177633956079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

Why do we need to negotiate both "IPv6 unicast 2/1"  and "IPv6+label 2/4" capabilities when  6PE is enabled with
a neighbor? We can only format updates with only one afi/safi pair and not both.

Thanks,
--
./gaurav..
------=_Part_246320_30449154.1177633956079-- --===============0685739873== 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 --===============0685739873==-- From idr-bounces@ietf.org Sat Apr 28 07:25:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhl22-0005n8-7C; Sat, 28 Apr 2007 07:24:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhl21-0005n0-38 for idr@ietf.org; Sat, 28 Apr 2007 07:24:01 -0400 Received: from diotima.switch.ch ([2001:620:0:4:203:baff:fe4c:d751]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhl20-00055v-Cb for idr@ietf.org; Sat, 28 Apr 2007 07:24:01 -0400 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.0+Sun/8.14.0) with ESMTP id l3SBNwpE017413; Sat, 28 Apr 2007 13:23:58 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.14.0+Sun/8.14.0/Submit) id l3SBNvGD017412; Sat, 28 Apr 2007 13:23:57 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon@limmat.switch.ch using -f From: Simon Leinen To: "Susan Hares" Subject: Re: [Idr] BGP MIBv2 implementations In-Reply-To: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F9BBE7@VS4.EXCHPROD.USA.NET> (Susan Hares's message of "Thu, 22 Mar 2007 06:40:27 -0600") References: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F9BBE7@VS4.EXCHPROD.USA.NET> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Sat, 28 Apr 2007 13:23:56 +0200 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.96 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.8 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 More than a month ago, Susan Hares wrote: > If anyone has implemented any portion of the BGP MIBv2, would you please > send mail to the mail list [It's a pity that no vendors responded, because obviously parts of BGP MIB v2 have been implemented. So this is just another response from an operator. Sorry for the late response.] > Indicating: > 1) What you've implemented Our vendor has recently (for our platform) implemented a vendor-specific BGP4 MIB that implements certain aspects of bgp4-mibv2. In particular, this -BGP4-MIB.my implements peer-specific and peer/AFI/SAFI-specific counters/gauges of accepted/denied etc. prefixes. What the vendor did not do is support non-IPv4 addresses in the index part of these tables. While the agent tries to represent IPv6 peerings in some of them, this fails because it tries to index the peerings with the first 32 bits of the peer's IPv6 address. While this happens to disambiguate eBGP peerings in the case that all peer addresses are from the peer ISP's address space, it collapses many peerings into one entry for the common cases of (a) multiple peers at an exchange point and (b) iBGP peerings, where the peer addresses are all from our own /32. This is what the vendor implemented; we recently (because the software for our platform only got this feature few months ago) implemented periodic polling and graphing of "accepted prefixes per peer" statistics. Although this variable is marked as a "Counter32" in the vendor MIB, in reality it seems to be a Gauge32, just like bgpM2PrefixInPrefixesAccepted and bgpM2PrefixInPrefixesAccepted in bgp4-mibv2. > 2) What's useful. Plotting the number of accepted prefixes from a peer is useful for us because of the following: * Long-term, we can get a (very rough) idea of how a peering evolves. This is useful e.g. to adapt prefix-limits, or as a first indication that a peering may have outlived its usefulness. * Short-term, we can get a quick idea of the effects of filter updates. One nice thing our vendor does is that it makes prefix limits ("max-prefixes") readily available in the MIB. I looked at using "rejected prefixes" counters as well, but couldn't find a useful application. Those seem to be REAL counters, i.e. I could only plot rates, not absolute numbers. And I'm not interested in the rate of rejection, only in the (temporal evolution of) the number of prefixes that we reject from a given peer (in a given address family). Such a variable seems to be missing from both the vendor's MIB and the bgp4-mibv2 proposal. Implementing it would probably require something similar to "soft-reconfig inbound", but it would certainly be useful where this is done anyway. -- Simon. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr