Norm.
I gather that Service Providers (which purchase and deploy or plan to deploy Ethernet bridging equipment) find it exceedingly difficult, if not next to impossible, to determine that each piece of bridging equipment uniformly adheres to the 802.1 model.
Consequently, I would not categorize having a mechanism that supports a path like (i.e., end-to-end) integrity validation (via preservation of the client Ethernet FCS) as *pointless*. Rather I believe it should be a considered requirement.
Marc.
-----Original Message-----
From: Norman Finn [mailto:nfinn@cisco.com]
Sent: Friday, November 21, 2003 7:03 AM
To: neil.2.harrison@bt.com
Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org
Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
Neil,
I think Pat Thaler's reply helps to straighten out this confusion, but let me try, also.
There is a *lot* of confusion about the words "end-to-end", and about "transport layers". There are lots of ends in this picture, and there are layers and there are layers.
An 802.1Q VLAN bridge, and by extension, a P802.1ad provider bridge, does NOT supply a "transport layer" in the same sense as IP-over-Ethernet or Ethernet-over-IP. This is because, at the data forwarding layers, VLAN tags are best though of as extensions to the address space, not as additional protocol layers. If you want to call it a "transport layer", feel free! But don't assume that VLANs are equivalent to other "transport layers". Data integrity, specifically, is different in bridges.
Routers provide "best effort" not only in frame delivery, but in data integrity. There is no upper limit specified for the probability of delivery of a packet with undetected errors. IP's response, if you demand a particular level of data integrity, is that your application must supply its own checksum.
Bridges, however, are not routers!
Bridges *do* guarantee a level of service. They manage to do this by guaranteeing the quality of each bridge, and by *demanding* the quality of each link. Non-VLAN bridges, VLAN bridges, and Provider Bridges all make that guarantee to their users using this method. The Customers of a Provider Bridge service are not an "802.1Q application" over an "802.1ad transport layer". They are, in the 802.1 model, just endstations attached to a bridge. The Customers' data is just as well protected as an enterprise bridges' endstations, as long as the model is maintained. Adding an additional CRC to end-to-end service, where the ends are Customers attached to 802.1ad Provider Bridges, is therefore pointless. Changing that model is as silly as turning the model for routing upside down.
When a Pseudowire is used to connect two bridges, the "end-to-end" is now just those two bridges. Those bridges are using that PW as an Ethernet to carry their traffic. The bridges demand that every wire be as reliable as an Ethernet. That's the PW CRC issue.
-- Norm
neil.2.harrison@bt.com wrote:
> Norm....As per our discussion today face-face. I don't really see
> what the problem is here. The client layer network should not care
> about the server layer network (and vice versa)....we need this layer
> independence for lots of reasons. An ethernet traffic unit has a FCS.
> This should simply be transported transparently in the payload area of
> whatever the server layer is....and the server layer should use its
> own (OAM) 'integrity mechanisms' irrespective of the client. Problems
> arise when people start doing things like client layer compression and
> thus forming inter-layer dependencies.
>
> Further, as we agreed today and as I posted on an earlier mail to this
> thread, the ethernet FCS is a CRC that can be linerarly updated for
> adaptation function changes (eg VLAN ID change) on each
> link-connection (as provided by some server layer trail technology)
> whilst preserving its end-end intergrity check of the rest of the
> ethernet traffic unit between its trail termination points.
>
> regards, Neil
>
>
>>-----Original Message-----
>>From: Norman Finn [mailto:nfinn@cisco.com]
>>Sent: 18 November 2003 08:56
>>To: mark seery
>>Cc: stds-802-1@ieee.org; pwe3@ietf.org
>>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
>>
>>
>>Mark,
>>
>>You say below,
>>
>> > but a PW will be running over a physical media itself
>>already, possibly
>> > even SONET.............
>>
>>Exactly! Here, the trail gets a bit murky. If I'm in total
>>control, and the PW
>>is running over known Ethernet links, then I can get away
>>without the CRC in the
>>PW. I have no problem whatsoever with the current definition
>>of PWs without CRC.
>>
>>But, if I don't have tight control over the physical media
>>over which the PW runs,
>>then I really need a CRC on the PW for the bridge to be able
>>to trust the "wire"
>>and thus provide the same level of data integrity that
>>bridges offer over physical
>>Ethernets. So, I claim that bridges need a CRC option on PWs.
>>
>>-- Norm
>>
>>mark seery wrote:
>>
>>>Norman Finn wrote:
>>>
>>>
>>>><snip>
>>>>In other words, routers pass about $0.93 of the data
>>>
>>integrity buck to
>>
>>>>bridges,
>>>>and bridges pass about $0.75 of that to the data links.
>>>
>>The buck has
>>
>>>>to stop
>>>>somewhere, and the data link is where it stops. The PW
>>>
>>has to take
>>
>>>>the same
>>>>hit as the physical media.
>>>>
>>>>-- Norm
>>>
>>>
>>>but a PW will be running over a physical media itself
>>
>>already, possibly
>>
>>>even SONET.............
>>>
>>>mark
>>>
>>>
>>>
>>>
>>
>>
>>
>>_______________________________________________
>>pwe3 mailing list
>>pwe3@ietf.org
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
>
>