Hi all,
So maybe this is
something to be commented to the IEEE……..they operate hybrid PBB/PBB-TE
networks.
In this draft we provide
a control plane to the dataplane that is defined by the IEEE, and specifically
we define a control plane for PBB-TE as defined by the IEEE 802.1Qay.
Nurit
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don Fedyk
Sent: Wednesday, April 09, 2008
17:38
To: neil.2.harrison@bt.com;
i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
Subject: RE: Continued Poll for
Adoption of Ethernet I-Ds
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.
|