Subject: Re: FCS retention in PWE3

From: Eric Rosen <[email-masked]>
Date: Tue, 25 Nov 2003 10:33:42 -0500

> FCS offers detection

I don't really see  any basis for this statement.  If what  we are trying to
detect is a malfunctioning switch, then we need to consider the various ways
in which a switch may malfunction before we can state that FCS enables us to
detect the malfunctions. 

For instance,  a switch  may malfunction by  discarding frames  entirely, or
perhaps by intermittently discarding bursts of frames.  FCS would not detect
this  sort of  malfunction.  Given  the way  switches work,  this is  a more
likely malfunction than overwriting the frame data.  

In  the particular  case  of PW,  a  switch may  malfunction by  incorrectly
manipulating  the PSN header  during transit.   This is  a much  more likely
malfunction than overwriting the frame data.  Carrying the customer's FCS to
the remote edge won't detect this at all. 

FCS may be  good for detecting burst errors on a  transmission medium, but I
see no reason to believe that  it has a high probability of detecting errors
that might be caused by malfunctioning switches. 

> CE to CE OAM tools are not in control of the provider and IMO the provider
> asking the customer to diagnose the service is a non-starter. 

I agree with this, but note that with the usual ethernet switching equipment
it would be the  egress CE that would detect any FCS  failure that is caused
by problems in the provider network.   So any specification of an option for
carrying the customer's  FCS should REQUIRE that the  egress PE validate the
FCS.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 25 Nov 2003 12:19:30 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Allan
Sent: Tuesday, November 25, 2003 10:08 AM
To: [email-masked]'; Scott Kotrla
Cc: [email-masked]; 'mark seery'; [email-masked]
Subject: RE: [PWE3] FCS retention in PWE3

 > Stewart: 
 >I think there is an aspect of your assertions that I am missing. CE to
CE OAM tools are not in control  
 >of the provider and IMO the provider asking the customer to diagnose
the service is a non-starter.  
 
      It is my understanding that at least several providers today 
have mechanisms that they provide to customers that allow them 
to test the PE-CE link from the PE if they suspect there is a 
problem (or check the link's status from the PE side), so I 
am not sure it is not such a "non-starter" as you characterize it.  
For example, in the L3 VPN case, I have seen
end-customers (i.e.: those that buy the L3 VPN service) simply ping  
 (using ICMP IP) betweeen the CEs  to test connectivity and/or
verify SLA on their own. When this fails, they can either call the
provider or  
 try the SPs web-based PE testing tool  which might further isolate the
problem 
 using LSP ping and other things within the core, as well as to to  ping
the PE-CE.
The only difference would be the inclusion of VCCV/LSP ping /trace on
the
core side.
 
    --Tom 

 > PE to PE OAM tools have incomplete coverage in the PE and as the
whole ECMP discussion highlights, is not payload and  
 > therefore may not be subject to exactly the same transfer functions.
PW OAM tools are typically single hop at the PW  
 > level so IMO are rather limited in utility.
 >Key delta here is detection vs. diagnosis. FCS offers detection, and
if done right can also provide a useful degree of fault isolation  
 > (via ingress and egress checking). It is not clear to me that an OAM
protocol helps the detection aspects in any useful timeframe  
 > if the nature of the problem is inherently masked. I also am not
grokking the reference to the use of crypto esp. in the context of  
 > diagnosis once we've assumed a problem exists....
 >What we are really discussing is the economics of service integrity,
a.k.a. is the problem sufficently rare that only diagnosis is  
 > required, and therefore it can be punted into reactive OAM tools and
we can save that 1/8th sq. inch of silicon in the  
 > forwarding plane. Personally I think there is a lot of value in a
service that works, and self identifies when it is broken.  
 > Ruthless optimization of the forwarding plane on the assumption that
it just works really complicates life when it doesn't work....
 >cheers 
 >Dave 

> -----Original Message----- 
> From: Stewart Bryant [ <mailto:[email-masked]>
mailto:[email-masked]] 
> Sent: Tuesday, November 25, 2003 5:47 AM 
> To: Scott Kotrla 
> Cc: [email-masked]; 'mark seery'; [email-masked] 
> Subject: Re: [PWE3] FCS retention in PWE3 
> 
> 
> 
> 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]>
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 
> > Mark> before 
> > they 
> > Mark> entered the customers network, and at least provide an 
> > Mark> 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>
https://www1.ietf.org/mailman/listinfo/pwe3 
> > 
> > 
> > _______________________________________________ 
> > pwe3 mailing list 
> > [email-masked] 
> >  <https://www1.ietf.org/mailman/listinfo/pwe3>
https://www1.ietf.org/mailman/listinfo/pwe3 
> > 
> > 
> 
> 
> _______________________________________________ 
> pwe3 mailing list 
> [email-masked] 
>  <https://www1.ietf.org/mailman/listinfo/pwe3>
https://www1.ietf.org/mailman/listinfo/pwe3