2015年11月10日に開催した、「Cisco EPN Innovation Seminar ～ネットワーク変革の源泉となるオープン コミュニティ～」と題したセミナーの資料です。

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?