Hi Brent, 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 that specification. 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. -- don On 16/10/14 08:50, Brent Marquis wrote:
All,
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.
Thanks, Brent
-----Original Message----- From: Simon Allard [mailto:Simon.Allard(a)team.orcon.net.nz] Sent: Monday, 13 October 2014 12:06 p.m. To: Nathan Ward; Brent Marquis; Dave Mill; Don Stokes Cc: nznog(a)list.waikato.ac.nz 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 hardcoded!
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 NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog