[PWE3] draft-ietf-pwe3-fcs-retention-04.txt - Pub request and proto

[Stewart Bryant <[e-mail]>]

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.



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