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

[<philip.eardley at bt.com>]

Thanks david

> 
> > Over the last few months, our conversation has been progressing like
> > two guys at each end of a blunt saw. 

It is too painful to speculate how I fit into this analogy.

> 
> My concern is based on the following two points:
> 
> (A) I agree with reasoning of the form "<X> needs to be done for
ECN:CE,
> 	therefore it needs to be done for PCN:CE."  That's has to be
> 	valid, because if it were not, PCN would not have used the CE
> 	codepoint.
> 
> (B) I do not agree with reasoning of the form "<X> needs to be done
> 	for ECN:CE and PCN:CE, therefore it needs to be done for
> PCN:ECT(1)."
> 	As noted above, PCN:ECT(1) is not a directly comparable
> congestion
> 	indication to either ECN:CE or PCN:CE.
> 
> The immediate consequence of this is that we disagree on the treatment
> of Inner:Not-ECT/Outer:ECT(1).  I view the arguments for Drop in this
> case as instances of the (B) reasoning that I do not agree with.
Hence
> I prefer the treatment of this case to be forwarding with Not-ECT
(!!!)
> [exclamation points indicate unusual case that gets logged/alarmed.]
> 
> OTOH, this is splitting hairs over an error case [i.e., (!!!)].  If
I'm
> the only person with this concern, at some point the chairs should
> declare that I'm on the "rough" end of "rough consensus" and that'll
> be that - this issue is not worth the time of the ADs or IESG.

I'll leave the hair splitting to you & bob (presumably using an
extremely sharp saw)

> 
> That issue surrounded what to do when the inner and outer headers
> have different ECT values.  PCN uses Inner:ECT(0)/Outer:ECT(1), but
> has no use for the other case, Inner:ECT(1)/Outer:ECT(0).
> 

> 
> Let me suggest a blunter alternative:
> 
> - Only log/alarm (!!!) by default the transitions away from Not-ECT
> 	in the inner header (first line in Figure 4, 3 right hand
> boxes).
> 	These are just plain wrong, no matter what.
> - Do not alarm any other combinations by default.  That puts a rapid
> 	end to this discussion.

My original concern was about needing to have different configuration of
the alarms depending on the domain (PCN vs not). Not alarming any other
combinations is therefore ok with me.

> - Provide an explanation (in an Appendix?) about what to alarm in a
> 	controlled PCN environment.  The short summary is that because
> 	PCN has to be deployed in a closed/controlled network, it's
> 	reasonable for the operator to know (in some cases) that there
> 	are no RFC 3168 encapsulators, and therefore be confident I
> 	explicitly enabling a considerably more aggressive log/alarm
> 	approach that catches all reduction/removal of congestion
> 	markings by comparison to what's in Figure 4.
>