Greetings,
Here are the meeting minutes, sorry about the delay. They will be
posted shortly.
Christopher
IETF Operations Area Open Meeting and Operations Area Working Group
Combined Meeting
2 August 2012, 1510-1710, Vancouver, BC
Minutes by Tom Nadeau - edited by Christopher LILJENSTOLPE
1) Agenda bashing
2) draft-janapath-opsawg-flowoam-req
Sam Aldrin: This seems very general, very high level.
Tom Nadeau:
Ori/GOogle: This seems like a good idea, but like it could be quite bloated.
Co-chair: There is a body of work around this that applies to many areas. There
are common security issues that make sense. Is there real interest in solving
this problem?
Jeff Hass: There is plenty of interest in solving this problem. But seeing this
from a vendor perspective, you have two choices: generate data with
characteristics you are looking for and getting a reply, or a packet with all
characteristics. Then you tell the data path to send that like a normal packet.
The work is admirable, but ambitious.
Bonica: You need to figure out which of the two paths in this work you are
interested in: data plane or control plane. If its the second, we have plenty
of tools. SNMP, CLI, etcâ¦
Jeff Haas: the fundamental problem we have is the programming we have in the
hardware. The problem you want to solve though, is to ask the question of what
is happening to my data once it hits the link. Which path is chosen? Do you
want to ask the data plane what its going versus testing it.
Scott Bradner: This is the same discussion around OAM that came up in MPLS. The
conclusion there is that you bake new silicon. You might want to review these
discussions. IF there is a solution to be had we should have it, but it isn't
easy.
Warren: You can do this in the forwarding plane and the control plane. If you
do it in the data plane, vendors will complain. If you do this in the control
plane, you can do this and query this.
Kireeti: Jeff said its hard, and scott did. Its harder than you think⦠you
mentioned data center. We have 16 new encapsulations for there. This results in
new hashing. Hardware is difficult because we have random seeds generated in
the hardware, which makes it difficult to be told everything you need to know.
Going back to what scott was saying in MPLS, we found that we don't hash well
there so we cheat. Now we hash on random fields in the packet header. To
solve that problem we introduced something called Entropy Labels which improves
hashing of labels. The connection between data and control planes is
important. The CP and DP thought they were doing different things. We have
a trace route model and a ping mode. In the TR mode you find a field in the
header that can help you ping every path. That allows you to ping every path.
Chris: from jabber. Amir wants to agree with you.
Bill Manning: How big is your data center? Why is there a data center
orientation if we are designing things for the IP protocol? What do you do
about virtualization. Is this time bounded? What are the constraints? You have
some clear issue of scoping.
Jeff Haas: one other thing thatâs in the draft that is interesting in the
draft is to say, "this link is underutilized, I want to better utilize that"
how do I do this? Its different functionality, but useful. How do I split it
out.
Chris L: this example is DC centric, but I know of multiple other examples that
are CLOS like that are similar. DC is not the only application.
3) draft-schoenw-opsawg-vm-mib
Chair: There are two drafts for VM MIBs, one from Japan and one from Vmware.
Dan: If you ask for an opinionâ¦I believe the last state change is better. A
time filter is more resource heavy. It moves the problem to the agent, but I do
not believe it is an issue.
George from jabber: Amed â does it make sense to have threshold flags in the
mib to indicate that there is something going on in that tree?
Chris: slide 3, previous presentation. ⦠How about you guys take it
offline/mailing list.
Dan: The question is whether it is worth the pain, pointing to an OID.
J: We want to now if a vm is migrated, how or when. The question is do we
need to go from the entitymib and stick it in there, or â¦
Adrian: is the cpu feature a free-form string? At least there ought to be a
common subset. Will IANA standardize these? Should there be common ones called
out, and if vendor-specific we should handle those too.
Kireeti: I was wondering why we there're different tables. If someone wants to
move a physical machine into the cloud, you want to handle that. What ever
features you put here are interesting for the physical machine and another for
the virtual. Its more interesting if you can use the same table for both types
of machines.
J: I agree we should represent a machine in the same way, but where it shows up
is different.
Chris L: as far as cpu characteristics you called out speed. That is as
important as things like power state and # of threads. I'm thinking of this as
allowing someone to drive a migration and wondering if that station has left
the station and how many people will use a mIB for that. Something like
Openstack or virtual center change their interal workings change their products
to use this. You might want to ask the folks doing that if they want to use
this.
J: The goal of this is to provide another interface for debugging and
monitoring. That data may already exist in another environment. I am not sure.
Ron Bonica: normally when we write a mIB, there is a normative reference. Do
you intent on a reference?
J: Its not critical to have a reference for a MIB. Entity MIB, etc⦠don't
have one.
Ron Bonica: opinions of the room?
Dan R: my opinion/experience what you describe is true for specific protocols.
You can provide some examples where there is no reference. We modeled.
Ron Bonica:
Bradner: A reference to a vmware technical document makes sense too.
Kireeti: You need to write a virtual MIB. What you just said made sense:
people use SNMP so someone has to write it. I also think it would be good to
have a common model (I.E. net mod).
J: This is really for monitoring and troubleshooting. SNMP is good for that.
It is read-only.
Benoit: There is a good point in what you said. Last year ops has several
protocols. What do we use with operational data in a yang model? There is a
bigger question of operational data related to a yang model. This should give
a clear signal to all areas in the IETF.
Kireeti: If you are saying legacy is forcing you to write a mib because of
newer technology, you will never use the newer technology to manage that.
J: For some things snmp is more efficient, and others netconf.
?: we need to separate which protocol and data model we are using.
4) draft-fan-opsawg-transmission-interruption
Sharam: is anything less than 50ms an issue?
Wes George: 150ms is the lower limit of human perception.
Chris L: 150ms at the bottom end, probably higher, the GSM phones we have give
us a different expectation for quality. This work is interesting in that its
trying to figure out what delay applications can tolerate.
Kireeti: there are 2 things going on. The services, do they need 50 ms? I'd
agree with you that we're maybe a little strict. But if IP is my underlying
infrastructure, and I have an outage, how much damage am I really doing? You
made a comment that I don't like: IP is unstable. If you never converge, IP
will never converge. But the underlying infrastructure needs to be really
stable.
George Swallow: I wanted to make correction â the SONET spec has 50ms set
because they were still interfacing with the tdm system that took quite a while
to switch over. So they had to get sonnet way down to meet the total allotment.
Humans can tolerate 100-200ms.
Chair: We are running late, so can we take this to the list?
Adrian Farrel: There eis a lot of use in this work to understand what apps
actually need but I want to distinguish between "some apps need 50ms" and
others don't. The OAM we build needs to support 50ms regardless of what the
other applications need. We have had requirements imposed on us from other SDOs
like rfc5654. But unless we have a long list of apps and none of them needs 50
ms, we might not be able to influence what goes on in the network.
Jeff Haas: The motivation of this doc seems to be saying 50ms isn't important,
as have apps that demonstrate that. When you build devices what seems to set
your expectations. For example, financial apps need less than 50ms. Rather that
having a doc that sets the tolerances, let the applications set their
tolerances.
<unk>: the motivation here is based on information from a deployed backhaul
network. If we built an MPLS TE network the cost can be much higher. Our
analysts say that not all services need 50ms of outtage time. So we can get
more performance from different IETF WGs.
Wes George: 50ms is a crutch. Somewhere we decided that is a requirement. So we
build networks with this requirement. Somewhere you get diminishing returns
based on building a network for that requirement. We need a different
discussion forum that provides guidance for new applications. There are apps
that will need less than 50 ms (financials), but that doesn't mean that eveyr
network needs to support this (its a boiler plate requirement in most specs
now).
Speaker: we want to do some investigation to list some examples.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
