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

[David R Oran <[e-mail]>]

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


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