Re: [sidr] adopt a mib
Robert Raszuk <raszuk@cisco.com> Fri, 05 August 2011 07:17 UTC
Return-Path: <raszuk@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA6B11E8091 for <sidr@ietfa.amsl.com>; Fri, 5 Aug 2011 00:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.216
X-Spam-Level:
X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSg7FWCPP6nV for <sidr@ietfa.amsl.com>; Fri, 5 Aug 2011 00:17:16 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F247A5E8007 for <sidr@ietf.org>; Fri, 5 Aug 2011 00:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=3683; q=dns/txt; s=iport; t=1312528653; x=1313738253; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4RdJygEhmiAd5c62diSHrlEDjhSt1dl73DZ3rdNu85U=; b=ECHYcUkfpDYaxWMPk/pHV7TkAgF3heK0URr/gCJjn+mddePb2qBJn6Tr 0TZSaDKyK5vfyTgKHHA72cpRNA3lS2DWgeVhkwpw3Bu2XRc3UhFjxAwj1 s0NOXRa1rM1yvKpTlTLzVOeOmz1zr9nKiULC7WgMgXyGbSwsYhL7FcUvR M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANqXO06rRDoI/2dsb2JhbABDp253gUABAQEBAgESAQIBIjMNAQULCxgJFg8JAwIBAgFFBg0BBwEBHodLoj8BgxwPAZtLhkYEh1uLJIUIi38
X-IronPort-AV: E=Sophos;i="4.67,321,1309737600"; d="scan'208";a="9940339"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 05 Aug 2011 07:17:30 +0000
Received: from [10.21.108.128] ([10.21.108.128]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p757HTbo015421; Fri, 5 Aug 2011 07:17:29 GMT
Message-ID: <4E3B990B.1060409@cisco.com>
Date: Fri, 05 Aug 2011 00:17:31 -0700
From: Robert Raszuk <raszuk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "Bert (IETF) Wijnen" <bertietf@bwijnen.net>
References: <m2d3gkepg8.wl%randy@psg.com> <4E3B8930.9090605@cisco.com> <4E3B8EB1.7030007@bwijnen.net> <4E3B9018.80808@cisco.com> <4E3B9546.4000808@bwijnen.net>
In-Reply-To: <4E3B9546.4000808@bwijnen.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] adopt a mib
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2011 07:17:16 -0000
Hi Bert,
> The MIB module is not ready for WGLC, I agree on that.
Nothing personal to you Bert and I highly value your work and as we met
few times it is just awesome.
But when I write a draft I do try hard to make it useful. Then WG
adoption to will make it fine-tuned to be perfect and be able to
accommodate various additional little points which I may not have
thought about.
> In my feel, the adoption question is more of: Does the WG want to work on
> these 2 MIB modules. The exact content then needs to be agreed on by the
> WG.
The answer is yes - however WG IMHO should adopt a sculpture to polish
rather then piece of wood.
Let's try to maintain some level of value in this or any other WG.
> If you want to see another individual draft with better content first..
> I have no problem with that, up to the chair to decide I think.
My personal opinion is that the bear minimum is to see a draft which
allows to query for all states. Then we can accept this as WG item and
work on polishing it with sand paper.
> I did not author it, but I am now working on it.
I am glad you are as I know you and you are very experienced person.
> I am a MIB/SMI/SNMP guy. Not a router or BGP or RPKI expert.
> Constructive input is helpfull
Just trying to provide some input to you :) And I am just complete
mirror .. I (unfortunately :) had to spend months on developing SNMP
scripts when I was an operator, but now all I care about is to make sure
what we define for the router to do is at least minimally useful.
> The table (as in the current I-D) has this attribute:
> bgpVRTValid OBJECT-TYPE
> SYNTAX INTEGER { unknown(1), valid(2), invalid(3) }
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "This is indicates if the state of the roa associated with
> this row."
> DEFVAL { unknown }
> ::= { bgpValROATableEntry 5 }
>
> So my answer to your comments:
> - listing the status (unknown, valid or invalid) will only result in
> MORE entries than just listing the valid ones.
We do need few more attributes to be able to explicitly ask for all
validation criteria. Doing those is just really minor work.
> - My understanding is/was that the table might have some 300K entries
> But that is from hearsay.
> Anyways, that is still a lot, I Understand that. And therefor, proper
> indexing is important. I need to know what sort of queries operators
> are most likely to do on this table.
> If you (with lots of operator experience I assume) or others can help
> me with that, that would be great.
The minimum passing grade for me would be to have ability to query for
all results of origin validation state check.
However if we really would like to help NOC eng we should also provide
new class of attributes on what communities the routes after being
examined and been colored were advertised to IBGP peers.
I personally see no need for more to get to WG adoption phase.
Best regards and many thx for your reply Bert,
Robert.
>
> Bert
>
>> Best regards,
>> R.
>>
>>> During the discussion at the SIDR WG session at IETF81 we
>>> found that the bgpVRTValid attribute in that table makes no
>>> sense, because we do not have that info. These are ALL
>>> validated ROAs (or better validated prefixes) as I understand
>>> it.
>>>
>>> Bert
>>> On 8/5/11 8:09 AM, Robert Raszuk wrote:
>>>> Hi,
>>>>
>>>> Just looking at draft-ymbk-bgp-origin-validation-mib may I ask what
>>>> would be the root OID string to start SNMP tree walk (or set the trap)
>>>> to list all INVALID or NOT_FOUND BGP entries ?
>>>>
>>>> Rgs,
>>>> R.
>>
>>
>>
>
>
- Re: [sidr] adopt a mib Bert (IETF) Wijnen
- [sidr] adopt a mib Randy Bush
- Re: [sidr] adopt a mib Roque Gagliano
- Re: [sidr] adopt a mib Randy Bush
- Re: [sidr] adopt a mib Robert Raszuk
- Re: [sidr] adopt a mib Robert Raszuk
- Re: [sidr] adopt a mib Bert (IETF) Wijnen
- Re: [sidr] adopt a mib Robert Raszuk
- Re: [sidr] adopt a mib Sean Turner
- Re: [sidr] adopt a mib Rob Austein
- Re: [sidr] adopt a mib Warren Kumari
- Re: [sidr] adopt a mib Randy Bush
- Re: [sidr] adopt a mib Matthias Waehlisch
- Re: [sidr] adopt a mib Arturo Servin
- Re: [sidr] adopt a mib Carlos Martinez-Cagnazzo
- Re: [sidr] adopt a mib Randy Bush
- Re: [sidr] adopt a mib t.petch
- Re: [sidr] adopt a mib Michael Baer
- Re: [sidr] adopt a mib Robert Raszuk