[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

o&m sessions, ops division

This message contains the following reports:

    1       Jul 17 Al Morton             62 bmwg
    2       Jul 17 David Meyer           23 mboned
    3       Jul 17 David Meyer           14 grow
    4       Jul 17 David Meyer           13 dnsop
    5       Jul 17 Dave Plonka           28 ipfix
    6       Jul 17 Andy Bierman          20 netconf
    7       Jul 17 Andy Bierman          27 psamp
    8       Jul 17 Bernard Aboba         33 radius bar bof
    9       Jul 17 Bernard Aboba         37 aaa
   10       Jul 18 Pekka Savola          21 v6ops
   11       Jul 18 George Jones          21 opsec bof
   12       Jul 18 Sean M. Doran         51 multi6
   13       Jul 19 James Kempf           36 capwap bof
   14       Jul 22 Gianluca Iannacco     49 ispmon bof

( correctly mimed :-)
--- Begin Message --- 
On Tuesday, July 15, about 66 people attended one or both
of the BMWG sessions. Sue Hares took notes.
The draft on Terminology for Benchmarking BGP convergence
in the Control Plane was recently revised, and there will be
a short WG Last Call before returning it to the ADs (conterm-05).
The Terminology draft for Network-Layer Traffic Control Mechanisms
completed WG Last Call with one comment
(resolved during a face-face meeting later in the week).
A short discussion of the future Traffic Control Methodology Draft
revealed that time scale will be important for EF evaluation.
The text of IPsec Terminology was completed in this version (01);
there were several readers, with one endorsement,
and two comments on the scope (NAT and IKEv2 are out of scope).
The IGP Dataplane Convergence drafts are progressing with comments, one
identified the need for a note to cover forwarding rate change
after convergence.

In the second session, revisions to Resource Reservation Terminology
covered most of the AD review comments and will be revised again shortly.
Comments on the Core Router Accelerated Life testing Terminology
asked for examples of Management Plane Failures, and identified problems
with allowing complete flexibility in test configurations.
The Proposed Milestone Revisions revealed a growing list, and a need to
achieve "Done" on a few more before adding new work.
Last, there was a presentation of a revised work proposal to benchmark
protection mechanisms and a related draft on MPLS protection.
Discussion revealed that the previous direction to have a common
terminology draft for this work will be stretched and must be worked
further to see if it is possible. Also, a generic IP-centric Methodology
may be useful to benchmark unspecified protection mechanisms, but measuring
packet loss will not be sufficient in some cases. The discussion
concluded that the proposal requires more work before review by the WG.

Status of BMWG I-Ds at close of IETF-57

AD/IESG Review
<draft-ietf-bmwg-conterm-05.txt>, revised to reflect IESG input, LC soon.

I-D Last Call
<draft-ietf-bmwg-fib-meth-01.txt>,  Call ended 3/14.
<draft-ietf-bmwg-dsmterm-07.txt>, Call ended 7/15 with comment, revise.
<draft-ietf-bmwg-mcastm-13.txt>, Call ended 7/5, to ADs soon
<draft-ietf-bmwg-ospfconv-term-05.txt>, Call ended 7/1 with comments/resolved.
<draft-ietf-bmwg-ospfconv-intraarea-04.txt>, Call ended 7/1 to ADs soon.
<draft-ietf-bmwg-ospfconv-applicability-03.txt> Call ended 7/1 to ADs soon.

I-Ds
<draft-ietf-bmwg-dsmmeth-00.txt>, coming soon
<draft-ietf-bmwg-ipsec-term-01.txt>(comments, revise and WG Last Call on 02)
<draft-ietf-bmwg-benchres-term-03.txt>, back in WG, revise and Last Call.
<draft-ietf-bmwg-acc-bench-term-00.txt> New 06/2003
<draft-ietf-bmwg-igp-dataplane-conv-term-00.txt> New 06/2003
<draft-ietf-bmwg-igp-dataplane-conv-meth-00.txt> New 06/2003
<draft-ietf-bmwg-igp-dataplane-conv-app-00.txt> New 06/2003

Expired BMWG I-Ds
<draft-ietf-bmwg-bgpbas-01.txt>, Pending term. progress
<draft-ietf-bmwg-benchres-method-00.txt> Pending term progress

New Work proposal
Protection Switch benchmarking - revised draft in 01, needs more refinement.
--- End Message ---
--- Begin Message --- 
MBONED met on Tuesday, July 15, 2003, with the session running
over until about 1200 (suggesting that I should have scheduled 2
meetings).

I gave an introduction to my ideas surrounding the "Internet
Multicast Documentation, Oversight, and Coordination (IMDOC)"
idea. Discussion surrounded whether this is a directorate function
or not. We will pursue this on the list.

The major topic of the meeting surrounded ASM in IPv6. Both camps
are vocal, with no consensus available on how to move forward
(although those present hummed in favor of accepting
draft-savola-mboned-mcast-rpaddr-03.txt as a WG document).

There was also an update giveon on MSDP, and Bill (Fenner)
described where we are with the MSDP MIB.

Finallly, Micka l Hoerdt described his drafts on Multi-source in
SSM networks (it should be noted that he complained that he wasn't
given enough time for "his" drafts). It was suggested that he
coordinate with mmusic (Collin Perkins suggested that this work
could all be accomplished in SIP).
--- End Message ---
--- Begin Message --- 
The GROW WG met on Monday evening, July 14, 2003.

I gave an introduction to the generalized BGP TTL hack, which I
will write up and post next week. Oliver Bonaventure
draft-ietf-grow-bgp-redistribution-00.txt) was a no-show. Dave Ward
gave an update on Bidirectional Forwarding Detector: BFD, and Pedro
sought input on the utility of draft-marques-idr-flow-spec-00.txt
(he explictly took the protocol extensions out of the discussion).

The WG also hummed to remove draft-turk-bgp-dos-04.txt,
draft-grow-bounded-longest-match-04.txt,
draft-ietf-grow-bgp-redistribution-00.txt as WG documents (or in
the case of the first to, not to adopt them as WG documents).
--- End Message ---
--- Begin Message --- 
The DNSOP WG met on Monday, July 14, 2003. The main focus of the
meeting was on IPv6 DNS discovery. Briefly, the two camps (DHCP
vs. some new RA) were unable to come to any consensus. The RA camp,
however, has decided to combine
draft-jeong-ipv6-ra-dns-autoconf-00.txt,
draft-beloeil-ipv6-dns-resolver-option-01.txt, and
draft-park-ipv6-extensions-dns-pnp-00.txt into a single proposal.

Finally, the WG did accept draft-kato-dnsop-local-zones-00.txt as a
work item, and Mohsen Souissi will be working on a DNSSEC
operational requirements document (pursuant the main focus(es) of
the WG).
--- End Message ---
--- Begin Message --- 
The IPFIX WG session went smoothly.  The group is moving on to mostly
discussing technical rather than political issues now.

Now that the basis for the protocol has been selected, we have moved
passed the evaluation four new -00 versions of WG drafts: Protocol,
Information Model, Architecture, Applicability Statement.  They are all
pretty rough right now, and we're encouraging edit cycles and mailing
list discussion.

As for the IPFIX milestones, we're expecting to accept the protocol
evaluation report (by Simon Leinen) as a WG draft, and submit it to you
for publication as an informational RFC by August 3.  We're intending
to leave the dates at December 3 for submission of the new four drafts
to IESG.

The requirements draft is being edited to go back to AD review soon.
The most contentious point with the requirements reviews is Allison
Mankin's suggestion that IPFIX MUST support encryption and
anonymization.  (The current requirements draft only says SHOULD and
MAY respectively.)  Our position is that encryption and anonymization
is not current practice nor that the user base requires these
encryption and anonymization features.

At this meeting, we did not discuss the contentious protocol issue
about which congenstion controlled protocol (TCP or SCTP) will be
required to be implemented, and whether or not it will be the only
one.  This will be discussed on the list.
--- End Message ---
--- Begin Message --- 
The NETCONF WG met at the Vienna IETF to discuss work in progress.
There were 3 individual submissions presented to the WG for
consideration.  The XMLCONF Protocol was updated to include some
improvements previously discussed on the mailing list.  The NETCONF
Interface proposal presented some issues that the authors believe
are not adequately addressed in the XMLCONF WG.  The authors of
both drafts met after the WG meeting and most differences have
already been resolved.  The SOAP Binding for NETCONF document
proposes a transport mapping for the NETCONF protocol.

The WG seems to be converging on an appropriate set of protocol
operations.  There is also agreement that selecting a single
"mandatory to implement" transport mapping is important.  However,
there is not any clear consensus at this time which mapping to
chose for this purpose.  There seems to be agreement that the list
of choices is BEEP, SOAP, and SSH.

The WG will hold an interim meeting in early September.  The
location will either be Sunnyvale, CA, USA, or Ottowa, Canada.
--- End Message ---
--- Begin Message --- 
The PSAMP WG met in Vienna to discuss work in progress.  The
Framework document has been updated to address some clarifications
and modify the conformance requirements for PSAMP. This document is
ready for WG Last Call.  The Packet Selection document has been
updated and will be revised one more time before a WG Last Call
will be held.  Information modelling details will be moved to the
Packet Report document.

The IPFIX information model and protocol was discussed wrt/ to its
applicability to the PSAMP WG.  A new document will be submitted
soon which defines the PSAMP Information Model.  Another PSAMP
draft will also be submitted soon which addresses the transport
mapping and congestion avoidance mechanisms applicable to PSAMP
devices.

The initial version of the PSAMP MIB was discussed.  There were no
objections to its structure and contents.  There are still open
issues such as configuration of filtering that need to be addressed
on the mailing list.

An individual contribution for per packet records was presented to
the WG for consideration.  It did not appear that there is
sufficient interest within the WG to expand the charter to include
full support of the proposed features.  It is possible that some of
the features will be addressed by mechanisms already under
development by the WG.
--- End Message ---
--- Begin Message --- 
At the RADIUS dinner on Wednesday nite we went over the needs of 3GPP,
3GPP2 and IEEE 802, and also talked a bit about the current
RADIUS-related drafts.

Randy asked the question "what is the minimal set of things that you
must have?"

So I thought I'd kick off the discussion about what things are the
highest priority. Comments welcome.

Dorothy mentioned IEEE 802.11 interest in the RADIUS Handoff Extensions
document. My undertanding is that an IRTF WG will be proposed for this
so that there is no need for IETF action at this time.

There seemed to be considerable interest in prepaid services. So my
interpretation was that this a high priority.

I also heard interest in a document on WLAN RADIUS attributes. This
would include standardizing attributes already in use as VSAs, and
perhaps a few new ones within reason. WLAN access seemed to be an
important topic for 3GPP, 3GPP2 and IEEE 802.

I heard somewhat mixed feedback on a RADIUS transport behavior document.
RADIUS implementations do some bad things, so perhaps a draft saying
"don't do this" might make sense.  But attempting to achieve
Diameter-level reliability may not make sense.

I was not clear about the need for SIP/RADIUS work. Apparently there is
ongoing deployment of I-Ds (e.g. the Sterman draft on RADIUS attributes
for HTTP Digest Authentication), so perhaps standardization would be
valuable in documenting what is in use. On the other hand, I also heard
that "there isn't much commercial interest." Note sure what to make of
this, perhaps someone can clarify.
--- End Message ---
--- Begin Message --- 
At the AAA WG meeting at IETF 57, the focus was on security.  NASREQ-12
is on the archive, and after some last additional reviews should be
ready for IESG consideration.  Tom Hiller presented a proposed way
forward for Diameter MIPv4, which bore a remarkable resemblance to the
solution that is being proposed for Diameter EAP. These both involved
use of redirects so as to avoid providing keys to agents without "need
to know".

Diameter EAP has made considerable progress since IETF 56. It has
expanded from 12 to 40 pages, much of it relating to security issues.
The major remaining issues relate to handling of keys, as well as
authorization issues arising from reliance on redirect by a potentially
untrusted proxy.

Bernard Aboba presented the proposed response to Russ Housley's
guidelines at IETF 56.  This will be incorporated into the -07 rev of
the EAP Key Framework Document.  Most of Russ's requirements are well
understood and can be handled.  The trickiest ones relate to Key naming
and Binding. A proposal was made for moving forward on this and will be
incorporated into the Diameter EAP Keying AVP and explained in the Key
Framework Draft.

There were also presentations on Diameter Credit Control and Multimedia
applications. Diameter Credit Control has had initial architectural
review, which disclosed fundamental issues with the use of accounting
commands for prepaid. John Loughney is trying to strike a compromise
between the traditional "RADIUS centric" way of handling prepaid and the
proposals that were developed by 3GPP, as well as the needs of 3GPP2. As
befits a solution trying to satisfy disparate needs, it is somewhat
complex as a result.

Diameter Multimedia is still garnering its initial reviews prior to
being accepted as a WG work item.  There was some discussion of whether
AAA activity was appropriate in all the cases in which it is being
used. So some input from the SIP community as well as AAA community is
needed to validate the architecture.
--- End Message ---
--- Begin Message --- 
During the first session, the discussion on the unamanaged
solutions/scenarios degenerated into a useless debate because the author
wanted to push a specific solution. ISP and enterprise scenarios have
been rewritten and are much better now.  However, the WG seemed to be in
deep coma when it comes to the the scenarios, the effort may have
dragged on for too long.  Luckily enough, we managed to obtain a dozen
or so new names of operators to provide feedback on the ISP efforts at
least.

During the second session, some experiences of IPv6-on-by-default were
given: enabling v6 caused a significant amount of problems.  This is a
very high priority work to get done properly.  Similarly, thinking about
security is important.  There was a lot of feedback on the floor, but no
clear sign whether there are any work items we're missing.  6to4
security analysis will proceed as a WG item.  NAT-PT applicability
statement ("dn't do it") is being worked.  A guide for writing
IPv6-aware apps for app writers was also in progress, and luckily we
were able to obtain a co-author from the app area to help to make the
document more usable.  IPv4 survey in standards documents have been
updated and have been sent to the area directors.
--- End Message ---
--- Begin Message --- 
Attendance: ~80.  Scanned the draft: ~30.   Read the draft ~10.
Presentations largely followed outline: 
    (http://www.port111.com/opsec/opsec-bof.ppt)
with "Liaison" report from ANSI/T1M1
    (http://www.port111.com/opsec/t1.pdf)

Issues raised: no "risk assesment"/threat model, document can not be BCP
with current, questions about logging (what vs. how), the BCPness of some
items was questioned (details forthcoming in meeting notes).  A precise
definition of proper scope continues to be hard to nail down.

The no-tact assessment is: there appears to be a lot of latent interest, the
trick is to turn that into active interest (probably via interaction with
NANOG, RIPE/EOF/TechSecWG), there is still some question about the place of
this work given the advanced state of ANSI/T1M1, but I still think its worth
pursuing as an individual work through the next IETF.  From there, the
individual work should probably go to BCP or Info RFC.  Revisions beyond
that, in my opinion, should be the work of a larger body, probably a WG.

BTW, this week's Cisco issue is *prime* case in point as to why this work is
needed.
--- End Message ---
--- Begin Message --- 
The interesting fall-out is that we now have a second design team.
The first (tli chairing) is looking at split identity/locator, with
a bias towards 8+8, and an ultimate goal of detailing how it would
work both architecturally and a sketch of the direction protocol
work would need to go in order to produce a full implementation.
We have already arrived at the belief that many options lead us to
some degree of frame-type independence in the in-network and
inter-network network layer connecting locators, with the
end-to-end identifier/identifier connectivity looking like IPv6 as
it is now.  That is, some fallout may be:

a) changes needed to the routing system, or alternatively,
   liberation from the current model's worst deficiencies
   (or possibly both simultaneously and non-globally)
b) some (optional but desirable) host-to-network interactions
  facilitating better site multihoming than we have now

It is early days, and there are very different factions trying to
come to a consensus, although this is working surprisingly well,
given the personalities involved.

The second design team (Christian Huitema, chair) will look at
things with a multi-address mindset, using mobile-ip like means of
dealing with cases where "what" you are talking to has moved from
"where" you expect it to be.  It is too early to tell what the
fall-out will be, however, as at the moment, afaik, we have only
the chair, as the team was first concretely proposed in the second
slot on Wednesday morning.

My bet is that the approaches will learn from one another, and
raise interesting questions at one another -- facilitating this in
an adult way will be the management challenge for the wg chairs.  I
do not believe it is very likely that a future attempt to merge the
proposals or select bits of one and bits of the other is a given,
and starting to think along those lines now will dissuade lots of
interesting work by BOTH teams.

Tactlessness:

HIP should stay where it is, and not move into multi6.  SCTP should
stay where it is, and not move into multi6.

All the other stuff during the meetings was (imho) fluff, mostly to
let people air their various ideas.

It is probably not a waste of time to indulge people, rather than
have them snipe out of a feeling of exclusion.

Finally, afaik, gih has volunteered to replace smd as cochair, a
move which I strongly believe is a good one, and I also believe
Kurtis will benefit from this and also supports the move.
--- End Message ---
--- Begin Message --- 
Right.

My feeling is that it went well, there was smooth concensus for a WG and
rough concensus around the charter points, but fleshing out the charter on
the list is needed. We got some flak from IETFers with axes to grind, mainly
Dave Perkins and Bob Hinden. Charlie Perkins also hinted at an ax, but I
think he deferred delivering a full blast mainly because we are good
friends. If someone else had been the BOF co-chair, I think he might have
made more trouble. Cisco is somewhat ambivalent, because the vendors who
really want the standard are, in essence competing with them, but the Cisco
guys at the BOF I know quite well, and they are wireless guys who see the
technical value of this work independent of the business considerations. In
the end, I think they will see that they will benefit from a standard too
and I think they'll agree to work together with IETF though I think they may
need some persuasion.

The technical discussion was good, there were some questions about the
relationship between this effort and IEEE, particularly around splitting the
MAC layer and CAPWAP manager discovery. There is a question whether there is
some architectural work to be done. I think most of the architecture is
pretty obvious, but there are a few fine points. The difficulty is doing
architectural work is an opportunity for people to get caught up in
philosophy and argue endlessly because they feel there is some deep
principle they would be betraying if they were to compromise. The vendors
want a standard soon, so this would be a frustration. In a way, the
situation is very similar to iSCSI, as John Loughny observed, and I think
David Black would make the ideal co-chair (with Dorothy if she agrees to
continue) provided his employer would allow it. There will need to be close
co-operation with IEEE, and therefore I hope that Dorothy can convince Agere
to let her continue.

Randy, I'll not post a BOF review to the joint I*, if there's any question
from the IAB, you can let them now about this (my vacation train leaves in
about an hour).

            jak
--- End Message ---
--- Begin Message --- 
Monitoring Infrastructure Deployment BOF (ispmon)
IETF 57 - Vienna, July 17th, 2003

The goal of this BOF was to discuss whether a new WG is needed 
to: (i) define a monitoring framework to support day-to-day 
operations in IP networks, (ii) identify existing and on-going 
efforts in the IETF on various aspects of the framework and ensure 
that they guarantee inter-operability among ISPs, and 
(iii) provide clear guidelines to equipment vendors on what 
infrastructure is needed to support monitoring in ISP networks.

The room did not reach a consensus on the need for a WG and 
opposed the proposed charter.

The main arguments against the BOF expressed during the meeting 
are the following: 

  . The definition of how to monitor a network is a hard problem 
    that has already been addressed in the past at the IETF (e.g., 
    RFC 1857). All past efforts have failed. 

  . The problem definition proposed at the BOF is too generic and 
    risks to overlap with similar efforts within other working groups 
    (IPPM, IPFIX, PSAMP, etc). 

  . If the goal is to have ISPs contribute to the work of IPPM, IPFIX, etc.,
    it is not clear how a new working group would help. For example, ISPs
    did not contribute to the IPPM applicability statement in the IPPM WG.
    Why would a new WG convince providers to contribute?

The arguments in favor of the BOF: 

  . Previous works (RFC 1857) only focus on one aspect of monitoring,
    network resource usage. They are not appropriate for other monitoring
    applications, such as traffic accounting and fault diagnosis.

  . Currently, at the IETF there are several efforts that focus on different
    aspects related to monitoring. There is a need for a forum to coordinate
    the deployment, engineering, and operation of monitoring infrastructures
    in ISP networks.

  . No working group deals with the problem of storage (and aging) of 
    measurement data. RFC 1857 addressed the problem of storage, but
    the solution proposed is not appropriate for the terabytes of data 
    providers collect today. 
    
Overall, there seems to be consensus that the issues raised in the BOF 
proposal are of great interest. No consensus can however be reached
whether a new WG is the most appropriate venue to address those issues.
--- End Message ---