Subject: Re: Continued Poll for Adoption of Ethernet I-Ds

From: Igor Bryskin <[email-masked]>
Date: Wed, 9 Apr 2008 08:31:03 -0700 (PDT)

Hi Don,

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.  

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.

Cheers,
Igor

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Attila Takacs" <[email-masked]>
Date: Thu, 10 Apr 2008 08:54:21 +0200

Hi Igor,

	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.  

Unfortunately, leaking from PBB to PBB-TE does not necessarily means
immediate discarding of PBB frames. Due to the VLAN separation between
PBB and PBB-TE, there is no clear layering here. Hence leaking can
essentially mean that the VID of a bridged (PBB) frame is changed to a
VID used for explicitly routed connections (PBB-TE). This does not
necessarily means that the frame will be dropped. It is a valid
assumption that the MAC address of the PBB frame is configured in the
PBB-TE region as well and as such leakig PBB traffic will be forwarded
as if it would belong to an explicitly routed connection. 

	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.

I think this is not necessary true, if one allocates the whole VLAN
space to PBB-TE then there will be no bridged traffic in the network. As
a consequence no leaking and no other cross effects is to be expected.
 
Best regards,
Attila