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

RE: Continued Poll for Adoption of Ethernet I-Ds



Title: Message
Hi Igor and Neil
 
See below,

IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.

What am I missing here?

Thanks,
Igor 
 
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. 
 
Regards,
Don
 
regards, Neil