Subject: RE: pwe3-ethernet-encap - Ethernet FCS needed...

From: "Christopher N. \"Nick\" DelRegno" <[email-masked]>
Date: Fri, 18 Apr 2003 12:35:42 -0500

Akiva:

>  As i understand, your point is that in Ethernet-over-PSN PW some
>malicious
>switch/router can corrupt the payload; in that case some layer 2 FCS of
the
>PW packets will be unable to detect these corrupted packets. Is that so
?

Yes.  As Lloyd Wood clarifies, a switch/router which is buggy or
failing.  While the Layer 2 over the wire will protect packets from bit
errors on the line, the customer MAC is vulnerable inside the box.  How
often does this occur?...It's hard to say.  We have seen it consistently
with one switch from one vendor.  We only saw it because it was so
dramatic, but damn hard to isolate.

My point in raising this issue is that for the network to arbitrarily
discard the customer FCS it requires a leap of faith that the network is
not going to screw up the payload prior to calculating a new FCS at the
far end of the network.  The error we saw was internal to an Ethernet
switch.  In the case of a pseudowire, there may be opportunity for this
to occur, however rarely.  

What I am asking is that we have an option to keep or discard the FCS
and signal accordingly.  That way, vendor equipment which doesn't
support FCS retention would interoperate with those that do.  It is then
a SP's choice of which they would rather use in their network.  I am not
asking that the FCS be checked anywhere in the pseudowire path, only
that it be maintained intact.

Regards,
Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Akiva Sadovski
Sent: Friday, April 18, 2003 5:57 AM
To: 'Christopher N. "Nick" DelRegno '; [email-masked] '
Subject: RE: [PWE3] pwe3-ethernet-encap - FCS...

 Hi, Nick,

  As i understand, your point is that in Ethernet-over-PSN PW some
malicious
switch/router can corrupt the payload; in that case some layer 2 FCS of
the
PW packets will be unable to detect these corrupted packets. Is that so
?
  Note, that exactly the same problem may exist in the
FrameRelav-over-PSN
encapsulation, where FCS is stripped by the PE device. But in case of
FR-over-PSN the solution will be complicated by the fact that the FCS
must
be carried along with bit stuffing, and bit stuffing presence complicate
DLCI analysis etc...

Thanks,
  Akiva Sadovski

-----Original Message-----
From: Christopher N. "Nick" DelRegno
To: [email-masked]
Sent: 17/04/2003 06:29
Subject: [PWE3] pwe3-ethernet-encap - FCS...

Beware, can of worms opening...

>From the original "Martini" draft to today, the customer FCS data has
been discarded.  Initially, my interest was in the "tagged" mode more
than the "port" or "raw" mode of encapsulation.  I noted that the FCS
was discarded in order to save 4 bytes as well as the fact that many
deployed implementations discard the FCS today.  Until recently, we were
okay with this.

In testing a very widely deployed Ethernet switch, we encountered an
anomaly which, if the FCS is discarded, would be a nightmare to
troubleshoot in a live network.  Briefly, while we weren't seeing any
packet loss across a fairly large Ethernet network and every packet was
being received by the destination host, all higher-layer frames were
being dropped by the host.  After spending an inordinate amount of time
using traditional Ethernet performance metrics to attempt to isolate the
problem, not until we intrusively placed Ethernet test equipment on both
ends did we discover that while the Ethernet FCS of every delivered
packet was good, the customer data was corrupt.  Interestingly it was
only in one direction.

Apparently one of the Ethernet switches in the network was internally
corrupting the data between the discarding of the customer FCS and the
calculation of a new FCS.  Mind you, there were no VLAN tag swaps or
stacks or the like.  This was a simple bridged connection, where the
Ethernet packet in theory shouldn't change, that was consistently
corrupting the data.

Now, had the FCS been maintained throughout the data path, the
customer's network-facing Ethernet switch would have dropped every
corrupted packet due to the FCS error.

In the pwe3-ethernet-encap draft as it stands, there is no provision for
keeping the received FCS.  In tagged mode, this is understandable since
I very well may change the VLAN ID at the far end of the network.
However, in the Ethernet mode, where I am sending ALL of the customer's
frames, without looking at the VLAN ID, I need the ability to maintain
the customer's FCS as well.

I realize that A) this is not how the draft is written, B) that if the
FCS is optional, then pwe3-control-protocol will have to be updated as
well to signal the presence or lack of the FCS (possibly via the
Interface Parameters field) and C) that many popular techniques to
stacked tags don't retain the customer FCS.  However, the cost of the
additional 4 bytes per packet and extra signaling information is worth
it.  When providing Ethernet private line type services, we have to rely
on the Layer 2 information to determine the performance of the network.
Maintaining the customer's FCS, resulting in a "Path FCS", gives the SP
an end-to-end error check.

In the truest sense of the term pseudo-wire, we are using a PSN to
emulate an Ethernet-cable.  It would be unacceptable if an Ethernet
cable somehow corrupted the payload of the MAC frames without the FCS
being able to detect it.  It is just as unacceptable if that Ethernet
cable is composed of packet switched networks instead of twisted pairs.

Admittedly, if such internal errors occur in network devices, having a
"Path FCS" will not tell me which switch is errant.  However, it will
tell me a problem exists, hopefully prior to my customer's contacting
me.  

Regards,

Nick DelRegno

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