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

From: Scott Kotrla <[email-masked]>
Date: Tue, 11 Nov 2003 15:28:29 -0700

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.

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.  Neither solution is implemented today, so an FCS seems
a lot simpler way to do things.  Providers build scalable networks by
adding layers.

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.

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

---

From: Ali Sajassi <[email-masked]>
Date: Tue, 11 Nov 2003 15:14:55 -0800

>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

>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

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

>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