Subject: RE: FCS retention in PWE3

From: Scott Kotrla <[email-masked]>
Date: Mon, 24 Nov 2003 13:47:31 -0600

Why couldn't the corruption be occurring in the customer's network?  How
are the provider and customer supposed to figure out whose fault it is
with certainty?  Because all of the links are checksummed, the error had
to have occurred inside a device. But there is NO way to isolate whether
it was a provider device or a customer device.  There are likely more
customer devices in the path than carrier devices, so it would seem more
likely to be a customer problem.  

Is it not clear that this is a huge nightmare for a service provider who
deploys this in a large scale?  I just don't get how people cannot see
how this could be useful in some SP networks.  The blanket statement
that it would NEVER be useful and shouldn't be an OPTION is absurd.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rosen
Sent: Monday, November 24, 2003 1:27 PM
To: mark seery
Cc: [email-masked]
Subject: Re: [PWE3] FCS retention in PWE3

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

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

I don't  think so.   Presumably the frame  is ethernet-checksummed  from
its
source to  the ingress PE, and  then is ethernet-checksummed  again from
the
egress  PE   to  its   destination.   The  only   place  where  it   is
not
ethernet-checksummed is in the SP network.  So if the frame actually
arrives
at the destination host with a  bad TCP checksum, chances seem high that
the
problem was in the operator's network. 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Nick DelRegno <[email-masked]>
Date: Mon, 24 Nov 2003 13:51:55 -0600

The problem is that noone will ever see the TCP checksum reported!  What if
it is UDP and checksum is disabled?

Please educate me as to how, as a SP, I can detect TCP checksum errors in my
network, IP, Ethernet or otherwise.

How often, when a client station is experiencing Internet connectivity
issues, does Support say, "Please tell me what your TCP Checksum counter
says," or better yet, Tech Support calls the end user to tell them "Our
network management system indicates an unusually high number of TCP Checksum
errors being reported by several end stations in our network, yours being
one." ??  In my exerperience, never.

The bottom line is: If I am connecting two Layer 2/Layer 3 devices together
via an emulated Layer 2 connection, I need to ensure that the part of the
link carried by my emulation is functioning properly.  Not doing so is like
not running Ethernet FCS on the links connecting my SP ethernet switches
together.  We would never do that.  Retaining the error check mechanism that
is already there provides the error check I require without dramatically
changing the spirit or form of PWE3.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rosen
> Mark> they entered the customers network, and at least provide an 
> Mark> indication that the  problem  is in  the  operators  
> network  and 
> Mark> not  the  customers, therefore  narrowing  down  the  
> problem of  
> Mark> diagnosing  TCP  checksum errors?
> 
> I don't  think so.   Presumably the frame  is 
> ethernet-checksummed  from its
> source to  the ingress PE, and  then is ethernet-checksummed  
> again from the
> egress  PE   to  its   destination.   The  only   place  
> where  it   is  not
> ethernet-checksummed is in the SP network.  So if the frame 
> actually arrives at the destination host with a  bad TCP 
> checksum, chances seem high that the problem was in the 
> operator's network. 
> 
>