![[PukiWiki]](../image/pukiwiki.png "[PukiWiki]")
|
Top > JANOG22 Programs
General information about JANOG22
JANOG updateSpeaker
AbstractSlides
JANOG: Act locally, think globally - An introduction of the JANOG i18n teamSpeaker
AbstructDo you know "JANOG i18n" team? "i18n" stands for "Internationalization." In Japan, many economists and executives are discussing a serious issue of Japanese industry. It's called "The Galapagos Effect" or "Paradise Isolation." This means that many excellent, and often superior, Japanese technologies which are used domestically aren't being deployed globally, and sometimes this causes harmful effects. The JANOG i18n team has been trying to approach this BIG issue. One of the team's major activities is to globally disseminate information about what is being discussed in the JANOG community. The project is just beginning. We would like to share our activities with JANOGers, and we solicit and would appreciate your advice. Slideshttp://www.janog.gr.jp/meeting/janog22/program/day1/data/day1-1.pdf Let's Discuss Operational Guidelines for ISPs' Bandwidth ControlSpeakers
AbstractThe Ministry of Internal Affairs and Communications (MIC) and four associations of telecommunications carriers finalized guidelines as operation standards for bandwidth control on May 23rd, 2008. In this session, based on these guidelines, we are going to discuss bandwidth control as implemented by Internet service providers, what kind of traffic should be controlled, and what should not be. Bandwidth control by Internet service providers had been a controversial topic in connection with confidentiality of communications. In September 2007, MIC recognized the existence of implementations of bandwidth control in the final report compiled by the Panel on Neutrality of Networks and commented "It is advisable to formulate minimal operational rules linking to operational guidelines for bandwidth control". Additionally, some video service providers caused another controversy by suggesting possible implementation of bandwidth control on particular content by some telecommunications carries and asking those carries to disclose the fact. In response to such circumstances, since September 2007, four associations of telecommunications carriers (the Japan Internet Providers Association, the Telecommunications Carriers Association, the Telecom Services Association, and the Japan Cable and Telecommunications Association) and MIC as an observer conducted the "Study Group on the Guideline for Packet Shaping", and a set of guidelines as operation standards for bandwidth control titled "Guideline for Packet Shaping," which was finalized on May 23rd. In this session, we are going to examine the guidelines and discuss what should be bandwidth-controlled and how it should be implemented. Report of Experiment on Notifying Route Hijacks - For The Benefit of Internet Engineers -Speaker
AbstractJPNIC began the notification experiment of route hijack information for the JPIRR registrants in cooperation with Telecom-ISAC Japan in May, 2008. In this program, we introduce the outline of this coordinated experiment and the story of the experience of the JPIRR registrants who received the notification of route hijack information by the date of JANOG22. We want the participants of JANOG22 to recognize the reality where route hijacks occur. And, we hope for the an increase in the number of entrants in this coordinated experiment that is one of uses of IRR. Destructingly InternetSpeakers
AbstractCouldn't the Internet be a tool for realizing the world of autonomous and creative intercourse that Ivan Illich proclaimed? Was the idea of autonomy that the Internet implied just a pipe dream? Is the Internet deteriorating?
IPv4 Address Exhaustion News? ~ What will happen when using ISP-NAT~Speaker
AbstractIPv6 is identified as the most promising option as a counter-measure against IPv4 address exhaustion in reports published by the Ministry of Internal Affairs and Communications. JPNIC has highlighted these conclusions. These reports also mentions using ISP-NAT as a bridging transition mechanism while achieving wider IPv6 deployment. It has become clear that there are many issues regarding the application of ISP-NAT which require collaboration by various fields to overcome these challenges. First, we would like to provide current discussions about ISP-NAT and share issues with participants. Then we would like to have discussions to identify countermeasures to overcome such issues.
IPv6 address architecture on point-to-point linksSpeaker
AbstractIPv6 shares similar routing and forwarding concepts with IPv4. However, there is a difference in term of addressing and it could be prone to unexpected problems. I'd like to discuss considerations and possible countermeasures against such things which everyone (including network operators and vendors) tends to forget. Slideshttp://www.janog.gr.jp/meeting/janog22/program/day2/data/day2-1-e.pdf BGP 4 byte AS implementation - miscellaneous thoughtsSpeaker
Abstract4 byte AS numbers have been discussed in various places including JANOG, and actual allocations have been started by RIRs. AS numbers is no less a resource depletion issue than IPv4 address space, but thanks to its built-in mechanism for co-existence and the limited number of concerned parties (BGP operators only), the deployment is thought to be taking place without big problems. However, there is a point which has not yet been resolved, - a notation. AS numbers use a flat 32bit space and there is no concept of hierarchy or structure per se. But at this moment, it seems the "asdot" notation[*1], which separates the space into two 16bit spaces, is going to be adopted by RIR communities. It was my impression that the things were proceeded without enough intensive discussion. As presented in RIPE-55[*2], the asdot notation conflicts with the regular expression and filters/scripts/RPSLs could get incompatible. [*1] draft-michaelson-4byte-as-representation
[*2] http://www.ripe.net/ripe/meetings/ripe-55/presentations/jakma-critical-considerations.pdf JunOS has implemented "asplain" at first, since it's simpler and not conflicting with reg-exps. But it has quickly added "asdot" as well. In this session, I'd like to talk a little bit about miscellaneous thoughts on the 4 byte AS implementations. Overlay Routing and Traffic Fee Distribution IssuesSpeaker
AbstractOverlay Routing is a new route selection technology. In the Overlay Routing platform, hosts on the edge of the network are able to test connectivity between each other over multiple paths. The Overlay Routing platform then selects the best path based on delay, packet loss and bandwidth utilisation calculations. The result being the Overlay Routing path selection system provides better network performance than path selection based on current route selection algorithms. Also an ISP's cost structure is based on traffic flows between itself and other ISP's. However compared with Overlay Routing, traffic flows can be unpredictable with current route selection algorithms , which can lead to unexpected costs. This is the "traffic fee distribution problem". This presentation discusses the following results in detail:
Lastly the presentation will provide results for the use of the Overlay Routing algorithm on the "traffic fee distribution problem". Including comparing the balance of traffic using different Overlay Routing algorithms, showing that the "traffic fee distribution problem" is a difficult issue. Lastly the presentation will cover Overlay Routing selection algorithms that provide better performance for end hosts and reduces the effects of some of the "traffic fee distribution problem". What is "show tech-support"?Speaker
operation.
sales team, and the hardware.... AbstractWhen we need any hardware maintenance service (ex. RMA), the hardware support vendor will ask us to send a summary of the system information, the results of the so-called "show tech-support" command. To investigate a problem with an interface or with BGP flapping, trying to do "show tech-support" can cause the system to go down. Do you have such an experience? When trouble happens we want to give the necessary information to the hardware vendor. But typing "show tech" and waiting for the log takes a long time even though we'd like to recover our services ASAP. Sometimes the "show tech" seems irrelevant but the vendor still asks us to give it to them..... I'd like to discuss with other attendees what we really need to collect as data in case of trouble, then propose it to the hardware vendor in this meeting or via JANOG ML. IPv4 Depletion: Can Web services you use survive?Speakers
AbstractDepletion of IPv4 addresses is seen as inevitable in the coming few years.
Topics of the Internet and What's the Role of the Japanese Community in the Future[#dfa7f65b] Speaker
AbstractWe will discuss the topics of interest to the worldwide internet community and the role of the Japanese community with Philp Smith who is NANOG's Steering Committee chair and is familiar with the internet community. Part I: BGP Philip Smith will talk about the current status of BGP and it's future . Part II: The Internet Community and Future of JANOG Panel discussion in terms of the topics of interest to the worldwide internet and the roll of the Japanese community in the future. |
|
|
Modified by janog i18n team.
Powered by PukiWiki Plus! HTML convert time to 0.185 sec. |
|
