Agreed
Attila.....let's not get this out of proportion......the key thing is to
understand that we are dealing with different layer networks in PBB (cl-ps) and
PBB-TE (co-ps) networks and getting this right is then largely a matter of good
design and implementation. If we want to throw stones at the underlying arch issue I can think of another
technology close to home that provides a far
richer set of problems in this respect
;-)
regards, Neil
Hi
all,
I do
agree that a clear/single network operation mode is desirable in practice,
however, as Nurit pointed out, IEEE 802.1Qay is more permissive in this regard.
However, if every VLAN is allocated for
PBB-TE, which is a valid configuration in 802.1Qay, then the network will
operate in a clear co-ps mode without side effects due to parallel PBB
operation.
On the other hand, I can imagine that in
some cases having a PBB bridged VLAN used, e.g.,to create connectivity for
control traffic, would be desirable and I do not see a problem with this
until it does not carry customer
traffic.
I think we do not need to do anything in
here; the level of permitted coexistence of PBB and PBB-TE is a network
operational issue, and it does not really affect the GMPLS extensions much
more than probably adding support to ensure that the VLANs configured for
PBB-TE are the same throughout the
network.
Best
regards,
Attila
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.
|