[OPSAWG] meeting minutes

[Christopher LILJENSTOLPE <[e-mail]>]

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.