Subject: Re: [802.1] RE: last call on control and ethernet drafts

From: Luca Martini <[email-masked]>
Date: Thu, 13 Nov 2003 16:58:13 -0700

Scott,

First of all I have to say that your requirement seem to invalidate the 
10s of gigabit of IP traffic that is forwarded today without operational 
issues and end to end layer2 FCS.
I also believe that requiring ans FCS end to end will result in major 
architectural changes for the routers that would ultimately have to 
perform FCS calculations on the hole packet.
Egress FCS check would require the routing engine to have access to the 
hole packet. I can safely say that none of the routing engines can do 
this today , and new hardware would have to be built and inserted in the 
data path just before the output MAC.
This would in turn significantly raise the cost of transporting the PW 
and ultimately make the service non-economical.
I still believe that the end to end FCS is the application layer task, 
however all network elements should have means to guarantee that data 
does not get corrupted while transiting the box.
Please consider also the fact vlan re-write would no longer be easily 
achieved.

I have not seen consensus on this issue yes, but there is a lot of 
arguing about it.

I propose that since this is going to be a major change we look at 
having a PW FCS that would be optional , and would work for all PWs. 
This would allow the current design to progress as is , and yet would 
meet your requirements for all types of PWs.

Luca

Matt Squire wrote:

>  
>
>>I would think this would be a function that would occur between the
>>frame manipulation of 802.1ad and passing the frame to the MAC.  I
>>assume that the MAC is not what does the 802.1ad VLAN 
>>stacking/swapping
>>functionality.  Is this assumption not true?
>>    
>>
>
>Thats certainly true.
>
>This functional block, which is pretty much HW, doesn't exist in most product architectures. I'm not saying it can't be added, but its a new egress HW block that doesn't cost much in C?COGS but which does change the fundamental architecture of what happens where and why.  
>
>  
>
>>I take from your message that doing the egress FCS check is 
>>the concern
>>and not appending the new FCS at ingress?  If so, you could make doing
>>the egress FCS check optional.  If turned off, the error detection
>>wouldn't be confined to the service provider network, but at least the
>>frames would all get tossed at the ingress to the customer network and
>>it would be clear that there is a problem.  802.3ah OAM could
>>potentially send an alarm message back to the service provider that
>>there are excessive errors on the wire once customer CPE supports this
>>feature.
>>
>>    
>>
>
>That's my primary concern from an implementation and architectural perspective.  Can't speak for anyone else.  
>
>On ingress, I can imagine how it could be done on non-ASIC implementations.  Of course how I imagine it happening might conflict internal error detection mechanisms (e.g. if you treat a packet with an FCS as not having an FCS, then its just data and you can add one at egress, but then its difficult to use that FCS internally for detecting internal corruption).  
>
>But all implementations are different and I can also see how it would make life difficult for some.  
>
>Personally, I'm torn.  I understand your concerns.  But I also understand Ali's reasoning that it may not buy you anything.  Your basic premise is that equipment can't be trusted:(  As an equipment vendor, I think I might cry...
>
>  
>
>>Maybe you have some insight into what MAC chips typically do with the
>>FCS.  How often is it tossed after the FCS check and how often is it
>>passed through the system end-to-end, with recalculation only if their
>>have been changes?
>>
>>    
>>
>
>(based on recollection, haven't verified with spec reading)
>
>Officially, I believe the MAC discards FCS errored frames on ingress.  Unofficially, most MACs provide mechanisms to pass up FCS errored frame (really needed in system debugging).  
>
>- Matt
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>  
>

---

From: Keith Knightson <[email-masked]>
Date: Fri, 14 Nov 2003 10:28:38 -0500

>I still believe that the end to end FCS is the application layer 
>task, however all network elements should have means to guarantee 
>that data does not get corrupted while transiting the box.

Luca,

This is a key point...

What assumptions are people making about what is being carried as payload?.

If IP/TCP is carried as 802 payload then maybe FCS is not so important.

If something else is being carried, it may be on the assumption that 
no extra error checking was necessary because the FCS  (was thought 
to be) end-to-end.  If people are saying that this never was really 
the case,  because FCS's were never end-to-end anyway (when via 
bridges, etc), then nothing needs to be done.  Applications were 
already operating under a false illusion but so what, nothing has 
really changed.

However, if applications operating over 802 (without IP/TCP) really 
need error checks, then either it has to be done at the 802 level or 
at the application level as you say. So either applications have to 
change or PWE has to change. Which is it to be?

Regards
Keith

---

From: mark seery <[email-masked]>
Date: Fri, 14 Nov 2003 10:09:18 -0800

Keith Knightson wrote:

> no extra error checking was necessary because the FCS  (was thought to 
> be) end-to-end.  If people are saying that this never was really the 
> case,  because FCS's were never end-to-end anyway (when via bridges, 
> etc), then nothing needs to be done.  Applications were already 
> operating under a false illusion but so what, nothing has really changed. 

Keith,

the technical issues you and Heiles are raising are very good.

there are non-technical issues to be considered whether in this forum or 
another.

the process of problem determination in any network, using any 
technology, is essentially: isolate, isolate, isolate, gotcha (having 
had to do it may times)

when one network manager has a financial relationship with another, then 
the first level of isolation is: is the problem in my network or yours. 
the expediancy with which a subscriber can say, well you didn't give me 
back what I gave you, greatly improves this process. if there is any 
doubt whatsoever about what happened within the service provider's 
network, then this process becomes more difficult. so while I see the 
technical merits of approaches being suggested, and wanted to confine my 
comments to that, these kinds of issues are also floating around.

in addition, in the U.S., some large LECs would not put a PE at a 
customer premise for regulatory reasons, some would. It comes down to 
how conservative the LEC is at interpretating out dated and imprecise 
regulation, and uncertainty about how that regulation might be changed, 
or not, in the near future. I realise the PE being at the customer site 
might not be the usual case, but thought I would bring it up for 
consideration anyway. a traditional transport approach should get around 
such regulatory concerns, but things like QoS treatment get to be a 
problem as well sometimes (not relevant to this discussion, just an FYI).

best,
mark