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

From: Norman Finn <[email-masked]>
Date: Fri, 21 Nov 2003 13:03:07 +0100

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

[email-masked] 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:[email-masked]]
>>Sent: 18 November 2003 08:56
>>To: mark seery
>>Cc: [email-masked]; [email-masked]
>>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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
> 
>

---

From: mark seery <[email-masked]>
Date: Fri, 21 Nov 2003 08:31:11 -0800

Norman Finn wrote:

> "transport layers". 

Hi Norman, this is a key point and a key area of disconnect (which I 
think we have in IP-MPLS as well, though perhaps slightly less so in 
PW-MPLS). Service Provider's should consider this point carefully and 
decide whether it meets their needs or not.

> quality of each bridge, and by *demanding* the quality of each link. 

Norman, just out of curiousity, how does 802 guarantee the quality of 
bridges, and even if you get the PW requirements you want in terms of PW 
link guarantees, do routers have to be changed, in your opinion, to 
provide the equivalent quality of bridges. Just trying to understand all 
the moving pieces you need to get what you would consider an Ethernet 
grade service.

Thanks,
mark