RE: Continued Poll for Adoption of Ethernet I-Ds

[<neil.2.harrison@bt.com>]

Title: Message

Hi Igor....please see in-line (have snipped mail to your question only)

 

Igor Bryskin  wrote 08 April 2008 22:17

> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Notionally support.  One concern I have revolves around the implications
of this para:

"4.1.3 Hybrid operation with legacy Ethernet

  The solution should take into consideration the operational scenario
  that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet
  hybrid networks. This morphs of network architecture is possible
  considering evolution scenario of Ethernet. In such networks, legacy
  Ethernet functionality such as Spanning Tree Protocol (SPT),
  Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE
  functionality.

  The solution must not prevent the simultaneous existence of GMPLS
  controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with
  native Ethernet Layer2 control protocols on same node and interface."

We must avoid the mistake that different network modes (ie cl-ps or
co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and
also have the same CP).  More specifically, native Ethernet is cl-ps and
PBB-TE is co-ps....so even though the base DP traffic unit of these 2
different network modes looks the same they MUST exist in their own
layer network space.  This requires that some (lower) server layer
network should create *different resource partitions* (in either space,
freq or time dimensions) for each client layer network mode type.

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. 

 

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.

 

regards, Neil