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

[<Black_David at emc.com>]

Bob,

> On alarms - our final issue...
> 
> We're agreed a Not-ECT inner with anything else in the outer gets 
> logged/alarmed.

Yes, we agree on this baseline.

> >The log/alarm behavior in Figure 4 of the -04 draft is somewhat
> >alarming ;-) ;-).
> >
> >Clearing ECT(1) to Not-ECT doesn't get logged or raise an alarm,
> >but clearing ECT(1) to ECT(0) does, while clearing CE to Not-ECT
> >doesn't.
> 
> Eh? I think somehow you're reading the table wrong, or typing wrong, 
> or I'm misunderstanding what you mean by 'clearing'.

It's probably the latter.  I meant "clearing" as an action performed
by a node within the tunnel to the outer header, so "clearing ECT(1)
to Not-ECT" by a node within the tunnel results in "Inner:ECT(1),
Outer:Not-ECT" ... which is not alarmed.

> >Before you write a long response, I'm aware that the
> >explanations of what does vs. does not get the log/alarm treatment
> >involve what happens when a new tunnel decapsulator is paired with
> >one of the two RFC 3168 encapsulator variants,
> 
> The reason I added these alarms is actually not to do with pairing 
> with 3168. They are just cases that have always been errors, but 3168 
> omitted to log/alarm them.

And turning this reasoning around, anything that 3168 could cause did
not get error treatment, independent of whether it might be a problem
for PCN.

> What's the reasoning for removing them? I'm happy to remove the two 
> alarms for mixed ECT, just because the case for them is marginal.

I think those both need to be removed, as Phil wants one of them
removed, and I want both of them removed if one is removed, leaving
one last case ...

> But ECT(1) outer with CE inner is an unambiguous error case.

I agree that it's an "unambiguous error case" - my concern is whether
it's worth detecting in isolation.
 
> We don't have to alarm any of these, but we ought to have a reason.

I'm trying to figure out "who cares?" (aside from us), i.e., is the
alarm useful by itself?

I come up with two scenarios:
- In an ECN environment, the problem situations of concern are loss
	of congestion indications.  Any change of Not-ECT (inner) to
	something else is the big one; we agree on alarming that.
	Secondarily, clearing of Inner:CE to something else in the
	Outer also drops congestion indications, but 3168 prevents
	default alarms on two of the three cases [Not-ECT and ECT(0)],
	so I'm having difficulty seeing the value in alarms for
	1 of 3 error cases.
- In a PCN environment, any downgrade of either CE or ECT(1) should
	be alarming ;-), as both carry congestion indications.  There
	are 5 downgrade cases (CE -> anything else; ECT(1) -> ECT(0)
	or Not-ECT), of which only 1 will carry an alarm.  Alarming
	1 out of 5 error cases seems even more unproductive by
	comparison to not alarming any of them ... and instead
	writing an appendix that suggests all 5 cased could/should
	be alarmed in a (closed system) PCN environment.

Thanks,
--David

> -----Original Message-----
> From: Bob Briscoe [mailto:rbriscoe at jungle.bt.co.uk] 
> Sent: Wednesday, November 04, 2009 12:03 PM
> To: Black, David
> Cc: philip.eardley at bt.com; tsvwg at ietf.org; Black, David
> Subject: RE: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel
> 
> David,
> 
> On alarms - our final issue...
> 
> We're agreed a Not-ECT inner with anything else in the outer gets 
> logged/alarmed.
> 
> At 21:24 29/10/2009, Black_David at emc.com wrote:
> > > FWIW, this decision about whether ECT(1) can be another form of CE
> > > will probably also mostly resolve the dangling topic of what
> > > transitions may generate alarms.
> >
> >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).
> >
> >The log/alarm behavior in Figure 4 of the -04 draft is somewhat
> >alarming ;-) ;-).
> >
> >Clearing ECT(1) to Not-ECT doesn't get logged or raise an alarm,
> >but clearing ECT(1) to ECT(0) does, while clearing CE to Not-ECT
> >doesn't.
> 
> Eh? I think somehow you're reading the table wrong, or typing wrong, 
> or I'm misunderstanding what you mean by 'clearing'.
> 
> Clearing ECT(1) to Not-ECT does raise an alarm in Fig 4. There's no 
> case where ECT(1) is cleared to ECT(0). And no case where CE is 
> cleared to Not-ECT.
> 
> Ug.
> 
> >Before you write a long response, I'm aware that the
> >explanations of what does vs. does get the log/alarm treatment
> >involve what happens when a new tunnel decapsulator is paired with
> >one of the two RFC 3168 encapsulator variants,
> 
> The reason I added these alarms is actually not to do with pairing 
> with 3168. They are just cases that have always been errors, but 3168 
> omitted to log/alarm them.
> 
> What's the reasoning for removing them? I'm happy to remove the two 
> alarms for mixed ECT, just because the case for them is marginal.
> But ECT(1) outer with CE inner is an unambiguous error case.
> 
> We don't have to alarm any of these, but we ought to have a reason.
> 
> >but the result is
> >still strange and possibly of limited value for PCN.
> 
> True.
> 
> Cheers
> 
> Bob
> 
> 
> >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.
> >- 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.
> >
> >If this is done, I think the current Appendix F can be bit-bucketed,
> >and that's probably an improvement.
> >
> >Thanks,
> >--David
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 
> 
> 
>