Subject: RE: last call on control and ethernet drafts

From: "Christopher N. \"Nick\" Del Regno " <[email-masked]>
Date: Mon, 27 Oct 2003 19:54:35 -0600

Okay, technical merit. 

Pseudowires, as currently defined, leave the payload vulnerable to
undetected errors caused by the encapsulating network. As defined for MPLS,
not only can a PW-aware device internally corrupt an encapsulated payload,
but ANY MPLS LSR in the path can corrupt the encapsulated payload. In the
event of such corruption, there is no way to detect the corruption through
the path of the pseudowire. Further, because the FCS is calculated upon
egress, any corruption will pass transparently through ALL Layer 2 switches
(Ethernet and Frame Relay) through which the packets travel. Only at the
endpoint, assuming the corrupted packet even reaches the correct endpoint,
will the packet be discarded.  

Not only does the encapsulation technique leave the payload unprotected, it
also subverts the error checking mechanisms already in place in SP and
customer networks by calculating FCS on questionable data. 

In a perfect network comprising perfect equipment, this is a non-issue.
However, as there is no such thing, it is an issue. SPs should have the
option of saving 4-bytes by yielding the ability to detect faults. Equally,
SPs should have the option to sacrifice 4 bytes to ensure the ability to
detect faults in the encapsulating network. 

Now, in fairness we need to see the technical merit in not providing the
same error detection capabilities in pseudowires that we provide for higher
layer Internet, as well as other data networking, protocols. 

Should the consensus of the WG be to proceed "as-is", then so be it.
However, let's be realistic about the amount of time required to reinitiate
the process and progress toward three new RFCs. In the interim, SPs who wish
to maintain a reasonable level of sanity in their networks by retaining the
ingress FCS will be relegated to using proprietary implementations, usually
meaning single vendor solutions. 

Nick 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Danny
McPherson
Sent: Monday, October 27, 2003 6:41 PM
To: [email-masked]
Subject: RE: [PWE3] last call on control and ethernet drafts

Folks,
I don't care if you work for an equipment manufacturer, service
provider or at a fast food drive-thru, please state your positions
based technical merit (I assure you that's all they'll be weighted
on).  Where someone has (or currently!) works is completely
irrelevant!

At this point the closest thing to consensus I've seen (yes, after
re-reviewing ALL of the April and September discussions on this
topic [again]) is that a separate draft seems to be the preferred
option.

Even that option has pitfalls, most of which have been expressed
here (in this or the previous two threads on this subject), though
it's still seems to be the most widely supported.

Please continue discussing the issue and either Stewart or I will
summarize what we believe to be consensus by the end of LC  on the
concerned WG documents.

-danny

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 28 Oct 2003 09:27:36 +0000

I have been out of town for a few days, and so have only just got
to this thread.

The FCS topic was always planned for the Minneapolis agenda, so
I propose that we (the chairs) follow Danny's plan and put together
a summary of the consensus at the end of LC, post to the list, and
the WG discuss/ratify when we meet on 10th. I will post the summary
of the outcome to the list on the 11th.

As stated below, the decision (either way) must be based on the
TECHNICAL merits of the proposal, and be based on the behavior
of the PW as a system.

Stewart