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