Subject: [Int-area] draft-ietf-intarea-tunnels-00 review

From: Bob Briscoe <[email-masked]>
Date: Mon, 26 Jul 2010 18:55:05 +0100

Joe,

Here's my review.

My main concern is the scope. Currently it is largely focused on 
packet size issues (PMTUD, fragmentation). Below are at least a 
couple more sets of tunnel issues that this doc could cover. There 
are two ways to go:
i) add the additional material suggested below (which may not be the 
last addition) or
ii) Don't add the new material and change the title and scope to 
"Packet-size issues with tunnels"

* Issue 1: New IP hop-by-hop options and tunnels.

RFC2473 (S.5.1) says that a v6 encapsulator can copy incoming 
hop-by-hop option headers into a new outer hop-by-hop extension 
header after the main v6 header. But which ones are copied and which 
not depends on how the encapsulator is configured. For instance most 
tunnels are configured to copy the tunnel encap limit and jumbogram 
hop-by-hop options to the outer, but not others.

This effectively prevents new hop-by-hop option headers from ever 
being defined if they need tunnels to copy them to the outer.

The way to solve this would be for a hop-by-hop option header to 
self-describe whether a tunnel should copy it or not. Relying on 
configuration is a recipe for disastrous interworking.

Basically, this is a part of v6 that is missing (also missing in v4, 
but v4 options are already a lost cause). This is really a stds track 
issue, not an informational issue, but it might be worth describing 
the problem here.

* Issue 2: Propagation of mutable fields into the outer on encap and 
from the outer on decap.

RFC2983 covers these issues for Diffserv.
RFC3168 & RFC4301 covers this issue for ECN, and 
draft-ietf-tsvwg-ecn-tunnel has just past IETF last call to make 
these two consistent again.

You might want to discuss this area as a more general issue, or (as 
noted above) reduce the scope of the doc, so you don't have to cover this.

* Clearing up your own mess.
In S.5.2, the draft talks about a tunnel clearing up its own mess, 
rather than relying on some node outside the tunnel doing so.

It justifies this by the rather vague notion of architectural 
cleanliness. If you want to give a more solid reason for why 
cleanliness is godliness, you might want to appeal to upgradeability. 
If we ever need to change the tunnel behaviour, it's impossible if it 
relies on random nodes outside the tunnel all over the Internet - 
it's hard enough when the two ends are under different administrations.

For instance, see S6.3 of draft-ietf-tsvwg-ecn-tunnel-08. Even though 
there have been 6 changes to the ECN propagation behaviour of tunnels 
(for only two bits, that not a bad level of indecision!), it has 
still been possible to keep the external behaviour looking identical. 
The ecn-tunnel draft calls this property of a tunnel "black-box 
backward compatible".

Nits.
----
I have a few, but I'll send now, in case I never get round to 
finishing this email.

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design