Subject: [tsvwg] Review of draft-ietf-tsvwg-rfc6040update-shim-05

From: joel jaeggli <[email-masked]>
Date: Wed, 15 Nov 2017 15:31:20 +0800

Hello, I agreed to review  draft-ietf-tsvwg-rfc6040update-shim-05 during
the tsvwg meeting on Monday 11/13.

Section 5 details the various encapsulations to  to which the behavior
described in the update is inteded to apply which 5.1 outlines the
specfic changes to be made.

As far as I can tell this normatively updates  the following (and the
draft agrees) which is a fair number of communities to reach out to.

[RFC6040]

[RFC2661] [RFC3931]

gre - [RFC2784]

teredo - [RFC4380]

AMT [RFC7450]

Looking more closely at AMT, with respect to rfc7450 4.1.4.2. As far as
I can tell, no meaningful action can be taken with respect to an ECN
signal can undertaken by an AMT receiver WRT to an individual flow. 7450
is  clear on the mechanisms AMT receivers have available to them. ECN is
not a circuit breaker nor is it conceivably expressive enough to be used
as one. it's possible that some potential uses of AMT could make use of
ECN signals across multiple flows.

I have solicited feedback from Mboned participants on the proposed
negotiation changes, to me they seem feasible.

---

minor semantic quible.

section 3.0 scope

	There is only one safe value a
   	tunnel ingress can use if it does not know whether the egress
   	supports propagation of the ECN field; it has to clear the ECN field
   	in any outer IP header to 0b00.

The outer header is being created by the encapsulating device. It sets
the ECN field to 00 when creating it rather than removing any value.

section 3.0 paragraph

   However, an RFC has no jurisdiction over implementations that choose
   not to comply with it or cannot comply with it, including all those
   implementations that pre-dated the RFC.  Therefore it would have been
   unreasonable to add such a requirement to RFC 6040.  Nonetheless, to
   ensure safe propagation of the ECN field over tunnels, it is
   reasonable to add requirements on operators, to ensure they configure
   their tunnels safely (where possible).  Before stating these
   configuration requirements in Section 4, the factors that determine
   whether propagating ECN is feasible or desirable will be briefly
   introduced.

could be more compactly writen as

An RFC cannot impose behavior on implementations that choose
not to or which cannot comply with it, inclusive of implementations
that pre-dated the RFC. To encourage safe propagation
of the ECN field over tunnels, it is reasonable to require operators
to configure their tunnels safely (where possible).  The
factors that determine whether propagating ECN to the outer
header is feasible or  desirable will be briefly introduced.

Thanks, I hope this helps.
Joel

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Nov 2017 19:37:16 +0800

Thx Joel for rapid turn round, inline..

> draft agrees) which is a fair number of communities to reach out to.
Yeah, it hasn't been easy. But it would have been even harder to get 
each community to write one RFC each.
> ECN signals across multiple flows.
No judgement on how the signal might be used was intended, but you're 
right that to be worthwhile at least there would have to be /a/ way. 
However, a CC mechanism can't be built at all without the signals from 
the network and I would assert that ECN is more expressive (or at least 
less ambiguous) than loss.

This AMT mechanism was largely added to the doc cos Jake Holland proved 
to me that it was no less worthy a candidate than the other ones in the 
doc. I proposed a design and he altered it:
* from Relay discovery messages (which might get intercepted by an 
intermediary)
* to IGMP Query Request messages,

> negotiation changes, to me they seem feasible.
To be precise it's a declaration rather than a negotiation.
Whatever, thx for checking it out.

> the ECN field to 00 when creating it rather than removing any value.
I'll leave it - it's clear (pun intended).
I generally copy-pasted that phrasing cos most tunnelling is done in 
hardware, and I'm told that copy from inner to outer then change certain 
fields is more likely in h/w. I accept that AMT is most likely to be 
software-based tho.

> header is feasible or  desirable will be briefly introduced.
Thanks. I'll use this, with some further 'improvement':

An RFC cannot impose behavior on implementations that cannot or
choose not to comply with it, including implementations
that pre-dated the RFC. Nonetheless, to encourage safe propagation
of the ECN field over tunnels, it is reasonable to require operators
to configure their tunnels safely (where possible).  The
factors that determine whether propagating ECN to the outer
header is feasible or desirable will be briefly introduced.

> Thanks, I hope this helps.
Certainly does. Thx.

I have yet another mtg tonight so I'll do the edits next week, along 
with those Sri would now like to add regarding Mobile IP (sry, that 
changes the draft following your edit, but I didn't want to turn down 
the offer).

Bob