NH=> Excellent question. I have made exactly this same
observation in the past. In principle there is no reason why you cannot
re-use all the codepoints of each/every field in the traffic unit because, as
stated, although the traffic units look identical they do belong to quite
different layer networks. I think there are 2 reasons for
this:
- Firstly, most IEEE folks are not familiar with, and
therefore do not use, functional architecture techniques to describe layer
networks. So this issue may not be so obvious to many folks in
IEEE. Further, when we have QinQ techniques these are a form of
sublayering (like we find in nested LSPs in MPLS) and so we don't have
distinct layer networks here......and although folks may not describe it as
such they do recognise that one of the consequences of this (ie still a single
layer network) is that it affects scaling. However, once we have the
.1ah stuff and MACinMAC (ie true client/server) then everyone intuitively
recognises we have quite disjoint layer networks. So what I am saying
here is that for folks who don't have a strong background in functional
architecture, the observation you have made may not be so obvious even though
it is architecturally true.
- Secondly, there could be
practical/implementation reasons for doing this (ie creating a split in VID
codepoints) when dealing with COTS Ethernet hardware. Maybe some of the
Ethernet hardware experts can provide further clarification
here.
Disclaimer I'm not a hardware expert but Neil is correct there is
currently no "context" within an Ethernet Frame that could separate the PBB
B-VID space and the PBB-TE B-VID space. If these spaces used overlapping
B-VID values there would be know way to know by looking at the Frame. In
fact one of the attractions of PBB-TE is that it can reuse the existing
forwarding HW because it essentially forwards on (B-VID+MAC DA). A
result is a switch cannot tell the context implicitly.
One thing this does provide however is a clear way
to 'know' when looking at a traffic unit in isolation exactly which layer
network it belongs to.
Between the PBB B-MAC (server) and the PBB C-MAC
(client) it is clear looking at a
frame. Between PBB and PBB-TE the B-VID space partitioning in the
management (and control plane) is the only thing that separates the
behavior.
IB>> I think you are missing the point here. When it is said that PBB-TE and PBB (or any other native Ethernet) are different layer networks it means that what happens in one layer is transparent/irrelevant for the other even when the two layers have identical LI overhead. In other words this means that one layer does not get to analyze the LI (MAC header in this case) of the other layer unless there is some kind of misconfiguration and packets from one layer are leaking into another. But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB,
than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation.