Subject: [OPSAWG] OPSAWG Minutes from IETF 71 (Philadelphia)

From: "Seely, Ted A [CTO]" <[email-masked]>
Date: Fri, 11 Apr 2008 15:09:49 -0500

All,

These are the minutes as uploaded today.  If changes, clarifications, edits,
etc.. are required please let me know and I will incorporate them and
refresh the uploaded minutes.

Sorry we didn't get these to the list earlier.

Thanks to Matt and Dave for taking notes during the Meeting.

Scott & Ted

-----------

           OPSAWG WG

           Thursday, March 13,  13:00-15:00
           =========================================================

           CHAIRS: Scott Bradner <[email-masked]>
                   Ted Seely <[email-masked]>

           AGENDA

            o Administriva

              - Mailing list: [email-masked]
               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.

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg