Current Meeting Report
2.1.19 Network Data Management Protocol (ndmp) Bof
Current Meeting Report
Minutes from the 53rd IETF - 2nd NDMP BOF held 03/18/02 in Minneapolis
Co-Chairs: Greg Linn (Network Appliance), Lawrence Barnes, (Bakbone Software)
Review Agenda. Approved as proposed:
1) Summary of 1st BOF (52nd IETF)
2) Work group and protocol name
3) NDMP technical overview
4) NDMP v5 specification organization
5) Work group charter revisions
6) Milestone/deliverable revisions
7) Summary and next steps
- Mail reflector feedback rev'd with Ned. Use of the term mgmt in context of NDMP inconsistent w/IETF definition of mgmt.
1) Summary of 1st BOF:
- Some functionality deemed outside scope of IETF.
- Modularity considered essential to avoid too lengthy a spec.
- Why NDMP may or may not be appropriate within IETF community.
- Reiterated that we are not tied to past of NDMP protocol.
- Security, auth., bandwidth limitation are issues of concern to us.
- Positive consensus.
End of summary.
2) Workgroup and protocol name proposed change.
Comment: we have a lot of groups doing movement. It seems opaque that we are doing backup and recovery. NDMP essentially seems to be an ambiguous name.
However, we are trying to move away from just bu and rr. One possibility is that NDMP doesn't stand for anything. Protocol formerly known as NDMP.
n-dump is one possibility translation.
Working group and protocol name need not be identical. May want to rename workgroup only so that we can isolate consequences of name change from market.
3) NDMP technical overview - Harald Skardal, Network Appliance
History of NDMP. Came about as a mech for bu and rr. So that you could have a console or workstation to control:
Data Mgmt Application
Data Source, Data Sink
[Lightweight data movement and archive for appliances on storage networks]
show picture of a typical NDMP session for bu via port #10000. Sending of control msgs to NDMP data service and tape service. This results in a tcp connection between primary and secondary storage across which data can be transferred. Can be dump, tar, cpio or whatever the data service knows how to use.
q: why do you need communication on all three edges?
Perry Metzger: Don't understand why a full blown app can't be loaded on various boxes.
David Black: Point is not the weakness of the operating system. It is that the boxes are sold as fixed function appliances.
comment: typically deployed in highly heterogeneous environments.
q: multiple primary and secondary storage devices on a typical network.
comment: concerns over similarity with ftp protocol and some of the security issues it has experienced. Mechanisms which allow you to send commands to two boxes which allow them to connect and send data make some suspicious.
rathole: security discussion
q: The tape svc is a SCSI device. Fixing SCSI security issues is out of scope for this discussion (David Black)
q (Naveen Nimmu). Does it assume file level access?
Harald: NDMP is a file system backup protocol currently.
q: is this a limitation of the protocol?
comment: David Black. At a functional level it can operate file by file. At the data flow it is much more flexible. It can separate data flow from file system control information.
Jim Ward (workstation solutions - firstname.lastname@example.org): We've described so far how it is deployed today. There are other capabilities that are not currently exploited.
back to overview/summary.
V4 now allows extensions that provide availability of propietary functionality.
Need for session wide timeout mgmt
q: looking at list of security issues. Message integrity and confidentiality are also of concern. It's not just authentication.
Harald's example (not in slide) Backup of remote branch ofc's into hq
4) NDMP v5 specification organization - Jim Ward, Workstation Solutions Monolithic 250+ page spec for NDMP v4. A lot of IETF people found this off putting. On one page transport, then authentication, then tunneling, etc.. Scope seemed too broad. This is why we "parcelled" this up or modularized the spec..
One purpose is to review what we did right and what we didn't. With the v5 spec we intend to establish subgroups to work on various issues such as transport and security and layered services. Data archiving, though it has a movement component is still different from simple backup.
Clean segregation and parallel spec creation is part of what we want to accomplish with this IETF workgroup.
We expect within "under 15 months" to revamp or recast the protocol which will require parallel effort.
May need to provide in band "data transmogrification". With multiple data sources and data sinks connections become a little bit more sporty in v5 than v4.
q: how are we thinking of compression and encryption? Is this designed for the purposes of what will be stored or to keep in mind the transport limitations?
finite state machines. In the architecture spec what does each of the fsm's look like?
Like it or not NDMP has history. There needs to be some means to offer backward compatibility. But this isn't absolutely required.
q: can we just make the wall "thick"? In other words, if the device can't talk v5 then drop down to v4?
protocol namespace we think we have our arms around transport mgmt needs work.
svc checkpointing and restartability. Strictly byte stream connections today. Having computational objects in the middle may require msg capsulation.
Separating core and layered services in v4 doc is non trivial now but will become simpler due to modularization with v5 spec.
data svc - verification of data
end of Jim's discussion (modularization of spec's moving fwd)
5) Work group charter revisions - Greg Linn
q: Network based mechanisms? Will it cover more than just tcp? Perhaps we should specify tcp?
q: DMA is a *really* bad acronym
q: Luciano Dalle Ore (Quantum). Might want to generalize the device or storage type to just primary and secondary.
q: The protocol does not use RPC
q: Lots of "mom and apple pie". We seem to be too ambitious. Need to pare this down to improve chances of successful completion.
q: Geoff Huston. What is in scope and what is out of scope. Bringing in issues of dump protocols seems uninteresting. Need to more explicitly state things like NAT traversal and other specific security issues.
q: separation of san and nas brings up issues and suspect "moving targets". Only address "framework" and specific methods for handling specific types of data? Or should we generalize?
q: In NFS v4 we're looking at replication and migration (Robert Thurlow, Sun). Heterogeneous environments.
q: to NDMP data formats *must* be opaque
q: it would be nice to work together with the NFS working group to make sure there are no overlaps.
q: Pat Egan. Get somebody involved in group who understands working with underpinnings of IETF
q: Eric Rescorla. Why do we want this in IETF? Need to grab some people by the collar and make sure they will help us.
q: John Klensin. This is a wonderful piece of work, interesting and "probably" important. However, seems to involve things not core to IETF expertise. We don't handle those things very well. We should be trying to figure out what sorts of primitives and protocol notions we need in order to do an NDMP protocol somewhere else. Take the stuff which is bu specific and keep it out of IETF. Modularity of today's discussion seems alarming.
q: Brian Pawlowski. NDMP frequently lurks around NFS and other things that are within IETF scope.
q: Lisa. framework for storage transfer and to improve security and internationalization without adding any new real features (maybe "layered services" but not sure).
q: Text seems to not allow us to say "no" to anything so work seems to have potential to go on forever. We should bring in some people more familiar with IETF so that we can more clearly focus the work.
q: are there those in the audience who are willing to help who have ietf experience?
q: there is a core piece of protocol design that the IETF is expert in producing.
q: are the things we need to learn to do this necessary for the IETF to learn?
q: there are some things that are very relevant. Storage networks are now popular when initially IETF was hands off on storage. IETF is now actively involved in this, for example, storage over IP.
q: data formats are opaque. David Black.
q: Roger Cummings, Veritas. Take existing protocols and add features to them.
q: Perry. If only we had this protocol we could solve all of these problems. Protocols are hard. Frameworks are even harder.
q: Lisa. knowledge gap can be bridged. Make clear to people who have never heard of NDMP why they should care.
q: Eric Kadison, Broadband Storage. This is an area where the IETF and its customers can benefit. We need the participation of the IETF literate.
q: Dave Crocker, Brandenburg Internetworking. Multicultural activities tend to have poor track records. Perhaps the goal is to get the cultures together as opposed to writing the spec. What's the smallest thing that we can turn out that will be useful to our community that is a protocol? Suggest a 6 month time frame.
q: Get an experienced IETF'er to co-chair is suggested.
Scribe's notes: Althouth the general consensus was that a great deal of progress had been made in clarifying the purpose of the workgroup a significant amount of confusion and concern still remained. The following areas of concern were expressed:
"multicultural issues" were significant. In other words, the IETF people seemed very concerned that they were asked to become storage and application experts. It seemed that the goals of the workgroup itself were frequently expressed in terms of application functionality as opposed to being from the protocol viewpoint
As a further expansion of the multicultural issues there were also significant concerns that there wasn't much in the charter to equip the workgroup to determine out of scope efforts. This would inevitably lead to scope creep and inability to say no with the consequence of slipped schedules.