OPS Area Working Group and Open OPS Area meeting
Wednesday, 27 July 27 from 9AM to 11:30 AM

minutes by Linda Dunbar and Bhumip Khasnabish

Scott Bradner started the mtg. and Chris could not be here.
Scott started with citing the “Note well” and mentioned that a few folks
will take notes.

More than 100 people attended this meeting (at one point there was
standing room only).

1 - An Overview of the IETF Network Management Standards
	draft-ietf-opsawg-management-stds

Mehmet Ersue presented IETF Network Management Standards draft.

Changes (slide #5) since prague:
Introduced new appendix on the “high level classification of management
protocols and data models” as a dispatcher
Reduced text for security requirement on SNMP and referenced to RFC
Reduced subsection on VACM
Merged subsection on RADIUS authentication and authorization into the
section SNMP transport security model
Section on DHCP revised by Ralph
Next Steps:
Draft is also discussed in IP Suite WG session in the NIST SGIP meeting
on July 15, 2011
Add an appendix for the high-level overview of IETF MIB modules
Clean up I-D references 
Add PANA? 
What’s next:
We think the document is already stable and go to OPSAWG LC after
cleaning up.

 Scott asked if anyone has any opinion
Fred Baker: PANA is very funny to me. What is the real objective of the
real document?
Mehmet: Authentication
Fred: How PANA can help
Mehmet: May be we can extend PANA
Fred: I don’t think PANA is needed in this document.
Mehmet: maybe one sentence is enough
Scott: No other opinion is there, so it is a reasonable one to do, and
this sounds like a rational approach

2 - Inter-Carrier OAM Requirements
	draft-georgiades-opsawg-intercar-oam-req-00
	was presented next by Mike (?)

Scott announced that the Speaker will send the slides for uploading soon
AIM:
To support the operation regional scope of OAM mechanism proposals
To differentiate between single carrier and inter-carrier OAM
requirements
To differentiate inter-carrier requirements derived from
inter-operability versus business interworking considerations:
To define the OAM operational area scope:
The draft attempts to list all single carrier single technology
requirements identified within IETF, ITU-T, MEF, and IEEE
Also wants to address: network OAM vs service OAM where the latter will
be of interest for end to end inter-carrier
Inter Carrier OAM requirements addressed so far:
Should be supported by MEs that are handled by different operators
Some questions and Open Issues from the mailing list
How the OAM system can monitor QoS 
Scott asked how many people had read the draft - 1
Scott asked if the author had talked to any carriers?  
A. yes, 2
Scott: is there any parallel activity in ITU-T? 
A. “No.”
Scott: how many people think it is a interesting work for the WG: A: 6
Scott: Some people think that it is a topic of interest, so Scot will
take it to the list.
Dan (AD) says there is mild interest only, so let us talk to the list
and see what happens.

3 - Shared Transition Space
	draft-bdgks-arin-shared-transition-space
	draft-weil-shared-transition-space-request

Scott said that this idea has been discussed in IETF and ARIN regions
There was a good deal of support in ARIN but the ARIN Board was
concerned about authority, and asked IAB for advice. IAB said that ARIN
has no authority on this.
ARIN president said to Scott that ARIN can do that assignment if IAB
asks for it.
Two drafts will be presented and then Fred Baker will make comments
after that.

	Victor Kuarsingh presented the Shared Transition Space Draft
General proposal: should IETF get assignment from ARIN
Operators are implementing IPv6, or soon will. During the transition to
IPv6, need to continue supporting IPv4 for legacy CPE equipment and IPv4
only content sites, even after IPv4 extinction. 
For use only by SPs to facilitate transition
Maintain separate space from RFC 1918. Avoid overlap with customer
premises
Changes since IETF 79;
Per IETF feedback, requested /10 address space from ARIN
ARIN willing to allocate Shared transition space draft policy

Stan Barber presented the supporting draft
Provide foundational information and support for draft-weil-shared
transition-space-requests
We want find out what IETF can do. 
Reasons to do this:
Lots of people think it is carrier grade NAT. This is one of the
purposes. But it is not all. 
Alternatives:
RFC 6319 outlined alternatives:
Some options were: global unicast space (multiple allocation for same
use)
These have same basic effect as shared
Arguments and Rebuttals
NAT is bad
No feasible alternative in many cases
 NAT is also not the only use case for shared transition space
Some proposed uses of this space breaks host operation: Yes, but
manageable (better than no IPv4 at all)
This space could be misused: this is not a technical argument (many
technologies suffer from this)
Nobody will use it: incorrect-will be forced to solve IPv4 run out. 
IPS shared space uses up inventory: signle assignment vs. multiple
assignments to operators for the same purpose
/10 is not enough: does not argue the need for block. /10 still useful
and operators have sated this. 
It will not delay exhaustion: True, but can help reduce CGN need and
solves real problems. 
Just use IPv6: IPv6 connectivity in itself does not solve IPv4
connectivity needs. IPv6 is not ready everywhere
It Delays IPv6 deployment: this action helps direct resources to IPv6
Summary: we think we need it. It solve real problem. Arguments against
it don not overcome the benefits (i.e. benefits outweigh the drawbacks)

Fred Baker then spoke
RFC 1918: this is really intend to support isolated networks
If the prefix is used to address private networks and therefore free
public address space for use in a network. Note: that this was the
intended use of the RFC 1918 address space: NATs had not been invented. 
I see this is the continuous effort for RFC 1918
If we have RFC 1918 customers, have private address which 

It was noted that the Shared address/transition space is for service
provider (SP) community, and that it is not for general community.
ISPs may not be making more money but the number of endpoints is
growing.
If we deploy IPv6, we may be pushing them (consumers) too fast to get
there.
Juli E. (?): How it affect the CGN deployment, the walled garden
deployment
Stan if you can help us?
Fred says that he wrote a note in 1988 to IANA, and got Class B address
(like RFC 1918), and handled the problem like that ones that happened in
1988 (don’t need to connect to the Internet). 

Cathy A. (?): Member of ARIN advisory council, says that they have
limited time for /10 address provisioning, and is it urgent? If it is,
we need guidance now.

Next Step:
Time is of the essence due to the dwindling inventory of IPv4 addresses. 
Draft-weil can be processed separately or in tandem with this draft. But
the important thing to these authors is the disposition of draft-weil. 

Bradner: we don’t have time to go through normal WG progress. We might
need AD sponsored draft to accelerate the process.

Scott asked for comments.

Dave Taylor says that the requirements are contradictory but both may be
true. The speaker says that CGN deployment may not use RFC 1918 may use
squat space.
Dave Taylor does not agree.
The speaker says that it is important to overlap with customers address
space, and the speaker says that he did not discuss where multiple
layers will work or not.
Lee Howard says video devices (TW has 16 M subs) and supports this.
Ross Callon (Individual) says that NAT has a history, and Scott said
that NAT was evil but it was needed. 
Ross continued by saying that we slowed down because we did not get
getting good docs. 
We needed good evaluation and evolution of NAT, ... 32 bit is not enough
so need IPv6 . SP need to run the network .. each grab /10 internally .
.much better to have a single allocation.. get IPv6 out as his T-shirt
says.
It is practical way of doing it.
Ross thinks that it is useful to have a written doc with pros and cons,
and that he is willing to review the draft if it is written, and Thanked
ARIN.
Victor: as an operator, we want to support this. Operator for Modem
users, there can be 16 millions addresses, which will use up the RFC1918
addresses. We also have place to avoid NAT
Jabber (Chris L.): We are talking about single ISP
Chris D. (?): This refers to regional CGN deployments rather than the
nested CGN.
Margaret Wasserman says that the concern is that unique shared space is
required. The SPs will reuse for walled garden, and why not NAT everyone
why does it have to be special?
The speakers asks that do we want to deliver NAT-ed service to
customers? If not we should avoid that.
Joel Jaeggli (Checkpoint Software): If this is not globally routed, you
are breaking something. One example we have will break RFC1918. On the
operator side, we really want to 
Juli E. (?): New private scope with address range is needed…legacy CPE
devices may not work…you will break something .. avoid something in
operator’s side …AT&T plays in that as well.. 6to4 problem..mitigate the
use of legacy CPE…
John (Cablevision): Lesson is that because of time crunch no carrier
grade NAT is there … no strong mechanism when one goes to whole
Internet.
Lee H. says that TW does not have 16 M IP address, and that they have
multiple walled gardens … same RFC 1918 space can not be used .. it
breaks …  6to4 problem .. not more than it is broken  now.
Ross Callon (Indv).. 6to4 problem broken let us not break any more but
fix it fast …NAT box need to be updated with IPv6 support
Jabber (Chris L.): we need to do something different between router and
CGN
Juli E. (?): With reference to 6to4, implementations exist today e.g.,
LinkSys & Apple make it
Dave Taylor (): use IPV4 and 6to4 only … significant deployment is
there…prefix delegation can be used..
May need to deploy IPv6 first not keep IPv4 and do 6tp4
Scott asked for more comments, but none was raised.
Scott asked whether IETF should proceed on asking IANA for this…
Jabber (Chris D.): Shared space is more like that in RFC 1918

Scott if people think that the IETF should ask the IANA for this
allocation
most of room indicated support, one or two opposed

Scott we have two drafts. Going through normal IETF WG is too long. We
need to request AD sponsored approach.
Scott asks if this is a reasonable approach? - strong support
Ron Bonica says that we should do WG last call & IETF last call before
doing this.
Wes Hardikar (Sparta): possible way to forward: first document to
request allocation the space. Another document to describe the detail. 
Scott says we’ll do that 
Lee: Is this not what we have
Margaret W.: Does it take the same time to do WG last call rather than
AD-sponsored doc. Preparation?
Scott concludes this discussion

4- Data Center/ProcessVirtualization

Scott says that the WG have received 16 drafts including the FireWall
state migration that we heard last time. We hear the roadmap. What may
go to IETF and what may go elsewhere and with some drafts, the ADs may
be involved.

Scott says we had a meeting yesterday, and came up with nine categories.
This is a good approximation but may not be exhaustive, some drafts may
be merged, some may not be merged, and in some cases there may be gap in
terms of the drafts that we have.
Ning explained the Cloud Reference Framework and Datacenter physical
diagram figures.

Ron Bonica says that in the first two slides we can put another circle
in the slides showing what parts are in the domain of IETF.
Scott & Ning say that we have this in the subsequent slides.
Scott says that these are the drafts that have been submitted to OPSAWG.
There may be other drafts in other WGs in the IETF.
Dave Harrington (AD) says that he has a problem with calling these
active drafts. We need to make distinction between adopted and not
adopted drafts, active and not expired proposals, not expired proposal
and drafts. So, Ning should refer to these as  proposed and not expired
drafts, and not call these active drafts. Ning agreed to this.

Mr. Ning So presented the DataCenter (DC) related drafts. 
Cloud infrastructure (reference) overview
Put different layer in the data center
The bottom represents the networks
Cloud draft categories
2nd: Cloud service state migration
3rd: DC network mobility: how to migrate VMs and virtualized network
resources between virtual subnets and/or among DCs. 
4th: virtual resource management
5th: DC resources discovery and brokering: obtain cloud services related
information and use the aggregated information from multiple service
providers to deliver differentiated services.
(draft-lo-dvn-problem-statement & ) 
6th: Cloud work survey for SDO coordination
7th: DC reporting and diagnostics: create cloud service monitoring,
reporting, and trouble shooting in DCs. 
Syslog extension for cloud using 
Draft details
VPN for data centers (VPN4DC)
Reverse the cloud service operation: Can we leverage IETF protocols to
control the entire process instead of out-of-band web portal for
resource control?
Cloud reference framework
Cloud security: provide the security landscape 
Interaction with other SDOs
 Draft mapping to cloud framework. 

Ping Pang : This is a good summary. I don’t think most of work doesn’t
belong to IETF. Two aspects: 1) virtual memory/virtual resources. There
are a lot of works done already in virtual resources management out
there. It is not IETF’s job to do the virtual resources unless IETF
changes its scope.
Ning says that Telco service provider like Verizon is different from
Google, and that they have different interworking requirements and need
standard functions to achieve better mobility and utilization of
resources .. so it needs to be worked out elsewhere .. people are doing
Cloud for a long time .. given that we own network . .interface with
upper layer … bind apps to underlying network may be the only thing we
need to do here. 
Ning asked Ping whether he support that this work should be done here.
Ping said “Yes.”
Wes George  (WG chair) says that there may overlap with 6man. VM
migration from one DC to another. they are meeting during this afternoon
and have two drafts.. gap analysis, and there may be opportunity for
collaboration.
Ron Bonica (Indv): Next time of the 16 drafts, please identify which are
in IETF space based on criteria .. that they are related to network
layer .. some drafts may belong to no one ..are we well positioned to do
that work . .someone else may feel that others own the work. After that
you may find byte-chunk drafts that may be the focus of the DC work in
Ops area.
Scott says I did the same thing. By looking at those work, which belong
to IETF. AIM is to figure out which category belong to IETF.
Yo Shoveda (?): Some drafts may need business model, and hypervisor
implementers should write these docs for hypervisor and mobility
services.
Scott says IETF should do work where it has expertise (above the wire
below the Apps) and people will like that.
Ning says that equipment vendors and hypervisor vendors do not and
cannot do everything that the service providers want, so the Service
providers are soliciting solution that can work well for their
customers.
Dave Harrington (IESG member) There are a number of WGs proposal. So
far, I haven’t been convinced a lot of works identified here belong to
IETF..
Chris L. (from Jaber) says that this is an Ops group, and we need to see
Operators requirements not vendors implementations.
David (STORM WG) says that IETF should not go for compute and network
resource management but should focus on narrowed down network related
problems … some of the drafts may be useful for discussion only work,
survey is for start of discussion...may be useful for leading Internet
draft (not RFC).. Concrete suggestion.. State transfer, etc. may need
more attention.. no IP mobility technology  are in use … we need to
carefully define scope for the work.
Scott says FireWall state migration is not network related work.
Davis says that may not be for narrowly defined network but for broad
network.
Ping Pang: We need standard message between network and storage and
others. We need to be very focused so that we can finish it very fast
and deploy fast.
Scott says that we are rarely satisfied but it is a good desire
Linda: can we carve out a small subnet which people agree that belong to
IETF: such as policy migration & VPN
Scott says that is exactly the exercise what we want to do.
Ping Pang: VPN defined differently in different groups, MPLS.. L2, ..
L3, and so on.
Dan (AD): Two questions (1) What is within the scope of IETF, and (2)
What is well defined, so that we can get work done in IETF. 
Scott: yes, we need this exercise.
Dan (AD): We have open microphone session, and people can say things
that they want to say.

Scott does the polling for the following areas.
Virtual Resource Operations and Management: Eight (8) or so hands were
raised in support of this work. 
Cloud Service State Migration: Ten (10) or so hands were raised in
support of this work.
DC Network Mobility: Fifteen (15) hands were raised in support of this
work.
DC Resources Discovery and Brokering: Three (3) hands were raised in
support of this work.
Scott said that we need the Surveys, and there is no need to do any
polling for this.
Data Center (DC) Reporting and Diagnostics: Ten (10) hands were raised
in support of this work.
VPN for DC (VPN4DC): Twenty (20) hands were raised in support of this
work.
Scott said that we need the Cloud Reference Framework (CRF), and we do
not need any polling for this.
Sam says that security related works are what we need more and more.
Cloud Security: Twelve (12) hands were raised in support of this work.

Scott concluded the poll by saying that the Chairs will work with the
ADs on path forward for the drafts and work in this area.


the session then switched to the open ops area meeting