I took the following notes at the Int-Area meeting in Paris - if you
remember something else, please let me know, so we can actually submit
minutes for the proceedings!
Thanks,
Spencer
-------------------------------------------------------------------
Internet Area Meeting
ADs: Mark Townsley ([EMAIL PROTECTED]) and Margaret Wasserman
([EMAIL PROTECTED])
Notes: Spencer Dawkins ([EMAIL PROTECTED])
This is the first Internet Area meeting - consider it an experiment.
Lots of working groups IN the Internet Area that aren't aware of each
other and aren't doing a lot of cross-WG review within the area.
Mark did a walkthrough of all the strange combinations the Internet Area
is worrying about while they are "just looking at IP" - IP over IP, IP
over foo, foo over IP, foo, IP between IPs, ...
We seem to have overlooked IPv6, but that could have been implicit :-)
The centers seem to be IP, mobility, configuration/authorization, and
tunneling/VPN, and some working groups are in more than one center.
Margaret did a walkthrough of what's going on in each of the centers in INT.
IP/Addressing - getting close to full standard on IPv6,
multi-addressing, and ALIEN BoF (on anonymous identifiers, in SEC, but
looking for INT expertise)
Mobility - doing more with L2 mobility issues (IEEE 802, DNA), localized
mobility management, and multihoming of mobile nodes. MIPSHOP is
rechartering, and will probably include IEEE 802.21 on route optimization.
Config/Auth - TRILL working group has been chartered (shortest-path
forwarding of L2 using a link-state routing protocol). AUTOCONF and
SECMECH BOFs at this IETF.
Tunneling/VPN - Lightweight Reachability softWires BOF this IETF
(previously v6tc), tunneling for v6/v4 coexistence. Thinking about
multisegment pseudowires (would be chartered in PWE3 and L2VPN, if we
decide to do the work).
Pekka Savola presented a draft on MTU and Fragmentation issues. He's
been working on it for about 18 months and targeting considerations that
strongly affect router-to-router tunneling, and plans to publish as
Individual, Informational RFC.
Margaret points out that MTU is a frequent omission on drafts, and
mentioned MTU problems that happen with variable-length headers.
Erik asked if this document should be making recommendations - the
current draft gives hints, but not strong guidance.
Pekka Nikander - we are doing SO much tunneling - is this an indication
that we lack functionality that we SHOULD have in the IP layer?
Mark started a broader discussion in response to Pekka's point - we have
tunnels for lots of different reasons, and some tunnels we hope will go
away someday.
Ron Bonica talked about ICMP Extensions for MPLS. This was work that
started to happen about five years ago, and has been resurrected.
RFC 3032 extended RFC 792 ICMP to strip off MPLS labels and then send
ICMP messages back to the datagram originator, but the ICMP message
doesn't contain any part of the MPLS label, which is exactly the
addressing that caused the datagram to be unreachable - and the ICMP
message may go back to the wrong "originator", and the destination
address in the IP packet could have been perfectly routable - after you
stripped off the MPLS label. TTL Expired is also a problem.
Current ICMP "final field" doesn't have a length, so it's hard to append
to. Would like to limit this to 128 bytes, zero-padded.
Could have an MPLS-aware of traceroute, too.
Draft was originally submitted in 1999, has been deployed since 2001.
Bob Hinden - but we don't put L2 information in ICMP? but we made a
layering violation by putting MPLS in ICMP in the first place.
Could use something in MPLS, instead of ICMP?
Tim Shepherd - traceroute has been showing me MPLS labels for four
years. This is the way my Internet works. Should it be a BCP?
Bill Fenner - it would be nice to have something written down about
this, since it has been deployed. Have a document that defines TLVs and
an informational document that says what we are doing now? Worried about
what changing ICMP might break, but this doesn't seem to be breaking
stuff on today's Internet.
Mark - are there any other proposed objects? None that we know of, but
we don't know what else might have been deployed.
Erik - documenting what has been deployed isn't the same as saying this
is a good way to go, but we should document what has been deployed.
Eliot - should be consistent with other uses (either L2-is-OK or L3-only).
Geoff - V4-v6 isn't relevant, VPN isn't relevant, if I'm doing MPLS, I'm
trying to get back ICMP messages that tell me what's happening - I'm not
tunneling at all.
Bill - there isn't an L3/L2 relationship between IP and MPLS, they are
really bound together. MPLS is part of what we do.
Geoff Huston gave a talk on IPv6 Multi-Addressing, Locators and Paths.
This isn't new stuff - we're building on work done in the 1960s. But we
use IP addresses for a lot of different purposes, and this creates a lot
of challenges to the IP Address Model - mobility, nomadism, multihoming,
scoped addresses, routing complexy...
We've risen to all of these challenges simultaneously. A hundred flowers
have bloomed. We are trying to recover.
There are a lot of things we are doing to recover - MOBIKE, MIP4/6,
SHIM6, HIP, NEMO, ... but they all have similar functionality.
We already have a lot of discovery and setup protocols. There may not be
a lot of benefit in unifying them.
Could we have a single locator/path Update and Maintenance protocol?
Could do direct signaling, could use transport session-referred signals.
"What is an identity really?" Per host, per ID, per session class, per
transport session... and you have to think about outgoing and incoming
mappings.
Path maintenance could be passive, active, or super-active (probing for
the path characteristics).
(several speakers while Spencer was in line to whine about TCP multipath
and previous experience with ECM non-use)
Gab Montenegro - would a module that does path maintenance work in a
NETLMM network? In a TRILL network?
Erik - we don't want to end up with a lot of Transport protocols that
each provide different hints.
Geoff - choice is such a terrible thing... IP does unreliable datagrams,
full stop. If you think about packet/locator pairs that are best-effort,
life is easier.
(several speakers while Spencer was in line to whine about multiple
transports trying to provide hints, and about how ugly it could be to
try to get path reachability through a path that has NATs, firewalls,
and SBCs dropping packets semi-randomly)
Christian - this is transport stuff - don't put it in IP!
Greg Daley - we want to share this information for all sessions, but the
pairs of locators have all sessions die in a lot of wireless environments.
Pekka Nikander - we really do understand how ugly the network is. The
Internet isn't host-centric like it used to be - are there even hosts at
all now?
Geoff - if you have richness of choice, you're going to have to move up
the protocol stack. If you move into IP and stay there, the richness
won't work.
Bill Fenner talked for a moment about RFC 3692 on experimental values in
IANA-maintained number spaces.
Bill has a draft that follows the structure of 3692, The question is,
what experiments are likely, and which protocols can use experimental
values.
Brian Carpenter - a lot of DIFFSERV people needed experimental local use
code points, and that was a good thing. Brian supports this (speaking as
DIFFSERV former chair).
Please read and comment!
Margaret asked if we found this meering useful - it looks like we did!
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
