I thought the interface specs clearly say that they don't honour the DEI
bit (classification is done using the PCP bits) on ingress; while it
doesn't say anything about what colour the DEI bit will be on egress, I
would have thought that the clear implication is that DEI is not part of
Any RSP doing classification on it is therefore making an unwarranted
assumption. I'd be really surprised if anyone is actually doing so, but
if you turned it off and it broke something, that would be the RSP's
problem, not yours. (Still, it's a fair question to ask.)
The robust thing to do, given that the DEI bit behaviour is not defined,
and given that setting it has caused problems, is to treat DEI as a Must
Be Zero field, ignore any incorrectly set DEI bits on egress, and
reliably set DEI=0 on egress. That both defines the DEI behaviour and
interoperates with pre 802.1Q-2011 compatible gear.
Otherwise, you really need to update the interface specification, with
full consultation with RSPs / TCF, to redefine the DEI bit behaviour. If
you're going to do that, you should revisit DEI behaviour on ingress as
well to allow for (optional?) DEI colouring instead of or as well as PCP
colouring. I do think the ingress and egress behaviour should be consistent.
On 16/10/14 08:50, Brent Marquis wrote:
I have a question about the converse side of the issue we have struck...
Are there any RSPs out there that are classifying on ingress from us based on DEI?
i.e.*IF* we did remove DEI=1, is it going to cause any pain? I guess this would most
likely be the guys with ALU kit which are using the DEI bit from us to classify, but I
suspect that no one is doing this...
As has been mentioned, it’s a global change for us to remove DEI. Given the impact to
our customers (you guys) and your customers, we're still investigating the possibility
of removing DEI. Which has technical and commercial issues around it.
From: Simon Allard [mailto:Simon.Allard@team.orcon.net.nz]
Sent: Monday, 13 October 2014 12:06 p.m.
To: Nathan Ward; Brent Marquis; Dave Mill; Don Stokes
Subject: RE: [nznog] UFB Upload Issues
People should really just use 0x88a8 - those who
aren’t, can I ask why not? Is it because you’re trying to tunnel it over a switch that
doesn’t support 802.1ad or something? I’m not saying it’s wrong, I’m > interested in
understanding the situations in which you might do this.
Some devices just
don't support it, even modern kit.
We use Pseudowires to transport handovers to central ALU 7750's. The ALU 7750 drops
the packets if we use 08x88 on the handovers in the Psuedowire code. Apparently 0x8100 is
Hopefully one day they will fix it.
This communication, including any attachments, is confidential and may be legally
privileged. If you are not the intended recipient, you should not read it - please contact
me immediately, destroy it, and do not copy or use any part of this communication or
disclose anything about it. Thank you. No confidentiality or privilege is waived or lost
by any mis-transmission or error. Please note that this communication does not designate
an information system for the purposes of the Electronic Transactions Act 2002.
NZNOG mailing list