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

From: Ali Sajassi <[email-masked]>
Date: Tue, 11 Nov 2003 13:50:17 -0800

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: Shahram Davari <[email-masked]>
Date: Tue, 11 Nov 2003 14:22:25 -0800

Ali,

I think when folks talk about passing the customer FCS transparently, they mean reuse it if it is valid.
This is what 802.1D says:

"If both a) and c) are true, then the FCS carried in the received frame is still valid, and the ideal approach
would be to reuse this value as the FCS for the transmitted frame."

Yours,
-Shahram

>-----Original Message-----
>From: Ali Sajassi [mailto:[email-masked]]
>Sent: Tuesday, November 11, 2003 4:50 PM
>To: Scott Kotrla; [email-masked]
>Cc: [email-masked]; ali Sajassi
>Subject: [PWE3] Re: [802.1] 802.1ad Customer FCS Retention
>
>
>Scott,
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>

---

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

The problem is that when I add or swap a Service VLAN tag I change the
frame and the FCS is no longer valid.  Most switches today toss the FCS
after confirming that no corruption occurred on the wire.  I'd like to
keep that functionality the same everywhere except for the new Provider
Edge interface, where a new FCS can be added, facilitating no changes in
the intermediate P switches.  It is much easier to add new functionality
on two new PE interfaces that are not yet fully defined than it is to
add new functionality on all PE and P interfaces in the network.

Thanks,

Scott

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

Ali,

I think when folks talk about passing the customer FCS transparently,
they mean reuse it if it is valid.
This is what 802.1D says:

"If both a) and c) are true, then the FCS carried in the received frame
is still valid, and the ideal approach
would be to reuse this value as the FCS for the transmitted frame."

Yours,
-Shahram

---

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

>would be to reuse this value as the FCS for the transmitted frame."

With respect to .1ad, case (d) is the one to consider since either customer 
tag is changed or provider tag is added. And the Annex recommends a 
solution without adding additional FCS (4 bytes). Also, once the platform 
is capable of supporting case (d), it can apply the same method to case (a) 
and (c).

I think the important requirement is what is stated in the document:

"In each case, it is important to ensure that there is a low probability of 
additional undetected errors being generated by corruption of the data 
portion of the frame between removal of the old FCS and computation of the 
new one, which would result in the transmitted frame carrying invalid data 
and a valid FCS. Such corruption might occur, for example, as a result of 
the effect of environmental noise on the operation of the Bridge hardware."

And as mentioned before there are several ways to skin this cat but we need 
to differentiate between the requirement and its corresponding solution.

-Ali

---

From: mark seery <[email-masked]>
Date: Mon, 17 Nov 2003 18:47:48 -0500 (EST)

Hi Nick, good comments. See in-line.

Regards,
Mark

---- Nick DelRegno <[email-masked]> wrote:
> If the PW transits only the physical media, then the discussion is moot.
> However, since PWs will likely span multiple physical media, multiple
> devices, and at the end of the day looks to the 802 bridges like a 
> physical media, it needs to held to the reliability/tolerance standards
> associated
> with physical media.

If it is your, and others, opinion that a PW running over a reliable media does not meet those standards, then I accept your judgement. If it is your opinion that we can not predict what a PW will run over, then that is a valid argument as well. If we accept the argument that routers always pass the buck to someone else, then the question has to be asked what has changed here (not withstanding Scott's comments on the merge of transmission and switching which were both insightful and relevant). There is a larger architectural discussion about whether PW is a multiplexing construct or a separate layer which plays into this issue - but that discussion has proven to be one the group has not enjoyed having and therefore remains one of those unlanced boils (with perhaps only a small minority - agreed).

> At the extreme, a PW FCS would provide this functionality.  But
> pragmatically, reuse of the Ethernet/FR/PPP FCS provides similar
> functionality without major overhaul to the standard.

I am on record as supporting the draft from Malis et el. so no argument on this point.
 
> A similar example would seem to be that of SONET Section/Line/Path overhead and the PM enabled by such segmentation. <

Section/line/path discussions have proven to be difficult both in this organization and by the sounds of it (large inferring warning) in the IEEE based on comments made about not wanting to pursue additional overhead (in the form of multiple MAC layers - which would mean painful changes). It could be argued that 802.3ah OAM is a tool which will deal with this problem (and I do agree it has some good capabilities), but ultimately, I am not sure it is the same.

At any rate, I understand what it does for you, and I understand why you mention it.

> Why have a path level if we have a
> bunch of serial line PMs.  Wouldn't that be good enough? Or does it make
> sense to have a path level check to ensure the integrity of the path?

It does indeed make sense to have a path integrity check. Please see my earlier comments on e2e payload integrity.

> The problem with tunneling of any sort is the loss of visibility within the tunnel.  This makes troubleshooting difficult, but it shouldn't prevent
end-to-end tunnel fault detection. <

If I thought agreeing with Norman would give you the section/line/path capability you desire, then I would shout "Uncle" in a picosecond, but while I will acknowledge my response to Norman was also not consistent with what you would like (and what I have agreed to support previously), IMHO, until we can separate our thinking into transport layers, services layers, and multiplexing functions, all these discussions become somewhat complex (accept within the group of people who have already agreed on a "path" forward). Using this kind of vocabulary usally invokes an immune response - for both good and bad reasons, IMO.

So either we say PW is a service layer similar to IP and leverages the underlying media in the way Norman suggested with his cost model analogy, or we pursue a layered approach which gets us closer to PW being a transmission facility was merely the kind of thinking I was trying to tease out (perhaps I was not skilled I agree).

This is of course the kind of interesting discussion you have when you move into a new problem domain, such as transporting a layer 2 protocol over a layer ? (higher than 1) protocol. Not saying we shouldn't do it, just saying that it is entirely understandable why these kinds of discussions are occurring, and ceratinly trust that the various "E's" in IEEE and IETF will work through the issues, well-guided by prospective users of the technology.

---

From: Scott Kotrla <[email-masked]>
Date: Tue, 18 Nov 2003 14:22:02 -0600

Norman,

What media are bridges going to be running PW over that does not have a
CRC?  Are you talking about a CRC of the PW payload or a CRC of the PW
packet including both payload and header?    

Thanks,

Scott

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of mark seery
Sent: Tuesday, November 18, 2003 10:16 AM
To: Norman Finn
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Hi Norman,

This is a good formulation of the problem. 

thanks,
mark

---- Norman Finn <[email-masked]> wrote:
> Mark,
> 
> You say below,
> 
>  > but a PW will be running over a physical media itself already,
possibly
>  > even SONET.............
> 
> Exactly!  Here, the trail gets a bit murky.  If I'm in total control,
and the PW
> is running over known Ethernet links, then I can get away without the
CRC in the
> PW.  I have no problem whatsoever with the current definition of PWs
without CRC.
> 
> But, if I don't have tight control over the physical media over which
the PW runs,
> then I really need a CRC on the PW for the bridge to be able to trust
the "wire"
> and thus provide the same level of data integrity that bridges offer
over physical
> Ethernets.  So, I claim that bridges need a CRC option on PWs.
> 
> -- Norm

---

From: [email-masked]
Date: Tue, 18 Nov 2003 22:44:42 -0000

Norm....As per our discussion today face-face.  I don't really see what the problem is here.  The client layer network should not care about the server layer network (and vice versa)....we need this layer independence for lots of reasons.  An ethernet traffic unit has a FCS.  This should simply be transported transparently in the payload area of whatever the server layer is....and the server layer should use its own (OAM) 'integrity mechanisms' irrespective of the client.  Problems arise when people start doing things like client layer compression and thus forming inter-layer dependencies.

Further, as we agreed today and as I posted on an earlier mail to this thread, the ethernet FCS is a CRC that can be linerarly updated for adaptation function changes (eg VLAN ID change) on each link-connection (as provided by some server layer trail technology) whilst preserving its end-end intergrity check of the rest of the ethernet traffic unit between its trail termination points.

regards, Neil

> From: Norman Finn [mailto:[email-masked]]
> Sent: 18 November 2003 08:56
> To: mark seery
>  > but a PW will be running over a physical media itself 
> already, possibly
>  > even SONET.............
> 
> Exactly!  Here, the trail gets a bit murky.  If I'm in total 
> control, and the PW
> is running over known Ethernet links, then I can get away 
> without the CRC in the
> PW.  I have no problem whatsoever with the current definition 
> of PWs without CRC.
> 
> But, if I don't have tight control over the physical media 
> over which the PW runs,
> then I really need a CRC on the PW for the bridge to be able 
> to trust the "wire"
> and thus provide the same level of data integrity that 
> bridges offer over physical
> mark seery wrote:
> > Norman Finn wrote:
> >> <snip>
> >> In other words, routers pass about $0.93 of the data 
> integrity buck to 
> >> bridges,
> >> and bridges pass about $0.75 of that to the data links.  
> The buck has 
> >> to stop
> >> somewhere, and the data link is where it stops.  The PW 
> has to take 
> >> the same
> >> hit as the physical media.
> >>
> >> -- Norm
> > 
> > 
> > but a PW will be running over a physical media itself 
> already, possibly 
> > even SONET.............
> > 
> > mark
> > 
> > 
> > 
> > 
> 
> 
>

---

From: Scott Kotrla <[email-masked]>
Date: Tue, 18 Nov 2003 17:08:57 -0600

Let me attempt to clarify why I brought up Pseudowires in the first
place.

Pseudowire/Ethernet transport of Ethernet services(protocol stack is
Customer Tagged Ethernet/Pseudowire/Carrier Untagged Ethernet, note the
Carrier Ethernet could be GFP, HDLC, X.86, etc.) looks a lot like
Stacked VLAN transport of Ethernet services (protocol stack is Customer
Tagged Ethernet/Carrier VLAN).  In the Pseudowire model, the customer
FCS (originally tossed in the PWE3 specs but now optionally maintained)
is an end-to-end Path FCS, while the carrier FCS (always present for
Ethernet over Dark Fiber implementations as part of the underlying L2
transport of the L2.5 PW frame) is a Link/Line FCS.  In the stacked VLAN
transport, the customer FCS is tossed/overwritten, just like it was in
the PWE3 spec originally.  The newly calculated FCS is a Link/Line FCS.

Keeping the customer FCS in PWE3 (when there is already an underlying
Link/Line FCS) is exactly the same as keeping the customer FCS in a
Stacked VLAN model and appending a new Link/Line FCS (instead of
overwriting the customer's FCS).  If we can get consensus on this, then
we should also be able to get consensus that the same functionality
should optionally be available in either architecture.  This consensus
has already been reached in PWE3, and my goal is to reach the same
consensus in 802.1.  

As Norm stated, router guys take the underlying error correcting
capabilities that bridges provide for granted, so it should take less
work to convince bridge guys (who understand the importance of error
detection) than it did to convince router guys, which by the way was a
very long and grueling process.  

I plan to put some drawing together showing the protocol stack
similarities as well as the functions required at each point in each
switch for these various scenarios when time permits.  

Hope this textual explanation provides some clarification.

Thanks,

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mick
Seaman
Sent: Tuesday, November 18, 2003 4:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Let's be clear here. I believe Norm is saying that the service provided
to a
bridge by whatever media needs to provide the same integrity as is
provided
by Ethernet today. This may be accomplished by a CRC-32/integrity check
with
Hamming distance of 5/whatever is needed to cover the particular faults
of
the media. In this sense bridges may need a CRC option on some PW. This
is
not a CRC transported through the bridge, and whatever the media in
question
is or locally appears to the bridge to be, if it requires a CRC
additional
to the Ethernet CRC it is *not* Ethernet but a *new MAC type*.

This is true even if the new MAC is partially constructed out of
802.3/Ethernet technology, and is documented in the 802.1 July 2003
minutes
(documenting discussion with the 802.3 leadership), and in the liaison
to
the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay
function required 'inside' such a new media is not an 802.1 bridge.

For an 802.1 Bridge to use new media/MAC it requires a mapping of the
procedures etc. provided by the media to the Internal Sublayer Service
(ISS)
used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5,
FDDI, and 802.11. These mappings are developed in close cooperation with
the
group responsible for the MAC, and are usually written by that group, so
it
is not in 802.1's gift to arbitrarily add to any existing mapping. There
is
no restriction on such mappings being exclusively developed by IEEE 802,
the
FDDI mapping was developed with the ANSI committee responsible for FDDI
(I've forgotten its name).

I am currently confused by the different answers I am getting on the CRC
question that Scott is posing. In discussion at the meeting Scott told
me
that the proposed PW was using a perfectly adequate CRC, but hinted at
some
other source of faults (badly implemented bridge? thing that looks like
a
bridge to those not familiar with the bridging standards and what they
require?).

Mick

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Scott Kotrla
Sent: Tuesday, November 18, 2003 12:22 PM
To: 'Norman Finn'
Cc: [email-masked]; [email-masked]; 'mark seery'
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Norman,

Thanks,

Scott

-----Original Message-----

Hi Norman,

thanks,
mark

possibly
and the PW
CRC in the
without CRC.
the PW runs,
the "wire"
over physical

---

From: "Mick Seaman" <[email-masked]>
Date: Tue, 18 Nov 2003 15:46:16 -0800

Scott,

I thoroughly disagree with your statement

"Keeping the customer FCS in PWE3 (when there is already an underlying
consensus in 802.1."

The similarity in drawing pictures should not obscure the fact that no value
would be provided in current bridged networks by retaining the additional
FCS, as the existing mechanisms  have been shown to provide the level of
integrity required. The addition of the option would in contrast introduce
new scenarios for failure of network connectivity and new work for all, to
no purpose.

Modelling your "customer FCS" as part of the a "new MAC" that you are
creating, and thus purely applicable to the service provided between a pair
of bridges is sufficient to explain its role in the architecture.

Mick

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Scott Kotrla
Sent: Tuesday, November 18, 2003 3:09 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Thanks,

Scott

-----Original Message-----

Mick

-----Original Message-----

Norman,

Thanks,

Scott

-----Original Message-----

Hi Norman,

thanks,
mark

possibly
and the PW
CRC in the
without CRC.
the PW runs,
the "wire"
over physical

---

From: Nick DelRegno <[email-masked]>
Date: Tue, 18 Nov 2003 21:14:09 -0600

Maybe I have a far too simplistic view of the world, but...  Anytime you are
tunneling L2 across anything other than a link, I see merit in a path FCS.
This is as true for Stacked VLANs as it is for Ethernet pseudowires.
Fortunately, I see only a very limited life for Stacked VLANs with my
network.  As soon as I have the FCS retention on Ethernet pseudowires, I
will not deploy a single additional stacked VLAN.  In the interim, I'll
deploy proprietary solutions which allow me to leave the customer FCS
untouched and allow the appending of a provider FCS on the end.  These exist
today...

Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mick
Seaman
Sent: Tuesday, November 18, 2003 5:46 PM
To: 'Scott Kotrla'; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Scott,

Mick

-----Original Message-----

Thanks,

Scott

-----Original Message-----

Mick

-----Original Message-----

Norman,

Thanks,

Scott

-----Original Message-----

Hi Norman,

thanks,
mark

possibly
and the PW
CRC in the
without CRC.
the PW runs,
the "wire"
over physical

---

From: "Mick Seaman" <[email-masked]>
Date: Tue, 18 Nov 2003 22:54:11 -0800

Consider the following in stacked VLANs - Customer VLANs over Service VLANs
(once called Provider VLANs).

The provider bridges that support the S-VLANs run configuration protocols to
organize and operate the S-VLAN topology. These protocols use nothing more
than the naked service between those provider bridges. Therefore that
service has to provide a level of integrity comensurate with Ethernet as is
today, otherwise the network is going to fall apart in odd ways. Once you
have that necessary level of service and a decent bridge, you have the
service level necessary to support the customers.

Feel free to deploy your proprietary solutions if you must, there is an
amazing array of choices out there and IEEE standards are voluntary, but
don't push up the cost and complexity for everyone for what has to be
infinitesimal benefit. Would you like to put some numbers on the increased
level of reliability you expect from the additional FCS?

Mick

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Nick DelRegno
Sent: Tuesday, November 18, 2003 7:14 PM
To: [email-masked]; 'Scott Kotrla'; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Nick

-----Original Message-----

Scott,

Mick

-----Original Message-----

Thanks,

Scott

-----Original Message-----

Mick

-----Original Message-----

Norman,

Thanks,

Scott

-----Original Message-----

Hi Norman,

thanks,
mark

possibly
and the PW
CRC in the
without CRC.
the PW runs,
the "wire"
over physical

---

From: Heiles Juergen <[email-masked]>
Date: Wed, 19 Nov 2003 11:38:46 +0100

Pat,

we are talking about Ethernet services which are for example transported over IP. In this case the Ethernet MAC frame is a payload of the IP frame. This IP frame may again be transported over Ethernet so we have the following stack:

Ethernet MAC service
   |
  IP
   |
Ethernet MAC transport

Any changes to the IP header or the transport MAC header have no influence on the Ethernet MAC service frame and its FCS. 

Regards

Juergen

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Mittwoch, 19. November 2003 00:39
> An: [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
> 
> 
> 
> I am also confused about the same point. Some people such as 
> Norm seem to be concerned about a CRC over the media and some 
> seem to be concerned about an end to end CRC to protect 
> against errors during CRC regeneration in bridges.
> 
> Of course as long as all the media are using the same CRC 
> polynomial, the bridges could adjust the original CRC for any 
> packet changes rather than regenerate. Personally, I think 
> 802.1 Appendix G makes this look more complicated than it is.
> 
> Attempting an end-to-end MAC layer CRC isn't worthwhile. As 
> soon as one goes through a higher layer device such as a 
> router, it will get tossed and regenerated anyway (unless 
> they do CRC adjustment for IP and MAC header changes which 
> seems unlikely). If real end-to-end protection against 
> corruption is desired, then the place to do it is in 
> transport or above.
> 
> Pat
> 
> P.S. the CRC-32 provides Hamming distance of 4 - it detects 
> all 3 bit errors up to something larger than 8 K.
> 
> From: Mick Seaman [mailto:[email-masked]]
> Sent: Tuesday, November 18, 2003 2:12 PM
> To: [email-masked]
> Cc: [email-masked]
> Let's be clear here. I believe Norm is saying that the 
> service provided to a
> bridge by whatever media needs to provide the same integrity 
> as is provided
> by Ethernet today. This may be accomplished by a 
> CRC-32/integrity check with
> Hamming distance of 5/whatever is needed to cover the 
> particular faults of
> the media. In this sense bridges may need a CRC option on 
> some PW. This is
> not a CRC transported through the bridge, and whatever the 
> media in question
> is or locally appears to the bridge to be, if it requires a 
> CRC additional
> 802.3/Ethernet technology, and is documented in the 802.1 
> July 2003 minutes
> (documenting discussion with the 802.3 leadership), and in 
> the liaison to
> procedures etc. provided by the media to the Internal 
> Sublayer Service (ISS)
> FDDI, and 802.11. These mappings are developed in close 
> cooperation with the
> group responsible for the MAC, and are usually written by 
> that group, so it
> is not in 802.1's gift to arbitrarily add to any existing 
> mapping. There is
> no restriction on such mappings being exclusively developed 
> by IEEE 802, the
> question that Scott is posing. In discussion at the meeting 
> Scott told me
> that the proposed PW was using a perfectly adequate CRC, but 
> hinted at some
> other source of faults (badly implemented bridge? thing that 
> looks like a
> without the
> over which

---

From: Heiles Juergen <[email-masked]>
Date: Wed, 19 Nov 2003 11:50:51 +0100

Scott,

the pseudo wire and stacked VLAN case are different in my view.
Lets start with the Ethernet pseudo wire case:

The client is the Ethernet MAC signal. This could be a untagged frame, a .1Q tagged frame, a .1ad provider tagged frame or even a proprietary .1Q in .1Q tagged frame. The pseudo wire should not care about it. It is mapped into MPLS or IP using the pwe3 mapping. If the pseudo wire is a layer of its own or only a mapping is not relevant for this discussion. So we have the following basic network layering:

    Ethernet MAC ETH    client
          |               |          
       MPLS LSP         server  client
          |                       |
         xyz                    server

MPLS is a server layer for ETH and MPLS itself is again supported by server layers. MPLS switching, supervision and OAM is independent of the ETH client layer. MPLS can not touch or modify the MAC frame. It is a real tunnel case.
With the original pwe3 definitions the MAC FCS would be stripped when the frame was mapped and a end-to-end FCS check of the ETH link over the pseudo wire was not possible. With the optional inclusion of the FCS it is possible. This is the issue Norm is talking about I think. The ETH link over a pseudo wire should provide the same functionality as over a physical Ethernet or as for example over SONET/SDH (using GFP or LAPS).
Note that even with the inclusion of the FCS it doesn't always mean that this is the original customer FCS. This is only the case when the Ethernet UNI is directly forwarded to the pseudo wire without any Ethernet bridging in between. In case of a multiplexed access link (service services on the access link separated by VLAN tags) or in the VPLS case (MAC switching) a Ethernet bridge function is located between the UNI and the pseudo wire which does the normal Ethernet FCS processing.

Stacked VLAN:
With the stacked VLAN we do not introduce new layer. The VLAN provides a method to fragment/part ion an ETH network in several smaller ETH networks (see ITU G.8010 Ethernet Network Architecture which is in the approval process). Connectivity is only possible within the specific VLAN. Forwarding decisions are still based on the MAC addresses. Switching, supervision and OAM is/will be based on the MAC frame and the MAC frame can/will be modified including the FCS. So it is not a real tunnel.
Even in this case preserving the customer FCS is useful when errored customer frames would be forwarded through the network and not dropped at the ingress. This is for example the case in SONET/SDH Tandem Connection Monitoring as we do not drop frames with wrong FCS in circuit switched networks.
As stated in my earlier mail Ethernet drops frames with wrong FCS. So we have only customer frames with correct FCS forwarded at the ingress UNI. If the normal MAC FCS is not recalculated at each bridge but instead is modified according to the changes to the frame it provides the UNI-to-UNI coverage for the customer frames Scott is looking for without the need to tunnel the customer FCS.

Regards

Juergen

> -----Ursprungliche Nachricht-----
> Von: Scott Kotrla [mailto:[email-masked]]
> Gesendet: Mittwoch, 19. November 2003 00:09
> service provided
> particular faults
> some PW. This
> cooperation with
> that group, so
> mapping. There
> by IEEE 802,
> looks like

---

From: [email-masked]
Date: Tue, 18 Nov 2003 16:38:52 -0700

I am also confused about the same point. Some people such as Norm seem to be concerned about a CRC over the media and some seem to be concerned about an end to end CRC to protect against errors during CRC regeneration in bridges.

Of course as long as all the media are using the same CRC polynomial, the bridges could adjust the original CRC for any packet changes rather than regenerate. Personally, I think 802.1 Appendix G makes this look more complicated than it is.

Attempting an end-to-end MAC layer CRC isn't worthwhile. As soon as one goes through a higher layer device such as a router, it will get tossed and regenerated anyway (unless they do CRC adjustment for IP and MAC header changes which seems unlikely). If real end-to-end protection against corruption is desired, then the place to do it is in transport or above.

Pat

P.S. the CRC-32 provides Hamming distance of 4 - it detects all 3 bit errors up to something larger than 8 K.

-----Original Message-----
From: Mick Seaman [mailto:[email-masked]]
Sent: Tuesday, November 18, 2003 2:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Let's be clear here. I believe Norm is saying that the service provided to a
bridge by whatever media needs to provide the same integrity as is provided
by Ethernet today. This may be accomplished by a CRC-32/integrity check with
Hamming distance of 5/whatever is needed to cover the particular faults of
the media. In this sense bridges may need a CRC option on some PW. This is
not a CRC transported through the bridge, and whatever the media in question
is or locally appears to the bridge to be, if it requires a CRC additional
to the Ethernet CRC it is *not* Ethernet but a *new MAC type*.

This is true even if the new MAC is partially constructed out of
802.3/Ethernet technology, and is documented in the 802.1 July 2003 minutes
(documenting discussion with the 802.3 leadership), and in the liaison to
the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay
function required 'inside' such a new media is not an 802.1 bridge.

For an 802.1 Bridge to use new media/MAC it requires a mapping of the
procedures etc. provided by the media to the Internal Sublayer Service (ISS)
used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5,
FDDI, and 802.11. These mappings are developed in close cooperation with the
group responsible for the MAC, and are usually written by that group, so it
is not in 802.1's gift to arbitrarily add to any existing mapping. There is
no restriction on such mappings being exclusively developed by IEEE 802, the
FDDI mapping was developed with the ANSI committee responsible for FDDI
(I've forgotten its name).

I am currently confused by the different answers I am getting on the CRC
question that Scott is posing. In discussion at the meeting Scott told me
that the proposed PW was using a perfectly adequate CRC, but hinted at some
other source of faults (badly implemented bridge? thing that looks like a
bridge to those not familiar with the bridging standards and what they
require?).

Mick

-----Original Message-----

Norman,

Thanks,

Scott

-----Original Message-----

Hi Norman,

thanks,
mark

possibly
and the PW
CRC in the
without CRC.
the PW runs,
the "wire"
over physical

---

From: Heiles Juergen <[email-masked]>
Date: Thu, 20 Nov 2003 11:22:59 +0100

I had some further thoughts on the FCS issue and noted a major difference between FCS processing in circuit an packet switched networks. 

In a circuit switched network like SONET/SDH the FCS is bound to the trail while in a packet switched network like Ethernet it is bound to the link. 

In a circuit switched network a client frame is not dropped in case of bit errors detected by the server layer or link. It is still forwarded downstream and its payload can still be useful. In a packet network a frame is dropped in case of a server layer/link FCS error. One reason for this is in my view that packet networks have the forwarding information (address, label) as part of the frame itself. In case of a FCS error this information might be corrupted and correct forwarding is not guaranteed. In a circuit switched network the forwarding information is the timeslot which is a implicit information which can not be corrupted by bit errors (except for the case of excessive bit errors that result in loss of frame synchronization in which case the frame is also dropped = all-ONEs/AIS insertion). In addition circuit switched networks use in-frame multiplexing which means that frames from several clients are multiplexed into a single server layer frame. A server layer FCS err!
 
 or may only effect some, but not all of the client layer frames. Packet networks have often a one-to-one frame mapping between client and server layers or a 1 to n mapping where a client frame is split over several server frames. So server frame FCS errors are directly related to client frame FCS error.
Circuit switched networks use a FCS often at all layers (SONET/SDH, OTN) while packet networks use it often only at a single layer, the link layer.

In SDH the VC-4 BIP-8 is generated at the termination source and checked at the termination sink. The check at the termination sink provides the information about the error performance of the VC-4 trail. In addition we have BIPs at the multiplex section and regenerator section layer. These are mainly for error localization and protection switching trigger at these layers.

In an Ethernet network the frame is dropped in case the link detects an error. One cannot get the error performance of the connection by just checking the FCS at the termination (end station, or egress UNI) as only good frames are passed to it and only information about the dropped frames of the last link are available. For the error performance the number of dropped frames of each link has to be added or one makes a comparison between the number of ingress and egress frames.  The difference gives the number of dropped frames = error performance. This can be used for point-to-point connections (line), but gets difficult for multi-point-to-multi-point connections (LAN).

The different behavior means also that a end-to-end FCS is not required for a packet service, what is required is a full coverage of error checks which for example could consists of link FCS and internal error supervision of the network elements. If any of the two detects errors the frame is dropped. This leads to the same frame dropped as an end-to-end FCS. This approach however is problematic as it is difficult to standardize internal error supervision of network elements and very difficult for operators to test the internal supervision. SO they have problems to trust this functionality. A end-to-end FCS is easier to handle.

Regards

Juergen

> Von: Heiles Juergen [mailto:[email-masked]]
> Gesendet: Mittwoch, 19. November 2003 11:51
> An: 'Scott Kotrla'; [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: AW: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
> 
> 
> Scott,
> 
> The client is the Ethernet MAC signal. This could be a 
> untagged frame, a .1Q tagged frame, a .1ad provider tagged 
> frame or even a proprietary .1Q in .1Q tagged frame. The 
> pseudo wire should not care about it. It is mapped into MPLS 
> or IP using the pwe3 mapping. If the pseudo wire is a layer 
> of its own or only a mapping is not relevant for this 
> discussion. So we have the following basic network layering:
> 
> 
>     Ethernet MAC ETH    client
>           |               |          
>        MPLS LSP         server  client
>           |                       |
>          xyz                    server
> 
> MPLS is a server layer for ETH and MPLS itself is again 
> supported by server layers. MPLS switching, supervision and 
> OAM is independent of the ETH client layer. MPLS can not 
> touch or modify the MAC frame. It is a real tunnel case.
> With the original pwe3 definitions the MAC FCS would be 
> stripped when the frame was mapped and a end-to-end FCS check 
> of the ETH link over the pseudo wire was not possible. With 
> the optional inclusion of the FCS it is possible. This is the 
> issue Norm is talking about I think. The ETH link over a 
> pseudo wire should provide the same functionality as over a 
> physical Ethernet or as for example over SONET/SDH (using GFP 
> or LAPS).
> Note that even with the inclusion of the FCS it doesn't 
> always mean that this is the original customer FCS. This is 
> only the case when the Ethernet UNI is directly forwarded to 
> the pseudo wire without any Ethernet bridging in between. In 
> case of a multiplexed access link (service services on the 
> access link separated by VLAN tags) or in the VPLS case (MAC 
> switching) a Ethernet bridge function is located between the 
> UNI and the pseudo wire which does the normal Ethernet FCS processing.
> 
> Stacked VLAN:
> With the stacked VLAN we do not introduce new layer. The VLAN 
> provides a method to fragment/part ion an ETH network in 
> several smaller ETH networks (see ITU G.8010 Ethernet Network 
> Architecture which is in the approval process). Connectivity 
> is only possible within the specific VLAN. Forwarding 
> decisions are still based on the MAC addresses. Switching, 
> supervision and OAM is/will be based on the MAC frame and the 
> MAC frame can/will be modified including the FCS. So it is 
> not a real tunnel.
> Even in this case preserving the customer FCS is useful when 
> errored customer frames would be forwarded through the 
> network and not dropped at the ingress. This is for example 
> the case in SONET/SDH Tandem Connection Monitoring as we do 
> not drop frames with wrong FCS in circuit switched networks.
> As stated in my earlier mail Ethernet drops frames with wrong 
> FCS. So we have only customer frames with correct FCS 
> forwarded at the ingress UNI. If the normal MAC FCS is not 
> recalculated at each bridge but instead is modified according 
> to the changes to the frame it provides the UNI-to-UNI 
> coverage for the customer frames Scott is looking for without 
> the need to tunnel the customer FCS.
> 
> 
> Regards
> 
> Juergen
> 
> 
> 
> the liaison
> Sublayer Service
> Scott told

---

From: Akiva Sadovski <[email-masked]>
Date: Fri, 21 Nov 2003 09:39:34 +0200

Hi Juergen,
  1) thank you for your thorough explanation 
  2) however the question is how we can stretch your FCS/BIP processing
model to cover 
the PW case: should the PW be considered as an "Ethernet network link" that
has
to be protected by FCS or as a "packet service" ? IMHO the PW is closer to
the "link"...

Regards,
  Akiva Sadovski
 
-----Original Message-----
From: Heiles Juergen
To: Heiles Juergen; 'Scott Kotrla'; [email-masked];
[email-masked]
Cc: [email-masked]
Sent: 20/11/2003 12:22
Subject: AW: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

I had some further thoughts on the FCS issue and noted a major
difference between FCS processing in circuit an packet switched
networks. 

In a circuit switched network like SONET/SDH the FCS is bound to the
trail while in a packet switched network like Ethernet it is bound to
the link. 

In a circuit switched network a client frame is not dropped in case of
bit errors detected by the server layer or link. It is still forwarded
downstream and its payload can still be useful. In a packet network a
frame is dropped in case of a server layer/link FCS error. One reason
for this is in my view that packet networks have the forwarding
information (address, label) as part of the frame itself. In case of a
FCS error this information might be corrupted and correct forwarding is
not guaranteed. In a circuit switched network the forwarding information
is the timeslot which is a implicit information which can not be
corrupted by bit errors (except for the case of excessive bit errors
that result in loss of frame synchronization in which case the frame is
also dropped = all-ONEs/AIS insertion). In addition circuit switched
networks use in-frame multiplexing which means that frames from several
clients are multiplexed into a single server layer frame. A server layer
FCS err!
 or may only effect some, but not all of the client layer frames. Packet
networks have often a one-to-one frame mapping between client and server
layers or a 1 to n mapping where a client frame is split over several
server frames. So server frame FCS errors are directly related to client
frame FCS error.
Circuit switched networks use a FCS often at all layers (SONET/SDH, OTN)
while packet networks use it often only at a single layer, the link
layer.

In SDH the VC-4 BIP-8 is generated at the termination source and checked
at the termination sink. The check at the termination sink provides the
information about the error performance of the VC-4 trail. In addition
we have BIPs at the multiplex section and regenerator section layer.
These are mainly for error localization and protection switching trigger
at these layers.

In an Ethernet network the frame is dropped in case the link detects an
error. One cannot get the error performance of the connection by just
checking the FCS at the termination (end station, or egress UNI) as only
good frames are passed to it and only information about the dropped
frames of the last link are available. For the error performance the
number of dropped frames of each link has to be added or one makes a
comparison between the number of ingress and egress frames.  The
difference gives the number of dropped frames = error performance. This
can be used for point-to-point connections (line), but gets difficult
for multi-point-to-multi-point connections (LAN).

The different behavior means also that a end-to-end FCS is not required
for a packet service, what is required is a full coverage of error
checks which for example could consists of link FCS and internal error
supervision of the network elements. If any of the two detects errors
the frame is dropped. This leads to the same frame dropped as an
end-to-end FCS. This approach however is problematic as it is difficult
to standardize internal error supervision of network elements and very
difficult for operators to test the internal supervision. SO they have
problems to trust this functionality. A end-to-end FCS is easier to
handle.

Regards

Juergen

---

From: "Marc Holness" <[email-masked]>
Date: Fri, 21 Nov 2003 10:49:30 -0500

Norm.

I gather that Service Providers (which purchase and deploy or plan to deploy
Ethernet bridging equipment) find it exceedingly difficult, if not next to
impossible, to determine that each piece of bridging equipment uniformly
adheres to the 802.1 model.

Consequently, I would not categorize having a mechanism that supports a path
like (i.e., end-to-end) integrity validation (via preservation of the client
Ethernet FCS) as *pointless*. Rather I believe it should be a considered
requirement.

Marc.

-----Original Message-----
From: Norman Finn [mailto:[email-masked]] 
Sent: Friday, November 21, 2003 7:03 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Neil,

I think Pat Thaler's reply helps to straighten out this confusion, but let
me try, also.

There is a *lot* of confusion about the words "end-to-end", and about
"transport layers". There are lots of ends in this picture, and there are
layers and there are layers.

An 802.1Q VLAN bridge, and by extension, a P802.1ad provider bridge, does
NOT supply a "transport layer" in the same sense as IP-over-Ethernet or
Ethernet-over-IP.  This is because, at the data forwarding layers, VLAN tags
are best though of as extensions to the address space, not as additional
protocol layers.  If you want to call it a "transport layer", feel free!
But don't assume that VLANs are equivalent to other "transport layers".
Data integrity, specifically, is different in bridges.

Routers provide "best effort" not only in frame delivery, but in data
integrity.  There is no upper limit specified for the probability of
delivery of a packet with undetected errors.  IP's response, if you demand a
particular level of data integrity, is that your application must supply its
own checksum.

Bridges, however, are not routers!

Bridges *do* guarantee a level of service.  They manage to do this by
guaranteeing the quality of each bridge, and by *demanding* the quality of
each link.  Non-VLAN bridges, VLAN bridges, and Provider Bridges all make
that guarantee to their users using this method.  The Customers of a
Provider Bridge service are not an "802.1Q application" over an "802.1ad
transport layer".  They are, in the 802.1 model, just endstations attached
to a bridge.  The Customers' data is just as well protected as an enterprise
bridges' endstations, as long as the model is maintained.  Adding an
additional CRC to end-to-end service, where the ends are Customers attached
to 802.1ad Provider Bridges, is therefore pointless.  Changing that model is
as silly as turning the model for routing upside down.

When a Pseudowire is used to connect two bridges, the "end-to-end" is now
just those two bridges.  Those bridges are using that PW as an Ethernet to
carry their traffic. The bridges demand that every wire be as reliable as an
Ethernet.  That's the PW CRC issue.

-- Norm

[email-masked] wrote:
> Norm....As per our discussion today face-face.  I don't really see 
> what the problem is here.  The client layer network should not care 
> about the server layer network (and vice versa)....we need this layer 
> independence for lots of reasons.  An ethernet traffic unit has a FCS.  
> This should simply be transported transparently in the payload area of 
> whatever the server layer is....and the server layer should use its 
> own (OAM) 'integrity mechanisms' irrespective of the client.  Problems 
> arise when people start doing things like client layer compression and 
> thus forming inter-layer dependencies.
> 
> Further, as we agreed today and as I posted on an earlier mail to this 
> thread, the ethernet FCS is a CRC that can be linerarly updated for 
> adaptation function changes (eg VLAN ID change) on each 
> link-connection (as provided by some server layer trail technology) 
> whilst preserving its end-end intergrity check of the rest of the 
> ethernet traffic unit between its trail termination points.
> 
> regards, Neil
> 
>

---

From: [email-masked]
Date: Fri, 21 Nov 2003 17:15:53 -0000

Hi Norm....We are on the same page I am sure, just using different words....please see in-line.

regards, Neil

> Norman Finn wrote 21 November 2003 12:03
>
> 
> Neil,
> 
> I think Pat Thaler's reply helps to straighten out this 
> confusion, but let me
> try, also.
> 
> There is a *lot* of confusion about the words "end-to-end", 
> and about "transport layers".
NH=> Agreed.  G.805 and G.809 func arch really helps sort this out...as I hope was clear this week from Maarten's excellent analysis of the ethernet OAM issues at SG13.

> There are lots of ends in this picture, and there are layers 
> and there are layers.
NH=> Agreed.....just wish some more people grokked this stuff as it should help mitigate arch violates.
> 
> An 802.1Q VLAN bridge, and by extension, a P802.1ad provider 
> bridge, does NOT supply a
> "transport layer" in the same sense as IP-over-Ethernet or 
> Ethernet-over-IP.  This is
> because, at the data forwarding layers, VLAN tags are best 
> though of as extensions to
> the address space, not as additional protocol layers.
NH=> Understood and agree.

>  If you 
> want to call it a
> "transport layer", feel free!
NH=> No, that would be completely wrong....VLANs do *not* form a layer network in any way, shape or form.

>  But don't assume that VLANs 
> are equivalent to other
> "transport layers".  Data integrity, specifically, is 
> different in bridges.
> 
> Routers provide "best effort" not only in frame delivery, but 
> in data integrity.  There
> is no upper limit specified for the probability of delivery 
> of a packet with undetected
> errors.  IP's response, if you demand a particular level of 
> data integrity, is that
> your application must supply its own checksum.
> 
> Bridges *do* guarantee a level of service.  They manage to do 
> this by guaranteeing the
> quality of each bridge, and by *demanding* the quality of 
> each link.  Non-VLAN bridges,
> VLAN bridges, and Provider Bridges all make that guarantee to 
> their users using this
> method.  The Customers of a Provider Bridge service are not 
> an "802.1Q application"
> over an "802.1ad transport layer".  They are, in the 802.1 
> model, just endstations
> attached to a bridge.  The Customers' data is just as well 
> protected as an enterprise
> bridges' endstations, as long as the model is maintained.  
> Adding an additional CRC
> to end-to-end service, where the ends are Customers attached 
> to 802.1ad Provider
> Bridges, is therefore pointless.  Changing that model is as 
> silly as turning the model
> for routing upside down.
NH=> I agree with all this....so not quite sure what you think I am not understanding here.
> 
> When a Pseudowire is used to connect two bridges,
NH=> Similar to VLANs, a PW is *not* a layer network either.  MPLS does create layer networks however....but I suspect that is not well understood by many.  One of my colleagues, who like Maarten is a real expert in the func modelling detail, is formally describing MPLS right now...but of course MPLS is a not a singular layer network, it has many flavours and this work will clearly bring out the different arch behaviours.

> the 
> "end-to-end" is now just those
> two bridges.
NH=> Agreed.  If one drew out the proper func arch model one can see this immediately.

> Those bridges are using that PW as an Ethernet 
> to carry their traffic.
> The bridges demand that every wire be as reliable as an 
NH=> Grokked totally. A PW is a form of adaptation function that lies between a client (here we are discussing ethernet) and MPLS (or IP if one is happy with a cnls server behaviour)...and then there are further layer networks below this, eg the VC4 layer network of SDH, until we hit the duct.  The fact that a PW is not a layer network and not really necessary is neither here nor there....other than its just something else to manage.  When the port on a bridge is not connected to an 'ethernet shared media' (orginal case), but some technology (any) then one simply has to adapt the ethernet PDU (*including its FCS*, as its part of the client ethernet CI) to the payload of the server layer.  One should *not* be playing around with client layer network structures in a simple client->server adaptation process at all.  So I am totally against all the 'Martini' PW compression stuff....the BW squeezing is simply not worth it (compared to other technolgies that will squander BW). So IMO the ethernet FCS is part of the ethernet's CI and should not be removed by *any* server layer technology. 
> > Norm....As per our discussion today face-face.  I don't 
> really see what the problem is here.  The client layer 
> network should not care about the server layer network (and 
> vice versa)....we need this layer independence for lots of 
> reasons.  An ethernet traffic unit has a FCS.  This should 
> simply be transported transparently in the payload area of 
> whatever the server layer is....and the server layer should 
> use its own (OAM) 'integrity mechanisms' irrespective of the 
> client.  Problems arise when people start doing things like 
> client layer compression and thus forming inter-layer dependencies.
> > 
> > Further, as we agreed today and as I posted on an earlier 
> mail to this thread, the ethernet FCS is a CRC that can be 
> linerarly updated for adaptation function changes (eg VLAN ID 
> change) on each link-connection (as provided by some server 
> layer trail technology) whilst preserving its end-end 
> intergrity check of the rest of the ethernet traffic unit 
> between its trail termination points.
> > 
> > regards, Neil
> > 
> >

---

From: John Messenger <[email-masked]>
Date: Fri, 21 Nov 2003 20:31:44 +0100

Neil Harrison said:
>  IMO the ethernet FCS is part of the ethernet's CI and should not be
>  removed by *any* server layer technology. 

Absolutely.  Amen to that.
	-- John
--
John Messenger ([email-masked])
R&D Manager, Software
ADVA Optical Networking Ltd.
+44-1904-699309
www.advaoptical.com

---

From: [email-masked]
Date: Sat, 22 Nov 2003 17:29:29 -0000

Hi Mark, 

mark observed 21 November 2003 16:31
<snipped>
> But don't assume that VLANs are 
> > equivalent to other
> > "transport layers". 
> 
> Hi Norman, this is a key point and a key area of disconnect (which I 
> think we have in IP-MPLS as well, though perhaps slightly less so in 
> PW-MPLS). Service Provider's should consider this point carefully and 
> decide whether it meets their needs or not.
NH=> Have already responded to Norm on this but in summary:  VLANs are *not* layer networks, neither are PWs.  IP is a layer network and so is MPLS (though IMO it's deficient in some respects and has some aspects that violate functional arch requirements).  Please see G.805 (for the co modes) or G.809 (for the cnls mode) for further details (on functional arch), or Chapter 3 of my colleague Andy Reid's book on BB Networking (ISBN 0-890006-578-0) for a more comprehensive history/explanation.  
> > guaranteeing the
> each link. 
> Norman, just out of curiousity, how does 802 guarantee the quality of 
> bridges, and even if you get the PW requirements you want in 
> terms of PW 
> link guarantees, do routers have to be changed, in your opinion, to 
> provide the equivalent quality of bridges. Just trying to 
> understand all 
> the moving pieces you need to get what you would consider an Ethernet 
> grade service.
NH=> Mark.....It seems to me if more people grokked func arch and layered networks better the answer to this question would be self-evident, and it would hopefully also help in reducing the number of arch mistakes.....this is very important to us as an operator, since such mistakes create operational problems which ultimately impact our opex.  Bridges relay ethernet traffic units. The characteristic information of the ethernet layer network is the ethernet PDU as specified between the SA/DA and the FCS fields.  So if there is some (layer network) technology below this (eg FR, ATM, MPLS, etc), the *whole* ethernet CI PDU (ie inc the FCS) must be encapsulated and transported in the *payload* area of the relevent server layer technology.  As noted above, a PW is *not* a layer network per se though MPLS is.  A PW is an adaptation function to the server layer of either IP or (the LSP in) MPLS (in a similar way that GFP is used when adapating ethernet PDUs to an SDH VC4 server layer network).  Now whether a PW adaptation function is required or not is a different question.  It is my view that it is not, at least as how it has been specified in certain respects, and especially noting that XoverIP is *not* the same as XoverMPLS and thus the adaptation should not be *forced* to be the same....that is simply being dogmatic without properly understanding the functional arch requirements first.  In any case, removing the ethernet client's FCS (with any server layer network) simply to save some BW and/or processing should not be done.

regards, Neil

---

From: Keith Knightson <[email-masked]>
Date: Sat, 22 Nov 2003 12:43:53 -0500

Guys,

Well, this is what 802.1D has to say on the subject:

"...for frames relayed between LANS of the same MAC type, the bridge 
shall not introduce an undetected frame error rate greater than that 
which would be achieved by *preserving* the FCS.

I take this to mean that there is no requirement to preserve the 
(originally received) FCS, even on a pure native LAN system with 
bridges. Quite the contrary, Bridges are expected to not introduce 
errors.

If you assume a PW to be a sort of bridge, this is certainly the case 
for a VPLS with multiple PWs, then a PW is no worse with or without a 
preserved FCS, if and only if, the undetected frame error rate is no 
greater than that which would be achieved by *preserving* the FCS.

Why would one expect a PW to be better than a bridge?  (Since a 
remote bridge would have been would been the alternative anyway!)

I do not think that client/server has anything to do with this 
argument. In any case it is clear the client is the frame without its 
FCS. If anything, I would submit that the client is the LLC layer, ie 
the MAC Service User, and not the MAC Sublayer,  i.e.  the frames, 
yes,  but not the mechanisms associated with the actual transmission 
of the frames.

Otherwise, one could carry the argument to absurdum. For example, 
why not include the flags or manchester encodings or whatever else 
defines the frame?  In a bridge the relaying is taking place at the 
frame level, not the MAC level. For example one can different MAC 
sublayers on each side of a bridge, forcing a recalculation of the 
FCS.

MHO.

Regards

Keith

---

From: mark seery <[email-masked]>
Date: Sat, 22 Nov 2003 14:41:52 -0500 (EST)

Hi Neil, below. thanks

---- [email-masked] wrote:
>> <snip> NH=> Mark.....It seems to me if more people grokked func arch and layered networks better the answer to this question would be self-evident, and it would hopefully also help in reducing the number of arch mistakes.....this is very important to us as an operator, since such mistakes create operational problems which ultimately impact our opex. <<

I think having a model would obviously provide **a** common reference that would like simpler for everyone. However,as in software development, so too in protocol design there are varying degrees of like/dislike for architectural approaches. There is a time-to-market mindset which the essential tenant of which is just decide on something and let's ship, plus there are certainly truly different approaches which cause conflict. One of the trends over the last couple ofyears has been towards getting rid of layers which I think has probably encouraged the development of X+Y approaches(see below). X+Y approaches create controversy where ever they appear (certainly the case in IEEE and IETF), which is not a judgement, just an observation of the very least that can be expected when you do something that is outside the boundaries of what people have traditionally seen.

>> <snip> .... noting that XoverIP is *not* the same as XoverMPLS and thus the adaptation should not be *forced* to be the same....that is simply being dogmatic without properly understanding the functional arch requirements first.  In any case, removing the ethernet client's FCS (with any server layer network) simply to save some BW and/or processing should not be done.<<

if it is valid that MPLS is functionally deficient (as you stated but I snipped out) then XoverMPLS is never valid, which is why we have X+Y to get all the semantics required to make a layer. there are two ways of looking at this: 1) the IETF never meant MPLS to be an independent layer and therefore it is not deficient, it is just a shim with some function (from a data plane perspective) or 2) the IETF meant MPLS to be an independent layer and they did an incomplete job first go round. of the two alternatives, I suspect (like 802 did with VLANs) the first is more likely.

so I see three models in play. the Y-X model (routing), the XoverY model (G.805) and X+Y (IP-MPLS and 802.1q). I would suggest that bridging is in a sense similar to the Y-X routing model in a number of ways, not the least of which is that the data link layer is source/sinked at each link -it is different in that the only upper layer protocols that are processed are control protocols (snooping aside).

the beauty of Y-X models is that only an upper layer protocol indicator is needed. in XoverY models we have typically used encapsulations I agree. examples have included adaptation layers and RFC1483/1490 and their revisions. as I have said in private to some if we had used 1483/1490 as guidlines, then we may not have stumbled in to either the PID or FCS debates. however, that supposes that XoverY is an intent of the PW group. 

before we even get to the point of discussing encapsulation though, we first have to make sure we have a Y. because MPLS is not already a Y, we had to augment it with PW, by X+Y. Then we extend PW for encapsulation function and we still have X+Y, it is just that X is bigger now. Now comes the problem of  what to do with the service layers. is it Z over (X+Y) or is it Z+(X+Y). this is what is not clear to me, which I have to go and do some study of. what is clear to me though is that X+Y thinking is more pervasive in this process than what might be apparent.

there is a line of thought that says you must be able to functional understand what is going on, and then there is a line of thinking that says that functional thinking is broken and just slows everything down. i suspect this is the real disconnect. at the end of the day, the group will most likely focus on a set of requirements, create a solution, and ship. clearly the PW architecture document tried to create a functional model. translating that model is where the difficulty probably lays.

---

From: [email-masked]
Date: Sun, 23 Nov 2003 09:19:53 -0000

Keith,

Maarten....you may want to note this mail given you are defining the functional models for ethernet.  I'd be grateful if you would please check the accuracy of my remarks below.  Ditto Alan for MPLS.  Thanks, Neil

Keith Knightson wrote 22 November 2003 17:44

> If you assume a PW to be a sort of bridge,
NH=> A PW is for sure not a bridge!  A PW is an adaptation funtion that lies between a client layer network and a server layer network of MPLS or IP.  A PW is *not* a layer network itself since PWs are not 'networked'.  CF GPF which has a similar role in adapting an ethernet client layer network to an SDH VC4 layer network.  Now whether a PW adaptation function is required or is properly constructed is a different question, and some things are not right here IMO....but this is not relevant to this topic.  A bridge is a node in the ethernet layer network.....and from the perspective of recursive partitioning of the ethernet layer network, it is the smallest flow domain subnetwork.  I believe that if you were more au fait with G.805 and G.809 func arch concepts then this would help you see these things more clearly.

> this is certainly the case 
NH=> This is not a valid comparison, ie apples with oranges.
> argument.
NH=> On the contrary it has everything to do with the issue at question.  But I can see that you are having problems with this.

> In any case it is clear the client is the frame without its 
> FCS.
NH=> This is not correct.  The FCS is an intrinsic component of the ethernet CI (characteristic information).....you simply cannot go around arbitrarily changing/removing it.    

> If anything, I would submit that the client is the LLC layer, ie 
NH=> I can see your confusion given the way the LLC and MAC sublayers were orginally specified (for example, see Radia Perlman's book 'Interconnections' section 2.7).
> defines the frame?
NH=> This is wrong...and if you understood G.805/809 you would immediately know why.  Specific line codings belong to the section media level.  They occur *below* a given link connection on the *lowest* layer network.  Line codings are *not* networked entities.  For example, consider a VC4 layer network.  The SDH STM-N nodes can be connected together (so these would be link connections in the VC4 layer network) using radio, electrical or optical media sections.  The line codes used on each section are different, however the VC4 entity is consistent across all of them.  Note that a VC4 traffic unit carries a BIP check of degree 8 (x^8 +1), which is its FCS if you like....and these do not get changed/removed in some ad hoc fashion by the section layers.

>  In a bridge the relaying is taking place at the 
NH=> I assume you mean 802.3 and 802.5 interworking for example?  If you looked at what is happening here from a func arch perspective, you would note that we have to terminate the MAC trails either side.  Why?  Because the CI is different on each side, eg the bit ordering of DA/SA fields is different.  So it is a requirement to have different FCSs.

---

From: "Mick Seaman" <[email-masked]>
Date: Sun, 23 Nov 2003 15:55:54 -0800

Not withstanding the claim that an Ethernet frame has some called
characteristic information (CI) that one cannot change and that FCS is part
of it, no such notion (CI) exist in the MAC Service or Internal Sublayer
Service or bridge specifications (or I believe in ISO 7498 including its
addenda and interpretations) and Keith is entirely correct in saying that
the MAC Service (as delivered to an LLC Entity and specified in ISO 15802-1
,formerly ISO 10039) does not have FCS as a parameter.

Moreover the MAC Service is provided at an abstract interface in a system
and there is no requirement to associate an FCS with the parameters of the
service until they have been encoded and transmitted in a frame by media
access method specific functions. The coverage of an FCS is not from service
user to service user, it is across media.

Mick

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Keith Knightson
Sent: Saturday, November 22, 2003 9:44 AM
To: John Messenger; [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Guys,

MHO.

Regards

Keith

---

From: [email-masked]
Date: Mon, 24 Nov 2003 09:02:03 -0000

> > NH=> A PW is for sure not a bridge!  A PW is an adaptation funtion 
> > that lies between a client layer network and a server layer network 
> > of MPLS or IP.  
> 
> Neil
> 
> Surely that is just one way to model the PW? Can't a PW also be
> modelled as a repeater with certain internal delay and error
> characteristics.
> 
> Stewart

Stewart,
If this is a valid analogy then every networking technology that relays some traffic unit between points A and B can be regarded as modelling a bridge.....and that does not seem a good analogy to me.
regards, Neil

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 24 Nov 2003 09:37:20 +0000

[email-masked] wrote:
> If this is a valid analogy then every networking technology that 
> relays some traffic unit between points A and B can be regarded 
> as modelling a bridge.....and that does not seem a good analogy to me.
> regards, Neil
> 

A bridge has certain filtering and path selection properties, so
the PW is certainly not a bridge.

A PW has the property that it does not transform the data (any
transformation takes place in the NSP, and that is not part of the
PW).

The data carried over the PW has no meaning within the context of
the PSN that carries it, and from the point of view of the CE's
the PW does not exist other than in terms of delay and error.

Therefore from the CE point of view, the PW is just a repeater.

For the PW to be an adaptation function, one would have to assert
that the contents of the PW had some meaning within the PSN.
I don't beleive it has, because we never communicate any context
information to any object in the PSN (either by signalling or
self description) which it can use to interpret the contents of
the PW.

Stewart

---

From: [email-masked]
Date: Mon, 24 Nov 2003 11:46:26 -0000

Hi Stewart,

<snipped>
> the PW is certainly not a bridge.
NH=> Agreed
> transformation takes place in the NSP, and that is not part of the
NH=> OK, but there is an adaptation between the client and the server....the flags, length and Seq No. fields are that adaptation function.
> the PSN that carries it,
NH=> I agree that a client layer should be transparent to a server layer.....but does the ECMP hack not violate this then?

> and from the point of view of the CE's
NH=> But surely any client->server encapsulation relationship has this property.
> Therefore from the CE point of view, the PW is just a repeater.
NH=> As noted above, I believe we can extend this to any client->server encaps.
> that the contents of the PW had some meaning within the PSN.
NH=> See remark on ECMP above.....my observation however is that there are functions that lie between the client layer network and the server layer network (be this IP or MPLS), and in my mind these are an adapatation function.

regards, Neil

---

From: Heiles Juergen <[email-masked]>
Date: Mon, 24 Nov 2003 14:03:40 +0100

Neil I have to correct you here.

In the ITU Ethernet Network Architecture (G.8010 which is currently out for approval) the FCS is not part of the CI. It is a link property. This is the difference in FCS for circuit and packet switched networks I mentioned in my previous email.

G.8010 refers however to the undetected errors of a bridge. This doesn't mean that a bridge should be error free. An error introduced by a bridge which is detected by the FCS is ok. For a bridge as a single network element designed by a single manufacturer such a requirement on undetected errors seems to be achievable. For a pseudo wire which is a link connection through a network  which consists of network elements and connections between them such a requirement is very difficult to achieve.

Regards

Juergen

> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Sonntag, 23. November 2003 10:20
> An: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Maarten....you may want to note this mail given you are 
> defining the functional models for ethernet.  I'd be grateful 
> if you would please check the accuracy of my remarks below.  
> Ditto Alan for MPLS.  Thanks, Neil
> 
> NH=> A PW is for sure not a bridge!  A PW is an adaptation 
> funtion that lies between a client layer network and a server 
> layer network of MPLS or IP.  A PW is *not* a layer network 
> itself since PWs are not 'networked'.  CF GPF which has a 
> similar role in adapting an ethernet client layer network to 
> an SDH VC4 layer network.  Now whether a PW adaptation 
> function is required or is properly constructed is a 
> different question, and some things are not right here 
> IMO....but this is not relevant to this topic.  A bridge is a 
> node in the ethernet layer network.....and from the 
> perspective of recursive partitioning of the ethernet layer 
> network, it is the smallest flow domain subnetwork.  I 
> believe that if you were more au fait with G.805 and G.809 
> func arch concepts then this would help you see these things 
> more clearly.
> 
> NH=> On the contrary it has everything to do with the issue 
> at question.  But I can see that you are having problems with this.
> 
> NH=> This is not correct.  The FCS is an intrinsic component 
> of the ethernet CI (characteristic information).....you 
> simply cannot go around arbitrarily changing/removing it.    
> 
> NH=> I can see your confusion given the way the LLC and MAC 
> sublayers were orginally specified (for example, see Radia 
> Perlman's book 'Interconnections' section 2.7).
> > 
> NH=> This is wrong...and if you understood G.805/809 you 
> would immediately know why.  Specific line codings belong to 
> the section media level.  They occur *below* a given link 
> connection on the *lowest* layer network.  Line codings are 
> *not* networked entities.  For example, consider a VC4 layer 
> network.  The SDH STM-N nodes can be connected together (so 
> these would be link connections in the VC4 layer network) 
> using radio, electrical or optical media sections.  The line 
> codes used on each section are different, however the VC4 
> entity is consistent across all of them.  Note that a VC4 
> traffic unit carries a BIP check of degree 8 (x^8 +1), which 
> is its FCS if you like....and these do not get 
> changed/removed in some ad hoc fashion by the section layers.
> 
> NH=> I assume you mean 802.3 and 802.5 interworking for 
> example?  If you looked at what is happening here from a func 
> arch perspective, you would note that we have to terminate 
> the MAC trails either side.  Why?  Because the CI is 
> different on each side, eg the bit ordering of DA/SA fields 
> is different.  So it is a requirement to have different FCSs.
> > 
> > MHO.
> > 
> > Regards
> > 
> > Keith
> >

---

From: [email-masked]
Date: Mon, 24 Nov 2003 14:08:00 -0000

Thanks Juergen, please see below.
> In the ITU Ethernet Network Architecture (G.8010 which is 
> currently out for approval) the FCS is not part of the CI.  It is a link property.
NH=> Agreed.....you are correct that strictly speaking the FCS does not belong to the eth CI as defined in G.8010 though its still belongs to the eth client.....and as you note its part of the link-adaptation (so like the HEC in a ATM cell header changes with VPI/VCI change per link the FCS can also change if the VLAN field changes (though this would not be per link I guess)).

> This is the difference in FCS for circuit 
> and packet switched networks I mentioned in my previous email.
NH=>I have just been looking through G.8010 and I don't like the inconsistency in I see in the sections dealing with ethernet over X.  In SDH/VC4 and OTN/ODUk layer networks the FCS is carried transparently.  For ATM (or more accurately AAL5) its removal or carriage is optional.  And currently it is noted as removed for MPLS......but I guess this may now have to change and become optional too. Its my opinion that client layer traffic units should be carried transparently by some server layer technology.....irrespective of what that server layer technology is.

regards, Neil

---

From: Keith Knightson <[email-masked]>
Date: Mon, 24 Nov 2003 09:37:08 -0500

>NH=> I assume you mean 802.3 and 802.5 interworking for example?  If 
>you looked at what is happening here from a func arch perspective, 
>you would note that we have to terminate the MAC trails either side. 
>Why?  Because the CI is different on each side, eg the bit ordering 
>of DA/SA fields is different.  So it is a requirement to have 
>different FCSs.
>>
Neil,

Well, you illustrate my point exactly. Once you terminate the trail, 
you terminate the scope of the FCS.   THe FCS is particular to the 
MAC sublayer trail. The FCS does not belong to the information being 
relayed, it belongs to the framing mechanism, not the frame itself. 
You then have to create another trail on the other side with a new 
FCS.

As far as G.805 is concerned it is a question of interpretation. By 
that I mean it all depends which sub-strings of bits out of total 
string of bits under consideration, you think belong to which layer, 
sublayer, or trail.  Onion skin models of IEEE/HDLC protocols were 
around long before G.805 was invented, as a matter of fact.

BTW, I do not believe that the definition of network interworking 
(NI) supports your argument at all. There are many cases of NI where 
some changes take place between both sides of the IWF. The precise 
difference between SI and NI is not clear. They are simply two ends 
of a spectrum of mapping possibilities.

The data link layer was never conceived to be end-to-end, in the 
first place. It is an architectural aberration to make it so. I find 
it difficult to believ ein this day and age, that the FCS is the 
key/essential tool for data ensuring end-to-end integrity of 
application data.

The PW acts liike it is the internal part of a bridge, despite what you say.

In the VPLS work the service is described as a logical bridge, which 
is exactly what it is. It is a distributed bridge using PWs to effect 
is distribution to multiple ports. It uses PWs in excactly the same 
way,  just prefaced by selective forwarding functions. Bridges act as 
relays not interworking units, and did so long before G.805/9 or 
definition of NI was invented.

I would still maintain that  you cannot expect more from a PW than 
you would get from a remote bridges connected directly by another LAN 
or a real piece of wire.

Regards

Keith

---

From: Heiles Juergen <[email-masked]>
Date: Mon, 24 Nov 2003 16:06:18 +0100

Keith,

see my comments below.

Regards

Juergen

> Von: Keith Knightson [mailto:[email-masked]]
> Gesendet: Montag, 24. November 2003 15:37
> An: [email-masked]; [email-masked]; 
> [email-masked]

The PW acts like and is a link between two bridges.

> definition of NI was invented.

VPLS is a (sub) network of bridges interconnected by PW links.

---

From: Scott Kotrla <[email-masked]>
Date: Mon, 24 Nov 2003 11:40:16 -0600

As a service provider, I want layers.  I want to be as a transparent as
possible.  Throwing away the customer's FCS and introducing the
possibility of undetected errors is not transparent.  VLAN stacking
isn't the best solution here for layer encapsulation, but it can work.
MAC-in-MAC is architecturally a better fit because the whole customer
frame goes into the new payload field, but wasting 12 bytes for dummy
DA/SA that won't be used for TRANS (MEF layer) applications doesn't make
a lot of sense.  ETH layer functionality is the application of existing
802 technologies to service providers, so arguments about what exactly
does or does not belong has value.  

TRANS layer functionality for physical Ethernet transport is new
functionality that 802 was not designed for.  But for service providers,
this provides new requirements.  The TRANS layer often refers to
transport over SONET, but there is no reason why it shouldn't also
support the model of transport over Ethernet, in which case the
requirements are different from ETH requirements.  If physical Ethernet
is being used for point-to-point TRANS functionality, new features like
a Path FCS are required.  Otherwise, Ethernet over Fiber is not a viable
alternative to Ethernet over SONET.

In this context, it may be clearer how Stacked VLANs and PW are
comparable.  As a provider, I am looking for a way to tunnel customer
ports or customer VLANs from point-to-point from end-to-end
transparently across the access network.  I am open to other
alternatives.  Ethernet TRANS should maintain customer FCS end-to-end as
a separate layer from the service Ethernet Link FCS.

As some background, what started MCI's quest for FCS retention was a lab
infrastructure Ethernet switch that was corrupting packets and
calculating a new FCS on packets where no changes should have been
occurring.  This was one of the top Ethernet switch vendors as provided
by Gartner in 2002.  This took days to troubleshoot, and as service
providers, scared the Hell out of us.  The idea of VLAN stacking, VLAN
swapping, marking as discard eligible, and messing with packets in
general seems to open up the possibility of such things happening even
more.

Thanks,

Scott

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, November 21, 2003 11:16 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Hi Norm....We are on the same page I am sure, just using different
words....please see in-line.

regards, Neil

> and about "transport layers".
NH=> Agreed.  G.805 and G.809 func arch really helps sort this out...as
I hope was clear this week from Maarten's excellent analysis of the
ethernet OAM issues at SG13.

> There are lots of ends in this picture, and there are layers 
NH=> Agreed.....just wish some more people grokked this stuff as it
should help mitigate arch violates.

> "transport layer", feel free!
NH=> No, that would be completely wrong....VLANs do *not* form a layer
network in any way, shape or form.

> silly as turning the model
NH=> I agree with all this....so not quite sure what you think I am not
understanding here.
> When a Pseudowire is used to connect two bridges,
NH=> Similar to VLANs, a PW is *not* a layer network either.  MPLS does
create layer networks however....but I suspect that is not well
understood by many.  One of my colleagues, who like Maarten is a real
expert in the func modelling detail, is formally describing MPLS right
now...but of course MPLS is a not a singular layer network, it has many
flavours and this work will clearly bring out the different arch
behaviours.

> "end-to-end" is now just those
NH=> Agreed.  If one drew out the proper func arch model one can see
this immediately.

> Ethernet.  That's the PW CRC
NH=> Grokked totally. A PW is a form of adaptation function that lies
between a client (here we are discussing ethernet) and MPLS (or IP if
one is happy with a cnls server behaviour)...and then there are further
layer networks below this, eg the VC4 layer network of SDH, until we hit
the duct.  The fact that a PW is not a layer network and not really
necessary is neither here nor there....other than its just something
else to manage.  When the port on a bridge is not connected to an
'ethernet shared media' (orginal case), but some technology (any) then
one simply has to adapt the ethernet PDU (*including its FCS*, as its
part of the client ethernet CI) to the payload of the server layer.  One
should *not* be playing around with client layer network structures in a
simple client->server adaptation process at all.  So I am totally
against all the 'Martini' PW compression stuff....the BW squeezing is
simply not worth it (compared to other technolgies that will squander
BW). So !
 IMO the ethernet FCS is part of the ethernet's CI and should not be
removed by *any* server layer technology.

---

From: Scott Kotrla <[email-masked]>
Date: Mon, 24 Nov 2003 13:38:53 -0600

First topic:

TCP Checksum errors are spread out among all of the customer end
devices.  There is no convenient way to aggregate these and identify a
root cause.  It may very well look like a customer network problem and
not a service provider problem.  It's not clear that all endstations
even report such statistics.

For UDP traffic, the checksum may or may not be there.  For a handful of
packets, this may or may not be noticeable, but in the case of the bad
Ethernet switch, the majority of the packets were being corrupted, so it
is possible that corrupted frames would never be caught and the
applications just wouldn't work with no clear reason for the failure.

If service provider customer egress FCS checking were enabled, the
service provider would be able to catch the errors, identify that thee
is a problem, and begin fault isolation.  Even if egress FCS checking
were not enabled, the customer would see all of the FCS errors at the
service provider demark in a single place, and would be able to open a
trouble ticket with the service provider.  Either way, the issue is
identified, which is my number one concern as a service provider.  

Second topic:

We are not talking Ethernet "service" necessarily, but more Ethernet
transport.  I would like to take SONET out of the network where
possible.  To do so, I need the Section/Path/Line functionality of SONET
replicated over Ethernet.  Service providers cannot take SONET out of
the network anywhere unless the functionality of SONET is added to
packet switched protocols.  I don't want every device in the network to
be Ethernet service aware.  I see a clear distinction in packet
transport and packet services.  For my packet services to utilize packet
transport from A to Z, I need certain guarantees in the packet
transport, such as an end-to-end guarantee against unknown corruption.

Thanks,

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rosen
Sent: Monday, November 24, 2003 12:32 PM
To: Scott Kotrla
Cc: [email-masked]
Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Scott> As some background, what started  MCI's quest for FCS retention
was a
Scott> lab infrastructure  Ethernet switch  that was corrupting  packets
and
Scott> calculating a  new FCS on packets  where no changes  should have
been
Scott> occurring.   This was  one  of  the top  Ethernet  switch vendors
as
Scott> provided by Gartner in 2002.   This took days to troubleshoot,
and as
Scott> service providers, scared the Hell out of us.

My understanding  is that the customers  noticed the problem in  the
form of
TCP checksum errors, and complained to MCI. 

I'm not  sure how  having the customers  notice the  problem in the
form of
ethernet checksum errors rather than  TCP checksum errors would have
made it
any easier for you to diagnose the problem.  

Scott> The TRANS layer often refers to transport over SONET, but there
is no
Scott> reason  why it  shouldn't also  support the  model of  transport
over
Scott> Ethernet,  in which  case  the requirements  are  different from
ETH
Scott> requirements. 

Why is that?   In PWE3, we are accustomed to hearing  that SPs can't
provide
an IP service  unless IP becomes more  like ATM, but this is  the first
I've
heard that  SP's can't provide  an ethernet service unless  ethernet
becomes
more like SONET.

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

---

From: Keith Knightson <[email-masked]>
Date: Mon, 24 Nov 2003 17:48:08 -0500

Guys,

Anyway, let's set aside specious architectural arguments for  a moment.

What is the objective?

Is the objective to make the CE1 - CE2 path emulate a piece of wire, 
even though in reality it contains a CE1-PE1 - PE2 - CE2  intervening 
section?

Then and only then would there be a requirement to at least consider 
the problem.

If this was the objective, it seems to me that there is no practical 
solution. Because.....

First we need to capture the FCS at the ingress of PE1 (assuming it 
checks ok, if not discard).  I am not sure that FCS can be kept.   In 
my experience, when a frame is being received the FCS also goes 
through the hardware polynomial division process to get a zero result 
if correct?  There's a piece of math thats shows that Frame plus FCS 
all divided by the ploynomial goes to zero. The result is binary, 
good or bad.  This avoids the need for a two step process. So there 
is never a residual FCS to capture. Thus, we may fall at the very 
first hurdle.  Can someone check this point?

Anyway let's suppose the original FCS can be captured and can be 
associated in some way with the frame, by pre-pending, appending, 
whatever. BTW, a recalculation fomr the payload will not fit the 
bill, since it could be corrupted in memory of PE1 prior to 
recalculation, which presumably would have to be a software process, 
since there are no outgoing ethernet hardware ports on the PW side of 
the PE1.

The payload is then PW'ed, in IP, MPLS, whatever.

At the ingress to PE2, the payload + plus its FCS would be dumped in 
memory. This could be checked by software, it seems to me it would 
have to be, unless PE2 can transmit the frame to get a new FCS 
derived from payload (minus the original FCS) to itself in order that 
received FCS is still equal to the one stored in memory. This would 
allow PE2 to discard a frame corrupted over the PW. this is 
conditional on being able to capture FCS from receiving hardware.

But now we still have to ensure that PE2 itself does corrupt the 
payload before transmitting to CE2.

We have an outgoing ethernet port on PE2 to CE2, with its autonomous 
sending hardware with its autonomous "on the fly" FCS addition.  As 
far as I know (which admittedly may not be very far) when stuff is 
queued for transmitting that's the end of it. It just goes all by 
itself. The FCS is being calculated as it goes out on the wire and is 
automatically slammed on the end. How on earth is this "on the fly" 
FCS going to be compared to the original FCS still stuck in memory 
somewhere?  I do not believe the FCS is retained after transmission, 
and even if it could its too late. The frame has already gone with 
the new FCS!

Why is the hardware designed like this? Because it has been 
architected that way, it conforms to the architecture.  So in the 
end, the IEEE original architecture does count, and it is not 
surprising considering the definition of its layering.

It seems to me that the objective is in fact unobtainable given the 
hardware at our disposal.

BTW, when people say "this is an architectural violation' or the 
"architecture requires it", what they usually mean is one or both of 
two things:

a)	my idea of what an architecture is, is better than yours, and
b)	I can't find any other proper justification for what I want 
to you to do (or not do)

I think those who want this service have a duty to explain how this 
is all going to work. I may have missed something vital in my rant.

Regards

Keith

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 25 Nov 2003 13:33:45 +0200

Stewart and all,
Please see a brief comment inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, November 25, 2003 1:14 PM
> To: [email-masked]
> The IEEE 802.1 community may not be aware, but in addition to the
> encapsulation protocols, PWE3 is also standardising an OAM protocol
> designed to validate the PW.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-01.txt
> 
> This does not do a thorough bit integrity test, and maybe it
> needs to be extended to do so.
> 
> Perhaps the best way for a customer to validate the PW is
> with an OAM protocol that runs between the CEs, rather than
> trying to discover the problem implicitly through the FCS?
>
[Sasha] I am not sure this is the correct approach since it would mean
that the customer is aware of the fact that connection between CE devices
passes through a PW and has to modify CEs accordingly.  
>
> Stewart
> 
> 
> Mick Seaman wrote:
> 
> > There seems to be an undercurrent in this discussion that 
> somehow an FCS-32
> > is good protection against arbitrary packet mangling. 
> Sorry, not true.
> > 
> > The FCS/CRC-32 is designed to protect against a limited 
> number of changes in
> > bits, and was designed against a noise error model that 
> rated changes in
> > more than a certain number of bits improbable. You can't 
> reliably use the
> > CRC to defend against a wider range of errors such as omission or
> > replacement of whole bytes or words (which has been know to 
> sporadically
> > occur in DMA controllers designed close to their limits), 
> or substitution of
> > part of the frame for another frame (which might occur if 
> frames were
> > interleaved on a synchronous clock and the clock slipped a 
> bit position once
> > in a while for example). Nor does the FCS protect well 
> against software
> > errors where a relay system does something other than it is 
> supposed to do
> > when forwarding a frame.
> > 
> > The protection offered by a CRC-32 against such events is 
> little better than
> > the chance of randomly guessing the right number in 2**32. 
> To put that in
> > perspective if all frames on a fully utilised 10 Gb/s link 
> were errored you
> > would get a frame with a good FCS about once every 20 
> minutes. Of course if
> > all the frames were errored the link would probably come 
> down, but spread
> > around a network or many the errored 10Gb/s aggregate is 
> more plausible. Now
> > if you factor out all the errors that are going to get 
> caught with the exact
> > same CRC algorithm used on a link by link basis then the 
> extra CRC is pretty
> > much a waste of 4 bytes. At least use a different integrity 
> check if you are
> > serious! (and not one that the existing hardware is not going to
> > accidentally emulate by accident when there is a software bug!).
> > 
> > This discussion seems to be largely driven by philosophy, 
> if it is going to
> > go anywhere at all there better be an engineering component.
> > 
> > Separately you are not going to get bit level transparency 
> for a bridged
> > network. In particular we have already established the 
> layering model will
> > not be broken to allow media specific frames (PAUSE, LACP) 
> etc. to transit
> > though bridges.
> > 
> > Mick
> > 
> > Sent: Monday, November 24, 2003 9:40 AM
> > To: [email-masked]; [email-masked]

---

From: [email-masked]
Date: Tue, 25 Nov 2003 14:40:45 -0000

Stewart,

I think it only fair to point out that ITU SG13 has already defined some pretty good OAM for MPLS p2p LSPs (in Y.1711) that could be complimented with LSP-Ping for the more complex problem of fault-diagnosis on mp2p constructs.  Further, SG13 is also working on ethernet OAM based on the functional model of ethernet as defined in G.8010.

The OAM solutions required for each of the 3 networking modes of cnls, co-ps and co-cs mode are somewhat different.  A PW is not a layer network....if you look at the func arch picture of what is going on in the case of MPLS then an adaptation function (ie comprising of the PW CW flags/length/Seq No fields, some of which are optional) is being added onto a (top-level) p2p LSP.  IMO the thing that needs the OAM is the LSP not the PW, so that it can cater for all current and future cases.  Similarly IP needs its own independent OAM which it has in ICMP.  Ethernet also needs its own OAM.  Etc.

Further, when there are defects between LSPs (ie swaps or mismerging/branching faults) one wants the OAM to be *same* in order to detect/handle the defects in a consistent manner irrespective of the client.  This won't be the case if the OAM is only in the PW adaptation function, ie an LSP carrying a PW interfering with an LSP not carrying a PW.

So I really question the value of adding PW OAM.

One further remark below

regards, Neil

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stewart Bryant
> Sent: 25 November 2003 11:14
> To: [email-masked]
NH=> Why should a client layer be aware of the lower level PW.....or even any lower level technology right to the duct?  What is required is independent OAM in whatever the clinet layer is and all the server layers.  
regards, Neil

---

From: Scott Kotrla <[email-masked]>
Date: Tue, 25 Nov 2003 14:21:12 -0600

Mick,

So is your argument that I found the one switch that corrupts packets
and MCI will never encounter another one?  Or is your argument that the
number of switches that MCI finds and the time spent troubleshooting
those switches is not worth the amount of work needed to add an option
to the standard?

This problem is so difficult to diagnose without the right tools that
switches would just be swapped out as "bad."  If you can't diagnose, you
simply start replacing switches until the network works, and if it is
not 
your business to care, you don't worry about why things aren't working.

These types of failures vary by implementation.  An equipment provider
that is having problems like this will fix it in future products.  But
this doesn't help the service provider who already has the switches in
his network.

If an equipment provider had these kinds of problems, do you think it
would make them well known?

So there are two options to dealing with the service provider
requirement below.  Either you say it is not a valid requirement or you
propose solutions to fix it.  I believe it is a valid requirement and I
have proposed an end-to-end FCS that is never recalculated as a
solution.  I am open to discussing either the requirement or proposed
solutions.  Detailed analyses of how likely or unlikely this event is to
happen across equipment from 100s of vendors is likely to be very
difficult if not impossible.  

I find it very amusing that this simple topic of having an option to
support service provider requirements could prompt such a heated and
religious discussion.  If only I had more time to put into this.  I
would love to find switches from all of the top equipment vendors that
exhibited this behavior.  Would that be enough to convince people that
this is a valid concern?  What exactly would it take to get this
requirement to be seriously considered?

Thanks,

Scott

-----Original Message-----
From: Mick Seaman [mailto:[email-masked]] 
Sent: Tuesday, November 25, 2003 1:54 PM
To: 'Scott Kotrla'; [email-masked]; [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Scott,

If switches in deployment were corrupting packets at the rate you
observed
in your lab the millions of switch ports that have been deployed simply
would not be there.

Mick
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Scott Kotrla
Sent: Tuesday, November 25, 2003 8:36 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

So are you suggesting because a CRC-32 will miss 1 in 4 billion frames
it is not useful to know?  I don't need to catch every frame to know
there is a problem.

The standard Ethernet CRC protects the link and not the internal switch,
and it is very difficult to put requirements on the internal working of
a switch.  As stated in a previous message:

"The model of operation is simply a basis for describing the
functionality of the MAC Bridge. It is in no way intended to constrain
real implementations of a MAC Bridge; these may adopt any internal model
of operation compatible with the externally visible behavior that this
standard specifies. Conformance of equipment to this standard is purely
in respect of observable protocol."

I am not worried about link errors.  I am worried about corruption
within switches.  If switches have unknown failure modes that add
unknown corruption, what besides a Path FCS will be able to determine
that there is a problem.  Once again, detection is at least 10 times as
important as diagnosis.  If we can come up with a better way to detect
when (not if) switches are corrupting packets, I would be very
interested in understanding the benefits of this approach.

The service provider requirement can be succinctly stated as:

The network shall be able to detect when (not if) switches are
corrupting packets.  Suggesting that switches will never unknowingly
corrupt packets is wishing the problem away and is not an acceptable
answer.  Never is a very long time.  Besides, out of the 100 or so
switches I have worked with, I have already seen it happen.  And I am
not all that lucky.

Thanks,

Scott

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mick Seaman
Sent: Monday, November 24, 2003 2:05 PM
To: [email-masked]; [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

There seems to be an undercurrent in this discussion that somehow an
FCS-32
is good protection against arbitrary packet mangling. Sorry, not true.

The FCS/CRC-32 is designed to protect against a limited number of
changes in
bits, and was designed against a noise error model that rated changes in
more than a certain number of bits improbable. You can't reliably use
the
CRC to defend against a wider range of errors such as omission or
replacement of whole bytes or words (which has been know to sporadically
occur in DMA controllers designed close to their limits), or
substitution of
part of the frame for another frame (which might occur if frames were
interleaved on a synchronous clock and the clock slipped a bit position
once
in a while for example). Nor does the FCS protect well against software
errors where a relay system does something other than it is supposed to
do
when forwarding a frame.

The protection offered by a CRC-32 against such events is little better
than
the chance of randomly guessing the right number in 2**32. To put that
in
perspective if all frames on a fully utilised 10 Gb/s link were errored
you
would get a frame with a good FCS about once every 20 minutes. Of course
if
all the frames were errored the link would probably come down, but
spread
around a network or many the errored 10Gb/s aggregate is more plausible.
Now
if you factor out all the errors that are going to get caught with the
exact
same CRC algorithm used on a link by link basis then the extra CRC is
pretty
much a waste of 4 bytes. At least use a different integrity check if you
are
serious! (and not one that the existing hardware is not going to
accidentally emulate by accident when there is a software bug!).

This discussion seems to be largely driven by philosophy, if it is going
to
go anywhere at all there better be an engineering component.

Separately you are not going to get bit level transparency for a bridged
network. In particular we have already established the layering model
will
not be broken to allow media specific frames (PAUSE, LACP) etc. to
transit
though bridges.

Mick

-----Original Message-----

Thanks,

Scott

-----Original Message-----

regards, Neil

---

From: "Mick Seaman" <[email-masked]>
Date: Tue, 25 Nov 2003 12:41:51 -0800

Lets just consider the part of my argument that says that fault analysis
tools should be designed to achieve a given coverage over a set of faults
and not just comprise a random borrowed idea with extremely poor coverage
but potentially large implementation consequence and costs to all. Again, if
the existing CRC mechanisms do not adequately protect the packet the bridged
network will fall apart. The bridges have to be designed so that they are
adequate. Reasoning by analogy with SONET just doesn't cut it.

By the way, I don't think that any service provider that doesn't
exhaustively test and running a thorough commissioning process, either
through their own labs or by vendor support backed by financial guarantees,
on vendor equipment deserves to stay in business.

Since you find the topic of adding options to standards amusing while to
others of us standardisation and the engineering that supports it is a
serious and time consuming activity I can only give up this thread of
conversation.

Mick

-----Original Message-----
From: Scott Kotrla [mailto:[email-masked]]
Sent: Tuesday, November 25, 2003 12:21 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Mick,

Thanks,

Scott

-----Original Message-----
From: Mick Seaman [mailto:[email-masked]]
Sent: Tuesday, November 25, 2003 1:54 PM
To: 'Scott Kotrla'; [email-masked]; [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Scott,

Mick
-----Original Message-----

Thanks,

Scott

-----Original Message-----

Mick

-----Original Message-----

Thanks,

Scott

-----Original Message-----

regards, Neil

---

From: [email-masked]
Date: Wed, 26 Nov 2003 10:26:53 -0000

Hi Ali,

The way I would answer (some of) your questions is as follows:

-	according to the func arch draft Rec (G.8010) being developed for ethernet, the eth FCS belongs to the link-connection adaptation function.....not the end-end (ie between eth flow trail term points) characteristic information.  You may recall Juergen corrected me on this a couple of days ago.

-	this means if any of the traffic unit that is covered by the FCS changes at a link-level then the FCS will need to be updated to reflect the changes.  CRCs are linear functions, and it can shown mathematically that a known change to specific bits in the traffic unit can be corrected by an update of the FCS and only the FCS, ie there is no need to recalculate the FCS over the entire traffic unit.  This is no different in principle to the HEC function that protects the ATM header (but only the ATM header) since the VPI/VCI label usually changes on link-connections.  One can consider the eth VLAN field in a similar manner, ie known changes to the VLAN field can be reflected as updates of the FCS.

-	the lesson that I take away from the above observations is that architecturally it makes more sense to have 2 different CRCs, (i) one protecting only the CI that goes between trail term points transparently (ie never changes on link-connections) and (ii) one protecting only the link-connection specific part of the client traffic unit that can change on link-connections (so this needs a linear update per link connection).

-	When ethernet was first designed the above issues were never considered....and in particular there was no VLAN field.  We cannot now go back and change this IMO.  However, the FCS does still belong to the eth client and IMO it should never be discarded in some arbitrary manner by a server layer.  I use the word 'arbitrary' here since I have noted different behaviours specified in G.8010 which I don't think is a good idea, eg for all co-cs server technologies the carriage of the eth FCS is a 'must', for an ATM co-ps server layer the carriage of the FCS is 'optional', and for an MPLS co-ps server it currently says it can be 'removed'.  A client and server layer network should be independent.....so having different behaviours dependent on the server layer mode and/or specific technology is not a logical behaviour to me.  IMO the default behaviour of the server layer should always be to carry the client layer traffic unit transparently.

regards, Neil

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Ali
> Sajassi
> Sent: 26 November 2003 02:24
> To: [email-masked]; 'Scott Kotrla'; [email-masked];
> [email-masked]
> I ask the question of service applicability for FCS retention 
> some time ago 
> and I didn't get a clear answer so let me ask again. When 
> talking about FCS 
> retention, which I of the following four Ethernet services do 
> you have in 
> mind ?
> 
> 1) port-based point-to-point Ethernet service
> 2) vlan-based point-to-point Ethernet service
> 3) port-based Ethernet bridge service (multipoint)
> 4) vlan-based Ethernet bridge service (multipoint)
> 
> In vlan-based service, the customer vlan is used as service 
> delimiter and 
> is NOT the same at the two ends of the service - e.g., just 
> like frame 
> relay or ATM where DLCI or VPI/VCI are not the same at two 
> ends. Requiring 
> that the VLANs be the same at the two ends, imposes 
> unnecessary restriction 
> in customer provisioning model. Therefore, FCS retention is 
> not viable for 
> applications where customer VLAN is used as service delimiter.
> 
> Also any bridge service (port-based or vlan-based) doesn't 
> require FCS 
> retention by the definition of the bridge service itself.
> 
> So, the only applicable service for this FCS retention stuff 
> (and I doubt 
> viability of it), is for port-based point-to-point service. 
> However, I 
> would like to ask the following question:
> 
> How do you catch the errors introduced by the switches for the other 
> services ??? Given that the same set of networking gears is 
> to support all 
> four Ethernet services, are you suggesting that we only need 
> to solve the 
> problem for a single service and not to worry about other 
> service type !!! 
> Or are you suggesting that you only offer a single service 
> and thus you 
> don't have to worry about other services !!!
> 
> As I mentioned previously, a better approach is to solve the 
> problem for 
> all the Ethernet services - whether it is through OAM 
> mechanisms or through 
> internal switch check-sum or a combination of two or 
> whatever. But the 
> point is we should try to address the issue for ALL service types.
> 
> -Ali
> 
> At 12:01 PM 11/25/2003 -0800, Mick Seaman wrote:
> 
> >If you are not concerned about protecting the customer but 
> merely locating
> >repetitively failed switch then OAM-like operations and test 
> should be
> >sufficient. It remains the case that placing exactly the 
> same error check
> >algorithm on the outer CRC as the inner does not extend your 
> fault coverage
> >for the customer much. Switch faults will still be capable 
> of bringing the
> >entire network to a halt and sending the wrong packets to the wrong
> >customers. Anyone who buys a network service from a provider 
> with poor
> >internals on the grounds that the outer CRC will protect him 
> is being simply
> >naive. I'll go further than that, if a salesman tries to 
> sell me a service
> >with an outer CRC I will know that I can't trust the network 
> and simply
> >should not buy.
> >
> >Moreover as I have pointed out it is perfectly in the spirit 
> of the 802.1
> >standards that the switch recalculate both the inner and the 
> outer CRC, and
> >indeed where the format of the frame delievered to the 
> custoomer changes
> >through the network it will have to recalculate both.
> >
> >Mick
> >

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 26 Nov 2003 12:10:30 -0800

Hi Neil,

At 10:26 AM 11/26/2003 +0000, [email-masked] wrote:
>-       according to the func arch draft Rec (G.8010) being developed for 
>ethernet, the eth FCS belongs to the link-connection adaptation 
>function.....not the end-end (ie between eth flow trail term points) 
>characteristic information.  You may recall Juergen corrected me on this a 
>couple of days ago.
>
>-       this means if any of the traffic unit that is covered by the FCS 
>changes at a link-level then the FCS will need to be updated to reflect 
>the changes.  CRCs are linear functions, and it can shown mathematically 
>that a known change to specific bits in the traffic unit can be corrected 
>by an update of the FCS and only the FCS, ie there is no need to 
>recalculate the FCS over the entire traffic unit.  This is no different in 
>principle to the HEC function that protects the ATM header (but only the 
>ATM header) since the VPI/VCI label usually changes on 
>link-connections.  One can consider the eth VLAN field in a similar 
>manner, ie known changes to the VLAN field can be reflected as updates of 
>the FCS.

Yes and this is the intended mechanism for bridges and it is reflected in 
Appendix F of 802.1D as I mentioned in one of my previous emails.

>-       the lesson that I take away from the above observations is that 
>architecturally it makes more sense to have 2 different CRCs, (i) one 
>protecting only the CI that goes between trail term points transparently 
>(ie never changes on link-connections) and (ii) one protecting only the 
>link-connection specific part of the client traffic unit that can change 
>on link-connections (so this needs a linear update per link connection).

So in the context of our discussions, given that the PEs are intended to 
provide transport functionality with respect to Ethernet services and not 
interworking, then it means any FCS to be added for the CI portion is the 
job of the CE and not the PE - this is analogous to ATM and FR transport 
where you don't expect the ATM switch or FR switch to add a CRC for the 
payload.

>-       When ethernet was first designed the above issues were never 
>considered....and in particular there was no VLAN field.  We cannot now go 
>back and change this IMO.  However, the FCS does still belong to the eth 
>client and IMO it should never be discarded in some arbitrary manner by a 
>server layer.  I use the word 'arbitrary' here since I have noted 
>different behaviours specified in G.8010 which I don't think is a good 
>idea, eg for all co-cs server technologies the carriage of the eth FCS is 
>a 'must', for an ATM co-ps server layer the carriage of the FCS is 
>'optional', and for an MPLS co-ps server it currently says it can be 
>'removed'.  A client and server layer network should be independent.....so 
>having different behaviours dependent on the server layer mode and/or 
>specific technology is not a logical behaviour to me.  IMO the default 
>behaviour of the server layer should always be to carry the client layer 
>traffic unit transparently.

And in terms of bridge applications, the client layer (user data) doesn't 
have FCS (the FCS belongs to the server layer - the MAC layer) and the 
client layer FCS (if needed) is the responsibility of the application and 
not the bridge. So if you want to have a new encapsulation on the CE side 
(similar to 1483/1490 that can have FCS for client data), then that a 
separate issue but we shouldn't impose such requirement on the bridges.

Regards,
Ali

---

From: [email-masked]
Date: Wed, 26 Nov 2003 20:53:54 -0000

Hi Ali,

Ali Sajassi wrote 26 November 2003 20:10
<snip>
> where you don't expect the ATM switch or FR switch to add a 
NH=> I tend to think in terms of G.805 func arch and not boxes, ie it is the func arch (eg where layer networks start and end) that is most important, not a 'CE' or 'PE' badge.  I look at this stuff very simply:  The FCS of eth belongs to the traffic unit of the eth layer network....not any other layer network.  Where the eth client gets encapsulated (let's say in MPLS) is where the LSP trail starts (this can be any box)....and there is an LSP trail term point where they get decapsulated. (Yes I know folks also add a PW header but this is not a layer network, simply an adaptation function).  This is simply client/server encapulation and well defined in G.805.  If we carry the eth clinet over any server layer, you mentioned ATM or FR (but I could also add PDH, SDH, etc), then exactly the same applies.  If one plays about with any aspect of the client layer traffic unit (usually some form of compression), and thus suffers a loss of client layer CI transparency, there is usually some price to be paid.  So, IMO, unless there are quite compelling reasons (like the cost of BW has gone through the roof) don't touch the client layer at all.
> have FCS (the FCS belongs to the server layer - the MAC 
> layer)
NH=> This, I think, is the key issue of contention Ali (and why various people see the situation differently).  If we take the LLC/MAC split then you have a valid point.  It's also pretty similar (if you think about it) to the ATM_cell/AAL_X split.  However, I would tend to look at the LLC/MAC as 'joined at the hip' sub-layers, ie they must go together...and I don't know of any std which allows the LLC part to sent on anything without its MAC part (but please correct me if you know otherwise).  There is not the same binding IMO between the ATM_cell and the AAL_X.....I can easily imagine AAL_X being carried over some other server layer network....and in fact Yaakov S has considered this for AAL1 (TDM) over MPLS for example.

The fact folks are now proposing to send the eth frames over WAN technologies is a problem of our making, not the orgins of eth with how it viewed what would be the MAC layer.....so these aspects were never clearly diveroced or considered before AFAIK.  And which is why on balance, I still err of the side of caution with the view that the FCS should be carried as the default behaviour.

regards, Neil
<snipped to end>

---

From: [email-masked]
Date: Thu, 27 Nov 2003 17:54:25 +0100

As far as I have understood the game of Ethernet over Transport, it is not 
opportune to change the basic ethernet frame format and behaviour. In that 
sense we simply have to accept the MAC FCS as is, as well as the dropping 
of corrupted frames at the input port of a bridge or EPL.

In this environment, the FCS is related to the ETH link (G.8010) and 
allows detection of errors introduced during transport over the link. Any 
ETH link should support FCS... i.e. ETH links supported by Ethernet PHYs 
(obvious), SDH VC-n(-Xv/Xc) or OTN ODUk(-Xv) (G.7041), ATM VC (RFC2684, 
select the option to inlcude FCS) and also MPLS (to be fixed).

What is now left are errors introduced during the forwarding through and 
processing in equipment. I.e. when there is an equipment fault... 

I can imagine that equipment adds equipment specific CRC (may re-use FCS) 
or BIP to the signal and checks this (to detect possible faults) before 
preparing the frame for transport over the egressing ETH link. Such 
capability could be assumed to be a major requirement for such equipment 
in a carrier network, and equipment non-compliant to this requirement is 
not installed in such network. 
Note - Isn't this error detection capability described in 6.3.7/802.1D?

If this route is followed, we can continue with the current definition of 
ethernet (only fix EoMPLS); i.e. no need to introduce a second CRC and 
change the basic MAC frame.

Regards,
Maarten

<[email-masked]>
Sent by: [email-masked]
26-11-2003 21:53

        To:     <[email-masked]>, <[email-masked]>, <[email-masked]>
        cc:     Maarten VISSERS/DE/ALCATEL@ALCATEL
        Subject:        RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Hi Ali,

> where you don't expect the ATM switch or FR switch to add a 
NH=> I tend to think in terms of G.805 func arch and not boxes, ie it is 
the func arch (eg where layer networks start and end) that is most 
important, not a 'CE' or 'PE' badge.  I look at this stuff very simply: 
The FCS of eth belongs to the traffic unit of the eth layer network....not 
any other layer network.  Where the eth client gets encapsulated (let's 
say in MPLS) is where the LSP trail starts (this can be any box)....and 
there is an LSP trail term point where they get decapsulated. (Yes I know 
folks also add a PW header but this is not a layer network, simply an 
adaptation function).  This is simply client/server encapulation and well 
defined in G.805.  If we carry the eth clinet over any server layer, you 
mentioned ATM or FR (but I could also add PDH, SDH, etc), then exactly the 
same applies.  If one plays about with any aspect of the client layer 
traffic unit (usually some form of compression), and thus suffers a loss 
of client layer CI transparency, there is usuall!
 y some price to be paid.  So, IMO, unless there are quite compelling 
reasons (like the cost of BW has gone through the roof) don't touch the 
client layer at all.
> have FCS (the FCS belongs to the server layer - the MAC 
NH=> This, I think, is the key issue of contention Ali (and why various 
people see the situation differently).  If we take the LLC/MAC split then 
you have a valid point.  It's also pretty similar (if you think about it) 
to the ATM_cell/AAL_X split.  However, I would tend to look at the LLC/MAC 
as 'joined at the hip' sub-layers, ie they must go together...and I don't 
know of any std which allows the LLC part to sent on anything without its 
MAC part (but please correct me if you know otherwise).  There is not the 
same binding IMO between the ATM_cell and the AAL_X.....I can easily 
imagine AAL_X being carried over some other server layer network....and in 
fact Yaakov S has considered this for AAL1 (TDM) over MPLS for example.

The fact folks are now proposing to send the eth frames over WAN 
technologies is a problem of our making, not the orgins of eth with how it 
viewed what would be the MAC layer.....so these aspects were never clearly 
diveroced or considered before AFAIK.  And which is why on balance, I 
still err of the side of caution with the view that the FCS should be 
carried as the default behaviour.

regards, Neil
<snipped to end>