Subject: Re: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

From: "Sodder, Arnold" <[email-masked]>
Date: Fri, 11 Oct 2002 10:39:14 -0400

This requirement comes from an operations standpoint.

Consider the case where a CE device is creating incorrect data in the frame
body and creating a CRC based on the incorrect data.  When the frame is
received by the L2PE device the CRC will be checked and found to be good,
even though the data in the frame is bad.  When the total frame (including
the CRC) is delivered by the service providers network there is a trace left
as to where the error was created.  In the case where the CRC is stripped,
detecting the error becomes difficult.

Thus when the original customers frame is not modified this error can be
detected.  In the case where the customers frame is modified the error
cannot be detected.  In general there should be no need for the L2PE device
to modify the frame.  

For this reason I have choosen to carry the complete frame (including CRC)
over the service providers network.  Having an option is possible but being
an implementor I'd like to keep the PE and L2PE devices as simple as
possible and so choose to not support one.

Hopefully this addresses your question.

Arnold

---------------------------

Hi,Sodder, Arnold,

[VHLS] say: 

In the above frame formats the CE frame MUST -include- the original CRC32 to
allow detection of bit errors introduced by devices in the  service provider
network or attached to the service provider network.  If the L2PE device
needs to modify the CE frame it MUST calculate and add a new CRC32 to the CE
frame.

draft-martini-l2circuit-encap-mpls-03.txt say:

For simple Ethernet port to port transport, the entire Ethernet frame
-without- the preamble or FCS is transported as a single packet.

Would you consider change [VHLS] as later, just because many vendors surport
it now.

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
Du Wenhua [email-masked] <mailto:[email-masked]> 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ ¡¡¡¡¡¡¡¡¡¡2002-10-11

---

From: Norman Finn <[email-masked]>
Date: Tue, 15 Oct 2002 11:22:16 -0700

Arnold,

Are we talking end-to-end (e.g. enter a box from an Ethernet,
transmit on a tunnel, and out again on an Ethernet)?  If so, this
requirement is totally obsolete.

Such a "don't touch the original CRC" rule was once used by bridges.
But, bridges have been violating this rule since 802.1Q was
introduced.  Today, few 802.1Q-compatible bridges keep the CRC
intact end-to-end, whether actually doing 802.1Q or not.

Furthermore, for many kinds of service, especially those in which
different Customer VLANs are used to tell the Service Provider which
"tunnel" to which other site a frame should be sent on, it may be
important to change part of the frame.  For example, the 802.1Q tag
may need to change.  Not only that, but as currently implemented in
many MAN Provider networks, a customer's BPDUs may have their MAC
addresses altered in order to get them to pass transparently through
a network of Provider bridges.

There do exist algorithms that the very careful implementor may use
so that, if a frame is altered, a delta to the CRC can be computed
and XORed into the original CRC.  This allows the frame to be
changed without losing all of the benefit an end-to-end CRC.  It
would be much better to specify a SHOULD for this technique, rather
than prohibiting a class of very useful operations based on a
behavior that is obsolete.

-- Norm

---

From: Eric Rosen <[email-masked]>
Date: Tue, 15 Oct 2002 14:34:48 -0400

Norm> Such  a  "don't  touch  the  original  CRC"  rule  was  once  used  by
Norm> bridges. But, bridges  have been violating this rule  since 802.1Q was
Norm> introduced.  Today, few 802.1Q-compatible  bridges keep the CRC intact
Norm> end-to-end, whether actually doing 802.1Q or not.  

This  is actually a  PWE3 issue,  as it  has to  do with  the ethernet-over-
IP/MPLS  encapsulation and  the service  provided thereby,  but  has nothing
really to do with VPNs.

The discussion in PWE3 might have been easier if anyone there had known what
you say  above ;-)  However, the  "requirement" to keep  the CRC  intact was
rejected  there on the  grounds that  the PE  devices offering  the emulated
ethernet service might be routers  with standard NICs, and the standard NICs
might insist on generating the CRC no matter what anyone says. 

---
You are currently subscribed to ppvpn as: [email-masked]
To unsubscribe send a blank email to [email-masked]