Subject: [Int-area] My Notes from Int-Area

From: Spencer Dawkins <[email-masked]>
Date: Thu, 25 Aug 2005 08:36:03 -0500

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-masked]) and Margaret Wasserman 
([email-masked])

Notes:   Spencer Dawkins ([email-masked])

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-masked]
https://www1.ietf.org/mailman/listinfo/int-area