[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Open OPS Area Meeting Minutes - Preliminary
Please find attached the preliminary minutes of the open OPS Area
meeting in Montreal. Thanks to David Nelson and David Black for the
notes taken during the meeting.
Comments about the minutes should be sent to ops-nm@ops.ietf.org.
David Kessens and Dan
Minutes of the Operations & Management Open Area Meeting - IETF66
When: TUESDAY, July 11, 2006, 1520-1720
Where: Room 519A
A. Agenda bash
no changes.
B. News
First open area meeting with new Area Director Dan Romascanu.
C. Proposals for new work - AnyCast work.
David Kessens - New document is available, coming from the GROW WG, looking for
presentation and discussion.
Presentation by Joe Abley.
(see slides for details of presentation)
Joe A.
- Service requests are attracted to distributed nodes based on topology. Anycast
distributes a service by installing multiple instances of the service in multiple places. Better service, can mitigate DDoS attacks. Done based on same
addressed being routed to multiple service nodes.
- Experience with anycast in IPv4, some IPv6 experience (e.g., F-Root).
- Routing infrastructure chooses node to direct client traffic to, not clients. All the same address prefix is advertised for all the service nodes.
- Anycast is not universally applicable. Protocols that keep state across interactions are vulnerable to subsequent interactions being re-routed to different servers.
- Equal cost paths break state-based services, TCP may also degrade if successive
packets go over paths with very different RTTs.
Comment
- What are the disadvantages?
Joe A.
- There are costs. Management of a distributed system, need to synchronize the data, etc.
AnyCast can be a problem for TCP-based services.
Sharron C.
- Seems to require an extensive knowledge of the net.
Joe A.
- It depends on the nature of the service
Sharon C.
- Seems like work in other spaces is more top down, e.g. web services.
Joe A
- Various ways of adapting techniques.
Comment
- RFC 2991 not refers applies
Comment
- Adding capacity for DoS, local impact of DoS. If node fails, do not withdraw the route, otherwise it results in a cascading failure
Joe A.
- It depends on deployment.
Comment
- Propagation of IPv6. No PI space consensus for RAR, recommendation for TLD.
Joe A.
- No recommendation for non-critical infrastructure.
Comment
- RIPE has plans for prefixes to TLDs.
Comment
- Issue with the mechanism for redundancy for failover. It might get in the way of the built in redundancy of the servers.
Joe A.
- If the routing information fails to propagate, follow the transit path.
Comment
- Prefer some text to address this issue.
Comment
- Any provision for different AS number for BGP?
Joe A.
- No measurement or research data on different approaches.
Comment
- Withdraw route fade sharing and how to identify the service; notion of what the limitations are; mention application behaviors appropriate for AnyCast.
Joe A.
- Use a tight binding of advertisement and service availability.
David Kessens - Encourage everyone to take a close look during the upcoming WGLC. Also looking for positive comments. Please think about whether there is more work required in this area. So far the ADs think no.
D. Issues with IPv6 Ops MIB,
- Presentation by Alain Durand, Anders Persson
(see slides for details of the presentations)
- RFC 4022 and 4113 have a couple of objects that insufficient.
Comment
- Looking for a home to work out the details. What WG?
Dan R.
- Get time on agenda for V6ops. Could be an individual submission.
- Will be presented in v6ops tomorrow, Dan (AD) will determine how to take it forward based on that.
E. Presentation of Security requirements by Dan Romascanu.
(see slides for details of the presentations)
- to be presented in the saag (security experts) meeting on Thursday
- RFC 3365 is too "high level" - needs some practical guidance to protocol writers.
- RFC 3552 has a number of problems - obsolete references, over emphasizes
communication security vs. attacks from protocol peers, not much material on actually writing a Security Considerations section. Also, there are security issues that don't fit neatly into a traditional security considerations section.
- Comment : one is likely to see a divergence of opinions among security experts.
F. Manageability considerations section requirements.
(Presentation by Avri Doria, Adrian Farrel -see slides for details of the presentation)
- Tried this requirement in PCE and ForCES WG. See slides for details.
- Initial experience appears to be positive.
- See draft-farrel-rtg-manageability-requirements-01.txt for motivation behind these
experiments.
Eric F. - Excited by the WG process experiments. Bottom up approach traditionally used, has been problematic. Lots of variation in the level of documentation. This work
will help.
Brian C. - Good idea to conduct an experiment. Why formalize as an RFC 3933
experiment? Just do it. Formal experiment RFC incurs some overhead, and you need to find an AD to sponsor it.
Dave K. agrees.
G. Manageability requirements, by Dan Romascanu.
(see the slides for details of the presentation)
Some WGs do MIB modules, sometimes because "the IESG wants it", some WGs take
alternative management approaches, and some ignore the issue (and that's a problem).
Question: Should existing (unwritten) rule that every WG write MIB modules
be relaxed?
If yes, should we provide a set of manageability guidelines?
Wes H. - Management is hard. The hard part is agreeing on the common models. We keep forgetting this critical need, to agree on a common model as early as possible. Don't have a solution. Convincing folks to do this now is hard, and using the mandatory requirements makes folks go elsewhere.
Eric F. - Adding to Wes' comments. If the IETF doesn't specify MIBs vendors will implement those of their own choosing. Vendor extensions are also a problem. The same concepts are expressed differently in different MIBs. All IETF protocols have MIBs and all MIBs have a common design structure.
Pekka S. - As an operator, I find that important stuff is not in the MIBs that the IETF provides. That causes us to deal with even more vendor specific MIBs.
Sharon C. - Has some slides on this topic.
Follow up discussion on the Ops Area mailing list. - ops-nm@ops.ietf.org
H. Management Considerations - Sharon Chisholm - Nortel
(see slides for details of the presentation)
Problems:
- Better ways to develop/review SNMP MIBs
- Putting more attention on management during protocol development
- Mapping to protocols other than SNMP
General trend towards creating management model that can be mapped to multiple
protocols (e.g., SNMP, CLI, etc.).
Things to be covered in Management Considerations document:
- Example use cases (running well/badly, setup, modify)
- Information to be manipulated (configured, status to be reported/changed,
statistics, how this relates to other things).
Protocol-neutral would be a good idea. Use plain-text instead of encoding UML into ASCII. DMTF may have something useful (CIM). See Section X.2 of Farrel draft for an idea of what would be involved.
Ok, now what?
Dan: Problem with plain English is that there will be lack of interoperability.
Sharon: Need to get to a prescriptive format.
Comment - There is a risk of disconnect between the meta-description and the concrete data model.
Wes H. - Text and model description is probably the best way to go. We don't follow the requirements document process in the IETF. The conversion methodology is ideal but nearly impossible to get right
David B. - The idea is good. What will be the carrier for the technology independent model? Going to have to be something formal, else implementations will not always match . DMTF technology used a subset of UML. It works well, but you have to buy in their framework.
Comment - I like the idea. Start with asking the open questions. Having done a MIB in the IETF that was a painful exercise, this is useful.
Follow up discussion on the Ops Area mailing list. - ops-nm@ops.ietf.org
I. New management Framework Presentation by Dave Harrington.
Do we need a new management framework?
(see slides for details of the presentation)
Proposal to develop modular framework that will include at least ipfix, netconf, SNMP, and syslog.
Start from RFC 3411 architecture/subsystems.
(ran out of time, presentation incomplete)
Dan R. - What is the basic problem being solved?
Dave H. - Reducing duplicate work.
Comment about using TCP.
Dave H. - Folks are working toward using TCP.
Further Discussions on the list - ops-nm@ops.ietf.org
(end of meeting)