Hi, As the author of rfc5706, and a long-time participant in the OPS area, let me make some comments and provide some advice.
First, OAM and "Operations and Management" are not the same thing. There is an RFC that discusses OAM terminology, and I recommend reading it to understand the distinction (which still is NOT unambiguous). Generally, 1) OAM happens inline as part of the protocol, 2) operations includes consideration of the environment in which the protocol will operate, and 3) management tends to be a combination of layer 7 protocols that provide monitoring/management capabilities combined with protocol-layer-specific information, such as MIB objects or ipfix information elements or syslog structured data, etc. IETF management protocols typically keep a clear distinction between the protocols used to carry management information and the data models used to model the managed functionality. Second, as the WG starts to consider how to address O&M requirements and/or OAM requirements, I recommend starting with an understanding of the difference between information models and data models, as described in RFC3444 (IIRC). OPSAWG is doing a lot of work at making sure the information used by one protocol can be correlated and/or translated between data models for use with other management protocols. I recommend developing a management-protocol-independent information model, plus at least one management-protocol-specific data model (which helps serve as a proof that the information model is viable). Third, The IETF currently has four main standards in the "management protocol toolkit": SNMP (monitoring and tweaking), IPFIX (flow monitoring), Netconf (configuration), and Syslog (logging). These are widely supported by operators, and standard data models should be available so operators can use these IETF management protocols to manage IETF protocols when possible. Fourth, RFC5706 discusses things to consider when developing a management information model (and subsequent data models). For example, for ALTO, an operator might want to be able to monitor what sources are being used to gather physical network information, what transform algorithms are being applied to the source data to produce ALTO application-level information, and to monitor who is getting that processed information from the ALTO server. You might want to consider whether protocol errors are being detected between the server and the data sources, or between the server and specific consumers. This might be important to understand whether certain sources or consumers are putting an unnecessary strain on the server, so a server might choose to stop communicating with that error-generating connection (and whether that decision should be standardized). That infomation also might help detect why certain consumers might choose non-optimal optimizations. RFC5706 also discusses operational requirements. If BGP will be used to gather source data, then BGP must be supported in the environment, and that has operational considerations. Will all ALTO servers operate in BGP environments? If an operator decides BP is not important to the physical network they run, or choose not tp provide BGP data for security reasosn, how will the ALTO environment be affected, and will this affect interoperability across ALTO servers? And so on ... -- David Harrington Internet Engineering Task Force (IETF) [email protected] +1-603-828-1401 On 5/11/12 12:30 AM, "Martin Stiemerling" <[email protected]> wrote: >Hi there, > >An important note on the ALTO protocol as part of the WGLC: > >The ALTO requirements have been discussed in the 2012-05-10 IESG >telechat and one point raised which is actually of importance for the >ALTO protocol is this: > >There is/was a DISCUSS on the ALTO requirements about operations and >management (OAM) of the ALTO protocol. >RFC 5706 (http://tools.ietf.org/html/rfc5706) gives an overview of >points to be checked for new protocols. > >However, we have not considered RFC 5706 (at least to my knowledge) in >the ALTO protocol that discusses operations and management of the ALTO >protocol. > >The outcome of the IESG discussion is that the ALTO protocol must cover >the aspect of OAM and discuss what is potentially needed and what is >potentially not needed. > >For instance: >- the support of logging at the server for failure detection is a >potentially a good idea, though it might become touchy in the p2p use >case. >- discussion of what clients are supposed to do when a server fails for >various reasons. This is probably already covered in the current ALTO >protocol draft. > >Regards, > > Martin > >-- >IETF Transport Area Director > >[email protected] > >NEC Laboratories Europe - Network Research Division NEC Europe Limited >Registered Office: NEC House, 1 Victoria Road, London W3 6BL >Registered in England 283 >_______________________________________________ >alto mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
