Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention

From: Stewart Bryant <[email-masked]>
Date: Mon, 01 Dec 2003 13:37:18 +0000

[email-masked] wrote:
> Hi Ali.....just a small remark.  regards, Neil
> 
> Ali Sajassi wrote 01 December 2003 08:13
> <snipped>
> 
>>>  Where the eth client gets encapsulated (let's say in 
>>
>>MPLS) is where the 
>>
>>>LSP trail starts (this can be any box)....and there is an 
>>
>>LSP trail term 
>>
>>>point where they get decapsulated. (Yes I know folks also 
>>
>>add a PW header 
>>
>>>but this is not a layer network, simply an adaptation 
>>
>>function).  This is 
>>
>>>simply client/server encapulation and well defined in 
>>
>>G.805.  If we carry 
>>
>>>the eth clinet over any server layer, you mentioned ATM or 
>>
>>FR (but I 
>>
>>>could also add PDH, SDH, etc), then exactly the same applies.
>>
>>No PDH and SDH are different. These are port-based Ethernet service; 
>>whereas, I was talking about vlan-based services (e.g., each 
>>VLAN is a VC) 
>>and making analogy between VLAN-id in Ethernet and DLCI in FR 
>>or VPI/VCI in 
>>ATM.
> 
> NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), 
> DLCI (FR) or a 'label' (MPLS) are all examples of link-connection 
> identifiers.  These entities have no network currency until/unless 
> they are associated with some parent trail entity (no matter 
> how that is created).  

Here you are talking about the inner label. The outer label
would normally be an abbreviation for an IP address.

> A VLAN ID is not a link-connection 
> identifier.  It is more like a 'name', in that it 
> subdivides the total MAC address population into contained 
> sub-spaces of MAC addresses (that belong to a given VLAN).  

Isn't it a virtual network identifier.

Stewart

---

From: mark seery <[email-masked]>
Date: Mon, 01 Dec 2003 12:38:55 -0500 (EST)

Hi Neil,

comment below,
mark

---- [email-masked] wrote:
> NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), DLCI (FR) or a 'label' (MPLS) are all examples of link-connection identifiers.  These entities have no network currency until/unless they are associated with some parent trail entity (no matter how that is created).  A VLAN ID is not a link-connection identifier.  It is more like a 'name', in that it subdivides the total MAC address population into contained sub-spaces of MAC addresses (that belong to a given VLAN).  I suppose it could be used in other ways, but that is my understanding of its native architectural significance.
> 
> regards, Neil
> <snipped

mark==> I think you have a reasonable grip on the intent of VLANs. From my own experience in defining products, it is clear though that a VLAN can have a membership of one, and can be used much like a link identifier. That use may not take in to account all the trail requirements you might see, but it is clearly possible including support for VLAN swapping/translation; and such solutions are already been marketed by vendors. There are some problems on the aggregation side, but am hopeful the formal definition of VLAN stacking might address these (not clear to me that all proprietary versions do).