OPS-AREA Open meeting minutes (based on notes taken by Warren Kumari and David Kessens) Tuesday November 9, 2010 Morning Session Area Directors and Meeting Chairs: Dan Romascanu and Ron Bonica (remote) agenda: http://www.ietf.org/proceedings/79/agenda/opsarea.txt meeting-materials: https://datatracker.ietf.org/meeting/79/materials.html#wg-opsarea 1. Note well, agenda bashing, note takers, jabber scribe, blue sheets - 5 min 2. Exporting MIB variables using IPFIX ? Benoit Claise - focus on big picture - motivation: -flow & counters not synchronized, need to do SNMPgets and IPFIX at the same time - two overlapping data models - For example, the IPFIX record has the InterfaceName (see RFC2863), this duplicates information. We don't want to have to go check the mapping with the ifTable. - can be used instead of SNMP notifications, but is not the goal, we should NOT bypass the SNMP access mechanism.... - The IPFI metering process MUST check if the MIB variable can be accessed by the user / group. - Examples.... (Go see the presentation: http://www.ietf.org/proceedings/79/slides/opsarea-0.pdf) - Non-Indexed OID, Indexed OID. - IPFIX implicaitons: Need 2 new set IDs, Targeting STD track. Q: Dan: I assume the objects that have a size range, it will always use the max? A: Max or variable length.. - Patent-778837 TODO : - Better explain the concept / use case. - Mode examples. - Add feedback. - Validate security section. Scott B: What kind of IPR ? BEnot: thinks it is standard Cisco IPS Dan: 1) Is the MIB cast in stone from the perspective form this work, no need for changes Benoit: Yes, this true 2) Time sync with sending MIB or actually when measures are taken Benoit: time is last packet of flow, might be specified different 3) what access are being exported - read/write or notify Exporter needs to be able to internally represent capability Benoit: need exporter that can speak IPFIX and SNMP Hardaker: there was a draft on delivery of multiple OID value pairs in one PDU there is a lot of interest among my customers Andy: currently export OID ? You are exporting the OID of the MIB. Is that is instance added on? Is the value included in the OID? A: No, as including hte OID it will require a new template for each index. So the Index in the export. ----------------------------------------------------- 3. Proposal on the table for Kerberos security model for SNMP - Juergen Schoenwalder - ISMS has one doc is still on RFC editor que - One topic was a proposal to develop Kerberos model for SNMP - Come to the IMS meeting if you have views on this. ----------------------------------------------------- 4. NAT444 OPerational concerns ? Chris Liljenstolpe - Changing CPE can be expensive and cause customer churn most CPE are v4 only - conflicts between 1918 space on both sides of CPE options: - avoid nat444 - deploy and hope for the best - deploy nat with reusable space that is not recommended to use for this already - For some /8 is too small, but can use regions of NAT444 - For all, prolly /16 is to small. - In between is jut right! - The space is reusable but reserved for NAT devices. - Space has a time horizon, when CPE is all replaced. - We are running out of time, SPs see BIG issues looming with overlapping RFC1918 space. Do we want to request (as the Ops Area) a new reserved block for this? Wes: if /8 is too small, if we allocate a /6, than we can kill ipv4 quicker ;-) A: Plan is not to kill v4 :-) Q (Lee Howard): I don't hate v4 and don't think we need to kill it. I think we need this! Need something between 8 and /16. Closer to /8 is better. Q (Rudiger): Is there a requirement that this has to be contiguous? A: No! FQ: This is a big ask, and will take a long time, maybe big players can contribute space. Are they willing if they need this? FA: 1: Impression is that this is all big players, but it also affects small players too! 2: Carving out addresses -- from talking to policy folk, if we do this, it will limit our ability to request new space of a year (in APNIC region). A (Ron): Since 2002, someone has come to the IETF... (Inaudible)... Every year, someone has come to the IETF asking for a /8 for their favorite mechanism, and it always gets knocked down. I think that if you ask for a /14, /15, /16 you will probably get it, if you ask for a /8, you will lose! A: Yup. This is why we have a more general draft, so we can figure out what the right size is. Q (Wes): Few problems if we decide to fix this: Even if you try push this through, is this the RIGHT body to do this. Getting something through the IETF takes so long that there will be no space left. A: If OPS Area sees this as an issue, we should at least try. FQ: What if we DON?T do this.. FA: Kessens: Big issue is that this is a protocol issue. This is one of the cases where the IETF has to move fast (if we move at all) as we need it to be IANA space - it is a global allocation. Q: Wes: I think you have leverage -- getting donations from interested parties (and not all will be fair!) -- you might be able to get IANA to MATCH your donations. This might help avoid the policial issues! A: We had considered doing this, but in some regions this doesn't work... Q: Lee Howard: Pity to don't have a draft to move to last call! I haven't heard and objection in this room. I proposed a /12 as a strawman. I haven't spoken to others on the ARIN board, but I understand that, if you are using space, it doesn't need to be routed. This should be allowed within the ARIN region... A: Dan: Pessimism of getting though through - the IESG has some activities on record where we CAN do things fast... A: Ron: Chris -- I suggest you talk to ARIN and see what would be ok with them. 2 ARIN folk submitted a draft (ECHO). If you ask for a small block it might be OK (Tech issues). A: Scott Bradner: It is not an ARIN draft - it happens to come from folk who volunteer for ARIN. There was a proposal that the ISPs donate space - I don't know what happens in ARIN if you donate space -- this implies that you were not using it... Q: FT: I don't see anything against this, but I think it is a waste of time - it will be a temporary solution, and putting effort to deploy the final solution makes more sense. Use this energy to be prepared for the future... A: I don't think that deploying this will slow folk from replacing their CPE... FQ: Existing customers that have legacy CPE can just stay on v4 only. FA: We have a finite space of addresses, and I need to start shifting space around to support mobile folk, that doesn't do v6. Want a temperature check from the room -- should we got together this week an write a SHORT draft for bring back to the Ops meeting on Thursday? very mild consensus for going forward (no objections, low support). Dan: mild consensus Fred: socialize on Thu, propose on Fri in v6ops Dan: please go ahead with preparing a brief draft ---------------- 5. WG Status ADSL MIB: WG was recharterd. Set of MIBs for GPON. Docs have been reviewed by WG, and made WG docs. Going (as a packet) to WG last call. BMWG: Just been recharted - interesting new work. Priority flow control, content aware devices, flow export benchmarking, and some BGP stuff. SIP perf metrics completed. About to finish LC on the framework. DIME 2 docs in LC. Some IPR issues returned rfc3588bis to IETF LC. DNSOP. Moved NS mgmt just done WG LC. At last IETF we had a bar-bof for NS control protocol, AD asked for this to be in DNSOP. There are two competing approaches. We will discuss this in the meeting this week. Also a draft on v6 whitelisting. EMAN New WG. Lots of discussions on the list. Started in Opswg, charter has multiple aspects. We want energy aware devices and mibs to manage them. Q: How did the crater come about? A: When there is new work, the opswg that is a melting pot of new work. There was a draft on power requirements, asking if the IETF was the right place to do this. There was some support, the AD sponsored the new WG, and the charter was discussed with the IESG and the IETF discuss / LC. GROW 2 docs in IESG eval. MRT graft and graceful shut doc. Virtual aggregations drafts that have gone though WG LC, not enough review yet. Added a new doc, Unique Origin. IPFIX Close to finishing items on current charter - all docs in WG LC or further. Session tomorrow, discussing new potential items. Considering moving proposed to draft std, fix some errata. MBONED No chairs. No report. NETCONF 4741bis and 4742bis in AD review. Some discusses on (another), ended up a bit late for submission. Network config and access control is ongoing work. Netconf systems notification also ongoing. NETMOD One important thing is that we rechartered (cos we were done). David Partain resigned, and we have a new co-chair - Juergen. Going to more operation phase, need to look at data models, etc. Start with a few core models - systems and interface model, also conversion between SMI and yang. OPSAWG 1 ID went through the IESG, back on the agenda. Full agenda this time. Proposal to allocate /8 for NAT444. New activities, will need to get the charter changes, config of latge IP networks, overview, dynamic managment, etc. OPSEC Warren recently took over opSec Co-chair from Joel Jaeggli, so have large shoes to fill. Oh, and Joe Abley sends his apologies, he is unable make it to Beijing. Since the last meeting, we published RFC6039 (Issues with Existing Cryptographic Protection Methods for Routing Protocols) Currently have 4 active drafts. draft-ietf-opsec-igp-crypto-requirements-04 --- Approved and is now with the RFC Editor State draft-ietf-opsec-ip-security-04 --- In IETF Last Call Security Assessment of the Internet Protocol version 4 draft-ietf-opsec-protect-control-plane-04 --- AD Evaluation::AD Followup Protecting The Router Control Plane RADEXT Published a doc. 2 in IETF LC 3 in WG LC Wrapping up work on a design guide to help other groups define radius extensions. v6OPS Worried about Ron, so we have been sending him reading matter. He has 9 drafts in his queue, one has gone to the RFC Ed. This week will be discussing 22 drafts! Objective to work though operators deployment considerations, hope to coalesce these into smaller set! It is not surprising that folk have woken up and noticed! 9 of the drafts are from operators. Much is repeating work that we have already done, but now we are looking at it from a different angle. - Ron: Of the 9 docs, 5 are in the editor queue. Will start reading rest this week! 6. Open mike: nothing brought up