Subject: Re: FCS retention in PWE3

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 23 Nov 2003 03:52:50 -0500

Stewart et al,

I've just submitted draft-ietf-pwe3-fcs-retention-00.txt, which has been 
updated to reflect the discussion on the list to date.  In particular, I've 
added a new Applicability section to reflect the discussion on the list and 
in your message below, but I've made some other changes that were suggested 
as well, such as discussing FCS checking at pseudowire ingress (a MUST) and 
egress (a MAY).  I tried to make the new section succinct while still 
capturing the issues that have been discussed.

Once it comes out, please all send comments to the list.

Thanks,
Andy

----------

At 11/21/2003 04:24 PM +0000, Stewart Bryant wrote:

>Plan of Record
>--------------
>
>The plan of record in PWE3 with respect to FCS retention is that we
>would change the requirements draft to optionally permit the retention
>of FCS (currently is says must remove FCS), leave the base drafts
>as they are (they say remove FCS), and test the consensus of the WG
>for a new draft that calls up the optional retention of FCS for some
>encapsulations.
>
>Consensus
>---------
>
>Danny and I have reviewed the discussion on the list and agree that
>there is consensus for the new draft, and that we should proceed with
>the plan of record.
>
>We hence ask Andy to resubmit (draft-malis-pwe3-fcs-retention-00.txt)
>as a WG draft.
>
>Applicability statement
>----------------------
>
>Looking at the discussion so far, I think that we need to take great
>care in our drafting of the applicability statement in the FCS
>retention draft.
>
>To quote section 7 of our requirements draft:
>
>"An emulated service SHOULD be as similar to the native service as
>possible, but NOT REQUIRED to be identical. The applicability
>statement of a PWE3 service MUST report limitations of the emulated
>service."
>
>This means that our WG goal is to provide the necessary and
>sufficient degree of emulation, not perfection. In the specific
>case of Ethernet FCS retention, I would take this to mean that
>we must provide the necessary degree of faithfulness required
>to support the assumptions made in IEEE 802.1.
>
>I have seen three cases made for FCS retention in the mails to
>the list.
>
>1) IEEE 802.1 assumptions
>2) OAM
>3) Data integrity
>
>These need to be addressed in FCS retention draft applicability
>statement.
>
>
>IEEE 802.1 assumptions
>----------------------
>
>This is best summarized by the notes from Norman Finn:
>
>"PW is just another medium to a bridge.  However, *all* media
>known to bridges, at least as far as IEEE 802.1 are concerned,
>are 802 media, and all 802 media have 32-bit CRCs.  If you connect
>a medium that doesn't have at least a 32-bit CRC to a bridge,
>then the resultant bridged LAN will suffer a significant
>degradation in its ability to transport frames without error,
>because bridges depend on reliable media.  And then the routers
>on top of the bridges don't work so well."
>
>and
>
>"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."
>
>That is to say PWE3 provides a service to 802.1 and needs by one
>method or another to provide the necessary and sufficient
>degree of wire emulation such that their design assumptions hold.
>
>
>OAM
>---
>
>The original reason that FCS retention raised was because of an
>OAM issue. A malfunctioning bridge caused a network error, and
>it was thought that FCS retention would be useful in generating
>an alarm and diagnosing the fault. PWE3 is also developing an
>OAM method based on VCCV. We need to understand those
>circumstances where FCS retention is the best OAM technique,
>and those where VCCV is the better approach.
>
>
>Data integrity
>--------------
>
>Some folks want FCS retention as a means of assuring the data
>integrity of the PW service. The degree of enhancement in data
>integrity when using FCS retention, compared to the base drafts
>is something that we need to treat carefully, because CRC32
>offers a relatively weak degree of data assurance (4 or 5 bit
>corruption). The IETF standard method of ensuring data
>integrity is IPSec, and IPSec is called up in the security
>section of the PWE3 architecture for just this purpose. 802.1
>are planning their own method of enhanced data assurance which
>we would pass this transparently over the PW. Within the PWE3
>context the IETF method of providing a similar degree of
>data assurance would be to run IPSec between the PEs. We
>therefore need to describe the improvement in data integrity
>achieved through FCS retention and compare this to the
>improvements achieved through the use of IPSec.
>
>Regards
>
>Stewart
>
>
>
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Eric Rosen <[email-masked]>
Date: Mon, 24 Nov 2003 12:43:11 -0500

One thing that is  clear from this discussion is that we  were right to keep
the FCS option  out of the base  spec!  It's not at all  clear that carrying
the FCS is either a necessary  or a sufficient condition for the solution of
any actual problem. 

Let's step  back and look at some  of the reasons advanced  for carrying the
customer FCS: 

1. Port-to-port  ethernet  is  a  "transmission  service".   Unlike  general
   network  services, it is  a requirement  of "transmission  services" that
   every bit which goes in one end must come out the other end. 

   We haven't  discussed this putative requirement very  much.  There's been
   some  suggestion  that failure  to  meet it  will  result  in a  customer
   relations problem (between the SP  and its customers), but I haven't seen
   very much to back  this up.  Perhaps this is just a  dogma from the past,
   which can be discarded. 

2. A switch in  the SP network may corrupt frames.  If  this happens, and if
   there is no FCS which the  egress PE can check, then the corrupted frames
   will be  sent to the customer  network.  If this is  a regular occurrence,
   then the customer will complain to the  SP.  It would be better if the SP
   could detect  the corruption,  and not send  the corrupted frames  to the
   customer.   (Presumably  the customer  wont  complain  about the  missing
   frames?) 

   There seem to be two problems with this argument: 

   a. Since the ethernet FCS is  not validated on egress from a switch, this
      can't be  done.  Frames with bit  errors will be sent  to the customer
      even if they carry the customer's original FCS. 

   b. If  this were  really a  requirement, it would  apply equally  well to
      services other  than port-to-port  ethernet, even though  carrying the
      customer's  original FCS  is  not a  possibility  for those  services.
      Hence a solution other than carrying the customer's original FCS would
      be required.

   In  fact,  what  would really  be  needed  to  solve  this problem  is  a
   PW-specific checksum which is created  by the ingress PE and validated by
   the egress  PE.  However,  no one has  actually asked for  that, probably
   because the added overhead it would  create is obvious and the payback is
   minimal. 

   By the way, anyone  who thinks that the FCS should be  used to enable the
   SP (rather than the customer)  to detect the corruption should argue that
   the egress  PE MUST validate the FCS.   I don't see much  point in saying
   "MAY", as I think Andy has proposed. 

3. IEEE  specs require  that  any  media connecting  two  bridges provide  a
   bounded rate of undetected errors. 

   However, I  think the discussion has  made it pretty  clear that carrying
   the  customer  FCS  through  the  PWs  is  not  necessary  to  meet  this
   requirement.  As far as I can  tell, it is not sufficient either, because
   it is not possible to do in various scenarios involving VLANs.

4. A  proper understanding of  the theoretical  aspects of  network layering
   and/or  IEEE   standards  require  that  the  customer   FCS  be  carried
   transparently.  

   There are two problems with this argument: 

   a. Who cares? 

   b. In my  judgment,  Mick  Seaman and  Keith  Knightson have  thoroughly
      refuted the claim that this is even a theoretical requirement.

Taking  all these  together,  I just  don't  see any  reason  to pursue  the
"customer FCS retention" capability, even as an option.

---

From: mark seery <[email-masked]>
Date: Mon, 24 Nov 2003 14:08:46 -0500 (EST)

Eric,

Consider the following:

--|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|--

where a,b,c, & d are Ethernet ports

wouldn't ports "b" and "c" be able to detect FCS errors before they entered the customers network, and at least provide an indication that the problem is in the operators network and not the customers, therefore narrowing down the problem of diagnosing TCP checksum errors?

in the case where the CE-PE link was MPLS I agree that would require the CE to do a FCS check before egress on to a and d.

Mark

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 24 Nov 2003 14:51:02 -0500

Eric,

I think we've pretty beat to death whether or not FCS retention has merit, 
although I guess we can continue to repeat the same positions over 
again.  Both on the list and in Minneapolis, there has been expressed 
interest and consensus (which certainly doesn't meant unanimity :-) to make 
this a WG draft.  There are service providers who have said they would like 
to have this available for their networks, and vendors interested in 
implementing it.  As I said previously, I've tried to capture the 
discussion from the list in the new applicability section.  The draft 
should be out within a day or two (it's already been submitted), and I 
certainly invite your comments on the draft text.

Cheers,
Andy

----------