Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10

From: Randy Presuhn <[email-masked]>
Date: Tue, 16 Jul 2013 21:30:21 -0700 (GMT-07:00)

Hi -

>From: Steve Waldbusser <[email-masked]>
>Sent: Jul 16, 2013 6:02 PM
>To: [email-masked], "Giles Heron (giheron)" <[email-masked]>, "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <[email-masked]>, [email-masked]
>Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10
...
>1. There are three tables that have a many-to-one relationship with the 
>vplsConfigTable AND that
>    allow SNMP create operations. A potential ambiguity exists in the 
>creation process for these
>    tables. For example one could create entries in the vplsPwBindTable 
>that reference VPLS entries
>    that don't yet exist: IOW one could create 
>vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A
>    in the vplsConfigTable. It is perfectly alright for the inactive 
>rows in the vplsPWBindTable to
>    have unresolved dangling references to VPLS-A as long as VPLS-A is 
>created before the PWBind
>    Entry is set to active. On the other hand, it has been my experience 
>that agent writers will not
>    allow that mode of operation (i.e. will not allow creation of the 
>dangling references) unless the MIB
>    explicitly mandates it and I think such a mandate may be more 
>trouble than it's worth. Therefore,
>    to protect an NMS writer from ordering their create operations that 
>way and not interoperating,
>    I'd suggest explicitly saying that it is optional for the agent to 
>allow entries to be created
>    that point to non-existent VPLSConfig entries. The most 
>straightforward path is for the NMS to create the
>    VPLSConfig entry and then the vplsPWBind entries.

My own experience is that it is more robust (both from the
perspective of building management applications and from
the instrumentation / agent side of things) to permit
references to nonexistent rows, as long as what a reference
to a nonexistent row *means* is explicit.  Here are a few
reasons why permitting "dangling" references (as long as
the semantic is well-defined) is a better approach, in my
opinion:

   1) It simplifies provisioning.  Management applications
      don't need special knowledge about the order of creating
      table entries.  Also consider how having such constraints
      would complicate, for example, a Netconf interface to
      the same management information.

   2) It simplifies tear-down.  Management applications don't
      need to know about magical side-effects of deleting a row.

   3) It actually simplifies create-time and activation-time
      cross-checks within the (sub)agent.

   4) It simplifies delete-time cross-checks within the (sub)agent.

   5) It avoids access-control head-scratchers about whether a
      side-effect in conflict with access control policy should
      be allowed to take place.

In my opinion, having optional side-effects would be even
more problematic than mandated side effects.  It forces
management applications to deal with ordering constraints,
but still probe to see whether the side effects happened,
and if not, to issue additional operations.  Permitting
"dangling" references removes all the convoluted conditional
logic and ordering constraints, both for creation and deletion.
It's a win for the manager code, and a win for the (sub)agent code.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jul 2013 06:36:22 -0700

Hi,

>From the POV of an agent developer this is one of the fundamental
flaws in SNMP -- natural data structures are not possible.
IMO, the "unfolded" tables make agent implementation a nightmare.
SNMP allows an arbitrary number of arbitrarily incomplete "rows"
to be passed in each request.  Since there are absolutely no
high level procedures specified, the agent must support any
possible creation order sequence.

As I pointed out back when XMLCONF was started, this "gumball machine"
is not how CLI works -- this is not what operators asked for.

During the development of APM and TPM I realized we
had reached the upper bound of SMIv2 complexity, and nobody
would ever implement those MIB modules.  Not because we
didn't need Application Performance Monitoring, but because
SNMP/SMI was incapable of dealing with this level of complexity
in a way that would permit engineering managers to approve
agent development projects.

It is better for the NMS if every agent supports every possible creation order
for every data structure.  It is easy to say an agent MUST support any order.
Reality doesn't follow RFC 2119 though, and agent developers end up
putting lots of undocumented restrictions in their code.  NMS developers
are forced to play detective and figure out what each agent implementation
will actually accept.

So even though Steve's suggestion is more restrictive, IMO it might actually
help the NMS developer if the bar is set a little lower on the agent.

Andy

On Tue, Jul 16, 2013 at 9:30 PM, Randy Presuhn
<[email-masked]> wrote:
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 17 Jul 2013 06:52:11 -0700

I totally agree with Andy. One option is to simply forget about provisioning with this MIB altogether - which the industry really has, but the IETF seems to still have pockets of folks that think otherwise. Its my experience that with one exception of a popular vendor's proprietary NMS/EMS, no one is using read-write in production. I often wonder why do we still go through the "gumball machine" pain when perfectly good tools like NetConf/Mod exist?  Other WGs such as MPLS have agreed to simply skip mandating read-create/write objects, so there is plenty of precedent too.

	--Tom

---

From: "Giles Heron (giheron)" <[email-masked]>
Date: Wed, 17 Jul 2013 13:57:03 +0000

If it's an easy-ish fix I'd be up for that if it provides a way forward.  I've never been a fan of read/write SNMP MIBs :)

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 17 Jul 2013 07:09:15 -0700

Its fairly straight-forward to remove the read-write verbage.  I'd be up for it, but you probably need to ask the WG to avoid some lengthly additional LC.

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jul 2013 07:18:30 -0700

Hi,

I was not suggesting remove r/w.
I am agreeing with Steve's suggestion, which I think is:
   - agent MUST support creation without dangling references
   - agent MAY support creation with dangling references

Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 17 Jul 2013 14:24:53 +0000

but a simpler solution is to just remove read-write, no?

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jul 2013 07:34:23 -0700

Hi,

I am assuming the WG knows the objects are r/c and that's what they want.
IMO, a MIB Doctor's job is to help the WG achieve what they want,
not tell them what I want.

Andy

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 17 Jul 2013 07:52:48 -0700

I know. not sure r-w was discussed.

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 18 Jul 2013 13:18:03 -0700

>     - agent MAY support creation with dangling references

Yes, that was my suggestion.

> but a simpler solution is to just remove read-write, no?
It would probably take as much time to remove the read-write semantics 
from the MIB as it would to fix them (give or take an hour or two). And 
either requires WG review. Based on the principle of least astonishment, 
proceeding with the fixes has the lowest risk of generating a protracted 
WG discussion.

You've done a great job and you're 95% done, I'd suggest sticking with it.

On 7/17/2013 1:44 PM, Randy Presuhn wrote:
> My point is that from an implementation perspective (both manager and 
> agent) "creation in any order" (if dangling reference semantics are 
> properly specified) is probably the *simplest* for developers to get 
> right. It's the easiest to reason about, the easiest to test, easiest 
> for managers, and easiest for agents. It's also the easiest to extend, 
> should the need arise. Randy 

My experience is that the pre-existing data structures don't allow the 
dangling references and there are two options:
1. Retrofit the capability for dangling references into the pre-existing 
data structures and everything that reads and writes them, at some risk 
to the stability of that code
2. Create a separate data structure in the agent that holds these 
in-progress entries, merges the views of the 2 data structures, and 
moves entries between the two data structures as they are activated and 
inactivated.

I've coded #2 before (and probably #1 too) and it's not an incredible 
amount of work when you know what you're doing but I can understand why 
agent writers avoid it when left to their own devices. And they avoid it 
because they know they'll probably get away with it because NMS writers 
are probably reluctant to send the dangling references anyway (why take 
the risk that you won't get allocated the correct VPLS index and be 
forced to start over?)

I mostly agree with your 5 benefits of allowing dangling references - 
it's just that I see the cost as higher. You lose me when you talk about 
optional side-effects because I don't think we're talking about 
introduces optional side-effects. Same with "undocumented restrictions". 
I'm suggesting we document a restriction that would probably happen in 
real life *before* it happens in real life and could affect 
interoperability.

Steve