Hi Dave, Don,
Yes, Don is correct.
However, our handover is an 802.1ad interface. In .1ad CFI==DEI
My understanding is that this is regardless of SVID ethertype (which is selectable by RSPs when a handover is ordered) it is still an 802.1ad interface.
Alternatively - an RSP requesting us to change the SVID ethertype, doesn’t stop our interface from being 802.1ad.
I’m probably getting on some shaky ground here, but that is certainly how it appears to work on ALU’s implementation. If I’m wrong above, I’m happy to go back to ALU for clarification, etc.
Brent Marquis | Layer 2 Network Specialist
Chorus | T : +6448964169 | M :+64272290923
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Dave Mill
Sent: Thursday, 9 October 2014 12:14 p.m.
To: Don Stokes
Subject: Re: [nznog] UFB Upload Issues
We are using 0x8100 as the outer TPID in all cases for UFB. We're not certain at the moment if our equipment is dropping this traffic or if a provider could be. We have a bit of work to do to establish this still.
Would be interested to see Brent's thoughts on this on or off list :)
On Thu, Oct 9, 2014 at 11:52 AM, Don Stokes <firstname.lastname@example.org> wrote:
On 09/10/14 09:43, Brent Marquis wrote:
(stuff about CFI/DEI=1 traffic being dropped by Certain Hardware Vendors)
Quick question: are the handovers where this problem is occurring using
tag type 88a8 or 8100?
If it's using 8100, then the bit should be interpreted as CFI, whereas
if it's using 88a8 it should be treated as DEI. Thus, if the type is
88a8, the DEI bit should be treated as such, and equipment that
unconditionally drops DEI=1 traffic is Broken And Needs To Be Fixed.
On the other hand, if an 8100 tagged handover is not clearing CFI, it's
that end that is Behaving Badly and should be fixed. A box dropping
CFI=1 traffic on traffic received with a tag type of 8100 is behaving