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.
BertBest 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.
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
