Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

[Norman Finn <nfinn@cisco.com>]

Mark,

In order to find out what PWE3 does or doesn't need to do, I'd like to restate
the problem.

Ethernet networks, consisting of IEEE 802 media and IEEE 802 bridges, today offer
a service that delivers a certain level data integrity assurance.  This is
necessarily the minimum level of assurance that we want Metro Ethernet to supply.
Any less would violate the unstated and unknown assumptions made by any number of
protocols that will be using a Metro Ethernet Service.

I take as a given (having sold them) that networks consisting of IEEE P802.1ad
Provider Bridges, Ethernets, and Pseudowires will be built.  To put it another
way, P802.1ad Provider Bridges will be an important "user" of Pseudowires.

Provider Bridges will be almost identical from IEEE 802.1Q bridges.  In particular,
they will not introduce any new mechanism, such as carrying a customer frame's
encapsulated FCS inside an outer FCS.  That would require more changes to the
IEEE 802.1Q spec that 802.1 is willing to make on this pass.

Therefore, the only model available to P802.1ad Metro Ethernets for preserving data
integrity is exactly that employed today by 802.1Q.  This model makes the extremely
important assumption that the world consists solely of 802 media and 802 bridges.  In
particular:

 1. All 802 media provide the same 32-bit Frame Check Sequence (FRC == CRC, Cyclic
    Redundancy Check).

 2. Bridges are prohibited from introducing undetected errors at a rate significantly
    greater than that of a single hop over an 802 medium.

There are a number of techniques by which a bridge can handle requirement 2.  They've
been mentioned in this thread and don't need to be gone over again.  End-to-end
preservation of the Customer's original FCS is an interesting proposition, but is
not relevant to this formulation of the problem.  What is important is that, unless a
Pseudowire can make at least as good a guarantee about data integrity as a physical
Ethernet can make, then it cannot be of any use to a P802.1ad Provider Bridge.

Now, while one can argue that a Pseudowire *might* be carried only over Ethernet
physical media, that is clearly insufficient.  The only solution is for there to be
a version of Pseudowires that incorporate the IEEE 32-bit CRC, or something even
stronger, with every Ethernet frame.  This requirement has nothing to do with whether
end-to-end CRC is employed; it depends simply on the fact that a Pseudowire is not
useful to a major class of devices, namely bridges, unless it carries at least an
Ethernet CRC.

-- Norm

Mark Seery wrote:
> Hi Ali,
>  
> */Ali Sajassi <sajassi@cisco.com>/* 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).
>  


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3