Subject: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel

From: <[email-masked]>
Date: Wed, 5 Aug 2009 13:55:55 +0100

hi
i wanted to follow up on this from stockholm. i've tried to catch up with bob & david's discussion, sorry for where my reading is incomplete.
 
- tunnel egress behaviour for 3168 & 4301 is inconsistent, amongst other motivations for change to a single consistent tunnel egress behaviour
 
- one set of changes is about
inner: not-ect
outer: isn't not-ect
which should neve be seen.
i think bob & david have converged (?). i have no desire to upset their convergence!
 
- another cahnge is about:
inner: ect(0)
outer: ect(1)
decaps header: ect(1)
this is a change from the current specs, although it's somethng that should never be seen. 
making this change enables 2 levels of congestion severity.
i think bob & david both agree with this change.
 
the point where there is disagreement:
David: in environements without 2 levels of congestion severity, then this is an error, so the tunnel egress MAY raise an alarm.
Bob: don't raise an alarm. 
 
David, my argument against your view is: this 'MAY raise an alarm' is actually different from all the other combinations of codepoints where the egress 'MAY raise an alarm'. in those other cases it's always the right thing for the egress to do. in this case however, if it's a domain that uses 2 levels of congestion severity, then it MUST NOT raise an alarm (becuase it's the expected behaviour), whereas if it's a domain that uses 1 level of congestion severity, then it MAY raise an alarm (becuase something's wrong).
to me the simplest thing would be not to raise an alarm, so there doesnt have to be different configuration depending on the domain. if the std does mention the alarm then somehow it has to be very clear that this is different from the other alarms.
 
best wishes
phil