Re: RFC3411 discussion versus OAM + P + Mgt discussion

----- Original Message -----
From: "David Harrington" <[email protected]>
Sent: Tuesday, September 21, 2010 6:24 PM

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

Well, when OAM (mpls-tp style) estimates one way delay variation, I call that an
application.  And if you exclude such OAM from your 3410bis, then you
are, for me, redefining network management  to exclude OAM.  I continue
to see little difference between, say, ipfix and estimating one way delay
variation
( or measuring SD in order to decide when to switch to protection or ...); and I
want the exact opposite, I want inclusion.

Tom Petch

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