Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention

From: Scott Kotrla <[email-masked]>
Date: Tue, 11 Nov 2003 16:45:09 -0700

Let me make a small clarification.  

"My assumption is that the extra FCS could be added in such a way that
intermediate switches wouldn't have to know about or act upon the
original path FCS, since it would become part of the payload."

To fully understand what would happen, I'd have to understand what
happens per the 802 standards today.  Does 802.1 requires that the FCS
be:

1. Checked on ingress and carried across a device with recomputation at
egress if needed.

2. Checked on ingress, thrown away, with new computation at egress every
time.

For the first case, the customer FCS would be checked at Provider Edge
ingress, and a new service FCS would be added.  All intermediate
interfaces would treat the service FCS just like it has traditionally
treated the single FCS.  The Provider Edge egress would toss the service
FCS (without checking it since it was checked on ingress into the last
piece of equipment) and check the customer FCS before sending the
original packet to the customer.

For the second case, the customer FCS would be checked at the Provider
Edge ingress and passed through the device.  The egress of this device
would add a service FCS in the same way that in intermediate interface
would normally add a single layer FCS.  All intermediate interfaces
would treat the service FCS just like it has traditionally treated the
single FCS.  The ingress of the last piece of equipment would discard
the service FCS after checking it.  The Provider Edge egress would check
the customer FCS before sending the original packet to the customer and
it would not calculate a new FCS as would normally be done on a
traditional interface.  

Intermediate switches could look at both the path and the line level
FCS, but that requires even more functionality in the standard than I am
currently asking for and it obliviates existing devices in the middle.
If a device supports this functionality, then it should definitely not
pass the frame.  

As far as not knowing which box generated the error, I covered this in
my initial email:

> >As far as isolating the problem, a service providers can do fault
> >isolation using tools like loopbacks once it is know there is a
>problem.
> >If it is not known that the network is broken, there's no chance of
>ever
> >fixing it.  If equipment providers have done their jobs right,
internal
> >corruptions of packets should never leave the equipment.  However, if
> >equipment gets into the network that is not performing correctly, it
is
> >an absolute service provider requirement that it be possible to
> >determine that this unfortunate event has transpired.

If I know there is a problem I the network, then I can troubleshoot and
solve the problem.  If I don't know there is an error, how would I ever
know to even try to troubleshoot?  It could take days or even weeks to
determine that there is a problem that I need to troubleshoot.  This is
not acceptable to service providers who would use Ethernet as transport
infrastructure.

I am still in favor of requiring that devices in the middle of the
network not corrupt packets.  But this a requirement that is next to
impossible to check coherence to until the device has failed in such a
way and wreaked havoc on the network.

Thanks,

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali
Sajassi
Sent: Tuesday, November 11, 2003 4:15 PM
To: Scott Kotrla; 'Ali Sajassi'; [email-masked]
Cc: [email-masked]
Subject: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

At 03:28 PM 11/11/2003 -0700, Scott Kotrla wrote:
>As a service provider, my two issues with this approach are as follows:
>
>1. Every box end-to-end has to do this.  Some of the boxes in the
middle
>may already be deployed and may not support this functionality.  My
>assumption is that the extra FCS could be added in such a way that
>intermediate switches wouldn't have to know about it or act on it.

The intermediate boxes need to have such capabilities because:
a) If they don't detect, then they basically violate the basic
requirement 
of "keeping the integrity of FCS"
b) If they introduce an error and they cannot detect it and the
end-point 
detects it, then how do you know where the error occurred and how do you

trouble shoot
c) If they detect the error, then what is the point of passing the frame
to 
the end-point and waste BW

>2. I have no way of proving one way or the other whether equipment
>complies.  If I add an FCS I can very easily validate whether or not a
>vendor complies.

But how do you trouble shoot to find out which box generated the error
!! 
The important thing is to indicate the requirement and the vendors need
to 
meet that requirement. For example, there is a requirement for
availability 
and reliability of the box and a vendor needs to meet that.

>   Neither solution is implemented today, so an FCS seems
>a lot simpler way to do things.  Providers build scalable networks by
>adding layers.

But derivative of them have been implemented to ensure detection of
error 
that may be introduced inside the platform.

>While this has been addressed previously in 802.1, it has been
discussed
>in regards to enterprise applications and not provider applications.
>Providers have different requirements than enterprises do, namely in
the
>requirement to add layers and separation.  MAC-in-MAC would meet my
>needs, but I'd rather not go that route since it adds overhead, and I
>wouldn't be using the extra MAC address overhead.  Service providers
are
>not looking to turn Ethernet completely into SONET.  However, we are
>looking to port the small amount of SONET functionality that is
>regularly implemented into Ethernet so that carrier class Ethernet
>implementations are possible.  Line and Path level error checking are a
>key part of these requirements.
>
>I believe it was agreed in PWE3 that this functionality should be
>supported for those carriers who want to implement it.  I would agree
>that the 802.1ad and PWE3 applications are very similar and would
>encourage the same agreement to be reached.  I'm not asking for
>mandatory FCS retention.  I am asking for optional FCS retention.

I made my comments that I felt would help in clarification of this
issue. 
 From this point onward, I will pass the table to whoever else wants to
comment.

Regards,
Ali

>Thanks,
>
>Scott
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Ali Sajassi
>Sent: Tuesday, November 11, 2003 2:50 PM
>To: Scott Kotrla; [email-masked]
>Cc: [email-masked]; ali Sajassi
>Subject: Re: [802.1] 802.1ad Customer FCS Retention
>
>
>Scott,
>
>I tried to explain the issue and the possible solution in the PWE3
>mailing
>list; however, since you have brought this discussion to 802.1 group,
it
>is
>a good place to reference IEEE standards regarding this issue. This
>requirement is nothing new to IEEE and has already been captured in
>802.1
>standards.
>
>IEEE 802.1D/D3 Annex F (Preserving the integrity of FCS in MAC bridges)
>talks about exactly what you want and it suggests a solution for it
>without
>passing original FCS transparently. If you think about it, you see the
>situation of passing an Ethernet frames over bunch of bridges while
>keeping
>the integrity of FCS is the same issue as the one discussed for EoPW
>(over
>PtP PW).
>
>Either the scheme that is discussed in Annex F or a derivative of it
can
>be
>implemented to satisfy the requirement without passing the client FCS
>transparently.
>
>So instead of the solution to the requirement, it would be good if the
>requirement for this issue be clearly stated in your RFP.
>
>Regards,
>Ali
>
>At 11:57 AM 11/11/2003 -0700, Scott Kotrla wrote:
>
> >I am new to the 802 standards development effort, so please bear with
>me
> >if I break protocol.
> >
> >I'd like to open up the floodgate on the issue of Customer FCS
> >Retention.  I am very interested in what other service providers have
>to
> >say.  We have recently beat this to death in PWE3, and we haven't
seen
> >any service providers against it.  It has been agreed that the
Ethernet
> >PWE3 draft will be updated to make stripping the Ethernet FCS the
> >default action rather than the mandatory action.
> >
> >Since 802.1ad is specifically for service providers, I think this is
a
> >logical place to put this.  However, I don't really care where it
goes,
> >but as a service provider, I can definitively say that it is a
> >requirement.  MCI is already requiring dual FCS in RFP requirements,
>and
> >it is preferred although not required that there be a standard behind
> >this at some point in the future.
> >
> >I am a firm believer that this functionality is required to make
>802.1ad
> >useful to service providers.  Service providers require as much
> >transparency as is possible.  Keeping the customer FCS allows a
service
> >provider to validate end-to-end that a packet was not corrupted.
> >
> >As a service provider writing RFP requirements for equipment vendors,
I
> >can very easily require the FCS to be kept and I can do packet
captures
> >to validate compliance in a lab setting.  Asking an equipment
provider
> >to prove that their box is incapable of corrupting packets is a much
> >more daunting task, especially given that service VLANs may be riding
> >across an installed base of switches that may not meet these "packet
> >corruption requirements."  Other than the minimal effect of 4 extra
> >bytes, FCS retention affects the endpoints only and not every switch
in
> >between.
> >
> >As far as isolating the problem, a service providers can do fault
> >isolation using tools like loopbacks once it is know there is a
>problem.
> >If it is not known that the network is broken, there's no chance of
>ever
> >fixing it.  If equipment providers have done their jobs right,
internal
> >corruptions of packets should never leave the equipment.  However, if
> >equipment gets into the network that is not performing correctly, it
is
> >an absolute service provider requirement that it be possible to
> >determine that this unfortunate event has transpired.
> >
> >My recommendation is that stacking a Service FCS along with a Service
> >VLAN tag be an optional feature, with the default behavior being not
to
> >do so.  This will not affect equipment that does not support it, but
it
> >will allow service providers who are willing to give up 4 bytes the
> >capabilities to build more resilient and transparent networks.  I
> >understand that 802.3 would have to sign off on this as well, but
would
> >like to get agreement in 802.1 first.
> >
> >I'd like to focus on whether or not this should be worked on and not
> >specifically where it should go at this point.
> >
> >I'd like to understand concerns that anyone may have.
> >
> >Thanks,
> >
> >Scott

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

---

From: Mark Seery <[email-masked]>
Date: Tue, 11 Nov 2003 16:03:52 -0800 (PST)

Hi Ali,
 
Ali Sajassi <[email-masked]> wrote: 
<snip>
a) If they don't detect, then they basically violate the basic requirement 
of "keeping the integrity of FCS"

Ultimately, the issue may not be the integrity of FCS but the integrity of the payload. If the payload and a FCS become separated, and the payload gets corrupted before/while a new FCS is being generated, what has protected the integrity of the payload. Serious concern for people doing financial transactions as an example.
 
While I personally believe networks should be build so the layer that creates the PDU does the end-to-end check (so that service providers can do interworking for example without worrying about essentially the same issue and remembering that Ethernet is in some people's minds a link layer), it might be that service providers do not have control over their subscribers, and it might be that technologies built historically relying on link layer checks are at risk; and I suppose it could be argued that a PW is a virtual link layer - though I think that is debatable.
 
So while I personally believe that we should not try to solve a PWE integrity problem (perceived or otherwise) by making use of an Ethernet FCS, if there is an integrity of the payload problem, that might be a different issue.
 
>> <snip> b) If they introduce an error and they cannot detect it and the end-point detects it, then how do you know where the error occurred and how do you trouble shoot <<
 
Historically, service providers have used sectionalized (section, path, segment, end-to-end, near end, far end,.....) OAM mechanisms within the transport layer to achieve ongoing measurements, and theoretically recorded for retroactive inspection, to achieve such insights (not wishing to ignite another round of OAM discussions , just an observation).