RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

[pat_thaler@agilent.com]

I am also confused about the same point. Some people such as Norm seem to be concerned about a CRC over the media and some seem to be concerned about an end to end CRC to protect against errors during CRC regeneration in bridges.

Of course as long as all the media are using the same CRC polynomial, the bridges could adjust the original CRC for any packet changes rather than regenerate. Personally, I think 802.1 Appendix G makes this look more complicated than it is.

Attempting an end-to-end MAC layer CRC isn't worthwhile. As soon as one goes through a higher layer device such as a router, it will get tossed and regenerated anyway (unless they do CRC adjustment for IP and MAC header changes which seems unlikely). If real end-to-end protection against corruption is desired, then the place to do it is in transport or above.

Pat

P.S. the CRC-32 provides Hamming distance of 4 - it detects all 3 bit errors up to something larger than 8 K.

-----Original Message-----
From: Mick Seaman [mailto:mick_seaman@ieee.org]
Sent: Tuesday, November 18, 2003 2:12 PM
To: stds-802-1@ieee.org
Cc: pwe3@ietf.org
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention




Let's be clear here. I believe Norm is saying that the service provided to a
bridge by whatever media needs to provide the same integrity as is provided
by Ethernet today. This may be accomplished by a CRC-32/integrity check with
Hamming distance of 5/whatever is needed to cover the particular faults of
the media. In this sense bridges may need a CRC option on some PW. This is
not a CRC transported through the bridge, and whatever the media in question
is or locally appears to the bridge to be, if it requires a CRC additional
to the Ethernet CRC it is *not* Ethernet but a *new MAC type*.

This is true even if the new MAC is partially constructed out of
802.3/Ethernet technology, and is documented in the 802.1 July 2003 minutes
(documenting discussion with the 802.3 leadership), and in the liaison to
the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay
function required 'inside' such a new media is not an 802.1 bridge.

For an 802.1 Bridge to use new media/MAC it requires a mapping of the
procedures etc. provided by the media to the Internal Sublayer Service (ISS)
used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5,
FDDI, and 802.11. These mappings are developed in close cooperation with the
group responsible for the MAC, and are usually written by that group, so it
is not in 802.1's gift to arbitrarily add to any existing mapping. There is
no restriction on such mappings being exclusively developed by IEEE 802, the
FDDI mapping was developed with the ANSI committee responsible for FDDI
(I've forgotten its name).

I am currently confused by the different answers I am getting on the CRC
question that Scott is posing. In discussion at the meeting Scott told me
that the proposed PW was using a perfectly adequate CRC, but hinted at some
other source of faults (badly implemented bridge? thing that looks like a
bridge to those not familiar with the bridging standards and what they
require?).

Mick

-----Original Message-----
From: owner-stds-802-1@majordomo.ieee.org
[mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla
Sent: Tuesday, November 18, 2003 12:22 PM
To: 'Norman Finn'
Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery'
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention



Norman,

What media are bridges going to be running PW over that does not have a
CRC?  Are you talking about a CRC of the PW payload or a CRC of the PW
packet including both payload and header?

Thanks,

Scott

-----Original Message-----
From: owner-stds-802-1@majordomo.ieee.org
[mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery
Sent: Tuesday, November 18, 2003 10:16 AM
To: Norman Finn
Cc: stds-802-1@ieee.org; pwe3@ietf.org
Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention


Hi Norman,

This is a good formulation of the problem.

thanks,
mark

---- Norman Finn <nfinn@cisco.com> wrote:
> 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

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3