IETF 59 Plenary Minutes
Thursday Plenary - Leslie Daigle
Erik Nordmark - locator/identifier split
This concept is sticking it's head up from multiple holes, like a gopher
Want to start the entire community thinking about this concept
One minute summary of multi-homing = sites connected to multiple ISPs
- want to improve failure resilience, load balancing, better
quality connectivity
- today - addresses usually assigned by ISPs and aggregated toward
the default-free zone
- provider-independent addresses can't be aggregated by ISPs -
doesn't scale to one router per site in the world
- IPv6 could use IPv4 technique (but doesn't scale), multiple
addresses per site and per host (but has limitations)
- transport/application paths don't survive when there's a problem
- applications have to do recovery on their own
- don't know how to do address combinations - RFC 3484 is (only) a
start, because of ingress filtering
Big questions:
- separate identifiers and locators?
- current IP addresses would become locators - need an indirection
layer, but may not need a new name space
- one approach - ID->locator shim layer, but need a protocol to
set up this mapping
- works for most applications, but referrals and callbacks need help
- not sure where the shim layer goes - IP routing layer, IP
endpoint layer ...
- need a new namespace?
- FQDN as the key, sets of locators, ephemeral ID/purpose-built key
...
- stable long-term? survice ISP changes, etc.
- need a managed hierarchy? as IP addresses and domain names are
today? or self-allocated? hard to build a mapping function without
hierarchy
- don't know how to make these spaces scale without hierarchy -
could it be made to work in the self-managed case?
- how to "re-home" traffic? plenty of proposals to do this in multi6
- how to accommodate ingres filtering? if you can tell each ISP
about all other ISPs, this goes away, but won't happen for
consumer-class services
- need to select source/destination locators - when communication
starts, when communication fails. Is there SCTP experience we can learn
from?
- how to detect failures? depends based on application. transports
can give hints. routing system may have a role here. Or we could
heartbeat...
- new protocols should not make Internet less secure than it is
today, should not become the weakest link
- various threats exist (redirection, 3rd-party flooding - and this
includes amplifiers) don't depend on security pixie dust ("PKI").
- security threats that force hosts to do more work - vulnerable to
DoS attacks
- Mobile IP doesn't cleanly separate out multihoming - may be OK
for sites but not for hosts
- multi6 and HIP are working groups, HIP-related research group
forming in IRTF
- Erik asking for help in several areas
Comments:
- Charlie Perkins: what about NEMO? NEMO is a consumer for
multihoming, not an inventor
- Eric? does HIP need hierarchy to scale? getting into details here
- Ohta-san: thank you for reintroducing my proposal four years
later...
- Ohta-san: multihoming and mobility are mostly unrelated ... ???
- <renewal of multi6 working group meeting in plenary>
- Geoff? structured and unstructured identity space - birthday
problem is real, even if it's 128 bits, for unstructured identity space
- Rohan: separation between who and where is turning into a giant
NAT - can we remember peer-to-peer applications in use cases?
- this is an architected NAT when we rewrite headers
- tight presentation in a tough problem space
- Dave Crocker: multihoming and mobility are almost the same ... !!!
- Dave Crocker: presentation assumed new identifier space - please
be skeptical about this in your work - could have different identifiers
at startup and in the association
- Eric: may also use the same mechanisms for renumbering
- Dave: site multihoming, but maybe host multihoming is the
interesting problem
- Dave: trying to avoid assumption of a new identifier name space,
but it's really hard
- need help in understanding the requirements from people in the
room - is this damage control for an application, or a feature?
- Allison Mankin: can you sketch some NON-requirements? path
selection based on path quality, for example - is this really
requirement? not an integral part of the problem
- there is complex interaction between IP layer, transport layer,
application layer - solving the problem for TCP, but nothing beyond that
- Kurtis? don't think application layer sees a different interface
whether this is provided in IP layer or transport layer
- Eric: can applications make use of locator information as well as
identifier information - remember site-local? this is a terrible idea
- Joe Touch: I think of these solutions as a routing overlay, but
this requires end hosts to participate in the routing protocol - not a
bad thing
- Eric: rewriting things scare me - going down a path that's not
sustainable
- Gab Montenegro: mobile IP gives you one identifier, but MIPv6 is
working on bootstrapping, so you're not tied to one identifier
- Erik: rehoming protocol - there are at least four being talked
about today - can we work together for a better architecture?
- Erik: can't solve mobility and multihoming if this involves
boiling the ocean
- Erik: what if there is no solution to this problem? there are
engineering tradeoffs here
- Erik: mapping a referred identifier to a locator is really hard
in the general case - this may be a researchy question for a while
- Tim Shepherd: there are a lot of proposals in multi6. Code would
be good. Reading code would be really good.
Leslie Daigle - Administrative Restructuring
- followon to presentation at IETF 58, this is a status report
since November
- draft-iab-advcomm-01.txt
- need a single focus for making operational choices that affect
the IETF
- draft-daigle-adminrest-00.txt is a high-level architecture
requiremnts document - specification to follow
- need IETF's own administrative function - need a full-time,
professional manager
- need better administrative pieces like WG tools, cross-area
tools, etc.
- not done directly by IAB or IESG(!) - not our core competency!
- please send comments directly to the authors
- plan to move forward to specific implementation proposal
- will continue to report status monthly
- have received zero comments on any of these documents - are you
reading them?
Comments:
- Jonas: are other people involved? mostly Leslie and Harald, with
other people who are affected
- Jonas: how can we contribute if we want to help? stay tuned for
the actual project plan, and thank you for volunteering
- Dave Crocker: is the board structure really a requirement? you're
overloaded now - this is actually "appointed by" IAB and IESG chairs
- Dave Crocker: board diversity to insure lots of stuff
- Larry Masinter: wow - this is a lot more than just workflow
management software! how big a budget, how long a timeline, ....
- Larry: could we start small and see if we need all this?
- Ohta-san: our concern is on how easy it is to propose a standard
- if it's not easy enough, people will leave IETF
- how to proceed with tool development? too early to know details
now
Harald - IETF Mission Statement
- draft-alvestrand-ietf-mission-00.txt
- "any organization that needs a mission statement is in serious
trouble"
- at least we'll shut down some of the mailing list discussion
about mission statements :-)
- goal of IETF is to make the Internet work
- Cardinal principles - open process, technical competence,
volunteer core, rough consensus and running code
- if the IETF can't help the Internet it will shut itself down, and
I'm proud of that
- please read this document and tell us what you think
- want to publish before the next IETF
Comments:
- Stuart Bryant: concern that our focus is on making the Internet
work, not on making IP networking work -concern that ITU is doing MPLS
work in competition with IETF
- Harald: but they are referring to 27 of our drafts in their
current work -if our standards don't work on the Internet, why would
anyone believe they would work anywhere else?
- Stuart: we over-constrained, causing parallel efforts elsewhere
- PWE3 WG drafts taken in by SG15, without prior agreement, because
of frustration with us - please follow up on the list
- James Polk: comments back only to the authors? didn't acknowledge
3-page comment (whoops!) - we don't do host-to-host, only require
Internet traversal
- James Polk: we got passed on preemption badly... ITU did a
standard in one year, we did a SIP version three years ago that's not
even through the RFC editor queue
- Harald: comments can go to IETF list to keep Harald alert, etc.
- Ohta-san: our quality is lower than other standards bodies - this
will make us disappear
- Brian Rosen: participants not standards professionals - we're
doing evolution here, not revolution
- Brian: IESG, IAB, WG chairs must spend huge amounts of time - you
guys really ARE standards professionals...
- Harald: "I'm an engineer on temporary assignment"
- Fred Baker: we need people who can set their careers aside for a
period of time - and then return to their careers, and we need to honor
people who can do this.
- Harald: "a life, a job, and the IESG - pick any two" - I want
people to have all three at once
- document headed in the wrong direction? sense of the room is "no"
- will continue
Harald the General Area Director - Changing the way the IETF Works
- inward-facing piece of the puzzle
- we have angry people - a symptom that something is wrong
- we are committed to improving
- ICAR - help with "late surprise" issues - security,
internationalization have been problematic lately
- in startup mode now
- NEWTRK - make the standards track make sense
- thinking for a while to make sure we're doing the right thing
- PROTO - help with IESG review process
- getting others involved
- MPOWR - smoothing the rough edges of the WG process
- still finding the next steps
- EDU team
- http://edu.ietf.org
- proposals we should "just do" - change rules on mailing list
management, etc.
- PROTO and ICAR changing the way IESG works - so step carefully
- we're starting to change things. we're trying to move quickly and
be careful. This is hard. Your help is needed.
Comments
- James Polk: catching a surprise "late" - what is late?
incompatible changes after WGLC
- James: Working group draft status = old PS, no wonder there's
confusion outside this room - abandon the label RFC?
- Harald: WGS presented in NEWTRK - go there
- James: Area Charters to help people find (for instance) VoIP with
all the groups working in the space
- Spencer: It's not just people who think RFCs are standards - RFC
821 is still a full standard, and 2821 is still a proposed standard
-when people believe us about SMTP, they're still wrong!
- John Loughney: IETF is not good at cost-benefit analysis - AAA
was so late that the incumbent technology was extended - and it's still
broken
- Harald: need more planning to accommodate this
- ?: too much time and energy to send stuff back to Historic -
should happen automatically -what we have in 2026 is reasonable - wish
we followed it
- ?: peer review in different WGs or even areas - we do this after
last call, too late
- Margaret: training of WG chairs - everybody thinks delivering to
the IESG is the last step in the process, but the fun is only beginning
-EDU team is working on chair training, and PROTO team looking for
places to involve WG chairs - 20 percent of WG chairs come to training
- and they get a free lunch
- Joe Touch: if there are too many documents to watch, stop
watching all of them - informational individual submissions - what
working groups do I take this suggestion to?
- Harald: IESG will no longer take responsibility for technical
review of individual submissions - only end run detection - change will
happen in a month or so
- Harald: the July14 draft on process change will be pursued
- Ohta-san: anyone can build code for anything, if they have enough
money...
- ?: how quickly will standardization process change? once no
review required to publish Informational RFC... is there a target?
mostly need a couple of months...
- Fred Baker: IESG was designed to offload RFC Editor and IAB...
we're where were for the Cambridge tea party in 1992
- Brian Rosen: biggest problems are being addressed now, but no one
is looking at Internet Draft process - don't want to mandate xml2rfc,
but could automate submission...
- Brian: what documents the process, and the policies, for
submitting an RFC? I thought an Internet draft could be announced to a
specific mailing list, but no longer?
- Bill Fenner: announcements could be swallowed by spam filters
- Barbara Fuller: secretariat staff has a document on how to
process various types of I-Ds - questions about formats and submission
will be worked on in the future
- Zafir: individual drafts bounce from working group to working
group for multiple IETF meeting cycles
- Zafir: it's hard to get attention for an individual draft - could
ADs help?
- Alex Zinin: in many cases when a draft bounces around, it's
because the topic crosses working group, or working group not able to
take on new work
- Zafir: can you help with existing working group items?
- Alex: just because a document isn't in a working group doesn't
mean that you can't be making progress outside a working group
- ?: can we move to a more modern document format? please work this
on a mailing list. You will be flamed, but then you'll know...
- Spencer: is this the right session to ask for plenary input on
draft-klensin-process-july14-00.txt on process change? Update is
coming, watch for the update, please read it and provide feedback on
solutions@alvestrand.no
|
