[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft Minutues OPS Area Meeting at 56th IETF
With thanks to Andy Bierman, Elliot Lear, Dave Harrington
for sending me their notes out of whihc I have destilled
the following draft minutes.
Everyone gets till Monday April 7th to comment.
The slides are at:
http://www.ops.ietf.org/OpsAreaAgenda.ppt
http://www.ops.ietf.org/BernardAbobaOM.ppt
http://www.ops.ietf.org/Ops_Area_v6ops_Mar03.ppt
http://www.ops.ietf.org/WesOpsArea.ps
http://www.ops.ietf.org/WesBoth.jpg
Thanks,
Bert
-------------- Draft Minutes -----------
OPS-NM Area Meeting, 56th IETF, Thursday, March 20 at 1300-1700
Agenda: (see also first few slides at
http://www.ops.ietf.org/OpsAreaAgenda.ppt)
Agenda Bashing
25 minutes on Radius
30 minutes v6ops
30 minutes network management
30 minutes open mike
Opening notes:
ADs refused to allow a prepared presentation on the benefits of
COPS and PIBs under the "Been There Done That category".
---------- Bernard Aboba: Radius, AAA Report
Slides at: http://www.ops.ietf.org/BernardAbobaOM.ppt
SDO dependencies & relationship issues.
One of most important background factors.
Most AAA work comes from other SDOs.
So we see 3 major sources of work in the IETF:
- IEEE 802.1aa published MIB in Bridge WG
- history of cooperation with IETF
MIBs and AAA material
comment resolution process for feedback from IETF to 802
- issues with 802.11
copyrighted by IEEE and not published as I-D, which
prevents IETF from creating dirivative works
can now have access to IEEE documents; archive access
Dependent on 2869bis, finding some spec bugs.
- IEEE 802.11i
- Sent Bernard a "Liaison" letter.
http://www.ietf.org/IESG/LIAISON/ieee802.11.txt
- RFC 2284bis
keying framework
- 3GPP2
Critical dependencies on a radius draft as well as Diameter
related work that we may not in fact be working on.
- 3GPP
Also have various dependencies on IETF work
See slides from Bernard on details
IEEE 802 is not a single organization.
802.1 has a history of cooperation with the IETF.
Less Bell started things off and they are willing to provide access to
the working group. They also allow us into "comment resolution".
We are planning an internet-draft on the history of the relationship.
Good example of a good a relationship.
This is not the case with other 802 areas. Lack of uniformity within 802.
With 802.11 we have recently gotten a liaison.
But there are some copyrighted MIBs and specs that have not been republished,
and there is no right to publish derivative works.
This is preventing development within the IETF.
We were initially refused to archive access, and that we could not quote
from drafts in the IETF work, but now IETF working groups can at least
read the documents.
IEEE 802 asked for and got a radius service-type value.
It defines entirely new uses of radius on a first come first serve basis.
Initiated discussion with 802.1f chair who will publish IEEE work as an
Internet-Draft, and he has agreed to resolve those comments through the
"Interpretation" process as opposed to the "Revision" process.
Whatever that means. But there is a willingness to republish and a
willingness to take back feedback.
Audience: clarification- "interpretation" is a first step toward revision.
3GPP
Issues with the dependency list. Work wasn't on the dependency list that
was in fact critical. Then we were given a month to respond.
3GPP2
More active participation.
AAA Working Group
There is an issues web page. 3 docs in RFC editor queue, 1 in last call
and new work items at the request of 3GPP2.
Major issue is key distribution. Both IEEE 802 and 3GPP have asked for
resolution. There is no document specifying AAA key distribution in
the IETF. Diameter MIB held up on security concerns. Flaws in
RFC 2548 key wrap (informational rfc on vendor extensions).
Russ Hously will help sort through some of these issues.
Radius/IANA update
RFC 2865 defines radius mailing list as expert review mechanism,
but it's defunct. So we need something else, and the RFC doesn't specify
a replacement mechanism.
First come first serve policy is not working all that well.
Specifications are not required, and that results in an inability to
document uses or functionality of existing allocations.
This is impacting radius/diameter migration.
It is very helpful to have specifications.
IANA allocations themselves is not actually consistent with usage.
Lots of unallocated codes that are in use.
Proposal: we need to select another mailing list to substitute for
the expert review function. Either current radius list
or one specified by the AD.
IETF concensus required for command code allocation.
Spec should be required.
Attribute allocations will not be updated to reflect "reality" because
we would have allocated virtually all of them.
SDO Radius Dependencies
Many docs in last call, some heading to ballot.
Service allocations in 802.1f granfathered.
3GPP2 standard requires command code allocations, but that requires a standard.
There are implementations out there, but there are some vulnerabilities.
Alternative is to allocate command codes in radius iana doc, but that's a
can of words due to the other codes being used, but not documented.
SIP Radius Use
Authentication & Accounting
SIPPING not enthuiastic about diameter because interoperability not demonstrated.
RFC2866 not reliable enough.
They could write a MIB instead. v3 and TCP transport mapping might do the job.
Or we could specify retransmission and failover behavior, but this won't help
deployed code.
Third possibility is to just focus on SIP diameter accounting only, and this is
the plan of record.
Prepaid service
Currently in use by cellular operators.
Enabled by addition of VSAs to accounting messages.
PPVPNs
Fast Handoff is also looking at this stuff.
Audience: mobile ip doc lost in id tracker...
---------- Margaret Wasserman: IPv6 Operational Scenarios
Slides at: http://www.ops.ietf.org/Ops_Area_v6ops_Mar03.ppt
Purpose of the meeting
Terminology change: "transition" -> "co-existance"
Focus on getting them to work together on a single Internet with global
connectivity... Looking at four different deployment cases
- develop guidelines for shared 4/6 internet
- develop guidelines for deployment: security and operations
- was focus on transition, now focus is on coexistance
- determine scenerios for deployment
3GPP
Home/unmanaged networks
enterprise networks
ISP networks
Identify as part of the analysis what co-existance mechanisms are needed
to deploy IPv6.
3GPP is far along. Documents nearly done. Analysis document nearly done.
3GPP will review docs in April.
need dual stack.
need a translation mechanism for IMS subsystem
Unmanaged team is also pretty far along.
Scenarios doc WG last call and analysis is under way.
Need a way to traverse IPv4 NATs.
6to4 tunnel broker may be useful.
Enterprise and ISPs areas are under way with Scenarios docs,
but we could use some help for input.
Co-existance mecnhanisms Discussion
- 6 over 4 tunneling (2 forms)
- transition mechanisms
- security and reliability concerns, such as which to use when both
are available; how to make sure operations don't open security
holes via tunneling configuration
- debate over when to use 6 over 4 tunneling vs. NAT-PT
WG requests operator help reviewing documents; may form a review team
Security and Reliability
Which to use when both are available? How does a host make that decision?
US government has made a decision not to deploy v6 into operational v4
networks due to tunneling and firewalls to avoid security holes.
Not right but that's what they're doing.
Dual Stack vs NAT-PT
Dual stack is preferable in most cases because it's simple.
But there are corner cases where NAT-PT or v6tov4 translation might apply.
In particular those cases where NAT is already deployed in a v4 world.
We have had a lot of trouble getting proper document review (endemic).
Need operator help and security people. Want the docs to be accurate.
Please contact Margaret if interested.
Questions? None.
----------- Network Management
Randy: Where's the vision?
We've spent 2.5 years figuring it out since 0 operators indicated
that they used SNMP sets. Are we getting anywhere?
Bush's law: bad ideas take a day whereas good ideas take lots of time.
Dave Harrington: need to work on "migration strategy".
Slides at: http://www.ops.ietf.org/OpsAreaAgenda.ppt
(right after the agenda slides)
Bert: MIB work/review
We have a MIB doctor team.
Trying to come up with MIB review guidelines, to get the docs through
much faster than they've been going through.
Guidelines written, useful also for PIBs.
Please check the document against the guidelines BEFORE submitting for
review so that MIB writers write better MIB docs.
Questions? none.
Bert: EoS and SMIng WGs
Both groups have failed.
Both had an aggressive schedule.
Both had docs, but there is no path to consensus on what we want to do.
SMIng had 6 documents and 1 editor. No additional volunteers.
These groups will close after this IETF (next Monday).
Bert: Next Steps for SNMP and SMI
maintenance mode, "step by step"
could be done with small design team or full WG process as
a generic SNMP/SMI maintenance, but small steps, short timeframe
Go for incremental mode. Do "small steps".
Other groups were too ambitious.
Not all changes will need a working group.
Example: Integer64 and Unsigned64
could be done with small design team or full WG process as
We could do a generic "SNMP/SMI maintenance group".
They get one item and are required to make fast progress -- 3 months.
repeat: small (and focused) steps!
Bert: COPS and COPS-PR
do not want duplicate MIB modules and PIB modules
No new arguments for PIBs.
Operators seem to be saying that they will not use PIBs,
and they will not use MIBs for configuration.
PIBs stay on informational or experimental,
but Bert discourages their work.
COPS-PR protocol is a proposed standard.
It claims to address some SNMP shortcomings.
EoS failed at this attempt for SNMP.
Bert is willing to entertain the idea of transporting
MIB data over COPS-PR.
DIFFSERV MIB and PIB are 95% same content.
Maybe a design team or IRTF RG to see what it takes to converge these?
Randy Bush: you've been saying this for a year. where are the results?
Bill Woodcock: we went through this a year ago.
a lot of ops contributed to the draft.
snmp won't do it. cops won't do it.
Randy: net-conf is born from Bill's doc.
Bert: this is not my last slide ;-)
if certain ops want to continue using PIBs he's not opposed.
Bert: Netconf BOF
We had the netconf BoF and it was very encouraging.
With xmlconf BoF it seemed as though XML was the solution,
but it didn't seem much like a vision. IRTF NM group discussed it too.
Should we used WSDL? etc? It became a grandiose vision,
and we didn't like that either.
So we said, "why don't a few vendors come up with a doc that shows
some vision, based on operator requirements"?
These requirements are not clearly documented and not documented in
one place... but most of us should have a reasonable idea of what they are
What they came out with, 260 people in room, 150 people had read the document.
This was really good. When we asked who would support the work, 50 people.
Which operators? 30 people. Which operators are willing to participate?
10 people. In comparison to SNMP and COPS it was very good.
What we do need is operator involvement: one of my prerequisities would be
a real operator as cochair and that we don't get to a situation where we
were a few years ago where we had plenty of mechanism and nobody willing
to use it.
We need to spend a bit more time to determine whether we *can* split
the data model.
Assuming that it takes off Bert would no longer mandate writable objects
in MIBs. If a WG wants writable objects, that's okay, but it won't be mandated.
Questions:
Faye Li: what kind of operators did you poll?
I'm coming from that ATM MIB world,
and we're using SNMP writable everywhere.
Randy: we've spent 3 years, and gone to a dozen strange fora to ask them.
If you have real operators who want to provide input, bring them here.
Bert: no prohibition on using writable objects, such as cable and ATM teams.
Faye: I went to the BoF and I was concerned that with ATM there's a
well defined model. For Router or DIFFSERV there is not so well
defined a model. People were quite clear that they didnt' want to
specify a model.
Randy: The tragedy for the mass of ISPs configuring routers they do
it with fingers.
Wes Hardiger: Two problems
-- area directors came into other working groups and discouraged
writable objects.
Bert: not what I said, [but close-eliot]
Wes: more importantly, we have to do something in the interim.
Majority of the people agree that xmlconf is the right direction.
But if we stop requiring other groups from doing so,
we'll go through a period of dead space in network management.
We influence the other groups.
Authors: Early goals to get MIBs converted.
Working groups must continue work.
David Perkins: [Presented white lillies to Bert..]
Dave explained later that this was for the funeral of SMIng and EoS WGs
Dave Durham???: will working groups now start defining management information
in XML schema?
Bert: I have my doubts on that.
Dave Durham???: that implies that the IETF intends to create a new data model...
Bert: not necessisarily.
No proposal to reinvent the wheel, according to Andy Bierman.
Randy Preshun: DISMAN working group- everything they do is writable.
Since their charter restricts them to controlling their MIBs
using SNMP, at what point will we permitted to relax that
restriction?
Bert- premature. No working group for netconf yet. Relax.
Randy: talking about XML-based configuration is like talking about
C-based configuration. Syntactic sugar.
A security model for XML is like a security model for PL/1.
Guy from Cable labs and cochair for IPCN (Jean-Francois Mule?):
we have 22,000,000 devices that use SNMP to configure devices.
We have spec to configure SIP and other gateways for XML and
we also maintain SNMP MIBs. We should have some applicability.
Randy: let's try again. We're not saying that SNMP is bad.
Guy from Cable labs and cochair for IPCN (Jean-Francois Mule?):
what's important to me is the data/information model behind the protocol.
there are numbers of vendors that use the same data/information model, today.
Randy: what message do you think is being sent?
Guy from cable labs: don't do writable mibs
Randy: WRONG
Bert: nobody is preventing SNMP from being used.
WGs may choose to do MIBs but will not be forced to do
writable MIBs
And we need to understand the data modeling aspects better.
If the SMI is the best world to specify a data model then we
do a mapping to XML...
Dan Romascanu: IEEE is beginning to use SNMP mibs for configuration,
and like the SNMPv3 security model.
The NETCONF WG is focusing only on the protocol; is a big problem,
because we need to deal with the data model. A new effort will
succeed if both are addressed
ADs: This issue was raised at NETCONF BOF too;
we may need to plan to do parallel work.
The Data model needs to be better understood and it needs to be
addressed, and we need to figure out if it needs to be done at
same time or if it can be delayed for a year or so.
Bert: nothing wrong with people using SMI and SNMP more and more
(certainly not for monitoring).
SNMPv3 is full standard and SMIv2 is full standard.
So it is perfectly all right to use it.
Someone: I was not aware that doing writable MIBs was mandatory.
Bert: explanation of history
Comment: IETF should decide which problems should be solved with SNMP
and which should be solved with XMLCONF
Comment: NETCONF addresses CLI migration and initial configuration
which is not widely done with SNMP. IETF should not mandate
which protocols are configuraed with SNMP and which with
netconf
Andy Bierman: operators want to migrate from CLI to something else,
not SNMP to something else. The vast amount of initial
configuration is not done using SNMP.
Melinda: MIDCOM is going to be a wrtiable mib. The decision was based
on the protocol, not the data expression. Security area
directors are going to be giving stronger scrutiny to writable
mibs; is this true?
Bert: AES support will be required. That work is under way.
Sec ADs will look closer at mib security sections.
Specifically for certain issues like exposing keys in MIBs,
which causes a cascading vulnerability
Curtis: SNMP config and XML conf address different space
Randy: SNMP is used for layer 1 and 2 config by many,
but not for layer 3 config, and this is the I-ETF.
The NETCONF is for layer3 config.
Comment: we are talking about not continuing work on SNMP standards,
not telling vendors or operators to stop using it
Q: why not call netconf to be router configuration?
A: no -- it's for Internet devices (that's the I in IETF)
Someone: My big concern is that netconf explicitly focus on
protocol development and put aside data model.
Margaret: that was not a statement of work, but there was discussion.
Bert: we need to understand the data modeling aspects better (cut and paste).
-------- Prepared presentation by Wes Hardaker
See also his slides at: http://www.ops.ietf.org/WesOpsArea.ps
http://www.ops.ietf.org/WesBoth.jpg
Wes Hardaker: Pain Management
- working last 2.5 years to to network config, not just
device config
- future work:
wireless: could be hard to manage because they are more dynamic
new work should be done for wireless
- OOPS work fixes many problems with SNMP
- goals of life: increase pleasure over time
- SNMP old dog, maybe we can teach new tricks
- XMLCONF solves all problems ... but
- need to avoid dead dog on dead car?
- need to speed up deployment of XMLCONF
- need work on security
- data modelling language
- monitoring needs to be worked
- need to do more work on SNMP
- need SMI 2.1
- bulk data fixes
- security infrastructure utilization
- better encryption support
- Need to push toward new stuff, but must not neglect the
house we're living in.
Transition time must be as short as possible.
C: market forces will decide when XMLCONF replaces SNMP if at all
C: SNMP will continue to be used as needed;
new maintenence work could be done in WG proposed by Bert
C: data model skew problem should be solved
C: Is it fair to have XML work exist when SNMP exists,
even though COPS-PR was told not to do 2 things at once
C: COPS-PR doesn't make a very far leap forward
C: XMLCONF is just like COPS-PR but it uses XML instead of SNMP-like
data