Hi Stewart, Comments inline.
On 2012-10-08 19:22, Stewart Bryant wrote: > Hi Magnus, > > On 08/10/2012 13:29, Magnus Westerlund wrote: >> Hi Stewart, >> >> See inline for comments >> >> On 2012-10-08 05:37, Stewart Bryant wrote: >>> Stewart Bryant has entered the following ballot position for >> No, but a tunnel know what general class of traffic it encapsulates. Is >> it IPv4 that has at least IPv4 header checksums and possibly non-zero >> transport checksums, or are they some type of other L2 frames that has >> checksums as part of their frame headers. It is this type of knowledge >> in the tunnel payload we want the tunnel designer to consider if they >> need additional checksums or not. > Sure you know if you are carrying IP or L2, but L2 mostly carries > IP anyway. However you do not actually know what the user > is going to carry over L2, and really have no right to know. You > have to treat it as opaque traffic. > > In any case, as I said we take no precautions in PWs and we do > not observe any issues carrying 'L1' or L2 over PW over MPLS > without a c/s at either the network or the tunnel layer. Are you really certain that PW doesn't have taken precautions. I took a look at RFC 4448 Ethernet over MPLS. That specification contains the following text: 4.4.4. Frame Error Processing An encapsulated Ethernet frame traversing a pseudowire may be dropped, corrupted, or delivered out-of-order. As described in [PWE3-REQ], frame loss, corruption, and out-of-order delivery are considered to be a "generalized bit error" of the pseudowire. PW frames that are corrupted will be detected at the PSN layer and dropped. At the ingress of the PW, the native Ethernet frame error processing mechanisms MUST be enabled. Therefore, if a PE device receives an Ethernet frame containing hardware-level Cyclic Redundancy Check (CRC) errors, framing errors, or a runt condition, the frame MUST be discarded on input. Note that defining this processing is part of the NSP function and is outside the scope of this document. Which I interprets that for an Ethernet PW over MPLS there will be verification of the Ethernets CRC, thus any assembly or payload errors are likely to be detected. This leaves primarily errors in the label addressing on the MPLS layer. What I lack in knowledge is to analyze how likely this is to occur and secondly what the effects are. How likely is it that a miss-labeled ethernet frame actually arrive in a context where it is either harmful to the receiver or actually ends up in some higher layer context not intended. I would guess due to the ethernet addressing an ethernet frame delivered to the wrong physical network will just be discarded due to lack of recipient in the domain it arrived in. I guess other L2 may look different but my understanding is that any PW must fulfill the basic requirements and assumptions on L1 that the carried L2 has. I think few L2 protocols are assuming an error free channel. And those who does requires PW encapsulation to meet these goals. > >> >> >>> In point 7 you suggest that an application cannot rely on packet length. >>> When PWs are used for tunneling we rely on exactly that (except in the >>> case of packets shorter than 64 octets for Ethenet padding reasons), and >>> I am not aware of any reported issues. Thus when the application is >>> tunnel encap/decap there is a body of evidence that suggests that this >>> OK. >> First of all, I would like to understand a bit more about these >> experiences from pseudowires. Which type of psuedowires are we talking >> about here. And the derived experiences over which type of lower layer >> are being used. Is this IPv6/UDP or something else like MPLS? > I am talking about PW/MPLS. Although PW/L2TP/IP exist in theory > there is very little deployment. The most common PWs seem to be > Ethernet (carrying whatever the Ethernet is carrying, IP but other > protocols as well), ATM and TDM. There is also some Frame Relay > (again with c/s removed and reconstructed), in all cases > carried directly over MPLS. The first if it is RFC4448 encapsulated then there is Ethernet layer CRCs that take care of most of the issues as discussed above. The second appear more interesting due to the lack of C/S at that layer. Question is what assumptions the thing on top of frame relay have done. If most of that traffic has checksums then a higher layer verification happens. >> I wished someone would repeat Stone and Patridge's investigation to get >> better understanding of the behaviors of IPv4 and IPv6 in this regards >> at different points in today's Internet. > > My point is that we have a practical experiment ongoing with the > huge number of PWs in deployment running over MPLS without > c/s protection at the tunnel or network layer and I have never seen > anyone raise an issue in either the PWE3 or MPLS WG. Hence > my conclusion that whilst there is a theoretical risk, the evidence > is that there are no reported issues. Well, without more knowledge about what is actually being run I am not certain that you actually are getting data that doesn't have a higher layer protection against errors. > > Note that I am only discussing the tunnel case, I make no comment > on any other type of application. To try to come to some conclusions from my perspective. What you raise as an issue that the formulation may be to strict in regards to using unchecksumed information. I think the examples you have brought up appears to use higher layer checksum to verify the usage of an checksummed field. Nor does it result in accumulation of state. Thus the impact of using such a field are limited to a potential for increased residual errors. It is not like the error rate will be significantly higher due to these assumption errors. I would assume that a packet corruption will in most cases be non reversible, thus the need for a checksum would simply be to avoid propagating the error. But, if you do solutions that uses unverified fields in larger construct the effect amount of data might be larger and thus create significant larger error impact and thus warrant additional checks at lower layer. This have to be analyzed on a protocol to protocol basis. That is the goal of the list. Please be aware of the following and consider if you are impacted by them. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: [email protected] ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
