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
information?
SNMP & XML - some tools already support XML in SNMP-based tools.
Previous work indicates that SMIv2 is hard to use to model some
things.
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
Questions:
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
protocols.
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
right.
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.
Issues
- 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
parameters.
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.
Questions:
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
live.
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
diffserv.
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
good.
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
protocols
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
environment.
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
statement.
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
happen.
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
forward.
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.
Topics:
RFC 3588-bis
BCP on D-RADIUS interworking
DIAMETER URI
DIAMETER API
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.
---
|
