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.
>>
>>
>>
>
>