I'm working on the agenda for this week's TSC call. Please let me know if you have agenda items.

--dmm

Hi Dave,

I assume we will need to make an incubation project decision on the updated:

It is also my understanding they will ask to be accepted into the simultaneous release for 2013, we should likely invite them to present and respond to concerns.  This should be a point for discussion on the TSC with a close look at the project plan (although not many plans are exactly concrete at this time).

/ Chris

Just some feedback on the proposal. I did take a few minutes to review it a few weeks ago when it first came out and looked at it again just to make sure it had not been updated. I find the write up to be well, frankly not containing enough detail to determine just what it is the project aims to do.  On the one hand it talks about extending the SAL, but then it goes on to talk about SNMP and Ethernet. I find the mixture of  "commodity switches", "SNMP" and "Ethernet" to be confusing at best, as its unclear to me why they are related.  When I click through to the API documentation, that seems to have nothing to do with either as it talks about extending flow placement APIs.  What those have to do with Ethernet or SNMP I do not know. 

My recommendation is to ask the submitters to update the proposal before accepting. 

--Tom

To just add a little bit … I have similar skepticism about the use of SNMP (particularly write) to manage a virtual network (scalability/performance, universality of MIB used etc).  There's not a good explanation of what the Agent does here as well.

Beyond that, implementation of an SNMP server type process (plugin) and (one would assume) a modular MIB-add functionality might be interesting to those who want to use ODP as an integrated management/provisioning solution … in general (versus having an EMS handle all the traps and polled inventory shite, environmentals, etc).  We might want to discuss the feasibility of this and the need it would drive for a cluster (for sure) …but it's attractive on paper.

However, this is an interesting lever into the discussion about API.  Looking at the API, you have some proposals to get the LLDP topology and that would almost certainly overlap the generic topology repository and I'm not clear who's in charge here but know we're doing a lot of basic modeling that will define that API (the repository) … I don't know if we need to address individual SB plugins for topology via the NB API and feel that more than likely all topology queries SHOULD be shunted through the topology repository/model/API unless they are extremely unique to the plugin.  Same thing could be said of the Flow API, right? … Wouldn't it go through the generic controller flow management API … Same thing for ARP?

The basic switch config bits (turning of BPDU flood, STP, etc) MAY be redundant to other mechanisms …if not, then they are cool (though I think that we're opening a can of worms with the SAL and config data …exposing EVERY config possibility via the SAL is not ABSTRACT) …and that needs more thought as well, IMHO.  (This could also get interesting if someone proposes NETCONF as well …and I wonder if we shouldn't PREFER NETCONF/Yang/XML for config vs SNMP …if you loop all the way back to my performance concerns and openness concerns around writeable MIBs).

My .01c (I'm on PTO, only half the brain is working, the other is soaking)

Hi Guys,

Great comments and feedback, direct feedback is actionable which is good for them.

I suggest we post these comments, or similar, to the discuss list and aim them at the ITRI guys for action (I'm not going to paraphrase, nor forward/copy paste).  Given the 24 hour attention we get as OpenSource they might have made some improvements to the proposal by the morning.  Let's give them a fighting chance of creating clarity by Thursday. 

(or enjoy your PTO as the case may be ;)

/ Chris