On 09/10/2012 12:20, Magnus Westerlund wrote:
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.
This is saying that Ethernet frames may be delivered out of order
and that if we get a CRC failure in the PSN we will simple drop
the packet.
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,
At ingress only. The CRC is then discarded. There was no CRC
retention mode when RFC4448 was written.
thus any assembly or payload errors
are likely to be detected.
No, there is no assembly. RFC4448 describes Ethernet PW over MPLS
and MPLS has no fragmentation.
This leaves primarily errors in the label
addressing on the MPLS layer.
They exist, but if the payload gets corrupted in a PE or an LSR
packet buffer, it stays corrupted and gets played out with a good
CRC.
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.
Yes, there is some protection due to the Ethernet addressing, but
not all PWs have this. Frame Relay for example reconstructs the
DLCI at egress.
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.
The PWE3 WG has some pretty blunt advice to it's user community. We
explain the simplifications, and if the quality of emulation is not
good enough, then the user is advised to either design a better
emulation, or to use a real service. However so far the cost efficiencies
of the extremely simple emulations, combined with the low error
rate and relatively hard applications have meant that the simple
emulations are overwhelmingly used.
My prediction is that this will be the case for the UDP as a tunnel
class of applications.
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.
No, there is no Ethernet CRC in an RFC4448 encapsulated packet.
Please see RFC4720, which states it more clearly. Noting that
RFC4720 is hardly implemented.
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.
The applications just see the datalink as a datalink, and don't
realize they are being sent over a PW, or understand what the
PW is doing to the datalink CRC.
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.
Sure, that is what is keeping the system afloat against the error,
but that is also true of L2 and L3 protocols tunneled over UDP.
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.
No, the deployed PW/MPLS cases run without a datalink CRC.
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.
Understand that at the end of the day, I am not going to stand in the
way of the draft, what I am trying to do here is to help it reflect the
reality of existing tunnel experience and to be closer to the path that
the UDP tunnel designer's appear to be taking anyway.
- Stewart
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
