Subject: [sidr] adopt a mib

From: Randy Bush <[email-masked]>
Date: Fri, 05 Aug 2011 08:17:59 +0900

i would request the wg adopt

    draft-ymbk-bgp-origin-validation-mib
    draft-ymbk-rpki-rtr-protocol-mib

yes, they are works in progress.  but that's what a wg is for.

fwiw, bert is hacking away.  expect fuller work in a week.

randy

---

From: Roque Gagliano <[email-masked]>
Date: Fri, 5 Aug 2011 01:38:34 +0200

I support adoption of both documents with one comment:
On "draft-ymbk-bgp-origin-validation-mib", I would not use the word "ROATable". The router does not interact with ROAs and I believe it is confusing.
In  "draft-ietf-sidr-pfx-validate-02", the same table is referred as: "pfx_validate_table".

Roque

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Aug 2011 08:47:45 +0900

> On "draft-ymbk-bgp-origin-validation-mib", I would not use the word
> "ROATable". The router does not interact with ROAs and I believe it is
> confusing. 

point taken

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 04 Aug 2011 23:09:52 -0700

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.

 > On 8/4/2011 4:17 PM, Randy Bush wrote:

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 05 Aug 2011 08:33:21 +0200

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 04 Aug 2011 23:39:20 -0700

Hi Bert,

Many thx for your comment .. I was not able to stay at the IETF till the 
SIDR session.

If that is the case the draft-ymbk-bgp-origin-validation-mib is just 
completely not ready for adoption until it contains bare minimum which 
will allow operators to use it.

It would be insane to list 1 million of valid prefixes as opposed to 
little fraction of them being in question. Whoever authored that draft 
needs to develop a bit more real network operational experience :)

Best regards,
R.

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 05 Aug 2011 09:01:26 +0200

Inline

On 8/5/11 8:39 AM, Robert Raszuk wrote:
> Hi Bert,
>
> Many thx for your comment .. I was not able to stay at the IETF till the SIDR session.
>
> If that is the case the draft-ymbk-bgp-origin-validation-mib is just completely not ready for adoption until it contains bare 
> minimum which will allow operators to use it.
>
The MIB module is not ready for WGLC, I agree on that.
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.
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.

> It would be insane to list 1 million of valid prefixes as opposed to little fractionof them being in question. Whoever authored 
> that draft needs to develop a bit more real network operational experience :)
>
I did not author it, but I am now working on it.
I am a MIB/SMI/SNMP guy. Not a router or BGP or RPKI expert.
Constructive input is helpfull

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

Bert

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 05 Aug 2011 00:17:31 -0700

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.

> these 2 MIB modules. The exact content then needs to be agreed on by the

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.

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

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

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

---

From: Sean Turner <[email-masked]>
Date: Fri, 05 Aug 2011 09:04:57 -0400

I support both too.

spt

---

From: Rob Austein <[email-masked]>
Date: Fri, 05 Aug 2011 09:52:22 -0400

>     draft-ymbk-rpki-rtr-protocol-mib

Support.

> yes, they are works in progress.  but that's what a wg is for.

Just so.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 5 Aug 2011 10:25:57 -0400

>    draft-ymbk-bgp-origin-validation-mib

Support adoption.

>    draft-ymbk-rpki-rtr-protocol-mib

Support adoption.

> yes, they are works in progress.  but that's what a wg is for.

Yes they are, and,  yes it is (although sometimes a wg feels more like a soapbox... or a pulpit...)

W

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Aug 2011 23:27:55 +0900

>> yes, they are works in progress.
> Yes they are

bert is slaving away as we type

randy

---

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 5 Aug 2011 16:39:56 +0200

>     draft-ymbk-rpki-rtr-protocol-mib

I support the adoption, as well.

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Arturo Servin <[email-masked]>
Date: Sat, 6 Aug 2011 12:42:49 -0300

Support.

	Some comments.

	Roque previously mentioned something similar, for me it's a bit confusing to talk about ROAs validity in a router. In my mind ROAs are validated somewhere else and in routers you search for the validity of a prefix which I think what is referenced here.

	Also, as Robert Raszuk mentioned I am a bit concerned that in order to get the validity of a prefix first I need to get a table with ~400k entries. I do not normally get a full table BGP via SNMP so may be my concern is unjustified by my lack of experience. May be is it just the way it is with SNMP and we need to live with it.

Cheers,
-as

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Mon, 8 Aug 2011 05:08:32 +0000

I agree that some additional indexes in the tables may be needed, to
avoid the situation described by Arturo.

regards,

Carlos

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================

---

From: Randy Bush <[email-masked]>
Date: Mon, 08 Aug 2011 14:16:26 +0900

> avoid the situation described by Arturo.

yep.  exactly what bert was doing when he left for holiday.

randy

---

From: "t.petch" <[email-masked]>
Date: Mon, 8 Aug 2011 10:11:47 +0200

----- Original Message -----
From: "Arturo Servin" <[email-masked]>
To: "sidr wg list" <[email-masked]>
Sent: Saturday, August 06, 2011 5:42 PM
>
> Support.
>
> Some comments.
>
> Roque previously mentioned something similar, for me it's a bit confusing to
talk about ROAs validity in a router. In my mind ROAs are validated somewhere
else and in routers you search for the validity of a prefix which I think what
is referenced here.
>
> Also, as Robert Raszuk mentioned I am a bit concerned that in order to get the
validity of a prefix first I need to get a table with ~400k entries. I do not
normally get a full table BGP via SNMP so may be my concern is unjustified by my
lack of experience. May be is it just the way it is with SNMP and we need to
live with it.

The way with SNMPv1, long superseded, but still around, is to get table entries
one at a time, and if the table is dynamic, this process may never end - I once
set such a retrieval going (on statistics data rather than routing) and
cancelled it three days later, still incomplete (a good way of stress testing
router control planes:-)

SNMPv2 has a smarter way of bulk data retrieval but it depends on having the
right table structure, that is it can efficiently retrieve a slice through some
of the columns.  If you have thousands of rows, most with property X and a few
with property Y, then it should work well if X/Y is an index to a column and Y
collates after X, that is what you want is at the bottom of the column (since
the retrieval works down a column and  ends at the end of the column [RFC3416]).

But you can still be sabotaged by considerations of maximum PDU so for me,
accessing large tables remains troublesome:-(

Tom Petch

---

From: Michael Baer <[email-masked]>
Date: Mon, 08 Aug 2011 11:31:47 -0700

>>>>> On Thu, 04 Aug 2011 23:39:20 -0700, Robert Raszuk <[email-masked]> said:

    Robert> Hi Bert,
    Robert> Many thx for your comment .. I was not able to stay at the IETF till
    Robert> the SIDR session.

    Robert> If that is the case the draft-ymbk-bgp-origin-validation-mib is just
    Robert> completely not ready for adoption until it contains bare minimum which
    Robert> will allow operators to use it.

    Robert> It would be insane to list 1 million of valid prefixes as opposed to
    Robert> little fraction of them being in question. Whoever authored that draft
    Robert> needs to develop a bit more real network operational experience :)

Hi Robert,

I am co-editing the MIB and was the person that originally put most of
the MIB into SMI form.  Major flaws in the original MIB design are going
to be mostly due to me.  My SNMP background is much greater than my
routing knowledge, and I'm sure it shows (not shockingly, no network
operator experience).  I expected and hoped to get feedback on what was
wrong with the MIB and how it could be improved.

I do look at WG at adoption criteria differently.  I can see your point
of view.  But I generally look on adoption as whether a document/MIB is
useful, and appropriate for a particular WG and not whether the first
version of the doc/MIB is ready, with just minor adjustment, to be coded
and used.

But regardless of WG adoption, I am curious whether you think these MIBs
would be useful to have, not in the current state, but in a closer to
ideal state?

And please give as much feedback as you can,

Thanks,
Mike

    Robert> Best regards,
    Robert> R.

    >>> to list all INVALID or NOT_FOUND BGP entries ?

    Robert> _______________________________________________
    Robert> sidr mailing list
    Robert> [email-masked]
    Robert> https://www.ietf.org/mailman/listinfo/sidr

-- 
Michael Baer
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 08 Aug 2011 22:00:03 +0200

Hello Michael,

By all means this MIB extension is useful and I do support it's adoption.

I was only suggesting to perhaps wait just a bit and adopt something 
which we do already know will be needed in this MIB to avoid next rev 
just few days after the adoption and save authors of this MIB another 
submission cycle :) But You, Bert and Randy are so ready and open to 
continue enhancing it I see no show-stopper.

Once I will see new rev (regardless if this is WG item already or not 
yet) I will take a look again and provide my comments (if any are needed 
then :).

Many thx,
R.

>>>>>> On Thu, 04 Aug 2011 23:39:20 -0700, Robert Raszuk<[email-masked]>  said:
>
>      Robert>  Hi Bert,