2.4.9 Operations & Management Area Open Meeting (opsarea)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-12


Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

Goals and Milestones:

No Current Internet-Drafts

Request For Comments:

RFC3291 PS Textual Conventions for Internet Network Addresses
RFC3419 PS Textual Conventions for Transport Addresses
RFC3595 PS Textual Conventions for IPv6 Flow Label
RFC4181 BCP Guidelines for Authors and Reviewers of MIB Documents

Current Meeting Report

Draft Minutes (v1) Operations & Management Open Area meeting IETF64

When:   1740-1950, MONDAY, November 7, 2005
Where:  Salon 2/3

Minutetakers: David Partain & Jordi Palet Martinez

Area news and updates (Bert Wijnen, David Kessens)
 David Kessens: PROTO team model has been used in the area for the
 past year. Some recent documents haven't been properly prepared, so
 this a reminder to use the PROTO team process to your advantage.

 David Kessens: in dnsop, Dave Meyer stepped down as chair and the wg
 was asked for nominations. The ADs wrote a profile, conducted
 interviews. We had multiple good candidates and decided for Peter
 Koch. The ADs felt good about the way the chair was chosen as
 compared with the ADs simply choosing one.

 Bert Wijnen: NOMCOM wants volunteers for open positions. Bert
 is stepping down as AD and wants to encourage people to volunteer
 or nominate.

SNMP/ISMS issues (Dave Harrington and Simon Leinen)

 Slides are available from the webside and the minutes don't duplicate
 the content of the slides.

 Convergence of Network Management Protocols

 A number of things are being covered in the IETF related to network
 management and security. This talk is trying to raise awareness of
 what's happening. There is a need for balanced security systems; SNMP
 allows you to control very fine granularity and netconf allows only
 very course grained.

 - Netconf chose to make ssh mandatory for netconf 
 - ISMS has also chosen ssh
 - syslog appears to be heading that direction as well

 Netconf was started to deal with configuration and left monitoring
 to SNMP.  Netconf is now considering whether there should be
 monitoring capability, thus doing some of the things that SNMP is
 used for today.

 NANOG surveys indicated that TACACS and RADIUS are the two
 primary systems used for authentication.  RADEXT has been
 asked to define attributes that name policies for management
 access control for SNMP, netconf, etc.

 Netconf has no data model, some work has happened.  How do we
 converge the various models?  Let netconf access the MIB

 SNMP & XML - some tools already support XML in SNMP-based tools.
 Previous work indicates that SMIv2 is hard to use to model some

 Should we all be talking about standardizing security and
 transport?  ISMS is trying to get help from RADEXT.  There are
 ways to support SNMP MIBs in netconf, e.g., put SNMP operations
 directly in netconf, or that you would have an "snmp
 configuration" running alongside 


 Chris Lonvick (chair of syslog): there is also syslog over BEEP.
 They'll also be talking about TLS or other transports.

 Bert Wijnen: does syslog require BEEP?

 Chris Lonvick: not mandatory.  Only one mandatory today is UDP.
 Syslog WG is going to discuss what should be mandatory.  TLS is
 one possible option.

 Bert Wijnen: this is exactly the issue, that we don't want
 customers to have to support a bunch of different security

 Eliot Lear:  He wants a common substrate for security.  This also
 means you can use common authentication and possibly
 authorization tools.  

 Sharon Chisholm: support the idea of more convergence.  Easier
 for everyone.  A few caveats:  some things we've done have been
 done right, some not.  We should have some freedom to do things

 Wes Hardaker:  One thing that isn't clear that worries him.
 We're no longer picking the transport because that's what we
 need, but rather we're choosing the transport because that's what
 the security protocols require.

 Jean-Francois Mullet:  Would like to see netconf move forward in
 an SNMP direction.  Wants to able to manage devices behind home
 NATs.  Wants to be able to manage the MIBs in those devices.

 Sharon Chisholm:  Worries about taking MIBs and XML-ify them,
 largely because most MIBs were written with monitoring in mind,
 and we need to be able to configure.

 Russ Mundy:  an idea for thought.  As we look at transport, we
 should consider an API-ish thing that can be used by others so
 others don't have to worry about that.

 David Harrington:  As we look at putting SNMP on top of other
 transports, we know that SNMP bases authorization on users that
 make the request and we can't always get that from lower layers.

 Jean-Francois Mullet:  Agree with Sharon.  We need more than the
 SNMP data.

 David Black:  in the enterprise, other things need managing and
 which also introduce other elements, particularly the CIM.

 Bert Wijnen:  Tries to keep us up-to-date on what's happening in
 the space.  We first must worry about what we can do to converge
 internally within the IETF, and isn't sure how to deal with these
 external parties.

 David Black: one example of where convergence is an issue is that
 CIM uses TLS exclusively and it's not going to change.

 Eliot: CIM could certainly use something other than TLS.

 Simon Leinen:  What do people think about possible approaches to
 convergence?  What is realistic?  Doesn't think the IETF has
 traditionally been good at this sort of top-down architecture.
 The Grand Unified Network Management architecture is not likely
 to be IETF work.  However, bottom-up work (e.g., XML-ifying MIBs)
 might be something we could do.

 Bert Wijnen: These working groups (ISMS, Netconf, Syslog) are what we know
 about.  If there are others, please let us know so we don't
 diverge even more.  Are there others?  IPfix?

 Glenn Waters:  XMLpatch bof looks like netconf

 Jean-Francois Mullet: SIPPING is doing some work that seems to be
 related, and Bert asked him to check into that.

 Kwok Ho Chan: The policy wg used the CIM model to develop its work.
 Perhaps we can re-use some of that?  

 Eliot Lear:  one _could_ use netconf to transport data that 
 uses a CIM-based schema.  That probably wouldn't be too
 difficult.  Secondly, IPfix uses SCTP as the transport.  This
 re-raises Wes' concern that we are using the right transport for
 the job, not just what is given by the security.  We also need to
 take the installed base into consideration.

 Bert Wijnen: we are trying to take operators' current and near-term
 desires into consideration.

Proposed working groups:

 o MAVS discussion (Christian Jacquenet)
   Provisioning Internet-wide VPN services.

   Context & motivation

   Deploying wide range of service, including things like TV, other
   qos-demanding services, over multi-provider VPNs.


   - Towards automation:  We'd like to make service subscription to
     deployment as easy as possible

   - Dynamic provisioning of network resources

   - Dynamic enforcement of a set of VPN-specific policies

   Contractual commitments between participating service providers,
   based on a common understanding of what QoS means, so we can get
   to standardized SLS templates.  Need to find a way to exchange
   QoS information.

   More on QoS requirements.  Concepts have been defined by the
   DiffServ WG, but contents are left to service providers, which
   leads to inconsistencies.  Need to agree on a set of QoS

   Security:  need a trust model to be used between parties involved
   in the VPN service.  To securely deliver the service, to secure
   VPN route announcements between the domains, to provide the
   access to entitled users, even if mobile.

   Proposed approach:  write a requirements draft, to complement
   4031, currently being circulated on the mavs mailing list.
   Thereafter, ask the IETF to host a BOF on this topic.


   David Kessens: a BOF was proposed, which we rejected for admin
   reasons.  This meeting is a good way to let people know that this
   work is underway.  

   Ross Callon:  a number of issues in your proposal. Are we interested
   in multi-service provider VPN? Yes. What is the complete set of stuff
   that needs to be done and where should it be done? Doesn't know where
   some of these issues need to be handled. Basically, the MAVS document
   makes sense, perhaps it can fit into existing work. "Securing the VPN
   route announcements" - might be a group to do this. Do we want
   QoS-aware multi-domain routing? To me, most of this makes sense, but
   there are a bunch of tasks involved. Exactly what is the set of
   tasks, and where does the work fit in existing groups and what needs
   new WG. Multi-domain QoS probably needs a new one.

   David Kessens:  This presentation is in the ops because we were
   asked about it.  That doesn't mean that an eventual group would
   be in the ops area.  

   Ross Callon:  Looks like there will be work in other areas.

   Christian Jacquenet:  Where the work would be done is one of the
   reasons for having a BOF.

   Russ Mundy:  There appear to be things that have been done
   previously that would solve some of these problems, for example
   the IPSP working group.  Some past work that would have addressed
   some of these issues broke down (firewall MIB) due to lack of
   agreement on engineering details.

   Kurtis Lindqvist:  You were a bit all over the place.  Not well
   defined problem.  Unclear what you are looking for.  Need to
   split the problem into well-defined pieces.

   Chris Davis:  Think there should be a BOF.
   QoS often comes up in discussions related to multi-provider VPNs.
   I like to see it in the ops area since there is a history of
   dealing with operational problems.  Spin out other problems into
   relevant working groups, but the overall problem in the ops area.

   David Kessens: A BOF is of course there for brainstorming, but
   it's also valuable time and we need focus and prepared materials.
   We need to see more activity and clearer problem statements.

   John Loughney: In NSIS, we are working on a general signalling
   framework, including signalling QoS.  Have a look at what we are
   doing in NSIS.  This isn't exactly the target of our work, but we
   can take input.

   Shane Amante: We need to focus on the QoS space. The biggest
   challenge in multi-provider VPNs is agreeing on QoS. Another big
   challenge is monitoring the service. The most value would be to focus
   on QoS aspects of multi-provider VPNs.

 o Diffserv Control Plane Elements (DCPEl)
   (Kathleen Nichols, Scott Bradner)

   mailing list: dcpel@ietf.org
   archive: https://www1.ietf.org/mailman/listinfo/dcpel

   Discussion of proposal by Kathie & Scott followed by two related presentations.

   David Kessens: The feact that this happens during the Ops Open Area
   meeting doesn't mean that this is a Ops only topic, the Transport
   Area has a significant interest here as well.

   Kathie Nichols: We have not much interest in developing a signalling
   protocol.  What we are interested in working on is what's missing
   after working with diffserv and building a prototype.

   Do other people see a problem?  We want to solve the problem of
   delivering a service end-to-end.  You have to understand what
   you're delivering inside a domain and what you're going to say
   about it outside the network.

   Scott Bradner:  The idea of doing something here is not new.
   Shortly after the DiffServ group was done, it didn't seem that
   the time was ripe, but now it seems to be.  There are questions
   about relationship to other work like NSIS, and where it might

   DiffServ is explicitly about what a router should do when it has
   more packets than it can send.  The higher-level questions about
   how to configure queues, the big picture, was never part of

   Bert Wijnen:  The DiffServ working group defined MIBs and PIBs.
   Wasn't that part of this?

   Scott Bradner: That wasn't about the thought processes in the big
   picture.  It was about how to do it, not what to do.

   Bob Braden:  No doubt there is an issue until diffserv talks about
   end-to-end.  There's an element "and then there was magic" in
   diffserv.  RSVP started out with end-to-end in mind.  NSIS
   started out with "signalling is signalling" in mind and that's

   o Domain managed QoS (Jeff Pulliam)

     Web services-based network management system architecture.
     Integrate with whatever signalling protocols that are available in
     the various domains.

     Must have extensibility to be future proof.

     Built a demo system, but we have needs.

     - standards
     - evaluate existing implementations
     - need to look at commercial support for key signalling

     Hannes Tschofenig: you don't describe a clear problem statement.
     What are the requirements?  This reads like an IPSPHERE
     specification.  There are very many open issues that make it
     difficult to talk about the contents of the proposal.

     Scott Bradner: This is not necessarily our proposal.

     Hannes Tschofenig: So what's the problem?

     Scott Bradner: How to think about configuring a diffserv

     Allison Mankin: Don't really understand the problem.  The
     document doesn't have it.

     Scott Bradner: I agree the document doesn't have the problem

     Allison Mankin: Having had a number of documents where diffserv
     meant operations, it's important to have the right people who
     care about diffserv talking to each other.  Love to see the
     document have a good problem statement.

     Scott Bradner: Agree.  I've been looking at this a long time.
     Managing networks rather than individual devices.

     Kathie Nichols: The draft doesn't say we should go out and
     prototype this.  This is something we see as a general model, and
     this is our experience to try to get feedback.  There shouldn't
     be one exact way of doing this, but rather that it should be a
     very configurable kind of QoS.  In answer to Allison, this is
     very much about configuring the edge.  Rather than doing things
     in a static way, you'd change things based on signalling or
     something.  You need to change the way you provision things based
     on the policy of the moment.

     Hannes Tschofenig: If you are thinking in a way other than what
     you've prototyped, why the web services and the like?  Also,
     there are many people who can help with what has been done
     elsewhere, particularly in NSIS.

     Scott Bradner: We don't want to focus on the signalling protocol.
     We are trying to focus on _what_ to say, and not _how_ to say it.

     Ruediger Volk: Is the _what_ up to the level of the services?

     Scott Brander: Yes

     Ruediger Volk: That's a difficult task.

   o NSIS in an off-path world - the control plane (Hannes Tschofenig, Robert Hancock)

     NSIS was designed for path-coupled signalling in the spirit of
     RSVP.  If you want to do path-decoupled work, there is prior work
     on this topic.  There are some issues of off-path signalling.  

     Example QoS Control Plane  intra-domain.  In the vertical
     protocol, you can use something like RMD, Y.1541, etc. and in the
     horizontal protocol, you might want to contact individual devices
     with Diameter, RADIUS, SNMPv3.  You might want to off-load some
     decisions to a centralized box.

     If you want to go from intra-domain to inter-domain work, you can
     use the the NSIS model in a clever way to discover the boxes that
     can talk to each other.  The discover procedure makes this

     Conclusion:  NSIS as designed is a generic and flexible solution
     for a number of use cases and scenarios, including the ones
     you're looking at.  Advantage of using NSIS is that you can take
     advantage of previous work in NSIS and RSVP.  We are talking with
     other organizations (ITU-T, ETSI TISPAN) about how to use NSIS.
     We aren't exactly sure what the problem scope of DCPEl work is.

     John Loughney:  Hannes' second slide - NSIS has specifically not
     worked on the vertical protocols.

     Scott Bradner: We specifically made NSIS do on-path work.  We're
     concerned about how to know what to do, not how to do it.

     Kathie Nichols: We certainly want to re-use anything we can, but
     to articulate some things that need to be articulated.

     Kwok Ho Chan: COPS can do both push and pull.

     H. Kam Lam (not sure about speakers name): In the work done in
     ITU, we provide real-time configuration of routers in the traffic
     path. Part of that is the diffserv marking. How do you
     remark/mark packets. The question is whether the marking is
     real-time or not.

     Scott Bradner: Yes, it is.  We (ITU and IETF) need to make sure
     we're communicating properly about what you are doing.

   Summarizing the discussion:

   David Kessens: Sense of the room whether we should go forward with
   this work in the IETF?

   Hannes Tschofenig: What do you mean by "move forward"?

   David Kessens: Question is whether this should get more attention
   from the IETF.  I'm going to be asked if I can sponsor a BOF.

   Allison Mankin: Don't think we need to ask this question.  Kathie
   and Scott have gotten feedback and that's sufficient.

   Scott Bradner: We weren't clear enough, so please unask that
   question.  We'll produce more material and discuss it on the
   mailing list.

   Bert Wijnen: Let's see if there's mailing list activity and work on
   a problem statement. Then we can ask the quesion about how to move

   Fred Baker: Let's be careful not to squelch conversation, so I'd
   encourage Kathie to move forward.

 o Next Steps for DIAMETER and AAA (John Loughney)

   DIAMETER defines a base protocol and base applications.

   Good news: We've almost completed its charter.

   Bad news: first BOF was Aug 1998.  First milestones were to be
   finished Oct 99.

   We should shut down working groups when done. However, DIAMETER
   development will continue, so John proposed a DIAMETER
   maintenance working group.

   RFC 3588-bis
   BCP on D-RADIUS interworking
   DIAMETER QoS Appllication
   DIAMETER MIPv6 application

   If all goes well, we may have a BOF at the next IETF.

   Bert Wijnen: Not even sure if we need a BOF for this.  Have you
   posted the charter to the AAA list?

   John Loughney: I will do so.

   Bert Wijnen: Once posted, we can handle this on the AAA list.

Open Mike:

Nothing today.



SNMP/ISMS issues
MAVS BOF proposal (Christian Jacquenet)
AAA Maintenance
Diffserv Control Plane Elements (DCPEl)
DCPEl (Jeff Pulliam)
Existing diffserv control plane work on nsis, NGN and ETSI (Hannes Tschofenig)