Re: [Fecframe] Operations and Management Considerations (text for theframework)

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: Dave Oran (oran)
> Sent: Monday, January 17, 2011 4:34 PM
> To: David Harrington
> Cc: Ali C. Begen (abegen); [e-mail]; 'Lars Eggert'
> Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework)
> 
> Thanks for getting back to me on this. I think we're converging (somewhat), or at least talking about the same things.
> 
> On Jan 17, 2011, at 4:06 PM, David Harrington wrote:
> 
> > Hi,
> >
> > I agree that it may make more sense to focus on the interoperability
> > of specific fec schemes and features.
> >
> > The framework ops+mgmt considerations should SAY that, and should set
> > the requirement that framework-compliant components MUST specify
> > mandatory-to-implement protocols for config and monitoring, so
> > independently developed implementations have at least one protocol
> > available for operators to deploy to provide interoperable operations
> > and interoperable management for each chosen fec scheme.
> >
> This seems a reasonable principle to follow. The devil is in the details, especially in how the config and management for the
> overall system(s) interact with the FEC-specific pieces. See below for more.
> 
> > Of course, if each scheme chooses a different mandatory-to-implement
> > protocol, then an entity that supports multiple fec schemes might end
> > up with a panoply of mandatory-to-implement protocols for config and
> > monitoring, so it might make more sense to have at least one
> > mandatory-to-implement protocol at the framework level, to ensure a
> > minimum level of interoperability for config and monitoring.
> >
> If FEC schemes were "top-of-the-foodchain" kinds of protocol, like TCP, or RTP, or SIP, then following this rule would in fact
> help a lot in ensuring system-level interoperability for the operations and management components of making the protocol
> work and instrumenting it. Unfortunately (or perhaps in my view fortunately), that's not the case here. FEC schemes are
> pretty much without exception *embedded* in a "top-of-the-food-chain" protocol like RTP, or reliable multicast file transfer.
> That means one REALLY wants the operations and management protocols and instrumentation framework to be dictated by
> the embedding and not by the FEC scheme. In fact, I would consider it undesirable if we picked and mandatory-to-implement
> config/management protocol (e.g. SDP) for an FEC scheme, and then embedded it in a different "top-of-the-food-chain"
> system that has no need of SDP for anything. This is not entirely theoretical; we already have FEC schemes in use by other
> SDOs that use multicast file transfer and XML to describe and manage the protocols with which which the FEC scheme is
> based. It makes much more sense to ensure that the necessary configuration and instrumentation information is present in
> those protocols, than to declare the implementation non-compliant in the IETF because the implementer didn't (uselessly)
> put SDP in the system.
> 
> Therefore, I still maintain that:
> - There isn't a lot to say in the framework draft, and find your suggestion to limit language in that draft to saying that the
> operations and management of FEC is "scheme specific" and that the scheme RFCs MUST address O&M with the appropriate
> O&M considerations section.

This makes sense and agrees with what WG implicitly assumed so far IMO.

> - if you at all buy my logic above, then it is not appropriate to require "mandatory to implement" protocols in the scheme
> drafts; rather, the requirement is for enough specific information about configuration and instrumentation to give
> implementors guidance about what changes/enhancements may be needed to the protocols used in the "enclosing" protocol
> environment.

Indeed. One just needs to look at where FEC has been deployed so far and how it has been used in large networks to appreciate the statement above.
 
-acbegen

> > The approach so far taken by this WG seems to be "let's just declare
> > it out of scope" - i.e., have no standard mechanisms for configuring
> > or monitoring FEC operations or specific FEC schemes.
> That's a correct assessment of the WG's general approach, but I do not view that criticism as necessarily all that serious
> given the nature of the work.
> 
> > As far as I can
> > see, that means that if vendor A's server wants to use fec protection
> > for something it is sending to a client from vendor B, and vendor A
> > chooses one protocol for config, such as SDP, and vendor B chooses not
> > to support the same protocol, then the two endpoints cannot
> > communicate to agree on a configuration. That would be a pretty sad
> > situation for an IETF standard.
> >
> Not as sad as having an FEC scheme used with both RTP and with Reliable file transfer being forced to add a lot of useless
> complexity and introduce new interoperability problems for the system they are embedded in because the two systems for
> good reason use different configuration and management protocols.
> 
> I'm of course encouraged by the discussion, which has shed some light on the underlying issues. I think that at least at this
> point we are not in agreement about the right way forward, but hopefully this has helped make some progress.
> 
> DaveO.
> 
> 
> > David Harrington
> > Director, IETF Transport Area
> > [e-mail] (preferred for ietf)
> > [e-mail]
> > [phone] (cell)
> >
> >> -----Original Message-----
> >> From: David R Oran [mailto:[e-mail]]
> >> Sent: Saturday, December 11, 2010 3:26 PM
> >> To: Ali C. Begen (abegen)
> >> Cc: David Harrington; [e-mail]
> >> Subject: Re: [Fecframe] Operations and Management
> >> Considerations (text for theframework)
> >>
> >> It seems to me that since this is a framework draft, what it
> >> needs is a framework for how the FEC parts of a bigger system
> >> affect the overall operations and management of that system.
> >> While the current text may be view by the IESG as inadequate,
> >> there is frankly not a whole lot other than motherhood to say
> >> here. The framework is not a protocol with specific
> >> mechanisms and state machines that need configuration and/or
> >> fail in particular ways that need to be managed. Therefore,
> >> while I think some of the cited requirements on enhancing the
> >> draft make a certain amount of sense, the level of
> >> specificity that is possible is quite low, so the "pain-gain"
> >> ratio strikes at least this WG participant as not warranting
> >> a whole lot of work.
> >>
> >> The kind of drafts where the O&M considerations become
> >> concrete are documents like
> >>
> >>
> > http://datatracker.ietf.org/doc/draft-ietf-fecframe-config-signaling/
> >>
> >> and
> >>
> >> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/
> >>
> >> I think there's more bang-for-the-buck in focusing the
> >> limited energies of the FEC community there.
> >>
> >> DaveO.
> >>
> >>
> >> On Dec 11, 2010, at 2:26 PM, Ali C. Begen (abegen) wrote:
> >>
> >>> Hi David, All,
> >>>
> >>> This was not an attempt for a punt or refusal. This was
> >> simply a summary of what has been discussed in the WG and
> >> design team in the past three years. I might have done a poor
> >> job in summarizing it but your email is not concerned about it.
> >>>
> >>> I offered the text based on my knowledge and past meetings,
> >> and asked the WG to provide input on it. There were no
> >> objections. And from what we saw, I can tell that those of us
> >> who actually run FEC systems were happy with the points or
> >> arguments summarized in this section. I agree there is not
> >> much detailed information but the section offers why it is so.
> >>>
> >>> The list you provided below involves many things that were
> >> never discussed in this WG (at least to my knowledge),
> >> largely because they were left outside the scope since the
> >> beginning. I was still at school when fecframe was formed and
> >> chartered but the current charter does not have much
> >> (actually anything at all) related to the list below. If
> >> these things indeed needed a specification, the charter
> >> should have said so and they should have been worked on when
> >> the framework draft was still developing and during the time
> >> when we had a larger participation in the WG.
> >>>
> >>> I am happy with what the WG decides to do. As one of the
> >> current editors, I am willing to contribute but this is a
> >> daunting task, which will certainly require more than one
> >> person. However, first I would like to see what everybody
> >> thinks: are we missing essential information that we would
> >> need in the field for fecframe apps?
> >>>
> >>> -acbegen
> >>>
> >>>> -----Original Message-----
> >>>> From: David Harrington [mailto:[e-mail]]
> >>>> Sent: Friday, December 10, 2010 8:31 AM
> >>>> To: Ali C. Begen (abegen); [e-mail]
> >>>> Subject: RE: [Fecframe] Operations and Management
> >> Considerations (text for theframework)
> >>>>
> >>>> Hi,
> >>>>
> >>>> This is not adequate to address IESG concerns.
> >>>>
> >>>> You need to talk about what needs to be managed, and how it can
> > be
> >>>> managed in an interoperable manner.
> >>>>
> >>>> Excerpts from the IETF Mission statement:
> >>>> The mission of the IETF is to make the Internet work better by
> >>>> producing high quality, relevant technical documents that
> > influence
> >>>> the way people design, use, and manage the Internet...
> >> when the IETF
> >>>> takes ownership of a protocol or function, it accepts the
> >>>> responsibility for all aspects of the protocol.
> >>>>
> >>>> This is an excerpt from another conversation that is
> >> happening in the
> >>>> IESG, and the statement has IESG and IAB consensus:
> >>>> "IETF [...] has negative experience with two standards in the
> > same
> >>>> general area.  When one vendor implements one standard and
> > another
> >>>> vendor implements the other standard, there is no
> > interoperability.
> >>>> The result is two disjoint communities, which is
> >> considered a failure
> >>>> in the IETF."
> >>>>
> >>>> Some IESG responses to your proposed text:
> >>>>
> >>>> - This is worse than a punt. This is an explicit refusal
> >> to consider
> >>>> the issues of operation or management, plus the addition
> >> of text that
> >>>> states "we will not do this in this draft".
> >>>>
> >>>> - As holder of the DISCUSS I would not clear the DISCUSS
> >> based on the
> >>>> proposed text.
> >>>>> Defining tools for the operation and management of these hosts
> > is
> >>>> not within the scope of this specification.
> >>>> Sure - it's a framework document. Yet discussion of the
> >> operations and
> >>>> management interoperability is IMO within scope as it is
> >> part of the
> >>>> interoperable framework.
> >>>>
> >>>> I strongly support these IESG positions.
> >>>>
> >>>> So, going forward, what we need to produce, as a starter, is
> >>>> discussion of
> >>>> 1) what are the critical errors in FEC processing, and how should
> >>>> operators and applications respond to these errors?
> >>>> 2) How should critical errors get reported to operators and
> > network
> >>>> management applications?
> >>>> 3) How are the critical errors reported in a vendor-neutral
> > manner?
> >>>> 4) what is the ***standard*** for configuring FEC parameters, so
> > we
> >>>> have a minimum level of interoperability across vendors?
> >> If there is
> >>>> no need for such a standard, then it is questionable
> >> whether this is
> >>>> IETF work because the IETF works to develop vendor-neutral
> >> standards
> >>>> for interoperability across vendors.
> >>>> 5) A standard set of functionality can be supplemented with
> >>>> proprietary methods if desired, but there should be ONE method
> > that
> >>>> all compliant implementations support.
> >>>> 6) What statistics should be maintained by senders and recievers
> > of
> >>>> FEC-protected content? Faults? performance measures? connections?
> >>>> 7) What is the range of the statistics? What happens to
> >> the statistics
> >>>> when a device reboots? or a session restarts?
> >>>> 8) I recommend you expand section 6 to standardize this feedback
> >>>> information model in more detail.
> >>>> 	- see RFC3444 about information models,
> >>>> 	- see the BRIDGE-MIB for some guidelines about limiting the
> >>>> information model to necessary infromation
> >>>> 	- for those that participate in IEEE 802.1, you might want to
> >>>> look at how they separate the information model form the data
> > model
> >>>> 	- how does pre- and post-encryption affect those statistics?
> >>>> Should the use of pre-, -post-, or both encryption be
> >> reported so an
> >>>> operator can tell whether FEC configuration is properly
> >> aligned with
> >>>> domains of trust?
> >>>> 9) How are the statistics reported to an operator or NM
> >> application,
> >>>> especially NM applications from another vendor?
> >>>> 10) How are the statistics reported between receiver and sender?
> > is
> >>>> there in-line OAM functionality? What happens if there is a
> > proxy?
> >>>>
> >>>> One of things that happens, when you refuse to properly consider
> >>>> security and/or operations and management, is that you
> >> tend to get a
> >>>> bigger pushback in response. I think you are seriously beyond the
> >>>> point of being able to say "how security is handled and
> >> how operations
> >>>> and manageent are handled is up to the operator."
> >>>>
> >>>> when the IETF takes ownership of a protocol or function, it
> > accepts
> >>>> the responsibility for all aspects of the protocol.
> >>>>
> >>>> David Harrington
> >>>> Director, IETF Transport Area
> >>>> [e-mail] (preferred for ietf)
> >>>> [e-mail]
> >>>> [phone] (cell)
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [e-mail]
> >>>>> [mailto:[e-mail]] On Behalf Of Ali C. Begen
> >>>> (abegen)
> >>>>> Sent: Thursday, December 09, 2010 12:30 PM
> >>>>> To: [e-mail]
> >>>>> Subject: [Fecframe] Operations and Management Considerations
> >>>>> (text for theframework)
> >>>>>
> >>>>> This is the text that will be incorporated into the framework
> >>>>> draft (following up on the earlier discussion in the list).
> >>>>> If there are any final comments, please send them to the list.
> >>>>>
> >>>>> Otherwise, we are waiting for the AD to give us a green light
> >>>>> to move ahead with a submission to address the IESG comments.
> >>>>>
> >>>>> Thanks,
> >>>>> -acbegen
> >>>>>
> >>>>>
> >>>>> 10.  Operations and Management Considerations
> >>>>>
> >>>>>  The FEC Framework is concerned about the FEC encoding and
> >>>> decoding
> >>>>>  operations, and the configuration information that is
> > essential
> >>>> to
> >>>>>  control the hosts running these operations.  Defining tools
> > for
> >>>> the
> >>>>>  operation and management of these hosts is not within the
> > scope
> >>>> of
> >>>>>  this specification.
> >>>>>
> >>>>>  Some applications using the CDPs compatible with the FEC
> >>>> Framework
> >>>>>  are one-way meaning that they do not have a way to gather
> >>>>> any kind of
> >>>>>  feedback from receivers (e.g., broadcast), while some
> >> of them may
> >>>>>  collect detailed feedback (in case it is a one-to-one
> >>>>> application) or
> >>>>>  occasional feedback (in case it is a multicast
> >> application).  All
> >>>>>  these applications have naturally different management
> > aspects.
> >>>> If
> >>>>>  any, they also have different requirements or features for
> >>>>> collecting
> >>>>>  feedback, processing it and acting on it.  The data structures
> >>>> for
> >>>>>  carrying the feedback also vary.
> >>>>>
> >>>>>  On the operations side, it is not advisable for the FEC
> >>>>> Framework to
> >>>>>  explicitly list what the hosts (sender or receiver or even
> >>>>> a middle-
> >>>>>  box) could do upon observing something in particular or
> >> receiving
> >>>> a
> >>>>>  specific feedback.  The CDPs and the FEC schemes
> >>>>> compatible with the
> >>>>>  FEC Framework SHOULD make use of existing tools as much as
> >>>> possible
> >>>>>  and to the extent possible.  For example, for repair flows
> >>>>> using RTP
> >>>>>  transport, benefiting from all the features of RTCP
> >> mechanisms is
> >>>>>  strongly RECOMMENDED since RTCP has already solved many of
> > these
> >>>>>  issues in an agnostic way of the data carried with RTP.
> >>>>>
> >>>>>  Overall, the CDPs and FEC schemes compatible with the FEC
> >>>> Framework
> >>>>>  widely differ in their capabilities, application and
> > deployment
> >>>>>  scenarios such that a common operation and management tool
> >>>>> that works
> >>>>>  well for all of them does not exist.  Thus, as a design
> > choice,
> >>>> the
> >>>>>  FEC Framework does not dictate the use of any particular
> >>>> technology
> >>>>>  or protocol for transporting FEC data, managing the hosts,
> >>>>> signaling
> >>>>>  the configuration information or encoding the configuration
> >>>>>  information.  This provides flexibility and was one of the
> >>>>> main goals
> >>>>>  of the FEC Framework.
> >>>>> _______________________________________________
> >>>>> Fecframe mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/fecframe
> >>>>>
> >>>
> >>> _______________________________________________
> >>> Fecframe mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/fecframe
> >>
> >>
> >