Preliminary Minutes of the Dublin OPSAREA meeting

OPSAREA Open Meeting
Area Directors: Dan Romascanu and Ron Bonica
TUESDAY July 29, 2008
0900-1130  Morning Session


1. Note well, agenda bashing, note takers, blue sheets - 5 min

2. ITU-T JCA new work, Dan

http://www.ietf.org/proceedings/08jul/slides/opsarea-1.ppt 

- Joint Coordination Activity on Management (JCA-Mgt) is the coordination of the management standardization work inside and outside of the ITU-T. This JCA includes the coordination responsibilities previously addressed by the NGN Management Focus Group (NGNMFG) regarding NGN management, but goes beyond by including also the coordination of the work related to the next generation of telecommunication management networks. 
- SNMP, NETCONF and MIB documents included in the management roadmap documents issued by NGNMFG
- focused on the specification of management interfaces associated with a telecommunication management network. Such management interfaces include interfaces between a network element and a management system and between two management systems, but exclude management interfaces between network elements. 
- established by ITU-T Study Group 4 in May 2008 (liaison letter sent to a number of SDOs, including the IETF) and its terms of reference is documented in SG 4 TD 617 GEN
- Participation is open to leaders and other invited individuals from ITU-T and non-ITU-T organizations with expertise and specifications applicable to management interfaces
- Dan and Bert have been participating, as individual contributor, in the NGNMFG for the last two-three years, Ron joined lately
- Refreshing the participants list may be a good thing
- Please contact the ADs if you are interested to participate in this activity

Discussions:

- Scott Bradner: any overlap with the IETF? How does this affect us
- Dan: ITU-T wants to avoid overlap by doing harmonization. Useful, source of info and a good way to spread info on our work.

3. Performance of SNMP over TCP and UDP under various levels of lossy conditions - Wes Hardaker

http://www.ietf.org/proceedings/08jul/slides/opsarea-2.pdf 

- Wanted to see some real numbers, so did the experiment
- Purpose:
	How SNMP performs in bad environments
	How to pick the right protocol for the right task
- Why:
	Lossy networks are still common because of ..
		congestion, mobility, wireless meshes, satellite network
	Past UDP vs TCP study aren?t recent
- MITs RoofNet did some tests with links with average loss rate of 50%.    
- Conclusion: really difficult to predict the loss rate. 
- This is a very quick study (no plans to do more tests for now)
	2 PCs with a router in the middle, dropping random packets
	1000 GET requests with SNMPv2c, polling one sysContact.0
Study 1: 
	When there are no loss, UDP and TCP are identical
	With some loss: TCP (with a timeout=1s) takes longer -> this is normal
	Higher loss (27.7%): the results are still consistent (the TCP response time is linear compared to the number of requests)
	But with 32.7%, the TCP response time is not linear anymore compared to the number of requests while the UDP is still linear
- If you know how long your agent takes to respond, with UDP, you can predict how long the polling will take

- Study 2: Get 20 sysContact.0 instances with fragmentation
- TCP does a better than UDP (relying on IP) doing fragmentation, except at higher rate loss (around 30% loss), where the TCP line is not linear anymore

- With high loss rate (27.7%), with TCP, there is no way to predict the response time
- Conclusions: 
Not going to draw a lot of conclusions/recommendations
- Question for the viewer: when is it wise to use UDP versus TCP?
- TCP is great under ideal conditions and even mildy bad ones
- Proper setting of UDP timeout values is critical (no ones sets them up properly)
- Dont let UDP fragment. Should make sure that we don?t have too big SNMP packet
- TCP is great under ideal conditions and even mildy bad ones
- Proper setting of UDP timeout values is critical (no ones sets them up properly)

Discussions

Ron B: How lossy are the networks that are still use, anything over 5%?
Wes: More the 5% is common, but after a level of loss TCP gives up.
TCP should sometimes stop and restart. Users with a browser do that
programs dont. Why? Also the users don?t always complain. Example: waiting for a browser page, stop it, then reload sometimes works
- Liss ?:  If Loss is caused Congestion, you should not push harder, otherwise it is a good tactic. Because if the cause is congestion, then there is no point to push it
- Liss? : TCP meet a compromise between congestion and throughput. Run the test with fragmentation with different stacks because the implementation might be different. Try different UDP stacks, especially UDP fragmenting cases! Problems might be implementation specific.
Wes: Planned to try windows, didnt have time
 - Juergen Schonwaelder: for TCP, we know how congestion works. For SNMP over UDP, there is nothing: it depends on the implementation. NetSNMP does linear backup, not exponential
- Wes: we dont want to set the timeout below the latency
Jurgen Schouenwalder:  UDP congestion control? Congestion would modify the results.
Wes: UDP uses great lot of bandwidth. The manager should know the network it manages. We always used safe UDP timeouts. Setting it too low is risky. Getnext is not used, special case.


	
4. Operational aspects of NAT-PT

4.1 Post IPv4 ?completion - Alain Durand

- Why are people looking at IPv6 again?
- The internet must support continues, un-interrupted growth regardless of IPv4 address availability
- Still IPv4:
	Many hosts in the home are IPv4-ony
	Content servers hosted will take time to go to IPv6
- Two deployment scenarios for legacy deployments:
	Double NAT v4v4
	Dual-stack lite
- All-new device deployments (eg: wireless)
	Dual-stack lite
	NAT-PT, NAT64,IVI
- Discussed the impact on the IPv4/IPv6 operation and DNS
- Do we want to have IPv6 only server? Do we have requirement for IPv4 -> IPv6

Discussions

Margaret: V6 end device speaks v4 to the v4 internet, why do we need a NAT?
Alain: Not enough v4 address (e.g. wireless devices), 10-200 million new addresses needed. Even the private v4 addresses are not enough. (64 million address)
Margaret: ALG for v4 to v6 exist?
Alain: Not yet


4.2 NAT operational considerations, Iljitsch van Beijnum

- http://www.ietf.org/proceedings/08jul/slides/opsarea-3.pdf

- NAT64?s usefulness
      Dual stack light provides more backward compatibility with IPv4 stuff
	However, NAT64 breaks the vicious cycle for systems that (prefer to) only - use IPv6:
http://tools.ietf.org/html/draft-bagnulo-behave-nat64-00

Abstract
   NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and
   vice-versa.  DNS64 is a mechanism for synthesizing AAAA records from
   A records.  These two mechanisms together enable client-server
   communication between an IPv6-only client and an IPv4-only server,
   without requiring any changes to either the IPv6 or the IPv4 node,
   for the class of applications that work through NATs.  They also
   enable peer-to-peer communication between an IPv4 and an IPv6 node,
   where the communication can be initiated by either end using
   existing, NAT-traversing, peer-to-peer communication techniques.
   This document specifies NAT64 and DNS64, and gives suggestions on how
   they should be deployed.

- Discussed the possible locations of NAT64
- Discussed the possible locations of DNS64
- Conclusions:
Useful initial approach:
      place NAT64 somewhere in ISP network
      place DNS64 in ISP net close to user
Then later optimize:
      add DNS64 to CPEs and/or hosts

Discussions

???: CPE is what? L2 or L3?
Iljitsth: CPE gateway or dsl modem. Some Layer3 device needed

???: CPE is different for Cable networks and DSL nets

???: How to migrate DNS64 from ISP to host?
Iljitsch: Will not be a problem as host is v6


Dave: Placement of NAT64 in point7, why is this bad for global prefix?
Iljitsch: DNS64 will be available closer to the origin anyway.
Dave: Use nat64 and dns64 in the destination node
Iljitsch: No sense. The internet others will not know about the whole stuff

???: NAT64 in position6. If ISP A and Provider B has an agreement authentication is not problematic.



4.3 IVI Operational Considerations and practice

- http://www.ietf.org/proceedings/08jul/slides/opsarea-4.pdf 

- CNGI-CERNET is an IPv6 single stack network.
http://tools.ietf.org/id/draft-xli-behave-ivi-00.txt 

   Prefix-specific and Stateless Address Mapping (IVI) for IPv4/IPv6
                       Coexistence and Transition
Abstract
   This document presents the concept and practice of the prefix-
   specific and stateless address mapping mechanism (IVI) for IPv4/IPv6
   coexistence and transition.  In this scheme, subsets of the IPv4
   addresses are embedded in prefix-specific IPv6 addresses and these
   IPv6 addresses can therefore communicate with the global IPv6
   networks directly and can communicate with the global IPv4 networks
   via stateless (or almost stateless) gateways.  The IVI scheme
   supports the end-to-end address transparency, incremental deployment
   and performance optimization in multi-homed environment.  This
   document is a comprehensive report on the IVI design and its
   deployment in large scale public networks.  Based on the IVI
   scenario, the corresponding address allocation and assignment
   policies are also proposed.

See the slides for the details
The IVI (1:1) has been running at CNGI-CERNET2 for more than two years
	Open source available

Discussions

Pekka Savola: IVI might become a relay like an SMTP open relay. Might be black listed. V6 server all need a v4 address.
Xing: Security for study. v4 address sharing based on different ports possible.



5. WG Status reports:  WG chairs, 3 min each 

BMWG (Al Morton)
	IPSEC: Terminology, methodology settled, last-call coming soon
	SIP networking (new charter)
	MPLS 

PMOL (Al Morton)
	Only working on two drafts:
		SIP performance metrics
		Framework 

Dime (David)
	Finishing up the charter work
	Thinking of new work, recharter
		MIB. Looking for people who implemented Diameter
		Asking feedback for new work items

NetConf (Bert)
	Published the notification RFC
	New potential work item: notification content
	3 items on the table: Monitoring, Netconf over TLS, and partial lock

Netmod (David Pertain)
	First IETF meeting
	Documents covering all work items except one

IPIFX (Juergen Quittek)
	Based protocols published
	Information model: we defined a MIB (almost complete)
	Thinking on how to configure the device with NETCONF
	The NETCONF data model is not consistent with the MIB
	Translation from SMI to XML: will it be consistent with YANG?
	Sharon: interesting question
		May require two data models (one for config, one for monitoring)
		Might be an interesting case study
	Dan (contributor): maybe it?s time to have a new framework 
                           This is being worked on in OPSAWG
                           Aimed at other WGs. Multiple protocols needed. 
                           Multiple data models needed 

OPSAREA WG (Scott)
	One document in IESG
	Most interesting topic: what does OAM mean?
	We don?t mean the same thing when IETF/ITU speak about network management
	We don?t mean the same thing when IETF/ITU speak about O&M
	Example: MPLS OAM