Subject: [Rtg-dt-encap-considerations] Fwd: Encapsulator behaviour and encap header extensibility

From: Erik Nordmark <[email-masked]>
Date: Mon, 30 Mar 2015 10:16:23 -0700

-------- Forwarded Message --------
Subject: 	Encapsulator behaviour and encap header extensibility
Date: 	Sun, 29 Mar 2015 17:25:11 +0100
From: 	Bob Briscoe <[email-masked]>
To: 	Erik Nordmark <[email-masked]>

Erik,

This is to put our conversation during a break in Dallas on record to 
ensure it doesn't get lost. It looks like you're doing a good job of 
gathering all the issues, so I'm confident I am sending it into safe hands.

1) Below, I've pasted an intarea email in which I raised the encap 
extensibility issue 5 years ago (and it got lost). It's Issue#1 below 
entitled "New IP hop-by-hop options and tunnels". It's not specific to 
IP, but the email gives more specifics about the problem in IPv6.

[Incidentally, I recently realised that a new type of extension header 
is needed in IPv6 to complement destination and hop-by-hop headers; we 
need a middlebox header that applies at certain identifiable hops but 
not all (theoretically IPv6 is not limited to new headers under the 
existing two types, it does allow new extension types to be defined). 
Bob Braden, Ted Faber and Mark Handley foresaw this in "From Protocol 
Stack to Protocol Heap - Role-Based Architecture".]

2) Regarding extensibility, pls read my position paper for the SEMI 
workshop. It's about a general pattern that I have noticed is good for 
extensibility in the presence of middleboxes. It is not yet recognised 
or accepted as an architectural principle, even tho it is appearing in 
more and more examples at different layers (4 are given in the paper): 
Tunneling Through Inner Space 
<https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_briscoe.pdf>
Most relevant to your design team is Generic USP Tunnelling (GUT), which 
is summarised in the paper.

3) You've already caught my issue#2 below "Propagation of mutable 
fields", but the email usefully generalises it to any mutable field 
(whereas you have it under QoS and congestion in your 12 step list).

4) I mentioned that Pseudowire Congestion Considerations 
<http://tools.ietf.org/html/draft-ietf-pwe3-congcons-02> is another 
relevant draft.

HTH

Bob

> Date: Mon, 26 Jul 2010 17:55:05 +0000
> To: Joe Touch <[email-masked]>
> From: Bob Briscoe <[email-masked]>
> Subject: draft-ietf-intarea-tunnels-00 review
> Cc: [email-masked]
>
> Joe,
[snip]

> * 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".
>
>
>
> Bob
>
>
> ________________________________________________________________
> Bob Briscoe, BT Innovate & Design 

________________________________________________________________
Bob Briscoe, BT