ÊÊÊÊÊÊÊÊÊÊÊOPSAWG WG ÊÊÊÊÊÊÊÊÊÊÊThursday, March 13, Ê13:00-15:00 ÊÊÊÊÊÊÊÊÊÊÊ========================================================= ÊÊÊÊÊÊÊÊÊÊÊCHAIRS: Scott Bradner ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊTed Seely ÊÊÊÊÊÊÊÊÊÊÊAGENDA ÊÊÊÊÊÊÊÊÊÊÊÊo Administriva ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ- Mailing list: opsawg@ietf.org ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊsubscribe opsawg: https://www1.ietf.org/mailman/listinfo/opsawg ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ- Scribe(s)? ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ- Blue Sheets ÊÊÊÊÊÊÊÊÊÊÊÊo Agenda Bashing ÊÊÊÊ5 minutes ÊÊÊÊÊÊÊÊÊÊÊÊÊÊChairs ÊÊÊÊÊÊÊÊÊÊÊÊo Review and status of work items ÊÊÊÊ10 minutes ÊÊÊÊÊÊÊÊÊÊÊÊÊÊChairs ÊÊÊÊÊÊÊÊÊÊÊÊÊÊRFC published ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ------------ ÊÊÊÊÊÊÊÊÊÊÊÊÊÊNONE ÊÊÊÊÊÊÊÊÊÊÊÊÊÊWGLC after the last IETF ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ---- ÊÊÊÊÊÊÊÊÊÊÊÊÊÊdraft-ietf-opsawg-snmp-engineid-discovery-02.txt ÊÊÊÊ5 Minutes ÊÊÊÊÊÊÊÊÊÊÊÊÊÊRFC-Ed queue ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ------------ ÊÊÊÊÊÊÊÊÊÊÊÊÊÊNONE ÊÊÊÊÊÊÊÊÊÊÊÊÊÊAD Evaluation ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ------------ ÊÊÊÊÊÊÊÊÊÊÊÊÊÊNONE ?: SYSLOG alarm is still active. danr: words and status of ops and management id the charter id there was a little more discussion on the ML about it done, just about ready to go to last call on list scott agrees bob is not here to address doc, david will addrsss rajiv is there to present his work shane not here may be much shorter meeting than scheduled time for. ÊÊÊÊÊÊÊÊÊÊÊÊÊÊActive Drafts and related issues ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ------------- ÊÊÊÊÊÊÊÊÊÊÊÊÊÊdraft-ietf-opsawg-operations-and-management-03 ÊÊÊÊ10 Minutes ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊHarrington ÊÊÊÊÊÊÊÊÊÊÊÊÊÊdraft-ietf-opsawg-smi-datatypes-in-xsd-01.txt ÊÊÊÊ10 Minutes ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊNatale ÊÊÊÊÊÊÊÊÊÊÊÊÊÊdraft-ietf-opsawg-data-model-doc-template-00 ÊÊÊÊ10 Minutes ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊHarrington david harrington to talk about his drafts ops and mgmt draft some feedback, added to latest rev, some left been in the process of recruiting a co-author; because you feel you need one? yes. Êneed some extra eyes and feedback. esp w/folks w/op background would like more feedback in doc, checklist in back, appendix.... provide guidance to ops directorate to do reviews, if we can get agreement will try to align checklist with document. added some examples, something that has been missing. ----- Discussion / Presentation for smi datatypes in xsd Ð David Harrington revision published. Document reflects comments to date exception: bob natale & yan will put out a new revision to addr them they would like to see it go to wglc in near future a couple of information nmrg has doc on measurment. Êinfo on tcpdump -> snmp info -> xsd format to share amongst researchers spoke with juergen. Êsome of xsd in measure draft didn't match xsdi mi draft xsd mi was more specific. Êjurgen will change bert: when did this happen? david: sent recently bert: snmp measurement ready to go to last call. ÊI am shepherding,Êif more changes please let me know. xsd patterns for oid and for --- netconf working on data modelling. there are some available tools. Êlibsmi is on eof them take an smi doc, and spit out xsd. concern about taking to wglc is that consistentcy among tools, and doc. don't standardize based on an implementation. Êinappropriate to say wait until tool tells us what to do. Êtools are implementation of this, despite intermediate step to get there. Êlooking at implementation of this in a roundabout way. implement feedback if any problems trying to implementation document... believe xsd close to wglc. ------ data model doc template new doc. Êa doc been working on for mib docs that provides template for text in doc that surrounds mib module covers things like ÊÊ- how relate to other modules ÊÊ- recommend specific chaps in doc to talk aobut structure of mib just about done thru individual submission. Êtemplates are avail on tools web site trying to do a generic version, so will work for other data models being done since we don't actually have a solution as to what netconf data model looks like, it is a bit theoretical for now. there are a couple of sections that need work. Êspoken with dan and ron regarding. mib doc: talk about internet standard framework. ÊIssue carried over to snmp protocol distinction in ietf mgmt framework, 3 parts - protocol that carries data - modeling lang to write mibs - mibs themselves that model data want to maintain this going forward in other languages, including one for netconf but some of netocnf proposals are defining capability to define actions as part of data model. so mixing discussion w/in ietf, whether we want to continue separation opsarea is probably place to have discussion this wg would be place to have discussion danr: ask. Êif make assessment in iesg, will be asked why why is ops area to define such a template at ietf level doesn't show up in name of doc. ÊÊÊit's about network management data models. so not full ietf-wide data model template "right" appropriate for this wg to talk about network management data template not whole thing. danr: discussion about language, and apparea asking aobut specificity here yes, and expect that to be part of discussion second part of doc to deal with... second boilerplate security considerations boiler plate is one written for mib modules. Êrequires if pub mib mod doc, id all writeable objects in mib and discuss sensitivity and then readable objects, and discuss that and 3rd, protocols used ot carry data mentions as examples, security features in snmp v3. auth, acc ctl if generic data modeling template, need to clarify for things other than mibs. that's not an easy thing to do at this point. are others... syslog wg has structured data elements. Êmore machine readable. supplements syslog text netconf is doing work. a couple of boilerplates that need to be updated. Êthi sis appropriate place at least relating to network mgmt data models. started this from the mib template. Êhow much applicable in other areas. its' rough. Êplaces tht have refs to mib/snmp that need to come out but concept must remain. ---- there is a fourth doc been told could pub when did ops & mgmt draft, did survey of existing ietf std protos and data models. since alreay in doc, will pub. someone that is interested in co-authoring that. think lower priority athan ops and mgmt draft. need feedback! q's comments? nope... =============================================== ÊÊÊÊÊÊÊÊÊÊÊÊÊÊIndividual Drafts ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ----------------- ÊÊÊÊÊÊÊÊÊÊÊÊÊÊdraft-amante-oam-ng-requirements-01 ÊÊÊÊ15 Minutes ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Shane Amante presenting - talking about oam for nextgen nets. Êreal problem... networks operating for several years now, increasing in size... update ping & traceroute to accomodate for paths with link aggregation, etc. -- overview sob: ietf oam, or itu oam or ? ietf oam specifically. Êat best complentary to tampls oam not to capture thier requriements sob: itu has inband inviz signalling to understand state of link vs ping and traceroute yes, toward ping an dtraceroute side. -- why use lag, ecmp? nets will end up aggregating, so we need to deal with it. -- background & goals were other drafts stepped back to write requirements -- scenario 1: traceroute through routeed hops test may go over different path than actual traffic ron b: agree with general way you are going, but not sure agree with last thing said. Êping/tr from R1 and R3, every router will do hash, won't it do same thing every time? inside draft... solutionn, where hash not just on outer ip header. Êhave hash info in packet. ron: so can test all links of lag? traceroute context, find out which link used and force same path to test. ron: tracreroute not same path as customer traffic sob: talking about operators operating this, not customers operating this. yes, although inter-as requirements. Êsome minimal info, but not revealing exact details of others networks. Êenough to say problem is "there". -- scenario 2: traceroute thru 1 switched hop same as before, but l2 sw. l2 sw is aggregating need "outgoing" and "incoming" link id -- scenario 3: tr through 2+ sw hops switches typically peek into upper layer to do hash dan r: can you define what you mean by oam tools? traceorute and ping dan r: when say switch between tools, you mean switch at different layers? yeah, l3 traceroute and 802.1ag. Ênice to integrate in final don't know that ietf can do that, but should express goal if switches don't unerstand, can't tell aobut differnces in LAG2 -- other scenarios benoit c: getting ecmp... monitor ecmp exist on path; or use a single one? use a singel one. Êthe one that you want? sob: also report back what you want. two different contexts. Êping, want to chose path traceroute, tell # of ecmps that have from node traceroute give richer info back. Êversus ping. want ping to follow data plane as much as possible need to tell vendors to put minimal functionality into say, line cards, so don't have to go to general route processor to but tr, will probably get forwarded up to routing engine, benoit: would ou like to have the tpe of ippm featrue to get metrics about paths. ippm is aobut active probing. Êpacket loss, delay variation, etc. would you like to have feature, a to b, 3 paths, and metrics of each path are blah blah blah answer is yes, but... in requirements draft. Ênot speaking solutions. sob: ippm is a wg on measuring methodologies. Êbut it uses other otols such as ping so if have ping that has sect which path takes, then ippm could use something like that. that goes to perf monitoring aspect. proactive and periodic perf monitoring as being important so not only ad-hoc troubleshooting, but long-term [go back to draft.] sob: should look at ippm, design ted seely, as self, been needed for a long time confused about how get behavior on sw or router can understand tr. Ênot punt, forward along packet if icmp, will punt. will have to have vendors retool asic for certain packets. sob: most tr is actually handeled in processor. ted: where's packet loss. Êon line card or on egress.. so a couple ways to answer question. Êtrying to say, need to specify solutions that have a new label or new code point so that it can be picked up at the line card, and handled in some way. Êideally at asic. not just user data packet, put fivetuple from ip in algorithm. [[need to look at IPMP drafts...]] been living with problem for a long time. Êshouldn't be averse to having people specify new code points,e tc. may take 18-24 mos to get something but want people to think about problem. we need something, can we come up with something using existing toools? donÕt know, but need to ask. danr: did you get to perf mon bullet. well... proactive perf mon. do have in ietf already doc that defines how to define synthetic traffic: 4149. may want to refer to work. will look, may need to extend to accommodate these scenarios. danr: yes. -- intra-AS OAM reqs. the meat of the document. is a fair amount of work with MPLS already. sob: to be anal... the requirement is to be able to select which path it takes the implementation might be to pre-select which key to use. you could, in thy, if had enumeration of parallel paths, say "use 0" , rather than here are goobers that will cause you to use path 0. thought about that. Êhaven't gone down path of selecting each link... would much rather say "here is IP header to use" and you do whatever you need to do at each particular hop. sob: trying to tease apart requirement and solution. Êhear solution not req. a requirement: to select which paths to use. vs: to imitate customer traffic by inserting 5 tuple more phraseology stuff ted: I would steer away from "imitate customer traffic". ÊI hear DOS attack. %BW Util: to understand efficiencies of hash algorithms -- inter-AS OAM requirements stripped down from prev slides -- path capabilities how discover that going thru devices supporting capabilities do via traceroute? or... special label/codepoint ted: the big devil's advocate q. Êhate to do it. Ê5-6 yrs ago ew had this thing called sourceroute, and we all blocked it from our nets. Êdoes this suffer same fate. don't think so. ted: it can be used against you by evil people. good point, consdier more. perhaps I'm too optimistic, good an not evil. ted: that's why we blocked source route sob: clear the evil bit ron: like to answer ted's then draft a little different than sourc erouting, not active on every packet you receive when receive a probe, authenticate source, and see if want to pass on and rate limit... and not dos attacked by fake probes do something like traceprobe, have to be secure. general comments on draft * strongly support requirements. Êas individ contrib. Êthink these are real problems that ops wrestle with. * draft needs to be worked. Êneed to do ... ÊÊÊÊ- codify requirements. ÊLanguage of requirements not solutions ÊÊÊÊ- then think about solutions. Êsome are pretty easy, extend icmp. Êcan't do that here, would have to go to Intarea sob: could push requirements doc for them to consider ron: sure, or write docs and bring to inteara. ron: some of reqs at app layer. Êdoing the app that sends traceprobes. maybe could do that here, maybe not. Êopsarea normally doesn't write protocol oam, so maybe. parts very difficult. Êswitches might snoop l3, but don't say l3. sob: but management... ron: true, if own mibs typically, can assign ip addreses to internets as well, although typically don't can't look at them as black boxes ron: in any event, support working requirements doc. Êthink about solutions. Êlots of pieces to solutions, some here, some others. ok, other questions... questions from others... split to doc that is tuned to oam for mpls, and oam for ip Êso INT area could digest IP requirements. vs. requirements to MPLS. ron: not sure needs to be split yet. Êreqs could be one big doc. Êbut bits and pieces of solns may be many docs. danr: bert and I participated 3 yrs in 802.1. Êaware of the oam work there. this is a very complex problem. Êstarted wth 1ag. Êthen spun off a couple more projects and still growing. Êany work that would be undertaken should start with taxonomy or ... greater problem that ops will be facing soon , if not facing already what tools to pick. doc should start with review of what exists at l2 and l3. Êfrom here define what needs to be added. my understanding wrt to l2, is that this doesn't exist. not sure how much taxonomy will help. Êhave been battling for a while. Êonly now coming to realization of how much trouble because we haven't had tools like this. danr: yes and no. Êif talking about aggregating links, have tools that do some measurement. ÊIf your talking about bw measurement at two layers, similar or proportional results. confess not having read doc yet... at least from your talk have feeling that there is some relevant work. are solutions to some of these problems. Êmpls wg in particular. beyond that, not much that exists. danr: think if undertake, should limit ourselves to requirements. talking aobut new oam protocol is a broader thing that should be discussed at intarea and have proper bof. Êbut we can help it by doing reqs doc. i am not trying to solve all problems of IETF, or even all SDOs. but I need solutions for my running networks. but want people to to think about real requirements. Êtake time to do properly, rather than ad-hoc that solves partially bert: I can go to 802.1. ÊTalk to them about not wanting to do oam for other sdos, and understand requirement that l3 we want to use just one tool. Êbut pretty sure even if proper solution, pretty sure the ieee 802.1 will continue define their own schemes. ÊThere are environments where the don't care about l3 beniot: haven't read draft, but is one assumption, for icmp. Êhave two types of load bal. Êper packet and per dest. Êthis assumes not per packet, or can't conclude eveyrthing. should ned to state assumption fair point, should call out w/in draft. poll of room by speaker. Êhow many folks think is problem, and area where ietf should be doing work. most of room. AD's and chairs raised hands too :) ted: next steps? should have discussion in opsawg. Êand structure, and laise with othger wgs to work on solutions. Êcould decide here now ted: first , have to take to list. from requirements perspective, think right home, but defer to ADs sob: need to tweak charter, but seems rational. [[mjz: should post notice of draft to ippm list too, since old IPMP work]] ÊÊÊÊÊÊÊÊÊÊÊÊÊÊdraft-zinjuvadia-traceflow-00.txt ÊÊÊÊ15 Minutes ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Rajeev Manur Presenting - working on similar problem. Êthis is focused on solutions. -- agenda -- motivation as last time, also think policy based routing -- use case scenario -- proto operation--1 traceflow is inspired by traceroute RQ is request, RSP is response RT1 is starting point RT2 responds, and continues probe to RT3 too at each place, punt to cpu ron: you said probe hits ctl plane on rt2 what causes it to hit control plane? have a slide on that. Êhold on -- proto op --2 : fan out exercise all paths keep proto as stateless as possible which is why 3 responses are scaling implications Ê[oh yeah ;)] so will keep probe identifiable. ron: tracing rt1 to rt3. Êas part of this, sent 4 probes to nexthop, 3 to rt2 and 1 to rt4. Êhow did it know? RT1 knows. Êit sends to all equal cost next best hops. -- proto op 3 -- TLVs flow descriptor inside probe first 256 bytes of data packet that want to traverse so asics can do same hash. Êby just offsetting pointer have bitmap to say what you want and every hop have some authentication also have concept of termination TLV. Êto stop beyond domain boundary (or some nearer point) could have some other thing too. response, can depend on domain of originator. can respond coarsely outside, with rich data inside also record route tlv. get whole thing. Êsent back in response. ÊÊÊhelps graph when fan-out result tlv - say if can forward, or will drop because of acl benoit claise w/cisco: have not read draft. Êhate to say that but may have IPR based on previous diagram. if want to consider as wg item. what should I do? Êread draft and specify. cisco has standard process to report IPR. Êshould teach you to send note to IPR officer, and post the right stuff. once posted, send to ML ron: q about RR IP option? Êno, it's separate, not same as RR IP option. -- legacy support have thought about solns. Êbut complicates protocol. thought about sending probes that look like data. but lots o' problems with that -- encapsulation not religious ÊÊÊcan do with IP or ICMP ÊÊÊrfc 4884 ron: recommend the ttl expiry rather than router alert many nets block traffic w/router allert muchav: co-author. Êone problem with expiry, when inc ttl, and tyring to send hoping to send back... since the header not equal to data flow, may not take same path as data when have different ttl, might change data path ron not sure I agree w/analysis, but let's talk offline. -- open issues legacy support, how much do we need. is there sufficient interest to continue shane amate: for those folks that were not at Intarea meeting mark townlsey made interesting point worth mentioning here. this solution space/requirements, apply to large networks. one question that he proposed... do we need to design solution so it works only on routers & larger, or talk to Microsoft and Apple about putting into thier OSes. from my perspective as a carrier, want only in larger classesÊwhere problems are today and in future. if folks have sufficent interest, go ahead. Êbut need to make sure solve problem for big nets. ronb: as individual: we're interested to solutions in space, but given that just saw requirements 20 min ago, and given work here is fairly nascent, we should hold off a little while, chew on requirements for IETF or so, and then begin figuring out solution space. ÊMaybe this is part, maybe not. Probably not ready for wg doc yet. sob: and please do contribute to the requirements because you want a particular solution path, shouldn't inhibit you from contributed to requirements. ÊÊÊÊÊÊÊÊÊÊÊÊÊÊCharter Discussion/AOB ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ----------------- ÊÊÊÊÊÊÊÊÊÊÊÊÊÊGeneral discussion ÊÊÊÊ15 minutes ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊChairs/all any open issues? end.