[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: [PWE3] last call on control and ethernet drafts
Scott,
I agree that a network operator needs a end-to-end supervision of the service.
For the pwe3 case I therefore understood the proposal to include the FCS as the original definition didn't support it.
For the 802.1ad case I have problem to understand the need for an additional FCS as I think the existing FCS can be used for the end-to-end service supervision. May be it is as misunderstanding of the Ethernet process on my side.
The Ethernet frame from the customer has a FCS. At the ingress UNI all frames with wrong FCS are dropped. So you forward only frames with correct FCS into the network. When you add now an additional FCS it is not different from the already existing FCS, both indicate good frames. 802.1ad now manipulates the frame by adding the provider tag. This is similar to what .1q bridges are already doing today. These changes have to be reflected in the FCS.
802.1q says the following:
NOTE-There are two possibilities for recreating a valid FCS. The first is to generate a new FCS by algorithmically
modifying the received FCS, based on knowledge of the FCS algorithm and the transformations that the frame has
undergone between reception and transmission. The second is to rely on the normal MAC procedures to recalculate the
FCS for the outgoing frame. The former approach may be preferable in terms of its ability to protect against increased
levels of undetected frame errors. ISO/IEC 15802-3, Annex G, discusses these possibilities in more detail. The
frame_check_sequence parameter of the Enhanced Internal Sublayer Service (7.1) is able to signal the validity, or otherwise,
of the FCS; an unspecified value in this parameter in a data request indicates to the transmitting MAC that the
received FCS is no longer valid, and the FCS must therefore be recalculated.
For a end-to-end supervision the first approach has to be used. It means that for the outgoing FCS the incoming FCS is used and it is modified according to the frame modifications. This means that errors that occur within the bridge are covered and will be detected. 802.1d Annex G provides examples on how this can be achieved.
One question to the Ethernet community: What is the usual FCS procedure for .1q bridges modification or new calculation? What would it be for .1ad bridges?
The frame now passes through the network and comes to the egress UNI or may be dropped before due to a FCS error. Both, the original and the new FCS have the same coverage as they start with a no error value at he ingress UNI and are checked at the egress UNI. So the additional FCS provides no additional information in my view, as the standard FCS also covers internal errors of a bridge.
Only in case incoming customer frames with wrong FCS are not dropped at the ingress UNI and forward into the provider network the additional FCS is useful as in this case the network coverage of both FCS would be different.
Scott you mentioned that the egress counter tells you if the service provider network corrupted the packet. This counter will not give you the whole picture as Ethernet frames could be dropped at intermediate nodes in case of wrong FCS. The egress counter tells you only the frames with wrong FCS on the last link or you have to disable drop in case of wrong FCS at the intermediate notes.
Regards
Juergen
> -----Ursprungliche Nachricht-----
> Von: Scott Kotrla [mailto:scott.kotrla@mci.com]
> Gesendet: Donnerstag, 13. November 2003 15:09
> An: m_seery@yahoo.com; 'Ali Sajassi'
> Cc: pwe3@ietf.org; stds-802-1@ieee.org
> Betreff: RE: [PWE3] last call on control and ethernet drafts
>
>
> Let me start by clarifying something that may be leading to some
> confusion. MCI is pushing for an end-to-end FCS in both
> 802.1ad and in
> Pseudowires. Think of stacked VLANs spokes running across a
> network of
> switches into a Pseudowire Core connected via a network of routers. I
> think we have agreed in PWE3 that carrying an end-to-end FCS
> should be a
> service provider option and the drafts will be modified
> accordingly. I
> have now moved on to pushing for the same option in 802.1ad. Since
> there were still discussions going on in PWE3 when I started
> posting to
> the 802.1 listserv earlier this week, I started copying 802.1
> on my PWE3
> replies since my response were valid to both groups.
>
> I completely agree that it is theoretically possible to construct
> switches that are not anymore likely to corrupt packets than
> a CRC32 is
> to not catch a corrupt packet.
>
> It is also possible to build a network that can never be misconfigured
> and that never has any problems. This argument could be used to wish
> away all OAM tools. If one builds the perfect network, a lot
> of things
> become a lot easier and a lot of tools would never be used.
>
> Being able to detect errors in switches is a requirement from MCI.
> However, MCI is not convinced that every piece of gear ever
> deployed in
> the network will always meet those requirements, even if the equipment
> providers promise that they do.
>
> Equipment has always had bugs and it will always have bugs.
> Even if the
> equipment design makes unknown packet corruption highly
> improbable, the
> reality of some implementations will be holes that permit
> unknown packet
> corruption. Convincing me that no equipment provider that claims to
> meet the requirement of unknown packet corruption could ever get a box
> into the network that doesn't meet that requirement will be
> very tough.
> There are too many variables. I completely agree with
> service provider
> rights to save 4 bytes and not turn the feature on, but I stand by my
> assertion that any service provider who understands the risks will be
> willing to sacrifice 4 bytes.
>
> Regarding hardware costs, 802.1ad interfaces are likely going
> to require
> new hardware. I am highly suspicious of the assertion that stacking 4
> bytes on ingress and doing an extra CRC check on egress on new 802.1ad
> hardware will have any significant impact on cost. I agree
> that adding
> this feature on existing hardware might be cost prohibitive in some
> cases.
>
> As far as the importance of detecting end-to-end errors versus
> diagnosing where the errors are happening, I think I have stated this
> several times already. If I don't know that my network is running
> clean, how do I troubleshoot a customer call? I have to guarantee and
> be able to demonstrate beyond a reasonable doubt that my network is
> clean, and trying to walk the customer through the internal
> workings of
> a dozen boxes is much more difficult and less convincing than showing
> them egress FCS error counters. If I know there is a
> problem, I have a
> lot of tools at my disposal, depending on the seriousness of the
> problem. First of all, I can root cause my FCS errors to figure out
> which boxes/interfaces all affected customer traffic are
> going through.
> If enough customer packets are being corrupted that the service is
> unusable, I can do intrusive monitoring and loopbacks. If service is
> not being impacted so severely, I can diagnose the problem during a
> maintenance window. If the equipment is reliable as it should be, I
> shouldn't be doing this often anyway.
>
> Thanks,
>
> Scott
>
>
> -----Original Message-----
> From: mark seery [mailto:m_seery@yahoo.com]
> Sent: Thursday, November 13, 2003 1:17 AM
> To: Ali Sajassi
> Cc: Scott Kotrla; pwe3@ietf.org; stds-802-1@ieee.org
> Subject: Re: [PWE3] last call on control and ethernet drafts
>
> Ali,
>
> Sorry to see this is testing your endurance threshold (as measured by
> double !s), and anything I am doing to contribute to that.
>
> I understand your frustration at people throwing solutions at you and
> not requirements - this is obviously an oft-expressed angst
> by engineers
>
> in many different contexts. However, I think it is natural for
> experienced operators to offer their opinions on a solution, and can
> help sometimes to flush out the issues. I do agree that to deviate to
> far from a focus on the requirements is a dangerous path to travel in
> the long-term, so good to bring it back to that, but given
> the general
> scarcity of input from carriers, a little leeway might be
> constructive.
>
> As I stated in my last email, I do see how a single FCS can
> work, based
> on the draft from andy et el. I have seen you consistently
> suggest that
> solving the problems for all modes is desired - and I agree.
> I have seen
>
> others say this is not achieveable. Unfortunately I missed
> your proposal
>
> on how it is achieveable, and the technical critique from
> others on how
> it is not - I'll look back at the april/september entrails to
> re-educate
>
> myself.
>
> While I agree that solving for all modes is best, and ultimately the
> test of whether PW is a good layer - or at the least a
> consistent layer,
>
> if people seem to be focused heavily on the EPL case, that might be
> suggestive of where their interest lay.
>
> Personally, I think stating a requirement such as "like a
> transmission
> facility" is a good starting point, but ultimately does provide
> engineers anything constructive to design towards, it would
> be nice if
> someone could turn that general requirement in to something more
> specific, then all your comments like "probability of undetectable
> errors" would come more into focus.
>
> I am not sure I agree with your observations about loopbacks.
> It is not
> clear to me that it is impossible to construct non-intrusive
> tests with
> sufficient samples. I obviously missed that explanation as well. In
> addition, there is a distinction between the process of detecting an
> error and the process of diagnosing one - which is a point
> that has been
>
> made by others. I missed that distinction in your comments.
>
> I am not sure I understand your comments about IEEE 802.1ad
> compatibility. Even though I can see how one FCS might be
> sufficient, if
>
> a PW used two, I am not sure how this creates a compatibility
> problem as
>
> I don't forsee an "existing" bridge being in the middle of a PW.
>
> I do think the issue about cost is something I would have
> preferred the
> carrier representatives to have picked up on and commented on
> - but they
>
> probably can not give an intelligent response without a meaningful
> estimate of cost difference. If their answer is its your job
> to get the
> costs in line, we aint doing it with this functionality, well then I
> suggest that should probably spark a set of offline
> discussions. And the
>
> cost discussion is obviously not just pertinent to the double
> FCS case,
> the zero FCS case clearly provides for an interesting set of
> discussions
>
> between incumbent vendors and customers (one that is beyond me how I
> personally would gain by promoting, but it is clear to me how it is a
> worthy discussion for some set of agents in the value chain to have).
>
>
>
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3