Re: [PWE3] FCS retention in PWE3

[Eric Rosen <erosen@cisco.com>]

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. 



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