Subject: [tsvwg] draft-ietf-tsvwg-ecn-tunnel-04 - Comment on Section 7

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 06 Nov 2009 10:15:36 +0100

I've just completed a review of the ECN Tunnel draft, and note that this 
is a much easier read than the last version and addresses my previous 
concerns.

Best wishes,

Gorry

---

Section 7:
- I think the title doesn't draw the readers attention, IMHO "Future 
Non-Default Schemes" is too vague, and I think should explicitly mention 
"Alternate Semantics for ECN".

- This section appears to clarify the brief text offered in RFC 4774.

- I interpret this section as offering some useful new guidance, but I'd 
urge care here. Currently it says:

   "In one word the guidance is "Don't".  If a scheme requires tunnels to
    implement special processing of the ECN field for certain DSCPs, it
    is highly unlikely that every implementer of every tunnel will want
    to add the required exception and that operators will want to deploy
    the required configuration options.  Therefore it is highly likely
    that some tunnels within a network will not implement the required
    special case.  Therefore, designers of new protocols should avoid
    non-default tunnelling schemes if at all possible."

- I think to be explicit the guidance is "don't design alternative 
tunnel semantics" (I think you're not trying to make RFC4774 historic?)

- I also don't particularly like the "highly unlikely", an operator 
could use a single vendor solution that would be OK (perhaps) - to me, 
the core issue is the real concern that is hard to guarantee that all 
tunnel endpoints will have the same interpretation, and if I understand 
right, you are saying it is probable that some tunnels will not do what 
they should (which seems likely also to me).

- I think the section SHOULD conclude by saying this extends (clarifies, 
updates?) the few paras in RFC 4774 on tunnels, by concluding with 
something like:
"This guidance extends the considerations in section 5.4 of RFC 4774, 
which requires new methods to consider the implications of tunnel 
encapsulated packets." ???
---