[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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