Subject: Re: FCS retention in PWE3

From: Eric Rosen <[email-masked]>
Date: Mon, 24 Nov 2003 15:35:20 -0500

Scott> Why couldn't the corruption be occurring in the customer's network? 

In  my interpretation of  Mark's example,  there's an  FCS carried  from the
source host  to the operator's  network (native ethernet service),  and then
another  FCS carried  from the  operator's network  to the  destination host
(native ethernet service), so corruption  in the customer's network would be
caught by the FCS. 

(Of course, it's also possible that  the ingress PE fails to properly detect
an invalid FCS.  This is no  less likely than having a device which corrupts
the packets, and would certainly make diagnosis difficult.)

Nick> The bottom  line is: If  I am connecting  two Layer 2/Layer  3 devices
Nick> together via an emulated Layer 2 connection, I need to ensure that the
Nick> part of the link carried by my emulation is functioning properly. 

Of  course; that  implies  the need  for  some OAM  capability.  What  we're
discussing here  is a particular solution,  not the question  of whether you
really need to maintain your network.

Nick> when a client station is experiencing Internet connectivity issues

If you were a service provider  offering layer 3 connectivity, how would you
handle IP connectivity problems?

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

How do  you determine that  some customer's ethernet equipment  is detecting
checksum errors on packets that came from your equipment?  Note that if some
particular switch in your network is corrupting packets, the corrupt packets
may enter the  networks of a variety of customers at  a variety of different
places, not necessarily causing a very large "bad checksum" spike in any one
place.

I  think what you  are really  asking for  is an  OAM capability  which will
identify the PWs that are experiencing trouble.

Scott> The blanket statement that it would NEVER be useful ... is absurd.

I  don't think  anyone said  it  could never  be useful,  one can  certainly
construct situations in  which it would be useful.   The question is whether
it gives you a significant increase in coverage. 

Andy> I guess we can continue to repeat the same positions over again

The post-IETF  debate has  gone to  a somewhat deeper  level; I  haven't yet
ruled out  the possibility that  someone will actually learn  something from
someone else, unlikely as it may seem ;-)

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Nov 2003 10:46:40 +0000

A question that I have raised before, and called up in my
applicability statement notes is whether VCCV (or similar)
allows us to diagnose the problem more accurately.

VCCV run between the PEs will allow the SP to audit the PW's
path over the PSN. The only element not covered is the
circuit between the CE and the PE, and the different
internal data path between the VCCV generator/receiver
and the PE-PSN interface. If the customer also runs an
OAM protocol, they can audit from CE to CE and validate
the whole SP PW path.

Unlike the FCS approach the OAM could be signed with a
decent crypto and would not be fooled by short error bursts.

If FCS is the right tool for the path audit we should use it,
but I am not convinced that it will do better than a
purpose designed OAM protocol.

Stewart

Scott Kotrla wrote:

> 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
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
>