RFC3411 discussion versus OAM + P + Mgt discussion

Tom,

you're mixing two different issues. Sure they intersect, but they are
different problems.

This discussion started as a suggestion that RFC3411 "An architecture
for Describing SNMP Frameworks" be suppplemented with a simpler
architecture document so doing work on SNMP specifications stopped
being so onerous. The ISMS work was tremendously difficult because we
were required by charter to abide by the RFC3411 architecture. (This
whole issue could be made easier of the area directors didn't insist
on RFC3411 being THE architecture, rather than "AN" architecture, as
it was designed to be.)

As part of that suggestion, I also suggested updating the SNMP
applicability statetment, RFC3410, to reflect current thinking of SNMP
being applicable primarily for monitoring, Netconf for config, syslog
for logging, and ipfix for flow monitoring. These are all "vertical"
network management protocols that operate at layer 7, and make
information available from multiple layers of instrumentation. 

The OAM issue you are raising is about "horizontal" protocols that
operate within-layer. This would include protocols like ping,
traceroute, VCCP, and so on. 

I share your concern that the MPLS-TP work is bringing ITU-style OAM
protocols into the IETF, and the OPS area doesn't seem to be paying
much attention to this. draft-ietf-opsawg-mpls-tp-oam-def is under
review for Proposed Standard, and proposes standardizing terminology
for all future IETF documents dealing with OAM + provisioning +
management. I have concerns this will have an immense impact on how
the Internet is managed, without adequate consideration of the impact
outside the MPLS-TP environment. I am seeing portions of Y.1731
slipping into non-MPLS-TP internet-draft proposals (sometimes without
mention of Y.1731). That may or may not be bad, but I think the IETF
needs to be very aware that this is happening. 

I also have concerns that much of the recent work in v6ops seems to be
heavily influenced by ongoing 3GPP work. That also may or may not be
bad, but I think the IETF needs to be very aware that this is
happening.

We are a volunteer organization and if most volunteers want to work
only on their own protocols and put blinders on regarding the larger
trends that are happening around them, that is their choice. I'm sure
some have paid attention, and maybe they are not concerned about this
trend.

If you are really worried about the explosion in OAM, and Y.1731 in
particular, maybe you should do a presentation at the OPSAREA meeting
explaining how Y.1731 works, and why it might be bad for the Internet.

dbh

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of t.petch
> Sent: Tuesday, September 21, 2010 10:23 AM
> To: Jon Saperia; Randy Presuhn
> Cc: isms; [email protected]
> Subject: Re: [OPS-AREA] [Isms] status and future of the isms 
> working group
> 
> ----- Original Message -----
> From: "Jon Saperia" <[email protected]>
> To: "Randy Presuhn" <[email protected]>
> Cc: <[email protected]>; <[email protected]>
> Sent: Monday, September 20, 2010 7:43 PM
> 
> > I could not agree more.
> >
> > I would add  that additional 
> protocol/architecture/framework on any of 
> > the
> management infrastructures we have does not address the key 
> point I took from Randy's post.  What we need are widely 
> implemented objects (however you want to call the structures) 
> that give real visibility into what is going on in the 
> devices and networks.  That has always been the problem and 
> until we address that who cares how we transport the data. I 
> would settle for RFC2549, if it contained the right information.
> >
> Jon
> 
> My current hot button is not data but protocols.  I am 
> worried about the explosion in 'OAM' (ie ping, traceroute 
> etc) protocols to run in the MPLS dataplane, that are being 
> defined in the MPLS-TP nexus.  Before long, we might have 
> Y.1731 as a standards track RFC:-(
> 
> I was relieved to see the IESG sending back 
> draft-ietf-opsawg-mpls-tp-oam-def but what happens next, 
> metaphorically speaking? I would rather more people with a 
> background in the IETF were involved with this.
> 
> Tom Petch
> 
> > /jon
> > On Sep 20, 2010, at 1:04 PM, Randy Presuhn wrote:
> >
> > > Hi -
> > >
> > >> From: "t.petch" <[email protected]>
> > > ...
> > >> I think that our resources are limited, and tend to 
> decay with the 
> > >> age of a working group, so I would rather see them applied 
> > >> elsewhere.  I look back
> at the
> > >> effort that went into RFC3411, over many years, and yet 
> it fell at 
> > >> the
> first
> > >> hurdle, not accommodating the move of security from deep 
> inside the 
> > >> engine
> to
> > >> off the bottom of the radar; why should we do any better 
> this time?
> > > ...
> > >
> > > The problem as I see it was that RFC3411 was intended to 
> be the glue 
> > > describing how a particular set of specifications fit together, 
> > > *not* as
> > > *the* architecture for all future SNMP work.  *Requiring* 
> > > extensions, additions, and embellishments to adhere to that 
> > > architecture is in my opinion a huge mistake.  From my 
> perspective, 
> > > the real problem addressed by RFC 3411 was that some of the 
> > > preceding proposals for securing SNMP had so many 
> convolutions and 
> > > interactions that a lot of folks had trouble wrapping their
heads 
> > > around them.  The modularity brought by RFC 3411 was 
> modularity of 
> > > *specification*, not necessarily implementation.  The ASIs were 
> > > rather controversial because folks were (rightly, in retrospect)

> > > concerned that they would be understood in a prescriptive sense,

> > > rather than descriptive sense in which they were intended.
> > >
> > > More importantly, I think focusing energy on this 
> "problem" (which 
> > > is tempting because it's something we think we 
> understand) would be 
> > > a huge distraction from the *real* problem: the kinds of 
> information 
> > > models this infrastructure should provide access to.  If the 
> > > information models can't support the high-value functions 
> > > administrators / operators need, then embellishing the 
> protocol engine architecture is a waste of time.
> > >
> > > Randy
> > >
> > > _______________________________________________
> > > OPS-AREA mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/ops-area
> > >
> >
> > _______________________________________________
> > OPS-AREA mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ops-area
> 
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area