【EPN Seminar Nov.10. 2015】 Key note – Open innovation and Engineering community
1 like354 views
The document summarizes how the IETF process works to develop Internet standards and protocols. It discusses that the IETF is a community that works to describe and solve issues on the Internet, often publishing documents called RFCs. It provides examples of how technologies like Secure Shell and TCP congestion control were developed through discussions, Internet-Drafts, and published RFCs. It emphasizes that the IETF process relies on open discussion and consensus among participants to select solutions that work in practice for standards.
【EPN Seminar Nov.10. 2015】 Key note – Open innovation and Engineering community
- 1. Fred Baker Nov. 10. 2015 Open Innovation and the IETF Engineering Community
- 2. • Something basic to understand: • The IETF does not, fundamentally, write RFCs. • The IETF describes and solves issues in the Internet (often in RFCs) • What documents do we have? • Internet-Drafts (discussion documents) • Informational RFCs • Experimental RFCs • Standards (BCP, Proposed Standard, Standard) • Historic and obsoleted RFCs Topic: How does IETF process work?
- 3. • Secure Shell (SSH1) • Originally developed by Tatu Ylönen for his own use in early 1995 • Released in Open Source July 1995, and widely adopted (and still used) • Described in draft-ylonen-ssh-protocol November 1995, never published as RFC • Secure Shell v2 (SSH2) • Ylönen opened a company to improve and support SSH • IETF opened the Secure Shell Working Group, resulting in RFCs 2693 and 4251-4254 • Adoption spurred recently by loosening of license parameters and development of OpenSSH etc Example IETF Process: Open Source commercialization
- 4. • John Nagle published a QoS solution: • RFC 896, TCP Nagle Algorithm, January 1984 • Nagle recognized a fundamental flaw in IP design • RFC 970, On Packet Switched with Infinite Storage, Dec 1985 • 56 KBPS NSFNet Congestion Collapse, 1987-1988 • TCP Congestion Control • SIGCOMM 1988 (Research Paper) Van Jacobson • RFC 1812: change IP TTL definition to be a hop limit • RFC 2001 (Proposed Standard) Stevens • RFC 2309 (Informational) End to End RG • RFC 2581 (Proposed Standard) Jacobson et al • RFC 3465 (Experimental) Allman • RFC 5681 (Standard) Jacobson et al Example (pre)IETF process: Managing TCP in the developing Internet
- 5. • We could discuss • Integrated Services (RFC 1633, RSVP, etc.) • Differentiated Services (AF, EF, Scavenger, RFC 4594/5127) • RFC 6817 Low Extra Delay Background Transport (LEDBAT) • MANY research papers • Current Net Neutrality debates • But let’s not. • Remember it all started with RFC 970, “On Packet Switches with Infinite Storage”, which was NOT A STANDARD It didn’t stop with TCP…
- 6. • Issues: • Route symmetry • Enterprise network complexity • Security of routing • Mechanisms • Provider-independent Addressing – this works • Provider-allocated addressing – has issues with security • Prefix translation – stateless but still has issues Problem: IPv6 Multihoming without NAPT
- 7. Another – Source/Destination Routing • Normal IPv4 and IPv6 Routing • We route to destinations, without regard to source address or other attributes • We may distribute load using PFR or otherwise impose a policy 7 ISP BISP A
- 8. IPv6 Provider-allocated Addresses Routing with BCP 38 ingress filtering • Imagine: • We route to destinations, without regard to source address or other attributes, • But we have provider-allocated addresses • ISPs block traffic using addresses they did not allocate 8 ISP BISP A
- 9. Egress Routing with IPv6 Provider-allocated Addresses Routing with BCP 38 ingress filtering • We route traffic using an ISP’s PA address to the ISP that allocated it • Traffic with spoofed addresses has no route, so BCP 38 filters have nothing to filter • Route symmetry achieved for enterprise security systems 9 ISP BISP A
- 10. First hop: send to router advertising prefix (IPv6 Maintanence, 6man) Multihomed LAN network Split network (such as mobile telephone) ISP BISP A ISP BISP A
- 11. • OSPF and IS-IS calculates • A sequence of routers and links • That lead to an accessible object, primarily a destination prefix • What if the object had a source and a destination associated with it? • Source could be ::/0 (“anywhere to this destination”) • Destination could be ::/0 (source-specific default route, “from this prefix to anywhere”) • Could be more specific (“from my home to BFLETS”) • Current work in IPv6 Maintanence, Routing WG, IS-IS, OSPF, and Homenet (using Babel) OSPF/IS-IS observation
- 12. In theory, theory and practice are the same thing – attributed to Albert Einstein The Theory
- 13. • Internet Engineering Steering Group (IESG) • 7 Areas • Each with about 20 Working Groups • Internet Architecture Board • Several “activities” • Internet Research Task Force (IRTF) Organizational structures IESG IAB Area WG WG WG WG WG Area WG WG WG WG WG IRTF RG RG RG RG RG Other functions such as liaisons, RSOC, Etc. IAOC …
- 14. • Charters • Specific problems and perhaps solution approaches • Specific deliverables • Timelines • Public discussion • Primarily on mailing lists • Regular meetings to discuss difficult points • Interim meetings by telephone, video conferencing, or face to face Working Group Processes
- 15. • Development always starts with a problem to be solved • Problem is stated as clearly as possible during charter development Problem Statement
- 16. • Internet-Drafts posted to • Analyze problem, • Propose solutions, • Examine viewpoints • Not to “write an RFC”, but to discuss and solve a problem. • Working Group discussion • Merge/Select proposals • Formulate consensus Various Proposals
- 17. • Motto of the IETF • The proposal ultimately selected is one which demonstrably works • Politics may be a factor, not usually a deciding factor Rough Consensus Running Code
- 18. • Standards • Best Current Practice • Proposed Standard • Standard • Non-standard: • Experimental • Historic • Informational • What is an RFC? • Not necessarily a standard • Not necessarily in current use • Not necessarily even a good idea • Community memory • Experience is that marvelous thing that enables you to recognize a mistake when you make it again. - Franklin P. Jones RFCs: Archival Documents
- 19. In theory there is no difference between theory and practice. In practice, there is. – attributed both to Albert Einstein and Yogi Berra The Practice
- 20. IETF process • Depends heavily on: • Good will • Good judgment • Good planning • Consistency of application • All of which must be executed by human beings, which are notorious for • Private agendas, poor judgment, haphazard planning, and inconsistency • Like all IETF issues, the resolution is generally found in discussion
- 21. What happens with Internet-Drafts? • The drafts I have in the mill right now: • draft-ietf-6man-hbh-header-handling-03.txt • draft-ietf-6man-multi-homed-host-01.txt • draft-baker-ipv6-isis-dst-src-routing-04.txt • draft-ietf-ospf-ospfv3-lsa-extend-08.txt • draft-xu-ospf-multi-homing-ipv6-00.txt • draft-bao-v6ops-rfc6145bis-02.txt • draft-gont-opsawg-firewalls-analysis-01.txt • draft-ietf-aqm-fq-implementation-03.txt • draft-ietf-aqm-pie-02.txt • draft-szigeti-tsvwg-ieee-802-11-00.txt
- 22. Internet-Drafts in IPv6 Operations (v6ops) • RFCs-to-be: • 4 in RFC Editor’s queue • 1 in Independent Submission Editor’s queue • 1 in IESG • Working Group Discussion: • 3 working group drafts • 4 individual submissions • Oops… • 2 working group drafts dropped from consideration • 5 individual submissions shifted to another WG • 3 individual submissions submitted to the wrong WG http://datatracker.ietf.org/wg/v6ops/documents/
- 23. Making a difference in the IETF • Something very basic to understand: • The IETF is, first and foremost, a community • Communities are composed of people, with all of their good and bad points • How do you make a difference in your community at home? • Be constructive • Be willing to learn • Be willing to contribute to a team, a shared goal • Be part of the community
- 24. Making a difference in the IETF • Breaking into the community • People complain about the “old boys’ network”, but in my view that is a misunderstanding. • We have a number of good people, who often disagree among themselves • We have a number of people who create noise • We have a number of new people that haven’t established relationships or become known. • Who gets listened to in IETF conversations? • People with clue • To become a “person with clue” • Comment cluefully on working group discussions. • Not just your own interests • File drafts that are simple, well-written, and describe or solve real problems in implementable ways
- 25. Questions?