Subject: Re: last call on control and ethernet drafts

From: Danny McPherson <[email-masked]>
Date: Mon, 10 Nov 2003 12:46:49 -0700

Andy,
I've got a couple of comments on the draft.

The draft needs to specify that "default" mode is to
remove the FCS, not that both ends of the network need
to be "manually provisioned the same".

The security considerations are more of "data integrity"
considerations.  The draft should clarify this.

If the FCS is carried where would checks be performed
(e.g., after ingress PE NSP functions & before egress PE
NSP functions, as mainline function or other?)

-danny

On Nov 10, 2003, at 7:25 AM, Andrew G. Malis wrote:

> As I have previously stated, I am also in favor of the option to 
> retain Ethernet FCS.
>
> David, Nick, and I have written a short draft that we'll submit when 
> the draft site reopens that is 100% backwards compatible with the 
> current signaling so you can implement it in only a subset of the PEs 
> and they'll interoperate.  It's so short that I've attached it here to 
> give people a chance to look at it prior to this evening's meeting.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 10 Nov 2003 15:56:00 -0500

Danny,

>to be "manually provisioned the same".

The default mode is to remove the FCS.  It says that on page 3, second 
paragraph.  Would you like it repeated elsewhere as well?

>considerations.  The draft should clarify this.

Will do.

>NSP functions, as mainline function or other?)

Keith asked the same question (see my answer to him).  I'll clarify that as 
well.

Thanks for the comments!

Cheers,
Andy

---

From: Danny McPherson <[email-masked]>
Date: Mon, 10 Nov 2003 14:26:59 -0700

> paragraph.  Would you like it repeated elsewhere as well?

I was referring to this text in the last paragraph of page 2:

     If PWE3 signaling [4] is not in use for a pseudowire, then whether
     or not the FCS is to be retained MUST be identically provisioned in
     both PEs at the pseudowire endpoints.

Although I [now] realize it was a different point you were intending
to convey with this text (i.e., both ends must be configured the same
if no signaling is employed), perhaps closing this paragraph with a
"The default behavior is to remove the FCS" would make sense, else this
might introduce confusion WRT manually provisioned PWs.

-danny

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 10 Nov 2003 09:25:43 -0500

As I have previously stated, I am also in favor of the option to retain 
Ethernet FCS.

David, Nick, and I have written a short draft that we'll submit when the 
draft site reopens that is 100% backwards compatible with the current 
signaling so you can implement it in only a subset of the PEs and they'll 
interoperate.  It's so short that I've attached it here to give people a 
chance to look at it prior to this evening's meeting.

Andy

----------

  Internet Draft                                         Andrew G. Malis
  Document: draft-malis-pwe3-fcs-retention-00.txt                Tellabs
  Expires:  May 2004                                         David Allen
                                                         Nortel Networks
                                                          Nick Del Regno
                                                                     MCI
                                                           November 2003

                     PWE3 Frame Check Sequence Retention

  Status of this Memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time. It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
          http://www.ietf.org/ietf/1id-abstracts.txt
     The list of Internet-Draft Shadow Directories can be accessed at
          http://www.ietf.org/shadow.html.

  Abstract

     This document defines a mechanism for preserving frame FCS through
     Ethernet, Frame Relay, and HDLC pseudowires.

  Table of Contents

     1. Specification of Requirements.................................2
     2. Overview......................................................2
     3. FCS Retention With MPLS-based Pseudowires.....................3
     4. FCS Retention With L2TPv3-based Pseudowires...................4
     5. Security Considerations.......................................4
     6. IANA Considerations...........................................4
     7. References....................................................4
     8. Authors' Addresses............................................5

  Malis et al                Expires May 2004                   [Page 1]

                            PWE3 FCS Retention             November 2003

  1. Specification of Requirements

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
     this document are to be interpreted as described in RFC 2119 [6].

  2. Overview

     The specifications for Ethernet, Frame Relay, HDLC, and PPP
     pseudowire encapsulation [1] [2] [3] include a mode of use where
     frames are transparently delivered across the pseudowire without
     any header or other alterations by the pseudowire ingress or egress
     Provider Edge (PE). [Note that this mode is inherent for HDLC and
     PPP Pseudowires.]

     However, these specifications all specify that the original Frame
     Check Sequence (FCS) be removed at ingress and regenerated at
     egress, which means that the frames may be subject to unintentional
     alteration during their traversal of the pseudowire from the
     ingress to the egress PE.  Thus, the pseudowire cannot be
     absolutely guaranteed to be "transparent" in nature.

     To be more precise, 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 network 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, can the packet be discarded, and
     depending on the contents of the packet, the corruption may not
     ever be detected.

     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 not an
     issue. However, as there is no such thing, it is an issue. SPs
     should have the option of saving overhead by yielding the ability
     to detect faults. Equally, SPs should have the option to sacrifice
     the overhead of carrying the original FCS end-to-end to ensure the
     ability to detect faults in the encapsulating network.

  Malis et al                Expires May 2004                   [Page 2]

                            PWE3 FCS Retention             November 2003

     This document defines such a mechanism to allow the ingress PE to
     retain the original frame FCS on ingress to the network, and
     relieves the egress PE of the task of regenerating the FCS.

     This in an OPTIONAL mechanism for pseudowire implementations.  For
     interoperability with systems that do not implement this document,
     the default behavior is that the FCS is removed at the ingress PE
     and regenerated at the egress PE, as specified in [1], [2], and
     [3].

  3. FCS Retention With MPLS-based Pseudowires

     When using the signaling procedures in [4], there is a Virtual
     Circuit FEC element parameter ID used to signal the desire to
     retain the FCS when advertising a VC label:

        Parameter   ID Length    Description
             0x??           2    FCS Retention Indicator

       Note: The next currently available parameter number is 0x0A [5].
       This parameter number will be added to [5] if the timing permits
       while it is still a draft, otherwise it will be assigned by IANA.
       This note is to be removed once the assignment has been made.

     The presence of this parameter ID in the VC FEC element indicates
     that the egress PE requests the ingress PE to retain the FCS for
     the VC label being advertised.  It does not obligate the ingress PE
     to retain the FCS; it is simply an indication that the ingress PE
     MAY retain the FCS.  The sender MUST NOT retain the FCS if this
     parameter ID is not present in the VC FEC element.

     Since unknown parameter IDs are silently ignored [4], backwards
     compatibility with systems that do not implement this document is
     provided by requiring that the FCS is retained ONLY if the FCS
     Retention Indicator has been included in the advertisements for
     both directions on a pseudowire.

     If the ingress PE recognizes the FCS Retention Indicator parameter
     ID, but does not wish to retain the FCS, it need only issue its own
     label mapping message for the opposite direction without including
     the FCS Retention Indicator.  This will prevent FCS retention in
     either direction.

  Malis et al                Expires May 2004                   [Page 3]

                            PWE3 FCS Retention             November 2003

  4. FCS Retention With L2TPv3-based Pseudowires

     This section will be added in a subsequent revision.

  5. Security Considerations

     This mechanism enhances the security of transparent Ethernet, Frame
     Relay, and HDLC pseudowires, because the original FCS, as generated
     by the Customer Edge (CE), is included in the encapsulation.  When
     the encapsulated payload passes FCS checking at the destination CE,
     it is clear that the payload was not altered in any way during its
     transmission through the network.

     Of course, nothing comes for free; this requires the additional
     overhead of carrying the original FCS (in general, either two or
     four octets per payload packet).

     This signaling was designed to be backwards compatible and
     interoperable with systems that do not implement this document.

  6. IANA Considerations

     This document requires IANA to allocate a PWE3 Virtual Circuit FEC
     element parameter ID.

  7. References

     [1]
         Martini, L. et al, "Encapsulation Methods for Transport of
         Ethernet Frames Over IP and MPLS Networks", draft-ietf-pwe3-
         ethernet-encap-04.txt, October 2003, work in progress

     [2]
         Martini, L. et al, "Frame Relay Encapsulation over Pseudo-
         Wires", draft-ietf-pwe3-frame-relay-01.txt, July 2003, work in
         progress

     [3]
         Martini, L. et al, "Encapsulation Methods for Transport of
         PPP/HDLC Frames Over IP and MPLS Networks", draft-ietf-pwe3-
         hdlc-ppp-encap-mpls-00.txt, June 2003, work in progress

     [4]
         Martini, L. et al, "Transport of Layer 2 Frames Over MPLS",
         draft-ietf-pwe3-control-protocol-04.txt, October 2003, work in
         progress

     [5]
         Martini, L. et al, "IANA Allocations for pseudo Wire Edge to
         Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-02.txt,
         October 2003, work in progress

     [6]
         Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.

  Malis et al                Expires May 2004                   [Page 4]

                            PWE3 FCS Retention             November 2003

  8. Authors' Addresses

     Andrew G. Malis
     Tellabs
     90 Rio Robles Dr.
     San Jose, CA 95134
     Email: [email-masked]

     David Allan
     Nortel Networks
     3500 Carling Ave.
     Ottawa, Ontario, CANADA
     Email: [email-masked]

     Nick Del Regno
     MCI
     400 International Parkway
     Richardson, TX 75081
     Email: [email-masked]

  Malis et al                Expires May 2004                   [Page 5]