2.3.8 Internet Area Meeting (intarea)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-10

Chair(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Mark Townsley <townsley@cisco.com>

Mailing Lists:

General Discussion:
To Subscribe:
Archive:

Description of Working Group:

No description available

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Internet Area Meeting Internet Area Meeting

ADs:     Mark Townsley (townsley@cisco.com) and Margaret Wasserman (margaret@thingmagic.com)

Notes:   Spencer Dawkins (spencer@mcsr-labs.org)

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 - Do 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 meeting useful - it looks like we did!

Slides

Agenda
MTU and Fragmentation Issues with In-the-Network Tunneling
MPLS Extensions to ICMP
IPv6 Multi-Addressing, Locators and Paths