Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention
draft-ietf-pwe3-fcs-retention-04

Message to IESG Secretary for publication

-------- Original Message --------
Subject: draft-melsen-mac-forced-fwd (Informational)
Date: Mon, 20 Feb 2006 21:36:46 +0100
From: Mark Townsley
To: IETF Secretariat
CC: IESG


Secretary,

Please return this document to the RFC Editor with the following comment:

  1. The IESG has not found any conflict between this document and IETF
      work.

The IESG had serious concerns about an earlier version of this document with
respect to its affect on IPv6 and VRRP. The authors chose to make significant
efforts to correct the document based on these concerns. The latest version
(-04, published Jan 27) is now satisfactory.

Thanks,

- Mark

[Ballot discuss]
This document uses several acronyms without defining them first.  I know what most of them stand for, but I could not figure out what ICRQ and ICRP refer to...  These may be defined in one of the references, but without a specific reference when these acronyms are first used, I am not sure where to look.

[Ballot comment]
Strange location for IPR stuff (Section 1).

I will also note that this doc has a lot of NORMATIVE references
to internet-drafts. Let us hope those will also get approved soon.

IANA Comments:
As described in the IANA Considerations section, this document itself does not request any IANA Actions.  However, draft-ietf-pwe3-iana-allocation-11.txt allocated one assignment with this document as the reference.  The reference will need to be updated when this document is published as an RFC.

PROTO

-------- Original Message --------
Subject: draft-ietf-pwe3-fcs-retention-04.txt - Pub request and proto
Date: Mon, 12 Dec 2005 19:56:04 +0000
From: Stewart Bryant
To: iesg-secretary@ietf.org, Mark Townsley , Margaret Wasserman , Danny McPherson
CC: pwe3


Please publish

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fcs-retention-04.txt

Stewart

-----------------------------

Stewart Bryant is the WG Chair responsible for this WG draft.

  1.a) Have the chairs personally reviewed this version of the Internet
      Draft (ID), and in particular, do they believe this ID is ready
      to forward to the IESG for publication?

Yes

  1.b) Has the document had adequate review from both key WG members
      and key non-WG members?  Do you have any concerns about the
      depth or breadth of the reviews that have been performed?

This document has been fully reviewed by the PWE3 WG. We have
no concerns about the depth or breadth of the review.

  1.c) Do you have concerns that the document needs more review from a
      particular (broader) perspective (e.g., security, operational
      complexity, someone familiar with AAA, etc.)?

We have no concerns.

  1.d) Do you have any specific concerns/issues with this document that
      you believe the ADs and/or IESG should be aware of?  For
      example, perhaps you are uncomfortable with certain parts of the
      document, or have concerns whether there really is a need for
      it.  In any event, if your issues have been discussed in the WG
      and the WG has indicated it that it still wishes to advance the
      document, detail those concerns in the write-up.

Although we anticipate that few PWs will use this mode. The change is
small and it does increase the transparency and provides a mechanism
to prevent some types of packet corruption being passed outside the
provider network. As such it is a worthwhile extension of the PW design.

  1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

This is a very simple option so everyone understands how it works.
There is some concern as to whether the option provides a sufficient
improvement to be worthwhile deploying.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarize the areas of conflict in
      separate email to the Responsible Area Director.

No

  1.g) Have the chairs verified that the document adheres to all of the
      ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes

  1.h) Is the document split into normative and informative references?
      Are there normative references to IDs, where the IDs are not
      also ready for advancement or are otherwise in an unclear state?
      (note here that the RFC editor will not publish an RFC with
      normative references to IDs, it will delay publication until all
      such IDs are also ready for publication as RFCs.)

Yes it is correctly split into normative and non-normative references

The following references from the PWE3 WG are in their final
editorial phases within the PWE3 WG, and we expect to request
their publication soon.

  [2] Martini, L. et al, "Frame Relay Encapsulation over
      Pseudo-Wires", draft-ietf-pwe3-frame-relay-05.txt, April
      2005, 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-05.txt, May 2005, work in progress

The following is WIP in the L2TPext WG.
   
  [9] Aggarwal, R. et al, "Transport of Ethernet Frames over L2TPv3",
      draft-ietf-l2tpext-pwe3-ethernet-03.txt, April 2005, work in
      progress
 
  1.i) For Standards Track and BCP documents, the IESG approval
      announcement includes a write-up section with the following
      sections:

      *    Technical Summary

The PWE3 encapsulation specifications for Ethernet, Frame Relay,
and HDLC pseudowires Ethernet, Frame Relay, and HDLC pseudowires
require that the original Frame Check Sequence (FCS) be removed
at pseudowire ingress and regenerated at pseudowire egress.

This document defines an optinal mechanism for preserving frame
FCS and transporting it over the pseudowire.

      *    Working Group Summary

The PWE3 WG have thoroughly reviewed this design. There are mixed
opinions in the PWE3 WG on how beneficial this option is.

      *    Protocol Quality

This is a simple modification to a well known encapsulation
and the associated signalling protocol.